Should Have Gone With Cisco

This is a continuation from Part I of the MPLS worklog

PE-CE routing with BGP

I wanted to touch a little bit more on the subject of using BGP as a PE-CE routing protocol. In most cases, you probably won’t be using BGP as the routing protocol between the CE and PE routers (in terms of site-to-site VPN usage). In some cases, your sites may need to rely on BGP for internet routing and therefore we probably want to use an IGP protocol for route sharing between our VPN sites (especially if our sites use private IPv4 addressing). Don’t forget that our CE routers can only run one instance of BGP (only 1 BGP AS per router). Unless we are using static routing for internet access, we probably don’t want to waste our only instance of BGP for routing between our PE-CE routers. Now in some cases, our provider could import all routes from its global routing table into our vrf table—from the research I’ve done, this is very bad. Adding Internet access really introduces a lot of possibilities for how we can do things. I will cover more on Internet access later. Let’s get back on track here and take a look at the diagram below.

Notice that it really hasn’t changed much from the Part I diagram. The major difference to notice is that the Customer A branch office on the right is using AS 1 (it was 3 previously). This is probably more realistic, especially since getting multiple AS numbers (public) isn’t very likely for most customers. The question is, does it cause for any concerns? Do you think the local routes from each site are going to be exchanged and therefore be in the routing table on both sides? Do you see the problem?

Yup, you guessed it. Remember that BGP attribute called “AS-Path”. That’s the loop avoidance feature for BGP—yes, it does more than that, but you know where I’m going with this. So for example, when the branch office site shares 10.0.7.204/30, the central site receives that prefix with the following AS-Path “[500 1]”. So what does it do you might ask? Well, see for yourself.

*Mar 17 03:31:41.811: BGP(0): 10.0.7.226 rcv UPDATE about 10.0.7.204/30 — DENIED due to: AS-PATH contains our own AS;

The above is the output from a “debug ip bgp updates in” on CUST-A-1. This is normal BGP behavior working at its best. Seeing your own AS number in received updates means it could cause a loop, and is dropped. If you’re wondering why we don’t just run iBGP between PE-CE, it’s because it isn’t currently supported.

I wanted to show you some small excerpts from the configs of both CUST-A-1 and PE1. Notice that it’s a pretty standard BGP configuration. Keep in mind that the other PE routers are pretty much the same configuration just different addresses.

CUST-A-1

router bgp 1
no synchronization
bgp log-neighbor-changes
network 10.0.7.192 mask 255.255.255.248
neighbor IBGP peer-group
neighbor IBGP update-source Loopback0
neighbor IBGP next-hop-self
neighbor 10.0.7.201 remote-as 1
neighbor 10.0.7.201 peer-group IBGP
neighbor 10.0.7.226 remote-as 500
neighbor 10.0.7.226 filter-list 1 out
no auto-summary

Now take a look at PE1

PE1

ip vrf CUSTOMER_A
description Routing Table for Customer A
rd 500:1
route-target export 500:1
route-target import 500:1
!
interface Serial1/0
description Connection to Cust-Edge cust-a-1
ip vrf forwarding CUSTOMER_A
ip address 10.0.7.226 255.255.255.252
!
interface Serial1/1
description MPLS Edge Connection to P1 MPLS LSR
ip unnumbered Loopback0
mpls label protocol ldp
mpls ip
!
router bgp 500
no synchronization
bgp log-neighbor-changes
neighbor 10.0.7.241 remote-as 500
neighbor 10.0.7.241 description M-BGP to PE2
neighbor 10.0.7.241 update-source Loopback0
neighbor 10.0.7.242 remote-as 500
neighbor 10.0.7.242 description M-BGP to PE3
neighbor 10.0.7.242 update-source Loopback0
neighbor 10.0.7.243 remote-as 500
neighbor 10.0.7.243 description M-BGP to PE4
neighbor 10.0.7.243 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.0.7.241 activate
neighbor 10.0.7.241 send-community both
neighbor 10.0.7.242 activate
neighbor 10.0.7.242 send-community both
neighbor 10.0.7.243 activate
neighbor 10.0.7.243 send-community both
exit-address-family
!
address-family ipv4 vrf CUSTOMER_A
redistribute connected
neighbor 10.0.7.225 remote-as 1
neighbor 10.0.7.225 description VRF Customer A EBGP
neighbor 10.0.7.225 activate
no synchronization
exit-address-family

There are a couple of ways we can configure BGP to get it working. The first way to do so is what’s called “as-override”. Basically what this does is now when the branch office sends its prefix to its adjacent PE router. The PE router replaces the originating AS of 1 with its own (500) before sending to the central site. So when it gets to the CUST-A-1 router, it looks like this [500 500]. Take a look at the debug output now.

*Mar 17 05:39:47.319: BGP(0): 10.0.7.226 rcvd UPDATE w/ attr: nexthop 10.0.7.226, origin i, path 500 500
*Mar 17 05:39:47.323: BGP(0): 10.0.7.226 rcvd 10.0.7.204/30

Now isn’t that the prettiest thing you ever seen? This was easily done by adding the “neighbor 10.0.7.225 as-override” command on PE1 (it should be done similarly on PE3 and PE4). Note that this is configured under the CUSTOMER_A address family on the PE routers.

As a side note, you should probably implement site-of-origin (It’s an extended community that gets attached to routes) on the PE interfaces connecting to customers (especially with back-door links between sites or multi-homed!). This will prevent suboptimal routing or loops from occurring. With SOO, routes will not get sent back out an interface that’s configured with the same SOO value. Check out this link for more info.

The other way to achieve similar results as “as-override” is using “allowas-in”. Instead, this does not change the AS-Path, but ignores the fact that it sees its own AS in the update. From what I’ve seen, this is typically used with hub-and-spoke MPLS VPNs (site-to-site connectivity typically flows through central site/hub vs. directly between sites– for security reasons).

Well, now it’s time to start messing with other PE-CE routing protocols besides BGP. Stay tuned…

This entry was posted on Friday, April 20th, 2007 at 9:17 am and is filed under Cisco, Routing&Switching. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.