Junos OS

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

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

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

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

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

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

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.