[j-nsp] Collapse spine EVPN type 5 routes issue
Roger Wiklund
roger.wiklund at gmail.com
Fri Nov 18 06:38:13 EST 2022
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 at 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 <
juniper-nsp at puck.nether.net> 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
> <juniper-nsp at puck.nether.net> 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 <saku at ytti.fi>:
> >
> > > 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
> > > <juniper-nsp at puck.nether.net> 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 juniper-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> > >
> > >
> > > --
> > > ++ytti
> > >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list