Re: BGP and AS loop prevention

From: Nate Lee <natetlee_at_gmail.com>
Date: Tue, 20 Oct 2009 23:18:47 -0500

Aaahhhhh, you nailed it Alexei!

I didn't have NLRI for the subnet between the R2 <-> R4 and R3 <-> R5 so
they were in the BGP table but not the routing table. After I fixed that
problem they worked as expected. Thanks for the hint, I think I stared at
it too long and missed the most obvious solution :)

Nate

On Tue, Oct 20, 2009 at 11:07 PM, Alexei Monastyrnyi <alexeim73_at_gmail.com>wrote:

> Have a look at your R2 (and R3 for route 4.0.0.0) router(s); as per your
> output, 5.0.0.0 is not considered as best...
>
> R2(config)#*do sho ip bgp*
> BGP table version is 4, local router ID is 2.2.2.2
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
> r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
> Network Next Hop Metric LocPrf Weight Path
> *> 4.0.0.0 10.1.24.4 0 0 100 i
> * i5.0.0.0 10.1.35.5 0 100 0 100 i
> A hint for you?
>
> A.
> 2009/10/21 Nate Lee <natetlee_at_gmail.com>
>
>> I agree, I think it should be working, I can't for the life of me figure
>> out
>> why the AS 200 routers won't send the prefixes that originated in one AS
>> 100
>> to the other AS 100. If I originate routes inside AS 200, they pass to
>> both
>> AS 100 routers fine.
>>
>> Do I chalk this up to a bug? I am running 3725s in Dynamips on 12.4(25b).
>> I hate to leave something unsettled like this, but it appears that it
>> should
>> work, its not a very complex topology so there isn't really anything else
>> to
>> rule out. Its just strange that it is filtering on the outbound as though
>> it is making the assumption that the remote AS doesn't want it. I will
>> have
>> to try this with a different ver of the code to see if anything changes.
>>
>>
>> On Tue, Oct 20, 2009 at 9:51 PM, Alexei Monastyrnyi <alexeim73_at_gmail.com
>> >wrote:
>>
>> > Nate,
>> > this works perfectly fine for me.
>> >
>> > R1 <> R2 <> R3 <> R4
>> >
>> > R1-4 are in AS 1
>> > R2-3 in AS 23
>> >
>> > 1.1.1.1 and 4.4.4.4 are Lo0 IP addressess off R1 and R4 respectively.
>> >
>> > All routers run the same IOS on 7200 platform (Dynamips)
>> >
>> > R4#sh ver | in IOS
>> > Cisco IOS Software, 7200 Software (C7200-K91P-M), Version 12.2(25)S13,
>> > RELEASE SOFTWARE (fc1)
>> >
>> > ====
>> >
>> > R1#sh run | b bgp
>> > router bgp 1
>> > bgp router-id 1.1.1.1
>> > no bgp default ipv4-unicast
>> > bgp log-neighbor-changes
>> > neighbor 12.12.12.2 remote-as 23
>> > !
>> > address-family ipv4
>> > neighbor 12.12.12.2 activate
>> > neighbor 12.12.12.2 allowas-in
>> > no auto-summary
>> > no synchronization
>> > network 1.1.1.1 mask 255.255.255.255
>> > exit-address-family
>> >
>> > R1#sh ip bgp | b Net
>> > Network Next Hop Metric LocPrf Weight Path
>> > *> 1.1.1.1/32 0.0.0.0 0 32768 i
>> > *> 4.4.4.4/32 12.12.12.2 0 23 1 i
>> > ===
>> >
>> > R2#sh run | b bgp
>> > router bgp 23
>> > bgp router-id 2.2.2.2
>> > no bgp default ipv4-unicast
>> > bgp log-neighbor-changes
>> > neighbor 3.3.3.3 remote-as 23
>> > neighbor 3.3.3.3 update-source Loopback0
>> > neighbor 12.12.12.1 remote-as 1
>> > !
>> > address-family ipv4
>> > neighbor 3.3.3.3 activate
>> > neighbor 3.3.3.3 next-hop-self
>> > neighbor 12.12.12.1 activate
>> > no auto-summary
>> > no synchronization
>> > exit-address-family
>> >
>> > ===
>> >
>> > R3#sh run | beg bgp
>> > router bgp 23
>> > bgp router-id 3.3.3.3
>> > no bgp default ipv4-unicast
>> > bgp log-neighbor-changes
>> > neighbor 2.2.2.2 remote-as 23
>> > neighbor 2.2.2.2 update-source Loopback0
>> > neighbor 34.34.34.4 remote-as 1
>> > !
>> > address-family ipv4
>> > neighbor 2.2.2.2 activate
>> > neighbor 2.2.2.2 next-hop-self
>> > neighbor 34.34.34.4 activate
>> > no auto-summary
>> > no synchronization
>> > exit-address-family
>> >
>> > ===
>> >
>> > router bgp 1
>> > bgp router-id 4.4.4.4
>> > no bgp default ipv4-unicast
>> > bgp log-neighbor-changes
>> > neighbor 34.34.34.3 remote-as 23
>> > !
>> > address-family ipv4
>> > neighbor 34.34.34.3 activate
>> > neighbor 34.34.34.3 allowas-in
>> > no auto-summary
>> > no synchronization
>> > network 4.4.4.4 mask 255.255.255.255
>> > exit-address-family
>> >
>> > R4#sh ip bgp | b Net
>> > Network Next Hop Metric LocPrf Weight Path
>> > *> 1.1.1.1/32 34.34.34.3 0 23 1 i
>> > *> 4.4.4.4/32 0.0.0.0 0 32768 i
>> >
>> > ===
>> >
>> > HTH
>> > A.
>> > 2009/10/21 Nate Lee <natetlee_at_gmail.com>
>> >
>> > Thanks everybody, I do have the allowas-in command configured on the
>> >> routers
>> >> residing in AS 100 on both sides, from what the show ip bgp neighbor
>> >> x.x.x.x
>> >> advertised-routes is telling me though, the eBGP peer that resides in
>> AS
>> >> 200
>> >> is not even trying to send the route from the other side of my
>> >> discontiguous
>> >> AS 100. It will send any routes that originate in AS 200, but not from
>> >> the
>> >> other AS 100.
>> >>
>> >> As a quick snapshot, it is setup as such:
>> >>
>> >> R4 <> R2 <> R1 <> R3 <> R5
>> >>
>> >> With R4 and R5 being in AS 100 and R1, R2 and R3 fully meshed iBGP
>> peers
>> >> in
>> >> AS 200.
>> >>
>> >> The 4.0.0.0 is being originated from R4 and 5.0.0.0 is being originated
>> >> from
>> >> R5, both routes make it to all routers in AS 200 but neither makes it
>> to
>> >> the
>> >> far side AS 100 router.
>> >>
>> >> From R2:
>> >>
>> >> R2(config)#*do sho ip bgp*
>> >> BGP table version is 4, local router ID is 2.2.2.2
>> >> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> >> internal,
>> >> r RIB-failure, S Stale
>> >> Origin codes: i - IGP, e - EGP, ? - incomplete
>> >>
>> >> Network Next Hop Metric LocPrf Weight Path
>> >> *> 4.0.0.0 10.1.24.4 0 0 100 i
>> >> * i5.0.0.0 10.1.35.5 0 100 0 100 i
>> >>
>> >> R2(config)#*do sho ip bgp neigh 10.1.24.4 advertised-routes*
>> >>
>> >> Total number of prefixes 0
>> >>
>> >> R2(config)#*do sh run | s bgp 200*
>> >> router bgp 200
>> >> no synchronization
>> >> bgp log-neighbor-changes
>> >> neighbor 10.1.24.4 remote-as 100
>> >> neighbor 10.1.123.1 remote-as 200
>> >> neighbor 10.1.123.3 remote-as 200
>> >> no auto-summary
>> >> R2(config)#
>> >>
>> >> R4#*sh run | s bgp 100*
>> >> router bgp 100
>> >> no synchronization
>> >> bgp log-neighbor-changes
>> >> network 4.0.0.0
>> >> neighbor 10.1.24.2 remote-as 200
>> >> neighbor 10.1.24.2 allowas-in
>> >> no auto-summary
>> >>
>> >> And on R4, you can see it never received any prefixes:
>> >>
>> >> R4#*show ip bgp neighbors 10.1.24.2 | in Prefixes|Sent*
>> >> Sent Rcvd
>> >> Sent Rcvd
>> >> Prefixes Current: 1 0
>> >> Prefixes Total: 1 0
>> >>
>> >> There is no filtering going on throughout the topology, the only
>> >> non-standard thing is the discontiguous AS.
>> >>
>> >>
>> >> On Tue, Oct 20, 2009 at 8:24 AM, Victor Cappuccio <
>> vcappuccio_at_gmail.com
>> >> >wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > Like Andrew said you can use allowas-in to prevent this from
>> >> happening:
>> >> > to prevent this happening: *Mar 1 00:05:34.851: BGP(0): 10.1.12.2
>> rcv
>> >> > UPDATE about 3.3.3.3/32 -- DENIED due to: AS-PATH contains our own
>> AS;
>> >> > the thing here is that the other routers will have back the route
>> from
>> >> the
>> >> > next hop AS, now if allowed to use VRF to solve this issue, using the
>> >> > as-overrride feature
>> >> > http://anetworkerblog.com/2008/05/11/neighbor-ce-as-override/
>> >> > making Narbik Happy by using a 007 stuff here :-)
>> >> >
>> >> >
>> >> > R2(config-router)#do show run | b router bgp
>> >> > router bgp 200
>> >> > bgp log-neighbor-changes
>> >> > !
>> >> > address-family ipv4
>> >> > no auto-summary
>> >> > no synchronization
>> >> > exit-address-family
>> >> > !
>> >> > address-family ipv4 vrf X
>> >> > neighbor 10.1.12.1 remote-as 100
>> >> > neighbor 10.1.12.1 activate
>> >> > neighbor 10.1.12.1 as-override
>> >> > neighbor 10.1.23.3 remote-as 100
>> >> > neighbor 10.1.23.3 activate
>> >> > neighbor 10.1.23.3 as-override
>> >> > no synchronization
>> >> > exit-address-family
>> >> > !
>> >> > R2(config-router)#do show ip bgp vpnv4 all
>> >> > BGP table version is 7, local router ID is 10.1.23.2
>> >> > Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> >> > internal,
>> >> > r RIB-failure, S Stale
>> >> > Origin codes: i - IGP, e - EGP, ? - incomplete
>> >> > Network Next Hop Metric LocPrf Weight Path
>> >> > Route Distinguisher: 1:1 (default for vrf X)
>> >> > *> 1.1.1.1/32 10.1.12.1 0 0 100 i
>> >> > *> 3.3.3.3/32 10.1.23.3 0 0 100 i
>> >> > R2(config-router)#do show ip bgp vpnv4 all neigh 10.1.23.3 ad
>> >> > BGP table version is 7, local router ID is 10.1.23.2
>> >> > Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> >> > internal,
>> >> > r RIB-failure, S Stale
>> >> > Origin codes: i - IGP, e - EGP, ? - incomplete
>> >> > Network Next Hop Metric LocPrf Weight Path
>> >> > Route Distinguisher: 1:1 (default for vrf X)
>> >> > *> 1.1.1.1/32 10.1.12.1 0 0 100 i
>> >> > Total number of prefixes 1
>> >> > R2(config-router)#do show ip bgp vpnv4 all neigh 10.1.12.1 ad
>> >> > BGP table version is 7, local router ID is 10.1.23.2
>> >> > Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> >> > internal,
>> >> > r RIB-failure, S Stale
>> >> > Origin codes: i - IGP, e - EGP, ? - incomplete
>> >> > Network Next Hop Metric LocPrf Weight Path
>> >> > Route Distinguisher: 1:1 (default for vrf X)
>> >> > *> 3.3.3.3/32 10.1.23.3 0 0 100 i
>> >> > Total number of prefixes 1
>> >> > and
>> >> > R3#show ip bgp
>> >> > BGP table version is 5, local router ID is 10.1.12.1
>> >> > Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> >> > internal,
>> >> > r RIB-failure, S Stale
>> >> > Origin codes: i - IGP, e - EGP, ? - incomplete
>> >> > Network Next Hop Metric LocPrf Weight Path
>> >> > *> 1.1.1.1/32 10.1.23.2 0 200 200
>> i
>> >> > *> 3.3.3.3/32 0.0.0.0 0 32768 i
>> >> >
>> >> > Just my 2 cents!
>> >> > Victor.-
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Oct 20, 2009 at 6:35 AM, ALL From_NJ <all.from.nj_at_gmail.com
>> >> >wrote:
>> >> >
>> >> >> I would re-check your setup.
>> >> >>
>> >> >> You are right, the allow-as will simply allow in the local AS x
>> number
>> >> of
>> >> >> times in the path. This is done on the receiving end.
>> >> >>
>> >> >> If you changed your set up some, and one side has the AS 101, is the
>> >> >> problem
>> >> >> present? I might suggest to try this and make sure all BGP is cool
>> >> first.
>> >> >>
>> >> >> Also, you can prepend an AS on advertisement, so you can leave the
>> one
>> >> >> side
>> >> >> with AS 101 as is and simply send out a route with AS 100 in the
>> path.
>> >> >> The
>> >> >> AS 100 router should not accept it. This is another way to test the
>> >> >> allowed-as command.
>> >> >>
>> >> >> Create a new loopback on AS 101 and prepend AS 100 in it.
>> >> >>
>> >> >> HTH,
>> >> >>
>> >> >> Andrew Lee Lissitz
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Oct 19, 2009 at 11:12 PM, Nate Lee <natetlee_at_gmail.com>
>> wrote:
>> >> >>
>> >> >> > I have a scenario labbed up where I have an discontiguous BGP AS
>> >> split
>> >> >> by
>> >> >> > another AS, something like this: (AS100) <> (AS 200) <> (AS 100).
>> >> >> >
>> >> >> > I am trying to get the prefixes on the AS 100 routers to show up
>> in
>> >> each
>> >> >> > others BGP tables. I have implemented the neighbor x.x.x.x
>> >> allowas-in
>> >> >> > command on the AS 100 routers on their neighbor statements facing
>> the
>> >> AS
>> >> >> > 200
>> >> >> > routers but it does not seem to work. When I do a SHOW IP BGP
>> NEIGH
>> >> >> > x.x.x.x
>> >> >> > ADVERTISED-ROUTES on the AS 200 routers, I see that the AS 200
>> router
>> >> >> will
>> >> >> > not send the route that originated in the far side AS 100.
>> >> >> >
>> >> >> > Is there some sort of configuration needed on the AS 200 routers
>> to
>> >> >> allow
>> >> >> > them to send a route with an AS PATH that contains the AS they are
>> >> >> sending
>> >> >> > into? I was under the impression that they do not perform an
>> >> outgoing
>> >> >> AS
>> >> >> > PATH check.
>> >> >> >
>> >> >> > Thanks!
>> >> >> >
>> >> >> > Nate
>> >> >> >
>> >> >> >
>> >> >> > Blogs and organic groups at http://www.ccie.net
>> >> >> >
>> >> >> >
>> >> _______________________________________________________________________
>> >> >> > Subscription information may be found at:
>> >> >> > http://www.groupstudy.com/list/CCIELab.html
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Andrew Lee Lissitz
>> >> >> all.from.nj_at_gmail.com
>> >> >>
>> >> >>
>> >> >> Blogs and organic groups at http://www.ccie.net
>> >> >>
>> >> >>
>> _______________________________________________________________________
>> >> >> Subscription information may be found at:
>> >> >> http://www.groupstudy.com/list/CCIELab.html
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Victor Cappuccio
>> >> > CCIE R/S# 20657
>> >> > CCSI# 30452
>> >> > www.anetworkerblog.com
>> >> > www.linkedin.com/in/vcappuccio
>> >>
>> >>
>> >> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Oct 20 2009 - 23:18:47 ART

This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:51:00 ART