BGP Query

Hey Guys,

Been working on this BGP / Provider issue all day in the lab and what it comes down to is this. I don't know what's required to make BGP act like a service provider. Under normal conditions BGP AS 1 (the provider) will not pass routes from 1 connection to AS 2 (the client AS) so it can be used as a transit AS, AS 1 will horde all the routes to itself and share none with the clients (unless they are advertising something locally), is there a command/option to allow the client AS to use the provider as a transit AS? If there is not, how is this accomplished, separate vrf for each bgp instance?

Hope that made sense,
Thanks in advance!

Find more posts tagged with

Comments

fredrikjj

A topology diagram would help, but the most basic BGP configuration (eBGP peerings only) require no particular configuration for one AS to act as transit for another.

CiscoCerts

fredrikjj wrote: »

A topology diagram would help, but the most basic BGP configuration (eBGP peerings only) require no particular configuration for one AS to act as transit for another.

Thanks for the reply.

Here is the sample topology

Here is the config:
R1#show run | s bgp|interface
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
interface FastEthernet0/0
 no ip address
 shutdown
 duplex auto
 speed auto
interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
router bgp 2
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 192.168.1.2 remote-as 1

R2#show run | s bgp|interface
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
interface FastEthernet0/0
 ip address 192.168.2.1 255.255.255.0
 duplex auto
 speed auto
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
router bgp 2
 bgp log-neighbor-changes
 network 2.2.2.2 mask 255.255.255.255
 neighbor 192.168.2.2 remote-as 1

R3#show run | s bgp|interface
interface Loopback3
 ip address 3.3.3.3 255.255.255.255
interface FastEthernet0/0
 ip address 192.168.2.2 255.255.255.0
 duplex auto
 speed auto
interface FastEthernet0/1
 ip address 192.168.1.2 255.255.255.0
 duplex auto
 speed auto
router bgp 1
 bgp log-neighbor-changes
 network 3.3.3.3 mask 255.255.255.255
 neighbor 192.168.1.1 remote-as 2
 neighbor 192.168.2.1 remote-as 2

Relevant Output, notice how R3 does not share transit routes for AS 2, if you were to break AS 2 up into two separate AS's, then this would indeed work but when peering to the same AS twice or more as shown here, transit fails.

R1#show ip bgp
BGP table version is 23, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       0.0.0.0                  0         32768 i
*> 3.3.3.3/32       192.168.1.2              0             0 1 i

R2#show ip bgp
BGP table version is 5, 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, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.2/32       0.0.0.0                  0         32768 i
*> 3.3.3.3/32       192.168.2.2              0             0 1 i

R3#show ip bgp
BGP table version is 22, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.1.1              0             0 2 i
*> 2.2.2.2/32       192.168.2.1              0             0 2 i
*> 3.3.3.3/32       0.0.0.0                  0         32768 i

sample.png

fredrikjj

Yes, the routers in AS 2 will see their own AS number in the AS_PATH sequence and drop the updates for loop prevention purposes. The command you are looking for to fix that topology is neighbor allowAs-in

PS.
Alternatively you could use something called as override on the provider router to strip AS 2 from the AS_PATH.

CiscoCerts

fredrikjj wrote: »

Yes, the routers in AS 2 will see their own AS number in the AS_PATH sequence and drop the updates for loop prevention purposes. The command you are looking for to fix that topology is neighbor allowAs-in

PS.
Alternatively you could use something called as override on the provider router to strip AS 2 from the AS_PATH.

Thanks allowAs-in on the neighbor statement on the clients worked in this situation. I couldn't get the as-override command on the PE to take unless I put the client in a vrf, then the option showed up.

Thanks a lot you really helped fill in the gaps here... it all makes perfect sense now!

Jackace

Also something to consider is you would normally want all bgp routers in a given AS to have a full mesh ibgp (or use route reflectors) otherwise you could end up black-holing traffic. This isn't always the case however and your use case might be dictate otherwise. Just make sure you are aware of this.

As for a service provider I have setup customers both ways depending on what they wanted. The first method is to use the same AS for all their remote sites and then over-ride the AS on my side. The second method we use is to give each site a different private AS number. This method can make troubleshooting a little easier because you get a better picture of which AS routes are being learned from and you can look at those devices to troubleshoot. Either way it's not a big deal though. Some customers prefer one way and others prefer the other.