Hi
My 4 switches are model QFX-5120 48Y-8C and are in version 18.4R3-S4.2.
follow spines and leafs confs:
SPINE1
> show configuration interfaces irb unit 4018
proxy-macip-advertisement;
virtual-gateway-accept-data;
family inet {
address 10.18.19.253/24 {
preferred;
virtual-gateway-address 10.18.19.1;
}
}
virtual-gateway-v4-mac 00:00:5e:00:02:01;
> show configurations protocols bgp
group OVERLAY {
type internal;
local-address 172.16.11.201;
family evpn {
signaling;
}
cluster 0.11.11.1;
multipath;
neighbor 172.16.11.203 {
description "IBGP-EVPN SPGCSTKGHITA001";
}
neighbor 172.16.11.204 {
description "IBGP-EVPN SPGCSTKGHITA002";
}
}
group RR_MESH {
type internal;
local-address 172.16.11.201;
family evpn {
signaling;
}
neighbor 172.16.11.202 {
description "RR - SPGCSTKGHITA002";
}
}
group UNDERLAY {
type external;
hold-time 10;
mtu-discovery;
import Filtro_loopback;
family inet {
unicast;
}
export Anuncio_loopback;
local-as 65501;
multipath {
multiple-as;
}
neighbor 172.16.19.6 {
description "EBGP - SPGLTKGHITA001";
peer-as 65503;
}
neighbor 172.16.19.10 {
description "EBGP - SPGLTKGHITA002";
peer-as 65504;
}
}
VNI4018 {
vlan-id 4018;
l3-interface irb.4018;
vxlan {
vni 4018;
}
}
> show configuration routing-options
router-id 172.16.11.201;
autonomous-system 65001;
forwarding-table {
export PFE-LB;
ecmp-fast-reroute;
inactive: indirect-next-hop;
inactive: chained-composite-next-hop {
ingress {
evpn;
}
}
}
{master:0}
> show configuration switch-options
vtep-source-interface lo0.0;
route-distinguisher 172.16.11.201:1;
vrf-import EVPN-LEAF-TO-SPINE;
vrf-target {
target:2829:2829;
auto;
}
SPINE2
> show configuration interfaces irb unit 4018
proxy-macip-advertisement;
virtual-gateway-accept-data;
family inet {
address 10.18.19.254/24 {
preferred;
virtual-gateway-address 10.18.19.1;
}
}
virtual-gateway-v4-mac 00:00:5e:00:02:01;
> show configuration protocols bgp
log-updown;
graceful-restart;
group OVERLAY {
type internal;
local-address 172.16.11.202;
family evpn {
signaling;
}
cluster 0.11.11.1;
multipath;
neighbor 172.16.11.203 {
description "IBGP-EVPN SPGLTKGHITA001";
}
neighbor 172.16.11.204 {
description "IBGP-EVPN SPGLTKGHITA002";
}
}
group RR_MESH {
type internal;
local-address 172.16.11.202;
family evpn {
signaling;
}
neighbor 172.16.11.201 {
description "RR - SPGCSTKGHITA001";
}
}
group UNDERLAY {
type external;
hold-time 10;
mtu-discovery;
import Filtro_loopback;
family inet {
unicast;
}
export Anuncio_loopback;
local-as 65502;
multipath {
multiple-as;
}
inactive: neighbor 172.16.19.1 {
description "SPGCSTKGHITA001 - EBGP";
peer-as 65501;
}
neighbor 172.16.19.18 {
description "EBGP - SPGLTKGHITA001";
peer-as 65503;
}
neighbor 172.16.19.14 {
description "EBGP - SPGLTKGHITA002";
peer-as 65504;
}
}
> show configuration vlans
VNI4018 {
vlan-id 4018;
l3-interface irb.4018;
vxlan {
vni 4018;
}
}
> show configuration switch-options
vtep-source-interface lo0.0;
route-distinguisher 172.16.11.202:1;
vrf-import EVPN-LEAF-TO-SPINE;
vrf-target {
target:2829:2829;
auto;
}
{master:0}
> show configuration routing-options
router-id 172.16.11.202;
autonomous-system 65001;
forwarding-table {
export PFE-LB;
ecmp-fast-reroute;
inactive: indirect-next-hop;
inactive: chained-composite-next-hop {
ingress {
evpn;
}
}
}
LEAF1
> show configuration protocols bgp
log-updown;
graceful-restart;
group OVERLAY {
type internal;
inactive: traceoptions {
file traceoptions.log;
flag all;
}
local-address 172.16.11.203;
family evpn {
signaling;
}
multipath;
neighbor 172.16.11.201 {
description SPINE1;
}
neighbor 172.16.11.202 {
description "iBGP SPGCSTKGHITA002";
}
}
group UNDERLAY {
type external;
hold-time 10;
mtu-discovery;
import Filtro_loopback;
family inet {
unicast;
}
export Anuncio_loopback;
local-as 65503;
multipath {
multiple-as;
}
neighbor 172.16.19.5 {
description "SPGCSTKGHITA001 - EBGP";
peer-as 65501;
}
neighbor 172.16.19.17 {
description "SPGCSTKGHITA002 - EBGP";
peer-as 65502;
}
}
> show configuration routing-options
router-id 172.16.11.203;
autonomous-system 65001;
forwarding-table {
export PFE-LB;
ecmp-fast-reroute;
inactive: indirect-next-hop;
inactive: chained-composite-next-hop {
ingress {
evpn;
}
}
}
{master:0}
> show configuration switch-options
vtep-source-interface lo0.0;
route-distinguisher 172.16.11.203:1;
vrf-import EVPN-IMPORT;
vrf-target {
target:2829:2829;
auto;
}
> show configuration vlans
VNI4018 {
vlan-id 4018;
vxlan {
vni 4018;
}
}
LEAF2
> show configuration protocols bgp
log-updown;
graceful-restart;
group UNDERLAY {
type external;
hold-time 10;
mtu-discovery;
import Filtro_loopback;
family inet {
unicast;
}
export Anuncio_loopback;
local-as 65504;
multipath {
multiple-as;
}
neighbor 172.16.19.9 {
description "EBGP - SPGCSTKGHITA001";
peer-as 65501;
}
neighbor 172.16.19.13 {
description "EBGP - SPGCSTKGHITA002";
peer-as 65502;
}
}
group OVERLAY {
type internal;
local-address 172.16.11.204;
family evpn {
signaling;
}
multipath;
neighbor 172.16.11.201 {
description "IBGP-EVPN SPGCSTKGHITA001";
}
neighbor 172.16.11.202 {
description "IBGP-EVPN SPGCSTKGHITA002";
}
}
{master:0}
> show configuration routing-options
router-id 172.16.11.204;
autonomous-system 65001;
forwarding-table {
export PFE-LB;
ecmp-fast-reroute;
inactive: indirect-next-hop;
inactive: chained-composite-next-hop {
ingress {
evpn;
}
}
}
{master:0}
> show configuration switch-options
vtep-source-interface lo0.0;
route-distinguisher 172.16.11.204:1;
vrf-import EVPN-IMPORT;
vrf-target {
target:2829:2829;
auto;
}
> show configuration vlans
VNI4018 {
vlan-id 4018;
vxlan {
vni 4018;
}
}
Em sex., 11 de set. de 2020 às 11:30, Roger Wiklund
<roger.wiklund@gmail.com> escreveu:
>
> Hi
>
> Can I have the configs on spine and leafs? This is not expected behaviour.
> What version are you running?
>
> Regards
> Roger
>
> On Fri, Sep 11, 2020 at 3:51 PM Cristian Cardoso <cristian.cardoso11@gmail.com> wrote:
>>
>> Hello
>> Did anyone on the list have the EVPN-VXLAN scenario active with
>> Centrally-Routed Bridging?
>> Here in my scenario, I have two spines and 2 leafs and I am testing
>> this form of configuration, where the IRB interfaces work with the
>> virtual gateway function, for access redundancy, but I realized that
>> when restarting spine1, the active source of the virtual gateway ,
>> does not change from spine1 to spine2 generating network timeout.
>> When I restart spine1, the source of the virtual gateway on leaf does
>> not change, causing network timeout. The same timeout happens, on
>> VNI888, if I restart spine2.
>>
>> Below is the default.switch table
>>
>> Routing instance : default-switch
>> Vlan MAC MAC Logical
>> Active
>> name address flags interface
>> source
>> VNI4018 00:00:5e:00:02:01 DR esi.1750
>> 05:00:00:fd:e9:00:00:0f:b2:00
>> VNI4018 40:de:ad:7b:34:40 D vtep.32769
>> 172.16.11.201
>> VNI4018 40:de:ad:7b:66:40 D vtep.32770
>> 172.16.11.202
>> VNI4018 b4:96:91:70:db:84 D vtep.32771
>> 172.16.11.203
>> VNI4018 b4:96:91:71:25:c0 D xe-0/0/10.0
>> VNI888 00:00:5e:00:01:02 DR esi.1748
>> 05:00:00:fd:e9:00:00:03:78:00
>> VNI888 40:de:ad:7b:34:40 D vtep.32769
>> 172.16.11.201
>> VNI888 40:de:ad:7b:66:40 D vtep.32770
>> 172.16.11.202
>> VNI888 4a:7b:af:da:34:69 D vtep.32771
>> 172.16.11.203
>> VNI888 ae:cb:39:6b:a7:ee D xe-0/0/10.0
>>
>> The source 05: 00: 00: fd: e9: 00: 00: 0f: b2: 00 is spine1 and the
>> source 05: 00: 00: fd: e9: 00: 00: 03: 78: 00 is spine2
>>
>> Did anyone go through this?
>>
>> Best regards
>> _______________________________________________
>> 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