Hi
kronicklez,
Sorry but never tried to capture packets on MC-LAG configured MX devices so unfortunately not able to provide any real example from personal experience on that :(
Regarding MTU descrease, actually within family bridge only tag is being added to the packet size (depends on is it 802.1q or qinq), so interface (for example irb as I understood in your case) should be able to handle packets without any problem. I think I'm not clearly understood what you mean by "MTU decrease by automatically due to family bridge/irb." but for example I have the following configuration and MTU on interfaces:
set interfaces ae11 mtu
9192>show interfaces ae11 detail | match mtu
Link-level type: Flexible-Ethernet, MTU:
9192, Speed: 10Gbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled
L2 unit used in bridge-domain:
set interfaces ae11 unit 200 encapsulation vlan-bridge
set interfaces ae11 unit 200 vlan-id 200
> show interfaces ae11.200 | match mtu
Protocol bridge, MTU:
9192irb interface used in bridge-domain:
set interfaces irb unit 200 family inet address X.X.X.X/24
> show interfaces irb.200 | match mtu
Protocol inet, MTU:
1500Protocol multiservice, MTU:
1500As no MTU configuration on irb interface and it's not using 802.1q or qinq, only operates as L3 interface.
L3 unit operating as tagged sub-interface:
set interfaces ae11 unit 300 vlan-id 300
set interfaces ae11 unit 300 family inet address Y.Y.Y.Y/24
> show interfaces ae11.300 | match mtu
Protocol inet, MTU:
9170Protocol multiservice, MTU: Unlimited
So it looks there is no any MTU decrease on interfaces operating within bridge-domain. I've also found this information:
The MTU for an IRB interface is calculated by removing the Ethernet header overhead [6(DMAC)+6(SMAC)+2(EtherType)]. Because, the MTU is the lower value of the MTU configured on the IRB interface and the MTU configured on the IRB's associated bridge domain IFDs or IFLs, the IRB MTU is calculated as follows:
This also might help to understand MTU of irb interfaces on MX devices:
[MX] MTU calculation on logical IRB interfaces .
------------------------------
Regards,
Elchin
------------------------------
Original Message:
Sent: 11-30-2020 06:06
From: Unknown User
Subject: MC-LAG Layer 3 unicast functionality?
Hi EK.H,
Noted. But in my situation is MX480. One more thing, may i know how u do packet capture in MC-LAG environment? Coz in MC-LAG it will use family bridge. Also when u use MC-LAG on MX is there any MTU decrease by automatically due to family bridge/irb.?
Thanks and appreciate your advise.
Original Message:
Sent: 11-30-2020 05:48
From: Elchin Khudiyev
Subject: MC-LAG Layer 3 unicast functionality?
Hi kronicklez,
There is no mentioning about usage of dynamic or static routing protocols, so it should be applied to both and you need to configure each member of MC-LAG separately with routing configuration. Here is an example:
QFX1
set interfaces irb unit 153 family inet address 172.31.53.2/24 vrrp-group 53 virtual-address 172.31.53.1
set interfaces irb unit 153 family inet address 172.31.53.2/24 vrrp-group 53 priority 200
set interfaces irb unit 153 family inet address 172.31.53.2/24 vrrp-group 53 accept-data
set routing-options static route 172.31.50.31/32 next-hop 172.31.53.31
show route 172.31.53.31
172.31.53.0/24 *[Direct/0] 3w4d 18:31:53
> via irb.153
QFX2
set interfaces irb unit 153 family inet address 172.31.53.3/24 vrrp-group 53 virtual-address 172.31.53.1
set interfaces irb unit 153 family inet address 172.31.53.3/24 vrrp-group 53 priority 150
set interfaces irb unit 153 family inet address 172.31.53.3/24 vrrp-group 53 accept-data
set routing-options static route 172.31.50.31/32 next-hop 172.31.53.31
show route 172.31.53.31
172.31.53.0/24 *[Direct/0] 3w4d 18:32:08
> via irb.153
So each of the members will be able to communicate over directly connected interface in this case.
Also based on the documentation:
There are two methods for enabling Layer 3 unicast functionality across a multichassis link aggregation group (MC-LAG) to control traffic flow. You can choose either to synchronize the MAC addresses for the Layer 3 interfaces of the switches participating in the MC-LAG , or you can configure Virtual Router Redundancy Protocol (VRRP), but you cannot configure both at the same time. Because RVI interfaces share the same MAC address, if you enable MAC address synchronization, packets received on an MC-LAG peer with a destination MAC address that is the same as that of the peer's IRB MAC address will not be forwarded.
I think last statement clearly defines the reason, why this two statements should not being configured at the same time.
Note
On QFX5100 and QFX10000 switches, if you try to configure both VRRP over IRB and MAC synchronization, you will receive a commit error.
------------------------------
Regards,
Elchin
Original Message:
Sent: 11-29-2020 21:09
From: Unknown User
Subject: MC-LAG Layer 3 unicast functionality?
Hi E.K.H,
Based on url that u given, the caveat below referring to IGP right? So if from CE just have default route/static and from MC-LAG have default/static to CE then it should have no issue right?
"NoteHere are some caveats with configuring MAC address synchronization:
Use MAC address synchronization if you are not planning to run routing protocols on the IRB interfaces.
MAC address synchronization does not support routing protocols on IRB interfaces, and routing protocols are not supported with downstream MC-LAG clients. If you need routing capability, configure both VRRP and routing protocols on each MC-LAG peer. Routing protocols are supported on upstream routers."
Appreciate any feedback
Original Message:
Sent: 11-24-2020 07:33
From: Elchin Khudiyev
Subject: MC-LAG Layer 3 unicast functionality?
Hi, it's better to identify first if you really need this type of configuration mix. Here are some recommendations and notes on using VRRP and mac-address synchronization:
https://www.juniper.net/documentation/en_US/junos/topics/concept/best-practices-usage-notes.html#jd0e493
This document was really helpful when I've started configuring different features with MC-LAG installation.
------------------------------
Regards,
Elchin
Original Message:
Sent: 10-21-2020 08:59
From: Unknown User
Subject: MC-LAG Layer 3 unicast functionality?
Hi all,
Based on this url https://www.juniper.net/documentation/en_US/junos/topics/topic-map/mc-lag-high-availability-l3-vrrp-macsync.html#id-example-configuring-multichassis-link-aggregation-for-layer-3-unicast-using-mac-address-synchronization
"You can choose either to synchronize the MAC addresses for the Layer 3 interfaces of the switches participating in the MC-LAG, or you can configure Virtual Router Redundancy Protocol (VRRP), but you cannot configure both at the same time."
It said cannot use at same time. But when i look on config on that url the "mcae-mac-synchronize" was tie into irb interface. So it should not have issue right if we mix in one MC-LAG interface with VRRP and mcae-mac-synchronize with different irb? For example irb.40 i'm use VRRP method and irb.50 i'm use mcae-mac-synchronize method.
Thanks and appreciate any feedback.