Mailing List Archive

Collapse spine EVPN type 5 routes issue
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Collapse spine EVPN type 5 routes issue [ In reply to ]
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@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Collapse spine EVPN type 5 routes issue [ In reply to ]
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@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@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@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> ++ytti
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Collapse spine EVPN type 5 routes issue [ In reply to ]
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@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@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@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@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> >
> > --
> > ++ytti
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Collapse spine EVPN type 5 routes issue [ In reply to ]
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 <
juniper-nsp@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@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@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@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@puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> > >
> > >
> > > --
> > > ++ytti
> > >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: Collapse spine EVPN type 5 routes issue [ In reply to ]
Hi all,
I think following command is the best way to only get loop 2 for EVPN
routes, eBGP routes will still have loop 1 as control.
set protocols bgp group OVERLAY-EVPN family evpn signaling loops 2

Regards Niklas

Den fre 18 nov. 2022 kl 12:38 skrev Roger Wiklund <roger.wiklund@gmail.com>:

> 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 <
> juniper-nsp@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@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@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@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@puck.nether.net
>> > > > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> > >
>> > >
>> > >
>> > > --
>> > > ++ytti
>> > >
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>> --
>> ++ytti
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp