vSRX
Highlighted
vSRX

vSRX VRRP VIP not responding and not forwarding traffic to the outside

[ Edited ]
‎10-01-2017 03:07 AM

Hi All,

 

I've been using various Juniper devices for quite some time now in different infrastructures and actually never had to deal with a problem like this but unfortunately, there is always the first time!

 

I am managing a virtualized infrastructure for a client based on vSphere 6.5 with multiple hypervisors and dual vSRX instances used as routers, e.g. security flow is configured to packet-based for Inet, Inet6, MPLS and ISO. These are the only rules configured for security and any other default security configurations have been removed. I have proper filters allowing the VRRP protocol and both vSRX instances talk to each other and designate a master properly. I have also configured accept-data for the VRRP group in order to allow the router to accept packets destined to the VRRP virtual IP.

 

On the hypervisors side, I am dealing with the latest ESXi 6.5.0 Update 1 (5969303). For the sake of testing, a separate vDS (vSphere Distributed Switch) is configured. A port group is configured within the vDS and promiscuous mode, MAC address changes, and forged transmits are all enabled. Both vSRX instances have ge-0/0/3 configured within the port group, and for the sake of testing, I have another Linux VM sitting in the same port group, configured with L3 IP address within the same subnet and with the VRRP virtual IP configured as the default gateway.

 

Also in order to troubleshoot the issue, I have configured Port Mirroring on the vDS and I mirror the port where the ge-0/0/3 interface on the VRRP Master vSRX is connected to another Linux box where I do packet captures.

 

THE PROBLEM: Any host sitting within the same subnet and trying to route traffic through the VRRP VIP fails to do so. Hosts sitting in the same subnet are also unable to ping the VRRP VIP even though accept-data is set.

 

THE HARDWARE: Tests have been performed with both 15.1X49-D100 & 17.3R1.10

 

THE TROUBLESHOOTING:

 

1) The packet capture on the mirrored ge-0/0/3 of the VRRP Master shows the following:

 

     a) When a host sitting in the same subnet initiates an ICMP echo request to the VRRP VIP, the ICMP echo request is being properly switched by the vDS/Port Group and is delivered to the vSRX ge-0/0/3. The vSRX does not respond to the ICMP echo request.

 

     b) When a host sitting in the same subnet initiates an ICMP echo request to any destination that needs to be routed and uses VRRP VIP as GW the packet is not being forwarded by the vSRX, but is being silently ignored.

 

     c) When a host sitting outside of the VRRP subnet, e.g. L3 routed, initiates an ICMP echo request to the VRRP VIP it receives a proper reply.

 

     d) When a host sitting outside the VRRP subnet, e.g. L3 routed, initiates an ICMP echo request to the Linux host within the VRRP subnet, the request is properly forwarded by the vSRX and reaches the Linux host that uses the VRRP VIP as GW. The Linux host then responds to the ICMP echo request and on the port mirror, I can see the ICMP echo reply reaching back to the vSRX. The latter packet is again ignored by the vSRX and not being forwarded back.

 

2) Enabling promiscuous mode on the interface where we have VRRP configured on e.g. ge-0/0/3 partially solves the issue. After the promiscuous mode is enabled on the master vSRX, it starts responding to ICMP echo requests to its VRRP VIP from within the same subnet and starts forwarding traffic through it. But due to the fact that promiscuous mode is enabled on the vSphere Port Group, enabling promiscuous mode on both vSRX instances leads to an infinite loop and infinite packet duplication.

 

3) Using either one of the vSRX instances family inet IP address directly as GW, works just fine.

 

4) VRRP VIP on the current master properly responds to ARP.

 

5) I have tried with any configurations directly on the interface (ge-0/0/3), the unit (unit 0), the family inet, or the family inet address itself that made sense like gratuitous-arp-reply, no-gratuitous-arp-reply, no-gratuitous-arp-request, arp-resp, etc, but neither one has made any difference and the only way I can make a vSRX respond to its VIP is either if I enable promiscuous mode to ge-0/0/3 itself (set interfaces ge-0/0/3 promiscuous-mode), or if I start monitoring the traffic on the same interface which enabled promiscuous mode on it (run monitor traffic interface ge-0/0/3).

 

6) I have also tested with dual Linux VMs running VRRPD where VRRP works just fine.

 

THE VRRP CONFIGURATION - I am sure that this is not the issue, but as I know some of you will think I am crazy and will ask for it here is the conf:

 

vSRX_1:

set interfaces ge-0/0/3 mtu 9000
set interfaces ge-0/0/3 unit 0 family inet mtu 1500
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.241/29 vrrp-group 255 virtual-address 10.128.22.243
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.241/29 vrrp-group 255 priority 150
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.241/29 vrrp-group 255 advertise-interval 1
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.241/29 vrrp-group 255 preempt
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.241/29 vrrp-group 255 accept-data

 

vSRX_2:
set interfaces ge-0/0/3 mtu 9000
set interfaces ge-0/0/3 unit 0 family inet mtu 1500
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.242/29 vrrp-group 255 virtual-address 10.128.22.243
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.242/29 vrrp-group 255 priority 100
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.242/29 vrrp-group 255 advertise-interval 1
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.242/29 vrrp-group 255 preempt
set interfaces ge-0/0/3 unit 0 family inet address 10.128.22.242/29 vrrp-group 255 accept-data

 

THE CONCLUSION: 

 

The behaviour I see is that unless the interface where VRRP is configured on is set in promiscuous mode, vSRX actually ignores the traffic destined to or through its VRRP VIP address when the traffic is coming from within the same subnet. With that in mind together with the fact that VRRP VIP responds to and forwards anything coming from outside on L3, I am inclined to believe that vSRX refuses to accept traffic destined to its VRRP VIP MAC at the data link layer.

 

I know this is a very long message already, but any help that might render useful is kindly appreciated as I am already stuck and I wasted a lot of time troubleshooting. 

 

Thank you all for reading!

 

Best,

KG

1 REPLY 1
Highlighted
vSRX

Re: vSRX VRRP VIP not responding and not forwarding traffic to the outside

‎10-23-2017 12:46 AM

Hello,

Checking release notes, I see as below. 

https://www.juniper.net/documentation/en_US/vsrx/information-products/topic-collections/release-note...

 

  • VRRP is not supported on VMware hypervisors because of a VMware support limitation for virtual MAC addresses.

Regards

Vatsa

Feedback