Ethernet Switching
Ethernet Switching

IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Hi Everyone,

Im working on a set of QFX 10008s running VRRP over IRB interfaces to provide a gateway for the connected Vlans.  We have an issue where some random traffic is getting dropped.  While troubleshooting with ATAC. We noticed that both nodes seem to respond to arp for the virtual mac address. For instance -- while in a lab if i ssh to the gateway of the network i am on, the node that responds is always the first node it hits via the lag. So if i remove the link to Node1 VRRP MASTER, Node 2 Responds to the ssh request? Im a little fuzzy on how this Active - Active VRRP over IRB config is supposed to work but does that sound right to anyone? 

 

Also We have more than 255 routed vlans on here and we are limited by vrrp groups up to 255. We have are currently using group 10 for all vrrp config. Is that ok considering they are all in a different broadcast domain?

 

Thanks for your help!!

8 REPLIES 8
Ethernet Switching

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Not sure your concern regarding the ARPs, as both devices should respond with same [well known] MAC for the VRRP Gateway address.  Client should have no issue handling this.

 

As for VRRP, Group # only has local significance for the VLAN, so yes same number can be used.  People generally use different numbers (like map to VLAN #) to aid in any troubleshooting.  The Group # will affect the format of the well known MAC (01:00:5E . . .)

 

HTH

Ethernet Switching

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Harold, are you with Met Museum in NYC?

 

Just wondering, . . .

Ethernet Switching
Solution
Accepted by topic author harold.dauncey@metmuseum.org
3 weeks ago

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Hi Harold,

As the name suggesst in Active-Active mode any peer can respond to ARP and forward the traffic.

 

If you are getting confused because VRRP state on the device is backup but its responding to ARP/Forwarding traffic, you should know that in a VRRP-based Layer 3 solution, even the VRRP backup node forwards traffic. 

VRRP comes handy in assinging a VIP and VMAC but unlike VRRP the ARP entries are synced on both the MC-LAG peers which makes the active-active forwarding possible.

PS: Please accept my response as solution if it answers your query, kudos are appreciated too!

 

Thanks
Vishal

Ethernet Switching

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Hi!

 

Yes i am. 

Ethernet Switching

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Thanks Vishal,

 

This makes Perfect Sense.

 

Also, one more question about this setup.

 

A-TAC is recommending we place the iccp-peer-down prefer status control active on both nodes. However Many documents say dont do this. Is this a best Practice?

 

Thanks!

 

 

Ethernet Switching

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Hi Harold,

I'm not familiar with the context of your conversation with TAC Team so can't comment on that.

However, in general active is configured only on one of the peer so that traffic gets forwarded  via one peer and split brain scenario doesn't arise when the ICCP peer goes down.

 

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/mc-ae-edi...

prefer-status-control-activeSpecify that the node configured as status-control active become the active node if the peer of this node goes down. When ICCP goes down, you can use this keyword to make a mc-lag PE to become the active PE. For example, if you want mc-lag PE1 to be Active on ICCP down, then configure this keyword in PE1. It is not recommended to configure this keyword in both the mc-lag PEs.

PS: Please accept my response as solution if it answers your query, kuods are appriectaed too!

Thanks
Vishal

Ethernet Switching

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Great!

 

Thanks for the info on this. We removed that line and all appears to be stable now. 

 

 

Ethernet Switching

Re: IRB and VRRP on QFX10ks MC-LAG

3 weeks ago

Hi Harold,

 

I have always liked this document, it explains very well some of the concerns mentioned here in your post. if you haven't, you should take a look.

 

Best Practices and Usage Notes

https://www.juniper.net/documentation/en_US/junos/topics/concept/best-practices-usage-notes.html


Benjamin