Hello List, We operate a route-reflected internal BGP topology and have a number of customers to whom we offer L3VPN services. We recently upgrade our route reflectors (M7i) to 11.4R3.7, per our support provider's advice (and, indeed, requirement). Since then we have run into a what appears to be a bug that has been introduced since the 9.x stream (I know, I know, we've been slack about upgrading and I'm sort of glad we have been).
Basically, a CE device advertises a default route to its PE neighbour. The PE device advertises the route, with an rd-prefix, to the route reflectors; the RRs load the route into the bgp.l3vpn.0 table as expected. If we look at this default route in an RR's table, everything looks fine: the protocol next-hop is the loopback of the PE router and the community is the normal 'target:65535:12345' type that one would expect for a VRF route. The problem arises when that route is advertised to other routers. For some reason, when the route reflector is exporting the route, it is changing the protocol next-hop and the community. In the case of the community, it becomes the standard 1234:567 format that one associates with routes in inet.0 and inet6.0. Obviously, the receiving PE device doesn't load the route into its VRF, since the community doesn't match, and this is causing problems for customers. This *only* happens with a default route that's been injected into a VRF - other routes injected by the CE devices in each VRF are re-advertised by the route reflectors with their protocol next-hop and community values intact. Has anyone else come across this problem? Is it a bug or is there some new configuration knob that we have missed? Thanks, Dermot Williams IP Engineering Manager Imagine Communications Group Ltd. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
