Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  MC-LAG Layer 3 unicast functionality?

    Posted 10-21-2020 08:59

    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.

     

     



  • 2.  RE: MC-LAG Layer 3 unicast functionality?

    Posted 11-20-2020 20:22
    That's an interesting questions!!! 

    I've tested MC-LAG extensively, but never tested having both VRRP and mcae-mac-synchronize at the same time as you mentioned.  I cannot  think of a reason why it would not work, BUT I would test it carefully before implementing it in production.   I would look closely at loop avoidance, and failover under different failure scenarios.  

    Regards, 



  • 3.  RE: MC-LAG Layer 3 unicast functionality?

    Posted 11-24-2020 07:34
    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
    ------------------------------



  • 4.  RE: MC-LAG Layer 3 unicast functionality?

    Posted 11-29-2020 21:09
    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?

    "Note

    Here 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



  • 5.  RE: MC-LAG Layer 3 unicast functionality?

    Posted 11-30-2020 05:48
    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
    ------------------------------



  • 6.  RE: MC-LAG Layer 3 unicast functionality?

    Posted 11-30-2020 06:06
    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.


  • 7.  RE: MC-LAG Layer 3 unicast functionality?

    Posted 12-01-2020 10:17
    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: 9192

    irb 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: 1500
    Protocol multiservice, MTU: 1500
    As 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: 9170
    Protocol 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:

    • In case of Layer 2 IFL configured with the flexible-vlan-tagging statement, the IRB MTU is calculated by including 8 bytes overhead (SVLAN+CVLAN).

    • In case of Layer 2 IFL configured with the vlan-tagging statement, the IRB MTU is calculated by including a single VLAN 4 bytes overhead.
    This also might help to understand MTU of irb interfaces on MX devices: [MX] MTU calculation on logical IRB interfaces .


    ------------------------------
    Regards,
    Elchin
    ------------------------------