Junos OS

Expand all | Collapse all

VRRP asymmetric traffic

Jump to Best Answer
  • 1.  VRRP asymmetric traffic

    Posted 10-08-2019 06:28

    Hi,

    I have a VRRP towards a customer with with the master interface on an MX104 and the backup interface on an MX960. I have a problem with the traffic being asymmetric. Traffic towards the customer is running via the master while the return traffic is running via the backup. One thing that confuses me is that I see arp being resolved on both master and backup and probably that's why this asymmetry is happening. How come the arp is being resolved on both routers? Is this correct?

     

     

     

    VRRP Master
    MX104 Junos 15.1R6.7

    PE01> show configuration interfaces ge-0/0/1.100
    description "To Customer Acme;VRRP MASTER";
    vlan-id 100;
    family inet {
    address 10.1.1.2/24 {
    vrrp-group 200 {
    virtual-address 10.1.1.1;
    priority 110;
    accept-data;
    }
    }
    }


    PE01> show arp no-resolve | match ge-0/0/1.100
    44:f4:77:89:c4:06 10.1.1.3 ge-0/0/1.100 none <------ MAC/IP from backup router
    9c:7b:ef:93:31:a1 10.1.1.10 ge-0/0/1.100 none
    80:e8:2c:07:5e:a3 10.1.1.11 ge-0/0/1.100 none
    80:e8:2c:07:5e:60 10.1.1.12 ge-0/0/1.100 none
    80:e8:2c:07:5e:19 10.1.1.13 ge-0/0/1.100 none

     

     

     

    VRRP Backup
    MX960 Junos 15.1R7.9
    PE02> show configuration interfaces xe-0/0/6.100
    description "To Customer Acme;VRRP BACKUP";
    vlan-id 100;
    family inet {
    address 10.1.1.3/24 {
    vrrp-group 200 {
    virtual-address 10.1.1.1;
    priority 100;
    accept-data;
    }
    }
    }


    PE02> show arp no-resolve | match xe-0/0/6.100
    00:00:5e:00:01:c8 10.1.1.1 xe-0/0/6.100 none <------ VIP from
    80:ac:ac:9c:e8:48 10.1.1.2 xe-0/0/6.100 none <------ MAC/IP from master router
    9c:7b:ef:93:31:a1 10.1.1.10 xe-0/0/6.100 none
    80:e8:2c:07:5f:a3 10.1.1.11 xe-0/0/6.100 none
    80:e8:2c:07:5e:60 10.1.1.12 xe-0/0/6.100 none
    80:e8:2c:07:5e:19 10.1.1.13 xe-0/0/6.100 none



  • 2.  RE: VRRP asymmetric traffic

     
    Posted 10-08-2019 07:38

    Hi,

     

    arp is being resolved on the backup vrrp router due to the return/inbound asymmetric traffic. To forward to the next hop, arp needs to resolve ip to mac.

     

    "One thing that confuses me is that I see arp being resolved on both master and backup and probably that's why this asymmetry is happening."

    >> It's rather the opposite that is more likely here, i.e arp being resolved because of the asymmetric inbound traffic.

     

    The asymmetric inbound traffic is due to the upstream nodes seeing the VRRP backup router as a preferred path/next-hop.

     

    To try enforce symmetric traffic, vrrp track can be used to track various metrics.

    https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/track-edit-interfaces-vrrp.html

     

    Hope this helps.

     

    Cheers,

    Ashvin



  • 3.  RE: VRRP asymmetric traffic

    Posted 10-08-2019 08:17

    Hi Ashvin,

    Thanks for your input on this!

    However I thought the backup didn't claim the VIP unless it becomes master. And as a result the VIP mac address wouldn't be coming from the backup into the LAN switches. But maybe that's not how VRRP works?

     

    Actually I have now bounced the interface during trouble-shooting and then it became the other way around. Traffic towards the customer is running over the backup link now instead and traffic back from the customer is coming via the master.

     

    Regarding the tracking I'm not sure what to track in this case as the MX's are part of our mpls network. In other words they have direct connectivity between them over mpls. Hence no typical uplinks or routes to track.

     

    Any help is appreciated.

     

    Erac



  • 4.  RE: VRRP asymmetric traffic
    Best Answer

     
    Posted 10-08-2019 09:04

    Hi, 

     

    "However I thought the backup didn't claim the VIP unless it becomes master."

    >> Correct. The backup will not claim the VIP address and also not respond to arp towards the VIP.

    Note that the MAC address for the VIP is an IANA multicast MAC bearing the vrrp group ID: 

    00:00:5e:00:01:c8    -->  c8 in dec = 200 (vrrp group id)

     

    To force symmetry, assuming its an L3VPN, this could be done on the PEs' vrf export policies and using local-preference as one of the BGP attributes to influence inbound traffic.

    Question is how are the PEs learning the CE routes. All depending on the setup and routing protocols on PE-CE side, the symmetry could be enforced accordingly, with a combination of additional monitoring of the routes using BFD etc.

     

    Cheers, 

    Ashvin

     



  • 5.  RE: VRRP asymmetric traffic

    Posted 10-13-2019 14:26

    Hi Ashvin,

     

    Thanks for your suggestions! I will probably go for moving the VRRP out of our MPLS network and instead setup BGP sessions from the VRRP boxes to the MPLS network. That way I can influence traffic going towards the customer. Actyally I believe I don't need to move the VRRP away from the MPLS box (MX104) at all. I could just put the VRRP interfaces in virtual-router instances and then peer with logical tunnel interfaces into the VRF's instance on the same MX. Then run BGP on the peering logical tunnel interfaces. This should work right? Well I will test it in the lab anyway.

     

    Thanks for all the help!

     

    Erac



  • 6.  RE: VRRP asymmetric traffic

     
    Posted 10-08-2019 08:26

    Hi ErAc,

     

    The output that you are seeing seems to be correct.

     

    VRRP is only relevant in the L2 domain (downstream). Traffic going to upstream device should take the VRRP master as the destination MAC is VMAC of VIP which is owned by VRRP master.

     

    Traffic coming back doesn't have any sense of VRRP setup so routing is taking care of return traffic ending up on the VRRP backup.

     

    If you want the return traffic to take VRRP master you will need to make sure that upstream device has VRRP master as next-hop.

    PS: Please accpet my response as solution if it answers your query. Kudos are apprecuated too!

    Thanks

    Vishal



  • 7.  RE: VRRP asymmetric traffic

     
    Posted 10-09-2019 03:16

    Is the customer configured to use the vip as their gateway?

    If they are the traffic should come to your master on vrrp.  I wonder why there is no learned mac for the vip 10.1.1.1 on the customer side.

     

    Maybe you are peering bgp and they learn the physical address as the next hop?

    If that is the case and you have dual peers the import policy on the customer side can use local pref to steer the trafic to your primary when present.  Or you can configure med with the dual peers.