Re: asymmetric routing

Not out of the woods just yet...

what I'm seeing is if say CE1>PE1 goes down then SW1 effectively doesn't
have the same external source routes from PE in it's bgp rib reflected from
SW2 who are mutual RR clients....

**scratches head, I guess this was the corner case black holing of traffic
I was reading....where the advice was to use different cluster id's to
overcome this....but if I use different cluster-id's I
get asymmetric routing

the prefixes get denied here because of the same cluster-id

DENIED due to: reflected from the same cluster;

how to overcome this?

On 2 March 2013 03:55, marc edwards <renorider_at_gmail.com> wrote:

> Thanks for sharing :)
>
>
> On Friday, March 1, 2013, Tony Singh wrote:
>
>>
>>
>> fixed by changing to the same cluster-id on both RR's, I was reading that
>> using a different cluster-id's would avoid corner case black holing of
>> traffic hence my reason to use it.
>>
>> come in Mr McGahan
>>
>> :0)
>>
>>
>> On 2 March 2013 03:32, Tony Singh <mothafungla_at_gmail.com> wrote:
>>
>>
>>
>> Hi Marc
>>
>> Thanks yes because firewall see's half conversation it is dropping
>> traffic.
>>
>> Ok what I'm seeing on my RR is this
>>
>> SW1 clients are CE1 & SW2
>> SW2 clients are CE2 & SW1
>>
>> So in the bgp rib of both reflectors I'm seeing SW1 not seeing CE2 as a
>> valid path until the CE1>PE1 link drops
>>
>> SW2 however is seeing both CE2 (local) & CE1's addresses as bgp valid rib
>> paths to the learnt source prefixes herin lies the problem
>>
>> Is my RR design correct? I am using different cluster-id's within same
>> AS, but SW1 has it nailed on as in "I don't want to see the CE2 path as
>> valid until my CE1>PE1 link drops"
>>
>>
>> Tony
>>
>>
>> On 2 March 2013 03:24, marc edwards <renorider_at_gmail.com> wrote:
>>
>> So I have have a few thoughts on this...
>>
>> First, is it causing a problem (bandwidth congestion, added latency,
>> etc...) requiring fixing? Asymmetric routing can exist without harming
>> traffic (i.e. the Internet)
>>
>> Second, I thought about a fix. Since issue originates upstream I think
>> you will need to work with SP to possibly tag or send community valus
>> on upstream devices that can help identify where traffic is
>> originating and using these characteristics to filter.
>>
>> HTH
>>
>> Marc Edwards
>> CCIE #38259
>>
>>
>> On Fri, Mar 1, 2013 at 6:56 PM, Tony Singh <mothafungla_at_gmail.com> wrote:
>> > Hi Marc
>> >
>> > Its is one AS bro, im stumped a bit here...
>> >
>> > Say that same source gets to a subnet behind CE1 and everything works
>> fine
>> > on this inbound-to-outbound path then the same source decides to reach a
>> > subnet behind CE2 where inbound everything is ok but outbound for the
>> CE2
>> > originating subnet it prefers CE1 due to best path selection 11 lowest
>> > router-id..
>> >
>> > Now if I knew the source prefix I would create a standard ACL and route
>> map
>> > to achieve the desired goal, I'm sure I can figure this out with some
>> help
>> > :0)
>> >
>> >
>> > Tony
>> >
>> >
>> > On 2 March 2013 02:40, marc abel <marcabel_at_gmail.com> wrote:
>> >
>> >>
>> >> Is it one provider or 2? Can you do As path prepending?
>> >>
>> >>
>> >> On Fri, Mar 1, 2013 at 8:23 PM, Tony Singh <mothafungla_at_gmail.com>
>> wrote:
>> >>
>> >>> Hi Experts
>> >>>
>> >>> Just like to gauge what would you do on best practice if we have the
>> >>> following scenario
>> >>>
>> >>> PE1>CE1>FW>SW>trunk>SW>FW>CE2>PE2
>> >>>
>> >>> SW's are RR
>> >>>
>> >>> traffic inbound to particular subnets is influenced by outbound
>> policies
>> >>> on
>> >>> the MED attribute, but my problem is when routing outbound the lowest
>> >>> router-id of CE1 wins when the packet originated from CE2
>> >>>
>> >>> Now "when you do not know" what the out-to-in source prefixes will be,
>> >>> then
>> >>> what is the best design practice you would follow?
>> >>>
>> >>> BR
>> >>>
>> >>> Tony
>> >>>
>> >>>
>> >>> Blogs and organic groups at http://www.ccie.net
>> >>>
>> >>>
>> _______________________________________________________________________
>> >>> Subscription information may be found at:
>> >>> http://www.groupstudy.com/list/CCIELab.html
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >
>>
>>
>
> --
> Marc Edwards - CCIE #38259

Blogs and organic groups at http://www.ccie.net
Received on Sat Mar 02 2013 - 05:14:40 ART