Routing

Expand all | Collapse all

VRRP assistance

  • 1.  VRRP assistance

    Posted 01-19-2021 11:03
    I have the following topology.
    Everything works fine until I applied an ACL for irb.181.   What confused me is both MX routers became Masters if I applied ACL to IRB.181.  Two MX routers still ping each other.

    thanks in advance !!



  • 2.  RE: VRRP assistance

     
    Posted 01-19-2021 11:33

     

    Thanks for the details.

    VRRP master sends advertisements to VRRP backup to convey that router is master.

     

    For some reason if expected backup router (router with worse priority) doesn't receive those advertisement it assumes it should be master and starts sending advertisement which either gets dropped or reaches to the expected master (router with better priority) but since this  (expected master) router has better priority it remains as master and you end up getting split brain condition (both router as VRRP master)

     

    In nut shell, VRRP advertisement from expected master is not reaching to the expected backup.

     This means that VRRP Advertisements are getting dropped when you are applying the firewall filter on the IRB. So I would check the firewall filter configuration.

    In working condition, in the <monitor traffic interface irb.181 no-resolve matching "proto 112"> output taken on expected backup, you should see the VRRP advertisement packet from expected master

    Thanks
    Vishal Singh


    Juniper Business Use Only






  • 3.  RE: VRRP assistance

    Posted 01-19-2021 11:42
    thanks for quick response.

    What I don't understand is what traffic between two MX routers can be affected ACL on IRB.181 ?


  • 4.  RE: VRRP assistance

    Posted 01-19-2021 11:52
    Hi,

    we would need to see the ACL to have a look if you accidentally filtered the VRRP Messages :)

    BR
    Christian

    ------------------------------
    Christian Scholz
    Juniper Networks Ambassador | JNCIE-SEC #374
    Mail: chs@ip4.de
    Blog: jncie.eu | Twitter: @chsjuniper | YT-Channel: netchron
    ------------------------------



  • 5.  RE: VRRP assistance

    Posted 01-19-2021 12:00
    MX router VRRP traffic should not go through IRB.181, right ?  If not, how could ACL affect MX router VRRP traffic?  I thought VRRP traffic for MX routers just passes xe-0/0/4 which has not ACL on it. only vlan 181.

    thanks !!


  • 6.  RE: VRRP assistance

     
    Posted 01-19-2021 12:03
    If you can send your interface and firewall configuration that will help to understand what's going on.


  • 7.  RE: VRRP assistance

    Posted 01-19-2021 12:06
    set interfaces irb unit 181 family inet filter input SAN_Inbound
    set firewall filter Inbound term 1 from source-address 172.31.20.0/23
    set firewall filter Inbound term 1 from source-address 172.31.40.0/23
    set firewall filter Inbound term 1 from source-address 172.31.60.0/23
    set firewall filter Inbound term 1 from source-address 172.31.62.0/23
    set firewall filter Inbound term 1 from source-address 10.68.190.0/24
    set firewall filter Inbound term 1 from source-address 150.152.48.96/27
    set firewall filter Inbound term 1 from destination-address 150.152.48.96/27
    set firewall filter Inbound term 1 from destination-address 10.68.190.0/24
    set firewall filter Inbound term 1 then accept
    set firewall filter Inbound term 2 from source-address 0.0.0.0/0
    set firewall filter Inbound term 2 then count traffic-deny
    set firewall filter Inbound term 2 then reject

    Here is ACL !!
    thanks !!


  • 8.  RE: VRRP assistance

     
    Posted 01-19-2021 12:20

    Your destination address doesn't allow the VRRP multicast address (224.0.0.18) so the advertisement are getting dropped

     

     

    set firewall filter SAN_Inbound term 1 from destination-address 140.142.48.96/27
    set firewall filter SAN_Inbound term 1 from destination-address 10.68.190.0/24

     

     

    Thanks
    Vishal Singh


    Juniper Business Use Only






  • 9.  RE: VRRP assistance

    Posted 01-19-2021 12:26
    MX routers do not peer with irb.181 for vrrp.  Why does irb.181 need to accept 224.0.0.18?  This is what I don't understand.

    thanks !!


  • 10.  RE: VRRP assistance

     
    Posted 01-19-2021 12:31

    irb interface does all the L3 packet processing that's why you need to allow packet to reach to the irb

     


    Juniper Business Use Only






  • 11.  RE: VRRP assistance

    Posted 01-19-2021 13:28
    In my understanding, MX routers only need layer 2 to form VRRP, one master and one backup.
    If both are masters, some traffic is blocked or dropped.  But what I do not understand is why IRB.181 can affect these two VRRP to form a master and a backup.

    thanks !!


  • 12.  RE: VRRP assistance

     
    Posted 01-19-2021 13:35

    Actually No, VRRP serves layer-2 domain but it needs IP connectivity and protocol exchange between master and backup. Try that change in firewall filter and check if everything works.

     

     


    Juniper Business Use Only






  • 13.  RE: VRRP assistance

    Posted 01-19-2021 13:47
    I did packet capture to notice all the VRRP traffic to 224.0.0.18.  My understanding is all the VRRP information is exchanged via this Multicast address.

    1.  I did add 224.0.0.18 to the ACL applied irb.181.  It did not fix the issue.
    2.  My virtual lab works fine without 224.0.0.18 in the irb.181 ACL.
    3.  I still don't understand why ACL applied to IRB.181 affects the two MX routers to form VRRP correctly. The communication between these two MX routers to form VRRP correctly should not go through IRB.181.  Right ?     I might miss something here. like to know what I have missed here.

    thanks a lot !!


  • 14.  RE: VRRP assistance

     
    Posted 01-19-2021 21:12
    Is this what you are doing? 

    I am assuming  that xe-0/0/2 and xe-0/0/4 on QFX1 and xe-0/0/3 and xe-0/0/4 on QFX2 are all layer interfaces and part of VLAN 181, so that there is layer 2 connectivity all the way from MXR1 ge-0/0/2 and MXR2 ge-0/0/3 (which are configured on the same subnet). 

    If all the above is true, then I agree with you than a FF on irb.181 should NOT affect VRRP between the two MX routers, though it would affect VRRP between the two QFXs.  Only if L2 connectivity breaks, and the VRRP messages do not make all the way through between the two routers they both assume they are alone in the network and both  take the master role. 

    If there anything different in your configuration to what I described? 

    Also, why would you want to have VRRP between the two MXs and also VRRP between the two QFXs in the same subnet? 

    Regards, 


    ------------------------------
    Yasmin Lara
    Juniper Ambassador
    JNCIE-SP, JNCIE-ENT, JNCIE-DC, JNCIE-SEC
    JNCDS-DC, JNCIA-DevOps, JNCIP-CLOUD, CCNP-ENT
    ------------------------------



  • 15.  RE: VRRP assistance

    Posted 01-19-2021 23:06
    thanks a million for your help. 
    The following is my topology.


    MX routers are managed by our uplink provider. Their VRRP traffic goes through our L2 link (xe-0/0/4 tagged 181).  We created two VRRP groups, one is used for uplink (VRRP group 51), the other group (VRRP 55) for internal link.
    xe-0/0/2 and xe-0/0/3 on both QFX are layer 2 interfaces. xe-0/0/4 on both QFX are also layer 2 interfaces.

    Without ACL applied to IRB.181, everything works fine. But as soon as ACL is applied, MX routers breaks,  both becomes master.  Both routers can ping each other during VRRP break.

    I asked many people around,  most of them told me to add VRRP and 224.0.0.18 to ACL. I know these two are needed for VRRP ACL. But here I do not understand why ACL applied IRB.181 affects MX router VRRP.

    My understanding is VRRP formation requires Layer 2 communication, but IRB is layer 3 interface.

    I know I missed something here, but do not know what.

    Do you think this topology is fine ?

    One more thing, I tested this in my virtual lab, (both MX and QFX are vmwares). It works fine, including ACL applied. I am so stuck here.

    thanks a lot !!




  • 16.  RE: VRRP assistance

     
    Posted 01-20-2021 14:14
    I agree,  you only need layer 2 connectivity...   

    Are you sure you have different VRRP groups between the  MX routers and the QFX routers in network 150.152.48.104/30? 
    From what you are showing in the diagram, subnets 150.152.48.104/30 and 150.152.48.98/30 are on the same VLAN, this could cause conflicts between the two groups if the numbers are not different (which "could" potentially explain the effect of the ACL).  


    And just to make sure,  NO IP addresses on xe-0/0/2, xe-0/0/3 and xe-0/0/4 on the switches, and all 3 interfaces are configured with family ethernet-switching, correct? 

    Now, I still don't see why you would need VRRP between the MXs! Or even why you would need VRRP between the QFXs in VLAN 181.  That doesn't make much sense to me. 

    Logically this is how it looks like : 

    • Are the MXs connecting to the WAN or Core ? 
    • How are you exchanging routing information between the QFXs and MX?  Static routes pointing to VIP?  
    Typically you connect to the WAN using something similar to this:   

    Could have statics with BFD instead of BGP. 

    Regards, 


    ------------------------------
    Yasmin Lara
    Juniper Ambassador
    JNCIE-SP, JNCIE-ENT, JNCIE-DC, JNCIE-SEC
    JNCDS-DC, JNCIA-DevOps, JNCIP-CLOUD, CCNP-ENT
    ------------------------------



  • 17.  RE: VRRP assistance

    Posted 01-20-2021 15:57
    1.   Yes, all the VRRP groups are different.
    2.   Yes, xe-0/0/2, xe-0/0/3 and xe-0/0/4 are all configured with family ethernet-switching
    3.  VRRP has been used for a long time and no intention to change. even though I suggested  BGP approach. Hard to be accepted.
    4.  All the routing information is exchanged via static routes.

    thanks so so much for your time, patience, insights and assistance !!


  • 18.  RE: VRRP assistance

     
    Posted 01-20-2021 21:22
    oh you are more than welcome!  

    I am guessing the issue with the  firewall filter might be because of the QFX architecture and how the filters are applied at the PFE level, but again I am guessing. 

    Maybe open a case with JTAC. 

    Regards,

    ------------------------------
    Yasmin Lara
    Juniper Ambassador
    JNCIE-SP, JNCIE-ENT, JNCIE-DC, JNCIE-SEC
    JNCDS-DC, JNCIA-DevOps, JNCIP-CLOUD, CCNP-ENT
    ------------------------------



  • 19.  RE: VRRP assistance

    Posted 01-20-2021 21:28
    thanks a million!!

    I did open a case for Juniper.  They are testing in their lab.


  • 20.  RE: VRRP assistance

     
    Posted 01-21-2021 18:14
    Per our email exchange, we have seen similar behavior on Triumph3 systems (EX4300) where configuring an IRB interface would cause multicast traffic to punt to the CPU. QFX 1RU use Trident, but it could be something similar. There was a PR opened for this, but it was closed out with "Works per design".

    Not saying this is the case with the QFX you are using, but it sounds plausible. TAC should be able to tell you if this is the case.


    ------------------------------
    Consulting Engineer - Juniper Networks
    YouTube - 5MinuteJunos
    ------------------------------



  • 21.  RE: VRRP assistance

    Posted 01-25-2021 23:03
    Today I worked with Juniper tech support in their lab with two QFX5200 and two MX480. We could replicate the issue. As soon as we changed filter input to filter output. This issue was gone.

    thanks for your help !!