{"id":1514,"date":"2022-03-03T04:02:32","date_gmt":"2022-03-03T02:02:32","guid":{"rendered":"http:\/\/www.shukko.com\/x3\/?p=1514"},"modified":"2022-03-03T04:02:32","modified_gmt":"2022-03-03T02:02:32","slug":"configure-two-network-cards-in-a-different-subnet-on-rhel-6-rhel-7-centos-6-and-centos-7","status":"publish","type":"post","link":"https:\/\/www.shukko.com\/x3\/2022\/03\/03\/configure-two-network-cards-in-a-different-subnet-on-rhel-6-rhel-7-centos-6-and-centos-7\/","title":{"rendered":"Configure two network cards in a different subnet on RHEL 6, RHEL 7, CentOS 6 and CentOS 7"},"content":{"rendered":"\n<p>The goal is to become symmetric routing:<\/p>\n\n\n\n<p>Each interface on the server should have it\u2019s own default gateway, which allows that interface to reply itself to incoming packets from other networks.<\/p>\n\n\n\n<p>A normal routing table can only have one default gateway. This is quite logical since it\u2019s the place where to send packets that do not match anything else in the rest of the table. To be able to have two default gateways, one for each interface, you need to setup policy based routing.<\/p>\n\n\n\n<p>Policy based routing allows you to have multiple routing tables. Which table is used, depends on a set of rules.<\/p>\n\n\n\n<p>To setup policy based routing for our example case, we will use two policy based tables. While it is possible to give a nice name to the tables (in \/etc\/iproute2\/rt_tables), it\u2019s not really when you only plan to have a few. Without a name, the tables are automatically created when you\u2019re adding something to them.<\/p>\n\n\n\n<p>Let\u2019s start with adding a route for the network itself (link) and one for the default gateway for each interface. ens192 (192.168.0.10) will use table 1, ens224 (192.168.1.10) will use table 2.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;jensd@server ~]$ sudo ip route add 192.168.0.0\/24 dev ens192 tab 1\n&#91;jensd@server ~]$ sudo ip route add 192.168.1.0\/24 dev ens224 tab 2\n&#91;jensd@server ~]$ sudo ip route add default via 192.168.0.1 dev ens192 tab 1\n&#91;jensd@server ~]$ sudo ip route add default via 192.168.1.1 dev ens224 tab 2<\/code><\/pre>\n\n\n\n<p>To define when table 1 or 2 will be used, we\u2019ll add a rule, based on the source of the packet to the policy and refresh the policy based routing:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;jensd@server ~]$ sudo ip rule add from 192.168.0.10\/32 tab 1 priority 100\n&#91;jensd@server ~]$ sudo ip rule add from 192.168.1.10\/32 tab 2 priority 200\n&#91;jensd@server ~]$ sudo ip route flush cache<\/code><\/pre>\n\n\n\n<p>To check if we did everything correctly, let\u2019s list the tables and the rules:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;jensd@server ~]$ ip route show tab 1\ndefault via 192.168.0.1 dev ens192\n192.168.0.0\/24 dev ens192  scope link\n&#91;jensd@server ~]$ ip route show tab 2\ndefault via 192.168.1.1 dev ens224\n192.168.1.0\/24 dev ens224  scope link\n&#91;jensd@server ~]$ ip rule show\n0:      from all lookup local\n100:    from 192.168.0.10 lookup 1\n200:    from 192.168.1.10 lookup 2\n32766:  from all lookup main\n32767:  from all lookup default\n&#91;jensd@server ~]$ ip route\ndefault via 192.168.0.10 dev ens192\n169.254.0.0\/16 dev ens192  scope link  metric 1002\n169.254.0.0\/16 dev ens224  scope link  metric 1003\n192.168.1.0\/24 dev ens224  proto kernel  scope link  src 192.168.1.10\n192.168.0.0\/24 dev ens192  proto kernel  scope link  src 192.168.0.10<\/code><\/pre>\n\n\n\n<p>As you can see in the output from ip rule show, our policy based tables have a higher priority than the main table, which can be viewed with ip route. Nevertheless it\u2019s import to still have a default route in the main table since packets leaving the machine itself can have a source IP of 0.0.0.0 and would not match any of the rules in our policy.<\/p>\n\n\n\n<p>Make the changes permanent<br>Up to now, the changes would get lost after a reboot or restart of the networking. To make the changes permanent, create a route and rule file for every interface. For the above example, the contents would look like this:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;jensd@server ~]$ cat \/etc\/sysconfig\/network-scripts\/route-ens192\n192.168.0.0\/24 dev ens192 tab 1\ndefault via 192.168.0.1 dev ens192 tab 1\n&#91;jensd@server ~]$ cat \/etc\/sysconfig\/network-scripts\/route-ens224\n192.168.1.0\/24 dev ens224 tab 2\ndefault via 192.168.1.1 dev ens224 tab 2\n&#91;jensd@server ~]$ cat \/etc\/sysconfig\/network-scripts\/rule-ens192\nfrom 192.168.0.10\/32 tab 1 priority 100\n&#91;jensd@server ~]$ cat \/etc\/sysconfig\/network-scripts\/rule-ens224\nfrom 192.168.1.10\/32 tab 2 priority 200\n<\/code><\/pre>\n\n\n\n<p>Now your configuration should be persistent.<\/p>\n\n\n\n<p>Some people pointed out in the comments that, in order for the routers to be persistent, you need to first perform the following actions:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>yum install NetworkManager-config-routing-rules\nsystemctl enable NetworkManager-dispatcher.service\nsystemctl start NetworkManager-dispatcher.service\n<\/code><\/pre>\n\n\n\n<p>While this solution is slightly more work than changing the value for rp_filter, it isn\u2019t that hard and has a lot of advantages over the other solution.<\/p>\n\n\n\n<p>TAKEN FROM: https:\/\/jensd.be\/468\/linux\/two-network-cards-rp_filter<\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The goal is to become symmetric routing: Each interface on the server should have it\u2019s own default gateway, which allows that interface to reply itself to incoming packets from other networks. A normal routing table can only have one default gateway. This is quite logical since it\u2019s the place where to send packets that do [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1514","post","type-post","status-publish","format-standard","hentry","category-kategerisiz"],"_links":{"self":[{"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/posts\/1514","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/comments?post=1514"}],"version-history":[{"count":1,"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/posts\/1514\/revisions"}],"predecessor-version":[{"id":1515,"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/posts\/1514\/revisions\/1515"}],"wp:attachment":[{"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/media?parent=1514"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/categories?post=1514"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shukko.com\/x3\/wp-json\/wp\/v2\/tags?post=1514"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}