Re: BGP SOO

From: Adrian Brayton <abrayton_at_gmail.com>
Date: Fri, 28 May 2010 11:11:34 -0400

Do you have multiple route-reflectors? Why does only PE2 have a cluster list?
Do you have both neighbors set up as route-refector-clients?

You also need to add neighbor x.x.x.x next-hop-self on the PE routers?

On May 28, 2010, at 11:08 AM, Muzammil Malick wrote:

> Yes, as described in my previous email:
>
> CE1 - - PE1 - - RR - - PE2 - - CE2
> AS78 - AS1 - - AS1 - - AS1 - AS78
>
> I believe what Im seeing is that PE1 is rejecting the update from the RR,
the reason is ORIGINATOR Loop
> but this doesn't make sense to me. Why would PE1 be receiving a route with
the next hop as itself?
>
> On 28 May 2010 16:01, Adrian Brayton <abrayton_at_gmail.com> wrote:
> Are you running a set-up that uses a route-reflector?
>
> I see this Cluster list: 150.1.4.4 on PE2
>
>
> On May 28, 2010, at 9:35 AM, Muzammil Malick wrote:
>
>> I realised that I must apply SOO between the CE's aswell to fix the loop
there but I am trying to figure out why
>> PE1 never accepts update from PE1 regarding CE2's loopback with SOO of
100:2?
>>
>> On 28 May 2010 13:39, Adrian Brayton <abrayton_at_gmail.com> wrote:
>> What I am thinking is that you applied the "soo" but now you need to create
an extcommunity-list and then deny the routes from coming back into the core.
>>
>> #ip extcommunity-list 10 permit soo 100:1
>> #route-map GS deny 10
>> match extcommunity 10
>> #route-map GS permit 20
>>
>> Then apply that to you CE neighbors.
>>
>> I think that will fix the loop!
>>
>> On May 28, 2010, at 12:36 AM, Muzammil Malick wrote:
>>
>>> Hi
>>>
>>> Config is as follows om both PE's
>>>
>>> Ignore the previous configs because I wrote them manually because I was
not at my simulator
>>>
>>> Topology is
>>>
>>> CE1 - - PE1 - - RR - - PE2 - - CE2
>>> AS78 - AS1 - - AS1 - - AS1 - AS78
>>>
>>> CE1 and CE2 have a backdoor link running iBGP
>>>
>>> PE1 Config is as follows:
>>>
>>> router bgp 1
>>> no bgp default ipv4-unicast
>>> bgp log-neighbor-changes
>>> neighbor 150.1.4.4 remote-as 1
>>> neighbor 150.1.4.4 update-source Loopback0
>>> !
>>> address-family vpnv4
>>> neighbor 150.1.4.4 activate
>>> neighbor 150.1.4.4 send-community both
>>> exit-address-family
>>> !
>>> address-family ipv4 vrf VPN_A
>>> neighbor 155.1.67.7 remote-as 78
>>> neighbor 155.1.67.7 activate
>>> neighbor 155.1.67.7 as-override
>>> neighbor 155.1.67.7 soo 100:1
>>> no synchronization
>>> exit-address-family
>>>
>>> PE2 Config is as follows
>>>
>>> router bgp 1
>>> no bgp default ipv4-unicast
>>> bgp log-neighbor-changes
>>> neighbor 150.1.4.4 remote-as 1
>>> neighbor 150.1.4.4 update-source Loopback0
>>> !
>>> address-family vpnv4
>>> neighbor 150.1.4.4 activate
>>> neighbor 150.1.4.4 send-community both
>>> exit-address-family
>>> !
>>> address-family ipv4 vrf VPN_A
>>> neighbor 155.1.58.8 remote-as 78
>>> neighbor 155.1.58.8 activate
>>> neighbor 155.1.58.8 as-override
>>> neighbor 155.1.58.8 soo 100:2
>>> no synchronization
>>> exit-address-family
>>>
>>> CE1 Loopback 150.1.7.7
>>> CE2 Loopback 150.1.8.8
>>>
>>> The CE loopbacks are advertised into BGP and this is what I see on the
PE's for the remote loopbacks
>>>
>>> PE1
>>>
>>> sh ip bgp vpnv4 vrf VPN_A 150.1.8.0
>>> BGP routing table entry for 100:1:150.1.8.0/24, version 14
>>> Paths: (1 available, best #1, table VPN_A)
>>> Advertised to update-groups:
>>> 2
>>> 78
>>> 155.1.67.7 from 155.1.67.7 (172.16.7.7)
>>> Origin IGP, localpref 100, valid, external, best
>>> Extended Community: SoO:100:1 RT:100:1
>>> mpls labels in/out 24/nolabel
>>>
>>> PE2
>>>
>>> sh ip bgp vpnv4 vrf VPN_A 150.1.7.0
>>> BGP routing table entry for 100:1:150.1.7.0/24, version 3
>>> Paths: (2 available, best #2, table VPN_A)
>>> Advertised to update-groups:
>>> 2
>>> 78
>>> 150.1.6.6 (metric 66) from 150.1.4.4 (150.1.4.4)
>>> Origin IGP, metric 0, localpref 100, valid, internal
>>> Extended Community: SoO:100:1 RT:100:1
>>> Originator: 150.1.6.6, Cluster list: 150.1.4.4
>>> mpls labels in/out 21/20
>>> 78
>>> 155.1.58.8 from 155.1.58.8 (172.16.8.8)
>>> Origin IGP, localpref 100, valid, external, best
>>> Extended Community: SoO:100:2 RT:100:1
>>> mpls labels in/out 21/nolabel
>>>
>>> I find it really strange that PE1 is only receiving one update from its
local CE whereas PE2 receives 2 updates, one from remote PE and one from local
CE as I would expect.
>>>
>>> On 28 May 2010 00:17, Adrian Brayton <abrayton_at_gmail.com> wrote:
>>> What does your vpnv4 information look like on the PE routers? Can you send
there configuration?
>>>
>>> Sent from my iPad
>>>
>>> On May 27, 2010, at 6:36 PM, Muzammil Malick <malickmuz_at_gmail.com> wrote:
>>>
>>> > Hi All
>>> >
>>> > I have an issue when configuring BGP SOO. My topology is as follows
>>> >
>>> > CE1 - - PE1 - - RR - - PE2 - - CE2
>>> > AS1 - - AS2 - - AS2 - - AS2 - - AS1
>>> >
>>> > The CEs have a backdoor link via iBGP
>>> >
>>> > My config for the PE's is as follows
>>> >
>>> > PE1
>>> >
>>> > address-family ipv4 vrf VRF_A
>>> > neighbor 150.0.0.1 remote-as 1
>>> > neighbor 150.0.0.1 activate
>>> > neighbor 150.0.0.1 as-override
>>> > neighbor 150.0.0.1 soo 100:1
>>> > no synchronization
>>> > exit-address-family
>>> >
>>> > PE2
>>> >
>>> > address-family ipv4 vrf VRF_A
>>> > neighbor 160.0.0.1 remote-as 1
>>> > neighbor 160.0.0.1 activate
>>> > neighbor 160.0.0.1 as-override
>>> > neighbor 160.0.0.1 soo 100:2
>>> > no synchronization
>>> > exit-address-family
>>> >
>>> > I was under the impression that because the SOO values are different
that
>>> > the routes will be sent to the CEs. However my PEs are not advertising
>>> > remote CE routes to local CE
>>> > and I can see clearly from "show ip bgp neighbor command" that there is
an
>>> > SOO loop on the PEs.
>>> > Do I have this wrong?
>>> >
>>> > Thanks
>>> >
>>> >
>>> > Blogs and organic groups at http://www.ccie.net
>>> >
>>> > _______________________________________________________________________
>>> > Subscription information may be found at:
>>> > http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri May 28 2010 - 11:11:34 ART

This archive was generated by hypermail 2.2.0 : Tue Jun 01 2010 - 07:09:54 ART