cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1488
Views
0
Helpful
2
Replies

Trouble with routing between vlan subnets with VRRP topology

I hope someone out there is able to help me figure this out:

Topology: Two subnets - 10.1.1.0/24 and 10.1.2.0/24 segregated for data and voice traffic, and two links to the internet (one over T1 and one over cable) for redundancy.

I have a Cisco 861W and a Samsung Ubigate router - each router sits on both subnets, with the Ubigate connected to the T1 and the Cisco connected to the cable internet connections.

Both routers run VRRP on each subnet, with the Samsung/T1 router with higher priority on the voice (10.1.2.0/24) subnet and the Cisco with higher priority on the data (10.1.1.0/24) subnet.

Hosts (and phones) on the subnet then point to the VRRPs for their respective subnets as default route.

For the most part this all works perfectly:  Voice traffic goes to the T1, data traffic goes to the cable modem, and if one router goes down, the other router picks up the other half of the outbound traffic.  So far so good.

But here's the problem:

The Cisco router appears to be blocking forwarding between the two subnets unless the Samsung router is disconnected.  In other words, when the Cisco has master VRRP on both subnets, it is forwarding traffic between the two subnets fine.  But when the Samsung router comes on line, while Cisco correctly yields the voice subnet to the Samsung's VRRP - it appears that it is no longer forwarding traffic between the two subnets.  (Specifically, if a host on the data network at 10.1.1.1 tries to ping a phone on the voice network at 10.1.2.1, the ICMP echo request should go to the Cisco (master of 10.1.1.0/24 VRRP), the Cisco should forward it to the phone, and the ICMP echo reply should go to the Samsung (master of the 10.1.2.0/24 VRRP) and forward it back to the host.

I have determined that the fault is on the Cisco side because: If on the host I change the default route to point to the Samsung's subnet address (not VRRP address) instead of the VRRP address, I can ping the other side, meaning that the Samsung is able to route the echo request/reply between the two subnets.  But if I change the default route to point to the Cisco's subnet address, the ping does not go through.

And when I am trying to ping from host to phone using the two VRRP addresses on the two subnets, I get no reply, but when disconnecting the Samsung from the 10.1.2.0/24 subnet, the Cisco correctly takes over VRRP for that subnet and the ping starts to go through.  So I conclude that this is some kind of interaction between VRRP and local routing on the Cisco?

A final note - in the failure mode (e.g. with both Cisco and Samsung up with their respective VRRP masters), while I can't ping between the two subnets, I can ping from the Cisco router to each of the two subnets.

The full (sanitized) configuration is attached.

Any help would be greatly appreciated!

-Ian

1 Accepted Solution

Accepted Solutions

lgijssel
Level 9
Level 9

Reading your problem description, I cannot agree to your conclusion that the cisco router is the culprit.

Your test concentrates on the data network where cisco is already the def-gw.

It will then make little difference whether you use the vrrp address or the interface address.

When pinging from a host, the ip stack on the phone does probably not bother to use the mac on which the request was received but will use the mac of it's def-gw (the samsung vrrp address). This introduces a form of asymmetric routing because the return-path is different from the original.

The most likely reason for this to fail is that the samsung has some firewalling which blocks unsolicited icmp replies.

regards,

Leo

View solution in original post

2 Replies 2

lgijssel
Level 9
Level 9

Reading your problem description, I cannot agree to your conclusion that the cisco router is the culprit.

Your test concentrates on the data network where cisco is already the def-gw.

It will then make little difference whether you use the vrrp address or the interface address.

When pinging from a host, the ip stack on the phone does probably not bother to use the mac on which the request was received but will use the mac of it's def-gw (the samsung vrrp address). This introduces a form of asymmetric routing because the return-path is different from the original.

The most likely reason for this to fail is that the samsung has some firewalling which blocks unsolicited icmp replies.

regards,

Leo

Duh.  You're right.  The Samsung by default has firewall rules to prohibit "asymmetric routing" - turned it off and voila.

-I

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco