I don't see this issue. Does it only happen when you have a different ASN inside the VRF?
On Thu, Jun 28, 2018 at 10:44:07PM -0400, Philippe Girard wrote: > Grettings > > I'm setting up this VRF that hosts the full routing table. I have other > peerings or remote PEs that import IX routes through eBGP as well. > > The problem resides on something TAC tells me is Juniper specific, which is > to add my own internal ASN to the as-path when using vrf-import to get a > route that was learned through eBGP from another router to avoid potential > loops. > > So, let's say IX has AS 123 and I have AS 456 in the VRF, and my real > inet.0 AS is 789, what is seen by another PE than the one learning the > route directly from the IX is: > > IX -- eBGP - PE1 - iBGP inet-vpn - PE2 > > Route as-path seen by PE1: 123 XXX YYY I > Route as-path seen by PE2: 456 123 XXX YYY I > > The behaviour is the same on all Junos routing devices in my core (MX + > QFX5100) and I have to configure routing-options autonomous-system 456 > loops 2 for the other peers to accept routes imported by eBGP on another > node. > > Obviously, the "real" as-path is as follows, since the AS doing the > underlay iBGP has ASN 789. > > 456 [789] 456 123 XXX YYY I > > I've tried independant domain but that makes me unable to filter any bgp > attribute in vrf-imports and exports. I've also tried an "option A" peering > between the routers and that revealed the underlay AS in the path. Using > remove-private created a loop by re-sending the learned routes towards the > edge. > > Would anybody have an idea on how to achieve the equivalent of having and > inet.0 iBGP mesh and importing routes without the own as prepending that > takes place as described? _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp