You can verify they exist by running ip route show table admin Write the file contents out and quit your editor and now you'll have two empty routing tables. The file should be fairly short, so just append the values you want which, in my case, are two tables admin and users (numbered 1 and 2, respectively), since one Ethernet device is for user traffic and one is for admin traffic. To do this, we'll just append them to the end of the file using our editor of choice, vi. We need to add the new routing tables to /etc/iproute2/rt_tables. We don't necessarily need to do this next step, but it's a nicety and makes things easier to understand later so we'll do it. Since there is no way to have two default routes for a single routing table (that kind of defeats the purpose of the default route bit), we need to create additional routing tables. This causes the issues described above where traffic coming in eth1 is going out eth0. Yet, since the first line has a lower "metric", it is the preferred default route of the host. However, there's a problem: there's two default routes specified. By default, any traffic that comes in or out looks at this table to determine where it should be going. This is showing you the primary routing table for your Linux host. With that in mind, if you open up your console right now and type ip route, chances are the output will look something like this: $ ip routeĭefault via 10.255.254.1 dev eth0 proto static metric 100ĭefault via 10.255.72.1 dev eth1 proto static metric 101ġ0.255.72.0/22 dev eth1 proto kernel scope link src 10.255.72.230 metric 101ġ0.255.254.0/24 dev eth0 proto kernel scope link src 10.255.254.45 metric 100 The way that Linux accomplishes this is through the use of multiple routing tables.īefore getting too far into this, I want to note that all of these commands were run on RHEL7 hosts, so your-mileage-may-vary on other distros. Policy based routing, for our purposes, means "route traffic based on policy I write rather than your default behavior".
To specify where traffic should go out based upon where it came in, we need to set up what is known as Policy Based Routing. Unfortunately, this isn't as easy as just flipping a switch and being done with it. In order to solve the problem of asymmetric routing, we have to force our server to symmetrically route the traffic. Note: Asymmetric routing is fairly normal and would not be much of a user-impactful issue if both interfaces were on the same network, or both networks had equivalent firewall rules But How Do I Fix It? This is because eth1's network is awaiting a response from the server, but the server tried to send the response to eth0 's network. It will reach the last hop before the server but then never receive a response back. If eth0 's network is the default route, attempt to ping eth1's IP address.
Opensuse route gateway Pc#
If the host is configured to use eth0 's network as the default and an admin tries to access services running on Container 3 connected to eth1's network, the traffic will come in via eth1 and attempt to go out via eth0, where the packets will be dropped since eth0 's network never allowed a connection to the host from the Admin's PC (since it was eth1's network that allowed the inbound connection and is awaiting a response).Īn easy way to test this is by using a ping test. However, if the host's default route (more on this later) is configured to use eth1 's network, then the traffic coming in eth0 will try to go out of eth1 and will be unable to route back to the end user.
So they will try to access Container 1 that is connected to eth0 's network (on class 6), which they should have access to. In my environment, the network that the majority of end users are on does not have access to the server VLAN, which firewall class 10 is a part of. In this example architecture, asymmetric routing would occur when a packet comes in to eth0 but tries to leave via eth1. To demonstrate, consider this architecture: The issue was asymmetric routing.Īsymmetric routing, in simple terms, is when network traffic comes in a different interface than it goes out. Recently, while working on a project to spin up a server running a few different Docker services as part of a Prometheus stack, I ran into an issue that left me, a network engineer, and another SysAdmin dumbfounded for a few hours. Menu Avoiding Asymmetric Routing on Linux: Sending Traffic Out the Interface it Entered
0 kommentar(er)
