VRRP transition logs

Wendy2
Here to help

VRRP transition logs

We have a site with 2 x MX in HA.  We are seeing  VRRP transition logs. The MX security appliances are frequently swapping between Master and Passive.

VRRP transition old_mode

detect prio 235

old_prio 235

elector_state master

last_state_change_reason master_down_timer

 

We are seeing MAC_flap logs on our Cisco switch.  No impact has been reported, but this is the only site we're seeing these errors on.  MX each have a lan port and wan port connected into separate switches in a stack.

 

Haven't been able to figure this out yet.

18 Replies 18
alemabrahao
Kind of a big deal
Kind of a big deal

How is your topology? This is usually due to an error in the topology design.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.

Thank you for your response.  MX_01 : Lan port into Cisco switch 1 trunk port.  WAN into internet router.  MX_02 : Lan port into Cisco switch 2 trunk port. This is a switch stack.

Packet capture is showing a loop between the VLAN Interface IP's

Checked spanning tree, and no errors.  This site is setup identically to another site with no MAC_flaps

 

cmr
Kind of a big deal
Kind of a big deal

Does the trunk port include VLAN1?

Wendy2
Here to help

No, just the vlans setup on the MX

cmr
Kind of a big deal
Kind of a big deal

Is the Cisco switch stack the root bridge for all VLANs that are in the trunk?

Are there other switches in the LAN?

Wendy2
Here to help

Yes, the core stack is the root bridge for all VLANS in the trunk.  We have two other access switches in the topology.  There is no impact to production as a result of this mac_flap so far.

cmr
Kind of a big deal
Kind of a big deal

As mentioned elsewhere, we did have the same for several firmware versions and a switch to DAC cables fixed it. Do you have spare SFP+ ports on the switches?

alemabrahao
Kind of a big deal
Kind of a big deal

Just to remind you that it is recommended that STP is enabled to avoid looping.

 

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
PhilipDAth
Kind of a big deal
Kind of a big deal

>this is the only site we're seeing these errors on

 

Is this site running the same firmware versions as the other sites without issues?

Yes, it's identical to another site with the same topology.  MX_105 running the same versions 18.107.2

cmr
Kind of a big deal
Kind of a big deal

Are they MX250s and what firmware version are they running.  We had this issue with busy MX250s in concentrator mode where we used GLC-T modules in the WAN ports running at 1Gb.  Once we changed over to 10Gb DAC cables the transitions went away.

Wendy2
Here to help

Thanks for the reply.  MX_105 running the same versions 18.107.2.  We're using ethernet ports

cmr
Kind of a big deal
Kind of a big deal

Are the Cisco switches running STP?

I'd upgrade to 18.107.10 at least and ideally a newer version.

How loaded are the MXs, more or less than the other site where there aren't errors?

Wendy2
Here to help

The WAN ports lights are orange?  Is this correct?

cmr
Kind of a big deal
Kind of a big deal

Orange normally indicates that they are not running at the fastest port speed.  What does the dashboard report?

Wendy2
Here to help

Dashboard says 1Gbps full duplex
Wondering if this issue is due to faulty physical cabling?

cmr
Kind of a big deal
Kind of a big deal

VRRP is over the LAN ports and the logs don't seem to show WAN down, unless that is also in there?

Wendy2
Here to help

Site is fully up and functioning.  No issue reported about from the MAC_flaps I have noticed.  WAN is a separate thing, I agree

Get notified when there are additional replies to this discussion.