[c-nsp] IOS XR as-path-loopcheck and as-override
Ivan Madolev
ivan_madolev at yahoo.com
Tue Oct 28 10:17:20 EDT 2014
Hi James,
Just some ideas here:
In MPLS Option B and ASBR peering we exchange bgp vpnv4 labels to
create LSP all the way .So we need to disable the bgp label filtering on ASBRs -On
XR : router bgp xxxx-->add-family vpnv4 uni--retain route-target all. But i
believe that’s not the case here as you configured the vrf on the XR. Another thing
with XR and ASBR peering is that in IOS under the interface connected to the
peer on the other AS mpls bgp forwarding is added automatically as there is /32
entry on CEF .Thats not the case in XR. So for the labels to be exchanged b/n
the ASBR we need to manually add /32
entry for the interface connected to the ASBR peer from the other AS!!:
router static-->add-family ipv4 uni-->20.0.1.1/32 int gi0/0/0/0.1/for
example/.I came across the issue .Hope this helps.
Ivan
On Tuesday, October 28, 2014 1:45 PM, 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.
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?
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)
adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> James Bensley
> Sent: Tuesday, October 28, 2014 11:32 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] IOS XR as-path-loopcheck and as-override
>
> Hi All,
>
> I can't seem to get these features to work on my lab ASR9K1 running 4.3.4. I
> have two eBGP neighbours in AS 65001 both advertising a /32 loopback to the
> ASR9K (MPLS Opt B peerings). As per the output below the ASR9K receives the
> /32 route from each eBGP neighbour.
>
> I can't get the ASR9K to send the route from either eBGP neighbour in AS 65001
> to the other.
>
> I have added "as-path-loopcheck out disable" under both address-families
> under BGP and under the test VRF "vrf". I have also configured "as-override" on
> one of the neighbours (192.168.1.6) in both address-families.
>
> I understand how both of those features work, I'm not sure whythough despite
> enabling them everywhere out of desperation I still don't advertise the /32
> route from 192.168.1.2 to 192.168.1.6 in the test VRF.
>
> RP/0/RSP0/CPU0:ASR9001#show route vrf vrf1
>
> L 10.0.0.1/32 is directly connected, 20:25:10, Loopback1
> B 10.0.0.2/32 [20/0] via 192.168.1.6 (nexthop in vrf default), 00:08:53
> B 10.0.0.3/32 [20/0] via 192.168.1.2 (nexthop in vrf default), 17:03:24
>
> RP/0/RSP0/CPU0:ASR9001#show bgp vpnv4 unicast neighbors 192.168.1.6
> advertised-routes
>
> Network Next Hop From AS Path
> Route Distinguisher: 55555:1
> 10.0.0.1/32 192.168.1.5 Local ?
>
> Processed 1 prefixes, 1 paths
>
> ASR9K:
>
> router bgp 55555
> address-family ipv4 unicast
> as-path-loopcheck out disable
> allocate-label all
> !
> address-family vpnv4 unicast
> as-path-loopcheck out disable
> !
> neighbor 192.168.1.2
> remote-as 65001
> address-family ipv4 labeled-unicast
> route-policy PASS in
> route-policy PASS out
> send-extended-community-ebgp
> next-hop-self
> !
> address-family vpnv4 unicast
> route-policy PASS in
> route-policy PASS out
> next-hop-self
> !
> !
> neighbor 192.168.1.6
> remote-as 65001
> address-family ipv4 labeled-unicast
> route-policy PASS in
> route-policy PASS out
> as-override
> send-extended-community-ebgp
> next-hop-self
> !
> address-family vpnv4 unicast
> route-policy PASS in
> route-policy PASS out
> as-override
> next-hop-self
> !
> !
> vrf vrf1
> rd 55555:1
> address-family ipv4 unicast
> as-path-loopcheck out disable
> redistribute connected
> allocate-label all
>
>
> Any help would be greatly appreciated as I expected I have overlooked
> something really obvious.
>
> Cheers,
> James.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list