Hi Niklas We always use unique ASNs per device in the VRFs. Loop 2 should work fine, as-override also as previously mentioned.
There's also a few knobs for RT5 you can play with: root@qfx5120-48y-02# set routing-instances test protocols evpn ip-prefix-routes route-attributes ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups > as-path AS-PATH Attribute > community Community Attribute > preference Preference Attribute Regards Roger On Tue, Nov 15, 2022 at 2:53 PM Saku Ytti via juniper-nsp < [email protected]> wrote: > I would still consider as-override, or at least I would figure out the > reason why it is not a good solution. > > On Tue, 15 Nov 2022 at 15:40, niklas rehnberg via juniper-nsp > <[email protected]> wrote: > > > > Hi, > > Thanks for the quick reply, I hope following very simple picture may help > > > > Clients Clients > > > > | | > > | EVPN/VXLAN | > > | Overlay AS 6555 | > > spine1 --- type 5--- spine2 > > vrf WAN AS X | | vrf WAN AS X > > eBGP | | eBGP > > | | > > PE AS Y PE AS Y > > | | > > > > ----Core Network--- > > > > route example when loop occur > > show route hidden table bgp.evpn extensive > > > > bgp.evpn.0: 156 destinations, 156 routes (153 active, 0 holddown, 3 > hidden) > > 5:10.254.0.2:100::0::5.0.0.0::16/248 (1 entry, 0 announced) > > BGP /-101 > > Route Distinguisher: 10.254.0.2:100 > > Next hop type: Indirect, Next hop index: 0 > > Address: 0x55a1fd2d2cdc > > Next-hop reference count: 108, key opaque handle: (nil), > > non-key opaque handle: (nil) > > Source: 10.254.0.2 > > Protocol next hop: 10.254.0.2 > > Indirect next hop: 0x2 no-forward INH Session ID: 0 > > State: <Hidden Int Ext Changed> > > Peer AS: 65555 > > Age: 1:14 Metric2: 0 > > Validation State: unverified > > Task: BGP_65555_65555.10.254.0.2 > > AS path: 65263 xxx I (Looped: 65263) > > Communities: target:10:100 encapsulation:vxlan(0x8) > > router-mac:34:11:8e:16:52:b2 > > Import > > Route Label: 99100 > > Overlay gateway address: 0.0.0.0 > > ESI 00:00:00:00:00:00:00:00:00:00 > > Localpref: 100 > > Router ID: 10.254.0.2 > > Hidden reason: AS path loop > > Secondary Tables: WAN.evpn.0 > > Thread: junos-main > > Indirect next hops: 1 > > Protocol next hop: 10.254.0.2 > > Indirect next hop: 0x2 no-forward INH Session > ID: 0 > > Indirect path forwarding next hops: 2 > > Next hop type: Router > > Next hop: 10.0.0.1 via et-0/0/46.1000 > > Session Id: 0 > > Next hop: 10.0.0.11 via et-0/0/45.1000 > > Session Id: 0 > > 10.254.0.2/32 Originating RIB: inet.0 > > Node path count: 1 > > Forwarding nexthops: 2 > > Next hop type: Router > > Next hop: 10.0.0.1 via > > et-0/0/46.1000 > > Session Id: 0 > > Next hop: 10.0.0.11 via > > et-0/0/45.1000 > > Session Id: 0 > > > > > > // Niklas > > > > > > > > > > Den tis 15 nov. 2022 kl 13:58 skrev Saku Ytti <[email protected]>: > > > > > Hey Niklas, > > > > > > My apologies, I do not understand your topology or what you are trying > > > to do, and would need a lot more context. > > > > > > In my ignorance I would still ask, have you considered 'as-override' - > > > > > > > https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/as-override-edit-protocols-bgp.html > > > this is somewhat common in another use-case, which may or may not be > > > near to yours. Say you want to connect arbitrarily many CE routers to > > > MPLS VPN cloud with BGP, but you don't want to get unique ASNs to > > > them, you'd use a single ASN on every CE and use 'as-override' on the > > > core side. > > > > > > Another point I'd like to make, not all implementations even verify AS > > > loops in iBGP, for example Cisco does not, while Juniper does. This > > > implementation detail creates bias on what people consider 'clean' and > > > 'dirty' solution, as in Cisco network it's enough to allow loop at the > > > edge interfaces it feels more 'clean' while in Juniper network you'd > > > have to allow them in all iBGP sessions too, which suddenly makes the > > > solution appear somehow more 'dirty'. > > > > > > > > > On Tue, 15 Nov 2022 at 12:48, niklas rehnberg via juniper-nsp > > > <[email protected]> wrote: > > > > > > > > Hi all, > > > > I have the following setup and need to know the best practices to > solve > > > > EVPN type 5 issues. > > > > > > > > Setup: > > > > Two ACX7100 as collapse spine with EVPN/VXLAN > > > > Using type 5 routes between the spines so iBGP can be avoided in > > > > routing-instance. > > > > Both spines has same bgp as number in the routing-instance WAN > > > > See below for a part of configuration > > > > > > > > Problem: > > > > Incoming routes from WAN router into spine1 will be advertised to > spine2 > > > as > > > > type 5 routes > > > > spine2 will not accept them due to AS number exit in the as-path > already. > > > > > > > > Solution: > > > > I can easily fix it with "loop 2" config in the routing-options > part, but > > > > is this the right way? > > > > Does there exist any command to change the EVPN Type 5 behavior from > eBGP > > > > to iBGP? > > > > Different AS number in routing-instance? > > > > What are the best practices? > > > > > > > > Config part: > > > > show routing-instances WAN protocols evpn > > > > ip-prefix-routes { > > > > advertise direct-nexthop; > > > > encapsulation vxlan; > > > > reject-asymmetric-vni; > > > > vni 99100; > > > > export EXPORT-T5-WAN; > > > > } > > > > policy-statement EXPORT-T5-WAN { > > > > term 1 { > > > > from protocol direct; > > > > then accept; > > > > } > > > > term 2 { > > > > from protocol bgp; > > > > then accept; > > > > } > > > > } > > > > _______________________________________________ > > > > juniper-nsp mailing list [email protected] > > > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > > > > > > > > -- > > > ++ytti > > > > > _______________________________________________ > > juniper-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > ++ytti > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
