[j-nsp] Collapse spine EVPN type 5 routes issue

[niklas rehnberg]

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
>