cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NAT mode Warm Spare

Building a reputation

NAT mode Warm Spare

So for the last couple of months I have been troubleshooting an issue with two MX64s Warm Spare. mfc.PNG

 

 

My two MX'es kept going into Dual Master Mode, thus exhibiting a Split-Brain situation. I have had Meraki Support with me on this one, and we just couldn't seem to discover why this was happening. 

 

Layer 1, -2 and -3 connectivity has been verified. All links are trunk, and no VLANs were being pruned. MX'es could ping eachother, and VRRP messaging was being recieved by eachother - they were just not reacting to the VRRP messages. This was confirmed via packet captures.

Connecting the two MX'es directly to eachother, remedied the issue, but since this is not best practice we disconnected them again. Dual Master mode back.

 

Yesterday, we had a breakthrough. After enabling "Flood unknown multicast traffic" my two MX'es more or less instantaneously went into Master/Passive. 

 

Now I'm trying to determine why this is neccessary, because I have another installation that is also running Warm Spare, and this setting is _not_ enabled.

Why? What does "Flood unknown multicast traffic" do? I might not be all to keen on multicast, but I'm trying to understand why this is neccessary. 

9 REPLIES 9
Kind of a big deal

Re: NAT mode Warm Spare

VRRP uses multicast (224.0.0.18), but if your receiving the packets between the MX's, then it is strange that enabling 'Flood unknown multicast traffic' would make any difference. Hmm..
Nolan Herring | nolanwifi.com
TwitterLinkedIn
Kind of a big deal

Re: NAT mode Warm Spare

It sounds like the switches were not processing multicast traffic correctly.  Are you running 10.x (like 10.43) code on the switches?

 

Also check out this excellent post on multicast configuration when you have more than one switch.

https://community.meraki.com/t5/Switching/Multicast-Basic-s/m-p/25867#M2125

Kind of a big deal

Re: NAT mode Warm Spare

haha

Phil you gave a link for a hotel in New Zealand 😃
Nolan Herring | nolanwifi.com
TwitterLinkedIn
Kind of a big deal

Re: NAT mode Warm Spare

How funny, thanks @NolanHerring.  That is where I am going for lunch, in case anyone wants to join me in about 2 hours time. 🙂

Conversationalist

Re: NAT mode Warm Spare

Suggest to use trunk port instead. Never had problem for trunk ports.

Kind of a big deal

Re: NAT mode Warm Spare

Hmmm....let me see.

 

131313131.JPG

 

Nah...I think I'm good lolol

Nolan Herring | nolanwifi.com
TwitterLinkedIn
Kind of a big deal

Re: NAT mode Warm Spare

@AndyPan  Looks like (from his original post) that all the links are trunks, no pruning. 

Nolan Herring | nolanwifi.com
TwitterLinkedIn
Building a reputation

Re: NAT mode Warm Spare

@PhilipDAth 

We upgraded both switch and MX to latest beta release, to no luck. I'll have a look at that forum post. 

 

@AndyPan 

All links are trunk and allowed all VLANs, except for my Internet uplink. That is a dedicated vlan, on access ports (which not by my good will is allowed on the trunk). So no vlans are pruned along the way.

 

They grey links on the drawing by the way, indicate links that are physical in place but disabled. Since we got it working, all links are enabled, and continue on working.

Building a reputation

Re: NAT mode Warm Spare


@PhilipDAth wrote:

It sounds like the switches were not processing multicast traffic correctly.  Are you running 10.x (like 10.43) code on the switches?

 

Also check out this excellent post on multicast configuration when you have more than one switch.

https://community.meraki.com/t5/Switching/Multicast-Basic-s/m-p/25867#M2125


I read in to this, but I'm still unsure about this.

 

IGMP Snooping, allows us to send and recieve multicast streams out the same ports. If this is disabled, then we cannot recieve multicast streams stemming from ports where we send out multicast streams. Basically, depending on who comes first, whichever MX will not be able to reply on multicast streams. 

 

Flood unknown multicast traffic; will allow the switches to flood multicast traffic out all ports. But is VRRP considered unknown multicast traffic? Or maybe multicast traffic with unknown source/destination, is just flooded out all switchports?

Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.