Routing works, but how?

dipuasks · 03-28-2013, 07:13 AM

There are 2 nics in a Linux server(ubuntu)

The ISP provided cable goes directly to eth0
Internet is connected via ppp, the interface is ppp0.

eth1 is connected to a local switch, with private IP assigned, say
in the range 172.16.0.0. Three more machines are connected to the same switch and configured with the same network(172.16.0.0)

Masquerading is done on the Linux server so it acts as default gateway to other machines in the network.

Now, I connected another cable to the local switch that comes from a different network 192.168.1.0.

Then I added a rule in the Linux server:

route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1

And voila! All the machines in 172.16.0.0 network can now ping to machines in 192.168.1.0 network!!

What I do not understand is: I never assigned an IP of 192.168.1.0 network to the gateway linux server, neither physically nor by any virtual interface. How does routing work here??

nini09 · 03-28-2013, 02:25 PM

The forwarding packet only check destination IP address.

dipuasks · 03-28-2013, 11:57 PM

Yes, but how does it know a network 192.168.1.x exists there? Just by specifying "dev eth1" it would send packets via eth1 port? (eth1 is configured with 172.16.x.x IP!)

This is working, but going beyond my basic networking/routing knowledge. How would this work on a cisco router?

rigor · 03-29-2013, 01:19 AM

What did you mean by saying this:

Quote:

Originally Posted by dipuasks

Masquerading is done on the Linux server so it acts as default gateway to other machines in the network.

If the Linux system is, by your own statement, a default gateway for the other machines, what is the confusion?

Quote:

Originally Posted by dipuasks

How would this work on a cisco router?

How would the way routing works on IOS have anything to with routing tables or iptables on Linux?

pingu · 03-29-2013, 02:18 AM

Actually, it is strange?
Not that the 192.168.1.0 network is found, but that it can be communicated with?
And you are sure you don't have 2 ip's on eth1 - or on the other computers in network? What's the output of
# ifconfig
# route

jschiwal · 03-29-2013, 02:38 AM

Pingu is correct. Hosts on the 192.168.1 network need to know what the gateway is. There is more to the story going on. Such as is the modem also a DHCP router? Is the router plugged into the switch along with the modem?

What does ifconfig of the Ubuntu server say? Look at trace route output. Look at the routing table. Look at the client configurations.

nini09 · 03-29-2013, 02:42 PM

1) eth1 is configured with 172.16.x.x IP.
A interface route is added into route table.
2) route add -net 192.168.1.0 netmask 255.255.255.0 dev eth1
A 192.168.1.0 route is added into route table, too.

Now the Linux server know that both network, 172.16.0.0 and 192.168.1.0 network, is on eth1.

dipuasks · 04-01-2013, 05:51 AM

