[mini] Embarassing BGP as-override misunderstanding

It can be hard to post on the Internet about dramatically misunderstanding a technology. 

In my defense, I've never worked for an MPLS provider, so I've never used as-override outside of a lab - actually I'm not sure I've ever used it in a lab before tonight, either.

For those unfamiliar with the basic idea, as-override is used in MP-BGP/VRF/MPLS scenarios where the customer wants to re-use an AS number on several sites.  Since the CE routers see the traffic from the PE routers as eBGP, they see their own AS number in the path and reject the update from the PE.  as-override is the PE mechanism to overcome this problem.

Let's take a four-router scenario - two CE routers and two PE.

It might look something like this:

CE1 (AS 100) -> PE1 (AS 250) -> PE2 (AS 250) -> CE2 (AS 100)

Clearly, when PE2 advertises CE1's routes to CE2, CE2 should reject them.

Fixing this on the CE side is very easy; you can change the AS number or use allowas-in to allow the CE to ignore the fact that its own AS number is present while receiving BGP updates.

As a network consultant I regularly deal with MPLS site activations, and twice now I've had the carrier offer to use as-override to fix the problem above, and I've declined, one time opting to change the AS number on the CE, another time I used allowas-in. I'd gotten the idea that, given that the carrier technician was signed into the PE connected to my CE, that that's the only place where the as-override would go.  Boy was I wrong.

I spent about 90 minutes this evening trying to get as-override working in the scenario described above.  CE1 would send AS 100 to PE1.  PE1 was configured with as-override facing CE1, and what I expected to have happen was PE1 strip out AS 100 on its way to PE2.  Incorrect! 

I'd repeatedly pull up PE2's BGP table:

PE2#sh ip bgp vpnv4 vrf CCIE | s 1.1.1.1
*>i1.1.1.1/32       192.168.23.2             0    100      0 100 I

BGP output doesn't paste the best into a non-monospaced document, but in short, it shows the prefix is still learned from AS 100 still (the other "100" adjacent to that is the local preference).  I sat there scratching my head, wondering how CE2 was going to be able to learn this (quick answer - it can't).

It turns out as-override is not an ingress setting at all.  It's an egress setting.  All it does is tell the PE that as-override is configured on that when it's passing routes to a CE, to do a find-and-replace of the CE's AS number and replace it with the local PE's AS number.

In other words, in our scenario:

CE1 (AS 100) -> PE1 (AS 250) -> PE2 (AS 250) -> CE2 (AS 100)

If I were to set as-override on PE1, that would enable CE1 to receive CE2's routes - not vice-versa.

CE1(config)#do sh ip bgp | i 2.2.2.2
*> 2.2.2.2/32       192.168.12.2                           0 250 250 I

We see that CE1 sees 2.2.2.2 (CE2's loopback) as going through AS 250 twice, instead of AS 250 followed by AS 100.

Thought this might help others out there stuck on a similar misunderstanding.

Cheers,

Jeff