Ethernet Switching
Highlighted
Ethernet Switching

unknown unicast on QFX5100 mc-lag irb

[ Edited ]
‎04-28-2018 12:12 AM

Hi All,

I have strange problem with 2 * qfx5100 with mc-lag and irb + ospf

MC-LAG peers have configured static-arp on irb interfaces. Everything works ok. Vlans without IRB works as it should be.

 

But the problem is with vlans with IRB. When traffic goes from downlink host to IRB MAC of peer2.

Traffic goes like this: 

downlink-host > to peer1 mc-lag over mcae > to peer2 (to MAC on IRB)over ICL

 

Packet gets to peer2 but when traffic comes from downlink-host to peer1, peer1 treat this as unknown unicast because don't know peer2 MAC.

 

Documentation says:

"The IRB MAC address of each MC-LAG peer is replicated on the other MC-LAG peer and is installed as a MAC address that has been learned on the ICL"

but my mc-lag peers dont know each other's IRB MAC's Smiley Sad 

 

Any ideas?

 

I tried on JTAC recommended Junos14 and on Junos18 - didn't help

 

Configuration is very similar to this document: https://www.juniper.net/documentation/en_US/release-independent/nce/topics/example/multichassis-link...

 

 

6 REPLIES 6
Highlighted
Ethernet Switching

Re: unknown unicast on QFX5100 mc-lag irb

‎04-28-2018 12:57 PM

Hello,

Do You have this line in the QFX config?

set vlans <name> mcae-mac-synchronize

https://www.juniper.net/documentation/en_US/junos/topics/example/multichassis-link-aggregation-layer...

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Ethernet Switching

Re: unknown unicast on QFX5100 mc-lag irb

‎05-04-2018 10:42 PM

I can't use this command because I choose VRRP as a L3 solution instead of mac-synchronization.

Highlighted
Ethernet Switching

Re: unknown unicast on QFX5100 mc-lag irb

‎05-05-2018 04:55 AM

Hello,

If Your downstream host is using VRRP VIP as its default GW,, then the downstream host should resolve it to VRRP VMAC.

The VRRP VMAC is the source MAC in the VRRP packets, see RFC 5798 section 7,.3

https://tools.ietf.org/html/rfc5798#page-28

Thus, the VRRP backup should learn the VRRP VMAC from the periodic VRRP packets sent by VRRP master.

If Your VRRP backup does not receive VRRP packets over ICL and does not learn VRRP VMAC over ICL, it then it looks like there is no L2 path across ICL, perhaps only across the downstream host. If there was no L2 path at all between MC-LAG peers, I would expect that You'd have 2 VRRP masters.

If Your downstream host uses the VRRP master|backup' _OWN_ IP (as opposed to VRRP VIP) as its DG, then this is most unusual setup I could think of. Then You probably don't need VRRP at all and You can use mac-synchronize feature.

HTH

Thx
Alex

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Ethernet Switching

Re: unknown unicast on QFX5100 mc-lag irb

‎06-15-2018 10:55 PM

My configuration is very similar to this one: 

http://jncie.tech/2017/07/30/mc-lag-lab-advanced-irb-functionality/.

 

But I narrow the searching.  I have no idea why why 2 MC-LAG nodes dont know each others irb MACs.  They have proper static arp entries on irb interfaces and communicate. 

 

Please help

 

############################## 
# irb static arp
##############################

bartek@switch-e9-juniper-qfx5100> show configuration interfaces irb.1000 family inet 
mtu 1500;
address 10.0.1.9/24 {
    arp 10.0.1.8 l2-interface ae1.0 mac e8:b6:c2:8b:f2:80 publish;
    vrrp-group 100 {
        virtual-address 10.0.1.10;
        priority 109;
        accept-data;
    }
}

bartek@switch-f8-juniper-qfx5100> show configuration interfaces irb.1000 family inet 
mtu 1500;
address 10.0.1.8/24 {
    arp 10.0.1.9 l2-interface ae1.0 mac e8:b6:c2:8b:fc:80 publish;
    vrrp-group 100 {
        virtual-address 10.0.1.10;
        priority 108;
        accept-data;
    }
}

############################################## 
# irb MACs
##############################################

bartek@switch-e9-juniper-qfx5100> show interfaces irb | match Hardware                  
  Current address: e8:b6:c2:8b:fc:80, Hardware address: e8:b6:c2:8b:fc:80

bartek@switch-f8-juniper-qfx5100> show interfaces irb | match Hardware                  
  Current address: e8:b6:c2:8b:f2:80, Hardware address: e8:b6:c2:8b:f2:80

########################################### 
# ping works, ospf works and everything seems to be ok, but it is not
##########################################

bartek@switch-e9-juniper-qfx5100> ping 10.0.1.8 count 2    
PING 10.0.1.8 (10.0.1.8): 56 data bytes
64 bytes from 10.0.1.8: icmp_seq=0 ttl=64 time=8.368 ms
64 bytes from 10.0.1.8: icmp_seq=1 ttl=64 time=19.129 ms

--- 10.0.1.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 8.368/13.748/19.129/5.381 ms

############################################
#static arp entry looks ok
########################################

bartek@switch-e9-juniper-qfx5100> show arp hostname 10.0.1.8 
MAC Address       Address         Name                      Interface               Flags
e8:b6:c2:8b:f2:80 10.0.1.8        10.0.1.8                  irb.1000 [ae1.0]        permanent published

bartek@switch-e9-juniper-qfx5100> show route forwarding-table all | match 10.0.1.8             
10.0.1.8/32        dest     0 e8:b6:c2:8b:f2:80  ucst     1794     1 ae1.0

############################################
# the problem is that peers dont know each others mac addresses :(
###########################################

bartek@switch-e9-juniper-qfx5100> show ethernet-switching table | match e8:b6:c2:8b:f2:80 

{master:0}
bartek@switch-e9-juniper-qfx5100> 


  

Highlighted
Ethernet Switching

Re: unknown unicast on QFX5100 mc-lag irb

‎08-06-2018 02:02 AM

You are right. I would definitely prefer install VIP as next hop on downhost, because VIP in MC-LAG is processed by both peers - even backup vrrp host.

 

The problem is that i cant change next-hop on ospf. Each mc-lag peer send LSA's from its IRB, not from VIP.  On BGP you can change next-hop to VIP on routing policy, but not on ospf i think.

Highlighted
Ethernet Switching

Re: unknown unicast on QFX5100 mc-lag irb

‎08-06-2018 04:11 AM

A couple of comments:

 

#1 - I would not recommend running [plain] 15.1 on any switching product.  For QFX5100, I believe 14.1X53 is best, while for something like QFX5110, 15.1X53 is best.  I would certainly not run 18.x, at this time.

 

#2 - Yes since you are using VRRP config, do NOT set mac-sync.

 

#3 - It appears 15.1R3 added in a change of behavior for MC-LAG.  See this KB (very last statement about 16.1 is VERY confusing; I assume this is maybe a typo and should read 15.1[R3]??):

 

https://kb.juniper.net/InfoCenter/index?page=content&id=KB32549&actp=METADATA

 

So if you are going to run 15.1, you may want [need?] to delete static ARP entry??

 

#4 - I assume your edge device is some L3/Router device running OSPF.  So when a packet arrives at either QFX5100 MC-LAG node, it should be a route lookup and next-hop MAC that takes place, yes?  Do both nodes have a proper route table and proper next-hop MAC address?

 

Good luck.