9

It happens that I run across customers who have what I define as an "asymetric routing" in their networks. Simply said, they have two gateways on the same IP subnet. The clients are configured to point at one gateway (i.e. 172.16.1.1) but there is another device (i.e. 172.16.1.2) which connects and routes to somewhere. Mostly I've seen this kind of setup when there are 2 different types of WAN connections: 1 internet connection and 1 corporate MPLS connection.

I'm personally not attracted by the above kind of network design: each subnet has to have one and only one gateway. From my point of view, the above scenario may create some issues for clients, because they send a packet to their default gateway (172.16.1.1) and those packets are then forwarded out the other router (172.16.1.2) and when they get replied to, they reach the client simply passing through 172.16.1.2. The clients would or should expect the reply packets come from 172.16.1.1, or am I wrong here?

I'd be happy to have your opinions and technical views of this issue.

Improve this question
1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin♦ Jan 3 at 5:25
11

I would recommend that you look into First Hop Redundancy Protocols like HSRP or VRRP.

Actually, having two gateways can be a very good network design, because if a router were to fail, the other router can take over somewhat seamlessly. However, as you're aware, it's not easy to make this transition if you have to make a manual reconfiguration of each client on a subnet.

Protocols like HSRP (or VRRP if you have non-Cisco gear) allow you to have two (or more) routers (or L3 switches) on a subnet share a single IP address. You'll have your first router with an address of .2, the seond with an address of .3, and a "virtual IP address" of .1 that both routers are aware of through configuration. When the primary router fails, the secondary is able to detect this and take over the virtual IP address, meaning that your clients just need to have .1 configured as their gateway and you're good to go.

In terms of routing design, that would largely depend on the current setup. It's possible that both gateways lead to the same internet edge, in which case you may not have a problem. Asymmetric routing can be bad, mainly because you risk packets being delivered in the wrong order, but again, depends greatly on the topology you're talking about.

Lots of design principles implied in what I just said. I suggest you research both protocols, and determine what's best for your environment. If you're using Cisco gear, HSRP is a widely used and well understood method of solving this problem.

Improve this answer
2
  • and don't forget that there is also GLBP too which does the same sorta thing HSRP/VRRP (well kinda) but allows boths gateways to actually load-balance traffic. Just becomes a bit more difficult to debug at times as some clients may be on R1 and others may be on R2 – knotseh Jun 25 '13 at 21:24
  • @mierdin, asymmetric routing has nothing to do with packet reordering... reordering typically comes as the result of multipath routes for the same prefix... – This Jun 26 '13 at 19:23
9

The entire internet is built on asymmetric routing, so it's very common. Clients are interested in the interface they receive the packet on and the source of the packet, not which router passed it to them on that interface.

Asymmetric routing can get problematic however when devices keeping track of state (especially firewalls) and NAT are involved, but as far as I can tell this isn't the case in your example.

Improve this answer
3
  • It could also be an issue when you are running some kind of reverse path forwarding. Otherwise its not that big of an issue – mellowd Jun 25 '13 at 21:21
  • Why would that be a problem? The route exists and matches the interfaces, so even strict RPF wouldn't trigger here. – Teun Vink♦ Jun 25 '13 at 21:33
  • if a router has two external interfaces with packets going out one way (following IGP) and coming back into another, it would drop that packet. The incoming packet would fail a strict RPF check, unless of course the costs are equal – mellowd Jun 26 '13 at 9:39
4

Network clients identify traffic flows based on the combination of 4 values:

  • Source Address
  • Source Port
  • Destination Address
  • Destination Port

For every different connection the 4 values above form a different combination wich is used to match the reply packets to the right flow. As you can see, the gateway or next-hop address is not included in the list and therefore the client will not care if a packet comes back through the same gateway it used to send its packets. So, network clients do not care about assymmetric routing as soon as they can receive the traffic from the remote end. Actually, TCP/IP was designed originally to support assymmetric routing.

However, if we focus on network intermediate devices, assymmetric routing is not tolerated as soon as you are using any device/technology that needs seeing all packets in a connection to provide a given functionality. For instance: NAT, stateful firewalls or some WAN optimizators. Assymmetric routing in such scenario would cause either the intended functionality not being provided or, even worst, packets being drop making communication impossible.

Improve this answer
3

I agree with the answers before me, but I have to add something : if there any filtering on any of the gateways, or on any hop that are passed via only 1 of the 2 gateways, issues are likely to arise! (hops that get passed via both gateways, such as the source machine, the destination machine, and any "common to both gateway paths" hops, are not concerned with the following scenarios)

For example, if A send packets to B through gateway1, and packets returns via gateway2, then it's highly likely that reply packet will be dropped if gateway2 is doing filtering (because that gateway didn't see the initiating connection packet, so it doesn't expecta reply, thus if the dest/port of the reply packet is usually filtered, it will be filtered.)

(There are, of course, many similar scenarios)

Improve this answer
0

Other two areas where asymmetric routes will cause trouble are those: 1. MTU discovery - if the smallest MTU of the two paths differ, end-point MTU path discovery could result in a largest of the two MTU, which in turn will result in dropping of maximum size packets. For example, if one path goes through a VPN tunnel and the other does not, the VPN tunnel will have a smaller MTU. ping will work fine, but transferring large files will fail consistently. 2. Connectivity trouble shooting will be more difficult if one of the two path is broken but the other is not. Good old "traceroute" will be no help at all, as it will not be able to detect the reverse path intermediate points, unless it is exercised from both sides of the connection, which requires an out-of-band management channel ...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.