Ask Your Question
0

Default route not working as expected-Fedora23 on IBM Power LPAR

asked 2016-09-21 08:02:37 -0500

aixandy gravatar image

updated 2016-09-21 09:01:39 -0500

hhlp gravatar image

Looking to expand our hosting capability beyond just AIX, I am installing Fedora23 into an IBM Power lpar for the first time. I have created it’s profile in exactly the same way that I create all my AIX lpars, that is, it is allocated 2 virtual Ethernet devices, i.e. fully virtualised relying on VIOS for its external network connectivity . The first will be configured in subnet 10.96.18/24 for Install/Management traffic whilst the second will be configured in subnet 10.96.12/24 for all business user traffic.

I’ve successfully booted the lpar using an ISO image presented to it from a VIOS virtual media library, and updated the boot options to configure IP on the first interface, directing it to pick up a kick start file from an NFS share. In the kick start file I configure both interfaces as follows

# Network information
network  --bootproto=static --device=0e:5d:44:4f:ca:0a --gateway=10.96.18.254  --ip=10.96.18.4  --netmask=255.255.255.0  --noipv6 --activate  --nameserver=207.129.102.29

network  --bootproto=static --device=0e:5d:44:4f:ca:0b  --ip=10.96.12.3  --netmask=255.255.255.0  --noipv6 --activate

network  --bootproto=static --hostname=test01

The install completes successfully and I can log on. On first impression all looked ok. Here is the Ethernet interface and routing information:

# Ethernet Interface information
[root@test01 ~]# ifconfig -a

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.96.18.4  netmask 255.255.255.0  broadcast 10.96.18.255
        inet6 fe80::c5d:44ff:fe4f:ca0a  prefixlen 64  scopeid 0x20<link>
        ether 0e:5d:44:4f:ca:0a  txqueuelen 1000  (Ethernet)
        RX packets 676  bytes 56887 (55.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 234  bytes 30125 (29.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.96.12.3  netmask 255.255.255.0  broadcast 10.96.12.255
        inet6 fe80::c5d:44ff:fe4f:ca0b  prefixlen 64  scopeid 0x20<link>
        ether 0e:5d:44:4f:ca:0b  txqueuelen 1000  (Ethernet)
        RX packets 101  bytes 7774 (7.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 732 (732.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 4  bytes 340 (340.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4  bytes 340 (340.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

#Routing Information
[root@test01 ~]# netstat -rn

   Kernel IP routing table
   Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

   0.0.0.0         10.96.18.254    0 ...
(more)
edit retag flag offensive close merge delete

3 Answers

Sort by » oldest newest most voted
0

answered 2016-09-22 05:13:35 -0500

aixandy gravatar image

Ok, I've solved it. The method I need is called "Reverse Path Filtering". According to some info I've found, if the reply to an incoming connection doesn't go out of the interface it came in on (based upon the routing table) then its considered a bogus packet and is dropped. Appears from everything I've read on Google, if you're into Linux you therefore think Asymmetric routing is bad, which explains why on my Fedora23 build it too drops packets under these conditions.

The resolution is to update the file "/proc/sys/net/ipv4/conf/[...eth0, eth1...]/rp_filter so that the contents say "2" meaning switch this feature off, as opposed to the value "1" which means enable it.

Here's the link --> http://www.tldp.org/HOWTO/Adv-Routing...

For the configuration changes to persist across a reboot, I've added the following 2 lines to /etc/sysctl.conf

   net.ipv4.conf.default.rp_filter = 2
   net.ipv4.conf.all.rp_filter = 2

Here's that link --> https://docs.fedoraproject.org/en-US/...

edit flag offensive delete link more

Comments

I think asymmetric routing is asking for trouble, but then I'm a Linux user. :-)

ssieb gravatar imagessieb ( 2016-09-23 13:19:26 -0500 )edit
0

answered 2016-09-21 13:40:36 -0500

ssieb gravatar image

You are trying to connect to the server from an address that is unreachable from that interface. It will not route a bad packet on the wrong interface. The IP address you are connecting to is not valid on the other interface, so it won't send from it.

edit flag offensive delete link more
0

answered 2016-09-21 14:44:54 -0500

aixandy gravatar image

updated 2016-09-23 06:26:31 -0500

That doesn't make sense unless Fedora doesn't follow standard default route practice. In one interface and out via another (default route) is common . The whole point of a default route is to direct responses via an interface that should be used when a specific static route doesn't exist. My problem description works perfectly OK on AIX. I'm guessing there is some form of blocker between the interfaces, eg firewall that refuses to forward the packet that I'm unaware of but I just haven't found it. Remember that my packet reaches the Fedora node as confirmed with tcpdump, it should then check its routing tables and see the way to respond only exists via the default route, so why doesn't it do that . I agree that the source address 207.129.102/24 is not contactable from the 10.96.12/24 interface, but the default route (via 10.96.18/24) can . Does Fedora have to have some configuraion applied to perform asymmetric routing somehow ?

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2016-09-21 07:40:35 -0500

Seen: 101 times

Last updated: Sep 23 '16