NAT mode Warm Spare

[rhbirkelund]

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

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. 

[NolanHerring]

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..

[PhilipDAth]

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

[NolanHerring]

haha

Phil you gave a link for a hotel in New Zealand 😃

[PhilipDAth]

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

[NolanHerring]

Hmmm....let me see.

Nah...I think I'm good lolol

[rhbirkelund]

---

@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?

[AndyPan]

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

[NolanHerring]

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

[rhbirkelund]

@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.