[c-nsp] IOS XR as-path-loopcheck and as-override

James Bensley jwbensley at gmail.com
Tue Oct 28 16:13:44 EDT 2014


On 28 October 2014 12:39, Vitkovský Adam <adam.vitkovsky at swan.sk> wrote:
> Hi James,
>
>> I can't get the ASR9K to send the route from either eBGP neighbour in AS 65001
>> to the other.
>
> May I know your reasoning behind this nonstandard setup please?
> As the 9K1s should know the routes from each other via the intra-AS paths.


Hi Adam,

Just imagine two CPEs both in AS 65001 with MPLS Opt B Peerings to PE
in AS 55555. That could be one use for the configuration I have
provided.


> From the top of my head I can't think of a reason why it should not work.
> So the Ak9 in remote AS is advertising the routes over Opt.B to AS65001 but ASR9001s are dropping them please?
> Or the Ak9 in remote AS is not even attempting to advertise the routes back to AS65001 please?

192.168.1.2 in AS 65001 advertises 10.0.0.3/32 to ASR9K in AS 55555.
192.168.1.6 in AS 65001 advertises 10.0.0.2/32 to ASR9K in AS 55555.
The ASR9K PE in AS 55555 also has a loopback with 10.0.0.1/32
configured within the same VRF.

In the output I provided you can see that ASR9K has all three prefix
present in the VRF. The problem is that 192.168.1.6 has 10.0.0.2 and
10.0.0.1 inside the VRF. 192.168.1.2 has 10.0.0.3 and 10.0.0.1 inside
the VRF.

Neither of the AS 65001 devices receive the /32 route from the other.
The ASR9K that sits in the middle is not advertising between the eBGP
CPEs.


> The quickest way to figure things out is to use debug.
> debug bgp update vpnv4 u in (rpl)
> or
> debug bgp update vpnv4 u out (rpl)


Debug was next on the list, I'll see what I can find, I ran out of lab
time today.

Cheers,
James.



More information about the cisco-nsp mailing list