NAT mode Warm Spare

rhbirkelund
Kind of a big deal
Kind of a big deal

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. 

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
9 Replies 9
NolanHerring
Kind of a big deal

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

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

haha

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

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

Hmmm....let me see.

 

131313131.JPG

 

Nah...I think I'm good lolol

Nolan Herring | nolanwifi.com
TwitterLinkedIn


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

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
AndyPan
Conversationalist

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

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

Nolan Herring | nolanwifi.com
TwitterLinkedIn

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

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
Get notified when there are additional replies to this discussion.
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.
Labels