EVPN Convergence time in a Multihome setup is about 20 seconds. 2 slow

[DanielGutierrez615]

EVPN Convergence time in a Multi home setup is about 20 seconds. It's too slow.

I have one CE  connected to two PE1 and PE1.

PE1 and PE1 are connected to the MPLS core. From MPLS core there is another PE3. I'm running an 10G RFCtest between the Customer 1 device and Customer 2 device. 

I'm testing resiliency, and see how fast it can converge. Currently, both PEs are load balancing the traffic. When I reload PE1,   PE2 start to pass all the traffic. The problem is that when PE2 is about to reestablish the BGP neighborship with the RRs  PE1 stops passing traffic. Once PE2 finally reestablish BGP peers with the router reflectors, traffic starts to pass normally.   I'm read a tons of documents about how to improve the convergence time. the only one that made sense to me is the "bgp graceful-restart"

This is an ALL active MH secenario. With an ethernet segment.  I'm about to lab this with with the startup cost-in command to see if will help.    my question is are there any good articles that talk about SPECIFICALLY ALL ACTIVE MULTIHOME WITH BUNDLE scenerio that talks about improving the convergence time.  or a configuration that you will recommend.  I read 

[tkarnani]

We can check this command during the time of the reload, we want to check which timer is running
show evpn ethernet-segment interface bundle-Ether <> carving


Peering timer : 3 sec [not running]

Recovery timer : 30 sec [not running]


Thanks

[DanielGutierrez615 · Accepted solution]

I found the solution. Once I applied the  core-isolation-group  the convergence time dropped to ms

[jigojar]

we are facing the convergence issue during the acces ring failure. its taking 300 seconds to switch the traffic.

interface GigabitEthernet0/0/0/21
ethernet-segment
identifier type 0 10.70.25.27.11.22.33.44.66
load-balancing-mode single-flow-active
convergence
mac-mobility
!
!
timers

[nkarpysh]

300 se c is default MAC flush timer so it looks some TCN which should be generated upon your convergence trigger are not traveling through.

Can you pls provide more details of:

- Your topology

- HW/SW used

- Full config from each PE involved

- Describe the trigger you do for convergence

- Describe which flows (Source and Destination) are affected

Thx

Niko

[jigojar]

Hi,

pls find the config

evpn
!
interface GigabitEthernet0/0/0/10
ethernet-segment
identifier type 0 10.07.02.52.22.52.24.13.10
load-balancing-mode single-flow-active
convergence
mac-mobility
!
!
!
timers
peering 0
!

bridge group ENT_BCF-BCF_SVPN_2444_STAG
bridge-domain ENT_BCF-BCF_SVPN_2444_STAG
storm-control broadcast kbps 256
mac
withdraw state-down
!
interface GigabitEthernet0/0/0/10.2444
storm-control unknown-unicast kbps 256
storm-control broadcast kbps 256
split-horizon group
!
evi 2444
!

evpn
evi 2444
bgp
route-target import 100.70.252.1:2444
route-target export 100.70.252.1:2444
!
etree
rt-leaf
!
advertise-mac
!
!

[jigojar]

Hi Can some one help us to reduce the convergence time

[nkarpysh]

Hey,

From above we can see LB mode is SFA and convergence on ring failure is 300 seconds. In SFA convergence on the ring side will be achieved by the TCN coming from the ring to one of the PEs which will initiate the switchover/MAC flush. As convergence in your case is stuck for 300 seconds - it means that default MAC learnign time so SFA likely has not received any TCN from the ring and has not triggerred the MAC flush.

I'd recommend to check it from this angle. On last Cisco Live we were covering SFA triage from this angle as well - see BRKSPG-2473 from 2024 Amsterdam.

If further help is needed I will recommend to open a TAC case as that can look deeper into the logs/events to see where the fault is.

HTH

Niko