IP Alias issue

Droo · 05-24-2006, 09:54 PM

I'm having some issues with IP Aliasing, first some background info.

I've got 2x boxen setup. Box1 is a Slackware 9.1 (2.4.26) box set up as our router. It holds 5 static ip addresses on the one nic (eth1) that is our net connection using ip aliasing.

It then forwards ports through to different internal servers based on the dest ip and port of the incomming packet.

I want to upgrade this machine to 10.2 and get everything up to date.

Box2 is a Slackware 10.2 box with kernel 2.6.16. I've set up the firewall the same (iptables-save on box1 and restored to box2). I unplug the cables from Box1 and plug then into Box2 and bring up the interfaces and all appears to be working (NAT etc).

However I now have the issue that locally I can ping all IP's hosted on Box2 but remotely I can only ping the IP of eth1. The IPs aliased on eth1:1 to eth1:4 don't respond to the internet. At first I thought firewalling rules, but they're the same on both machines and it works on the other. Also there aren't any rules to deny icmp.

Interface & routing info:

Code:

eth0      Link encap:Ethernet  HWaddr xx:yy:zz:aa:bb:01
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6072 errors:0 dropped:0 overruns:0 frame:0
          TX packets:493 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:592652 (578.7 KiB)  TX bytes:40873 (39.9 KiB)

eth1      Link encap:Ethernet  HWaddr xx:yy:zz:aa:bb:02
          inet addr:xxx.xxx.xxx.82  Bcast:xxx.xxx.xxx.87  Mask:255.255.255.248
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:17 Base address:0x2000

eth1:1    Link encap:Ethernet  HWaddr xx:yy:zz:aa:bb:02
          inet addr:xxx.xxx.xxx.83  Bcast:xxx.xxx.xxx.87  Mask:255.255.255.248
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Interrupt:17 Base address:0x2000

eth1:2    Link encap:Ethernet  HWaddr xx:yy:zz:aa:bb:02
          inet addr:xxx.xxx.xxx.84  Bcast:xxx.xxx.xxx.87  Mask:255.255.255.248
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Interrupt:17 Base address:0x2000

eth1:3    Link encap:Ethernet  HWaddr xx:yy:zz:aa:bb:02
          inet addr:xxx.xxx.xxx.85  Bcast:xxx.xxx.xxx.87  Mask:255.255.255.248
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Interrupt:17 Base address:0x2000

eth1:4    Link encap:Ethernet  HWaddr xx:yy:zz:aa:bb:02
          inet addr:xxx.xxx.xxx.86  Bcast:xxx.xxx.xxx.87  Mask:255.255.255.248
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Interrupt:17 Base address:0x2000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3372 (3.2 KiB)  TX bytes:3372 (3.2 KiB)


Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xxx.xxx.xxx.80  0.0.0.0         255.255.255.248 U     0      0        0 eth1
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         xxx.xxx.xxx.81  0.0.0.0         UG    1      0        0 eth1

Any help would be greatly appreciated.

acid_kewpie · 05-25-2006, 04:13 PM

first off i would wonder if your netblock is being completely routed to your server, but if it is then you should try using tcpdump or ethereal to see if, for example, icmp packets are being seen by the server firt of all. then you can explore what is happening to them. i'm fairly sure that tcpdump will still see traffic that is blocked by iptables etc... as it listens directly to the eth interface.

Droo · 05-25-2006, 05:47 PM

After some experimentation this morning I believe I've virtually solved this issue.

I did the switch over again this morning and things started to work. I could ping all but 1 of the ips from an external source. The ip I couldn't ping was on eth1:1 (the first alias) yet eth1:2 to eth1:4 were all fine.

The only thing that confused me was using tcpdump I could see the incomming ping requests, but the box just wasn't answering them, I cleared all firewalling rules to be sure iptables wasn't blocking it either. After I added a SNAT rule so that outgoing data from a specific machine inside the network had the outgoing address of eth1:1 and did some pings from that I saw the following:

Code:

08:19:01.551599 IP xxx.xxx.xxx.83 > xx.yy.zz.aa: ICMP echo request, id 19016, seq 1, length 64
08:19:01.582292 IP xx.yy.zz.aa > xxx.xxx.xxx.83: ICMP echo reply, id 19016, seq 1, length 64
08:19:02.551056 IP xxx.xxx.xxx.83 > xx.yy.zz.aa: ICMP echo request, id 19016, seq 2, length 64
08:19:02.581287 IP xx.yy.zz.aa > xxx.xxx.xxx.83: ICMP echo reply, id 19016, seq 2, length 64
08:19:03.551144 IP xxx.xxx.xxx.83 > xx.yy.zz.aa: ICMP echo request, id 19016, seq 3, length 64
08:19:03.581630 IP xx.yy.zz.aa > xxx.xxx.xxx.83: ICMP echo reply, id 19016, seq 3, length 64
08:19:04.551352 IP xxx.xxx.xxx.83 > xx.yy.zz.aa: ICMP echo request, id 19016, seq 4, length 64
08:19:04.581240 IP xx.yy.zz.aa > xxx.xxx.xxx.83: ICMP echo reply, id 19016, seq 4, length 64
08:19:05.551457 IP xxx.xxx.xxx.83 > xx.yy.zz.aa: ICMP echo request, id 19016, seq 5, length 64
08:19:05.581506 IP xx.yy.zz.aa > xxx.xxx.xxx.83: ICMP echo reply, id 19016, seq 5, length 64

Yet the internal box wasn't getting any replies.

Anyway, since the other aliases were working, including forwarding packets to their internal machines and websites were functioning I don't feel it's an ipaliasing issue and more something to do with the arp tables on our VH-8 switch (xxx.xxx.xxx.81) that does our fibre to ethernet conversion.

Since I ran out of time to keep testing this morning I plugged the cables back into the existing linux router and tested my hunch. From outside I could ping both the eth1 and eth1:1 addresses (.82 and .83) but the others no longer worked. Guessing my arp assumption was correct? Since I don't have direct access to the VH-8 switch to reset it I quickly just set each ip to eth1 and pinged the switch before resetting eth1 and it's aliases back to normal.

A quick test and bingo, they all pinged successfully from the net again. The only thing that really puzzles me is why .84 - .86's arp tables updated given time but .83 didn't. Even though tcpdump showed the nic as receiving the data.