Sorry guys for late reply(I didn't get reply notification mails for some reason). First of all thanks for your replies.

Here are the output of ifconfig and route from the server:

ifconfig:

Code:

eth0      Link encap:Ethernet  HWaddr 00:25:90:53:cb:00  
          inet6 addr: fe80::225:90ff:fe53:cb00/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1751616 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1039149 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:533235376 (533.2 MB)  TX bytes:786094499 (786.0 MB)
          Memory:dc200000-dc220000 

eth1      Link encap:Ethernet  HWaddr 00:25:90:53:cb:01  
          inet addr:172.16.8.100  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::225:90ff:fe53:cb01/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1738435 errors:0 dropped:0 overruns:0 frame:0
          TX packets:932393 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1127912382 (1.1 GB)  TX bytes:337418545 (337.4 MB)
          Memory:dc300000-dc320000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:493 errors:0 dropped:0 overruns:0 frame:0
          TX packets:493 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:55962 (55.9 KB)  TX bytes:55962 (55.9 KB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:111.1XX.2XX.1XX  P-t-P:111.1XX.2XX.1XX  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1480  Metric:1
          RX packets:370243 errors:0 dropped:0 overruns:0 frame:0
          TX packets:373079 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:135083019 (135.0 MB)  TX bytes:271451462 (271.4 MB)

route:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1XX-2XX-1XX-111 *               255.255.255.255 UH    0      0        0 ppp0
192.168.80.0    *               255.255.255.0   U     0      0        0 eth1
172.16.0.0      *               255.255.0.0     U     0      0        0 eth1
default         *               0.0.0.0         U     0      0        0 ppp0

@rigor: There is no confusion about the masquerading part, it is was just to describe the situation. And yes, I understand that IOS routing could be different than Linux, but just generally wondering can we set up any kind of routing without the source interface having an IP from the destination network?

@pingu - Yes, I'm sure. Please see the ifconfig

@jschiwal - There's no modem/dhcp router. The client configurations are nothing but 172.16.8.x/16 with gateway 172.16.8.100

@nini09 - Even I assume it works the way you are saying, but when the packet goes out of the interface eth1, what would be the source IP in the header? (I'm not too much into networking I just know the fundamentals, the OSI layer etc.)

pingu · 04-01-2013, 12:49 PM

The problem is not in routing, both networks 172.16.0.0 & 192.168.80.0 are reached via eth1 which is correct.
The problem is the communication with 192.168.80.0 network. The server has one ip only, 172.16.8.100, so it can not communicate directly with 192.168.80.0 - there has to be a router in between, or multiple ip's on other computers.
Let's see now, you say:

Quote:

All the machines in 172.16.0.0 network can now ping to machines in 192.168.1.0 network!!

It does not necessarily mean that the server can reach 192.168.80.0.
So first question is: Can it?
But since the 2 networks can reach each other via a switch, main question is: What kind of switch is it? There are switches with Layer3 routing support, also sometimes small routers are mistaken for switches. So what make & model is your switch?

nini09 · 04-01-2013, 02:24 PM

The Linux server, as router, doesn't change source or destination IP during forwarding or routing and only change destination MAC address. The ARP request, first packet is send out when ping another PC, is broadcast packet. All PC connected with switch can receive the packet and Linux server can use it to update its MAC table.

pingu · 04-01-2013, 02:35 PM

nini09, if that was true no routers would ever be needed.
Computer with ip 172.16.0.2 can not communicate with computer ip 192.168.80.2 directly. There has to be a router in between, period.
Communication between different networks must be routed - just try setting 172.16.0.2 on eth0 computer1, 192.168.1.2 on computer2, connect via a switch. They will not be able to communicate.
Add ip 192.168.1.3 to computer1's eth0:1 - voila, they can communicate!
Or connect them via a router, also now they can communicate.
But directly, belonging to different networks, no.

rknichols · 04-01-2013, 11:36 PM

When a machine on the 172.16.0.0 network sends a ping to a 192.168.1.0 network address it will, since it has no specific route to that network, send the packet to its default gateway, i.e., the Linux server. The packet will have a 172.16.x.x source address and a 192.168.1.x destination address, but a destination MAC address of the Linux server.

The Linux server, since it has forwarding enabled and an explicit route via eth1 for the 192.168.1.0 network, sends this packet back out the eth1 interface, but this time with the destination MAC address of the 192.168.1.x machine. The IP SRC and DST addresses in the packet remain unchanged.

The target machine takes the source address from the received packet and sends its reply back to that address. Again, since it has no specific route to the 172.16.0.0 network, it sends the packet with a 192.168.1.x source address and a 172.16.x.x destination address to the MAC address of its default gateway, the Linux server.

The server forwards the packet according to its routing tables, i.e., back out the eth1 port, this time with a destination MAC address of the 172.16.x.x machine, without changing the IP SRC or DST addresses.

Note that none of this needs to have anything to do with masquerading. I suppose you could have set up masquerading for everything passing through the server (which would complicate the heck out of this description), but normally you would masquerade only traffic to or from the ISP on eth0 and not traffic between your various local networks.

dipuasks · 04-02-2013, 02:21 AM

Quote:

It does not necessarily mean that the server can reach 192.168.80.0.

I am really sorry for the confusion, actually there is no 192.168.1.0 network. In the first post, I had mentioned it to to describe an example situation. However when you asked for actual ifconfig/route I pasted the actual one. So there are only two networks: 172.16.0.0 and 192.168.80.0

pingu · 04-02-2013, 03:13 AM

Quote:

Originally Posted by rknichols

The Linux server, since it has forwarding enabled and an explicit route via eth1 for the 192.168.1.0 network, sends this packet back out the eth1 interface, but this time with the destination MAC address of the 192.168.1.x machine. The IP SRC and DST addresses in the packet remain unchanged.

This is where you go wrong.
The server can not communicate directly with computers on 192.168.80.0 since it doesn't have an address in that network. With no router in between the server will not know of the MAC address of machines in 192.168.80.0 network.

rknichols · 04-02-2013, 08:22 AM

Quote:

Originally Posted by pingu

The server can not communicate directly with computers on 192.168.80.0 since it doesn't have an address in that network. With no router in between the server will not know of the MAC address of machines in 192.168.80.0 network.

Yes, it can. It has been given a no-gateway route to that network

Code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.80.0    *               255.255.255.0   U     0      0        0 eth1

and will find the MAC address by sending an ARP packet that asks, "Who has 192.168.80.x? Tell 172.16.8.100." to the broadcast MAC address (ff:ff:ff:ff:ff:ff) on that interface. The target machine will recognize its own IP address and send a response back to the MAC address that it saw as the source of the original packet. Both machines now have each other's MAC address in their respective ARP caches, and can communicate.

Hosts in that 192.168.80.0 network presumably have 172.16.8.100 as their default gateway, so when they see a ping from any host not in their own network they will route the response back to that server.