Here is an example of the route being correctly advertised by the RR (ibb2) 2001:50::/64 and the bogus route that the 6PE RR client (ibb1) generates by "itself": 5000::/40. ?where does this prefix come from?
Finally the result of the debug bgp command when the session is cleanned. You can see that there is warning message and the "reserved" label = 0 is used, ?why does this happens?
I think Harold has a point and it is along the RFC mentioned above. From RFC 4798:
"A routing protocol (IGP or EGP) may run between the CE router and the 6PE router for the distribution of IPv6 reachability information."
The whole RFC does not mention your setup and EGP does refer to eBGP - unfortunately not written as explicitly as I do it here.
Also from RFC 4798:
"The ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP towards the egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix."
Now in your case a PE, which is IPv6 Route-Reflector does not insert itself as next hop - at least a RR should not do it. And there is the problem, as the LSP between the ingress and egress 6PE router is established using the IPv4 MP-BGP session addresses; those two addresses MUST be used. The RFC is absolutely clear about this.
So use eBGP or an IGP for IPv6 routing between CE and 6PE, MP-iBGP using IPv4 addresses for peering between 6PE routers and establish LSPs between all 6PEs IPv4 peering addresses. Then it works like a charm.
Looking at the RFC the topology used for testing is not quite aligned.
1) RFC says IPV4 source address to be used for advertising the routes, if we are receiving native IPV6 routes over a native IPV6 IBGP connection the source address wont be IPV4.
2) Its also says the main purspose of this document is to connect Native IPV6 islands to each other, which definately wont be the case when we do IBGP with the 6PE as it would be an extension of the network.
RFC are generally most technically and politically correct documents :-).
But here for the problem you pointed out, it appears to be an unwanted behaviour from the code. Where it should
not at all advertise the native IPv6 routes if the routes have not been originated by the 6PE it self from BGP point of view.
This point is also made clear in the RFC terming it as "distrbution of routes between CE and 6PE".
PS: Also the bogus routes are actually the native IPV6 prefixes received and advertised by the ingress PE to the egress PE.
I came to this conclusion by seeing this pattern, it always picks up the second octet and appends 00 to it with a mask of /40.
This is pretty consitent. for eg: if you have a prefix received on IBGP from your CE as 2001:25::/64 then on the other end you will see it as 2500::/40. I am not sure why is it doing this conversion as its an unwanted behaviour, when it should rather discard these native IBGP routes over an IPV6-MPLS MP-IBGP session.
Alternatively if you want to run IBGP only for some reason between the 2 native IPV6 islands then you can consider extedning your IGP across the IPV6-MPLS domain and running IBGP across it. You can have this achieved by injecting your IGP at the 6PE router and hence have a the native IPV6 route advertised with a label attached to it to the remote 6PE's. This works as well. This way forwarding will be done by MPLS and you can still retain the routing control you need within your AS using IBGP.
IntroductionPre-requisite: Caveat :When IPXE Boot could be done : IPXE Boot :Ipxe boot using DHCP Server :
iPXE boot in ASR9K
Migration recommendation document for Cxr to Exr.
This document applies to NCS5500 and ASR9000 routers and has been verified as such.
traditional ECMP or equal cost multipath loadbalances traffic over a number of available paths towards a destination. When one path fails, the traffic gets r...
Hi community,I just wanted to share my findings about accesing to ACL counters by SNMP on ASR9000/XR.
Searching on Internet I found the section ACL Counters Using SNMP in the IP Addresses and Services Configuration Guide but I didn't found any inf...