DS3 interfaces on a Cisco 7000 series router.
DS3 interfaces on a Cisco 7000 series router.
For most hosts, routing comes down to knowing just enough to make it someone else's problem. Hosts do not have complete routing tables describing the entire Internet. They generally know just enough to distinguish between "directly connected", meaning "on the same LAN", and "somewhere else", which makes it some router's problem.
Every host must apply the IP routing logic for every packet it transmits. Somewhat simplified, that logic is:
That is the logic, but how does it happen?
Simple binary logic is applied to the destination IP address, the netmask, the router's IP addresses, and the routing table entries.
Rack of Cisco routers. Most are 3600 series routers, the brown one near the bottom is a 2500 series. The network connections on on the opposite side, the single cable to each router is a connection to its console port.
Here is a simple network, the 10.1.1.0/24 network, meaning that all all hosts have IP addresses starting 10.1.1. There are three hosts connected — host1, host2, and router, with their IP addresses shown. The router has a second interface, which will have an entirely different IP address belonging to a different network. We will deal with that later.
(---------)
( )
+-------+ ( )
| Host1 +-----+ )
+-------+ ( ) +--------+
10.1.1.1 ( ) | |
( 10.1.1.0/24 +-----+ router +=======> To the Internet
( ) ^| |^
+-------+ ( ) |+--------+|
| Host2 +-----+ ) 10.1.1.254 some other IP address
+-------+ ( ) on inside on exterior interface
10.1.1.2 ( ) interface
(---------)
Firefox users may find that "monospace" isn't really a constant-width
font, and Courier works much better for ASCII art.
Here is the routing table for host1, as displayed on a Linux system:
Linux% netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.1.1.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 10.1.1.254 0.0.0.0 UG 0 0 0 eth0
Here is the routing table on a BSD system:
OpenBSD% netstat -nr -f inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 10.1.1.254 UGS 5 23902 - sis0 10.1.1/24 link#1 UC 1 0 - sis0 10.1.1.254 00:0d:61:b1:86:53 UHLc 3 4006 - sis0 10.1.1.1 127.0.0.1 UGHS 0 0 33208 lo0 127/8 127.0.0.1 UGRS 0 0 33208 lo0 127.0.0.1 127.0.0.1 UH 2 82 33208 lo0
So, let's say that host01 wants to send a packet to host02. It resolves the hostname host02 to the IP address 10.1.1.2, and then applies the logic.
In decimal:
?
10.1.1.1 AND 255.255.255.0 = 10.1.1.2 AND 255.255.255.0
In binary, the left side is:
00001010 00000001 00000001 00000001
11111111 11111111 11111111 00000000
AND ------------------------------------
00001010 00000001 00000001 00000000
And the right side is:
00001010 00000001 00000001 00000010
11111111 11111111 11111111 00000000
AND ------------------------------------
00001010 00000001 00000001 00000000
So, yes, it's directly connected! host01 sends an ARP request for 10.1.1.2. Both host02 and router receive that ARP request; router ignores it, but host02 should respond.
Given the MAC address for the IP host 10.1.1.2, host01 can send the frame directly across the LAN. And, host01 will keep the MAC address for 10.1.1.2 in its ARP cache so it doesn't have to ask the question again until some time has elapsed.
The same logic would apply if host01 were sending a packet to router. But what if host01 wants to send a packet to, say, 213.24.76.9?
Is it directly connected? No!
In decimal:
?
10.1.1.1 AND 255.255.255.0 = 213.24.76.9 AND 255.255.255.0
In binary, the left side is:
00001010 00000001 00000001 00000001
11111111 11111111 11111111 00000000
AND ------------------------------------
00001010 00000001 00000001 00000000
And the right side is:
11010101 00011000 01001100 00001001
11111111 11111111 11111111 00000000
AND ------------------------------------
11010101 00011000 01001100 00000000
Is there a host-specific route, a routing table entry for 213.24.76.9/32?
No!
Is there a network-specific route, a routing table entry for, say, 213.24.76.0/24, or 213.24.0.0/16, or similar?
No!
Is there a default route?
Yes! Good news, no routing error. Do what that route specifies, which means making it the problem of the router. Routers tend to know more about network topology, and they tend to have default routes. When you get to the core of the Internet, the backbone routers, they have enormous routing tables because they have to know (at least generally) where everything is.
Here is a more realistic situation, where host01 wants to send a packet to remote host02. Time increases as you go down the page. I'm not showing the ARP packets, let's assume that all the hosts and routers have already discovered each other's MAC addresses:
(--) (--) (--) (--)
+--------+ ( ) +---------+ ( ) +---------+ ( ) +---------+ ( ) +--------+
| host01 +-+( )+-+ router1 +-+( )+-+ router2 +-+( )+-+ router3 +-+( )+-+ host02 |
+--------+ ( ) +---------+ ( ) +---------+ ( ) +---------+ ( ) +--------+
(--) (--) (--) (--)
host01 asks itself:
Directly connected? No...
Have route? Just a default...
Send frame:
+------------------------+
[ IP: host01 -> host02 ]
[ MAC: host01 -> router1 ]
+------------------------+
router1 asks itself:
Directly connected? No...
Have route? Just a default...
Send frame:
+-------------------------+
[ IP: host01 -> host02 ]
[ MAC: router1 -> router2 ]
+-------------------------+
router2 asks itself:
Directly connected? No...
Have route? Yes, for the net, via router3
Send frame:
+-------------------------+
[ IP: host01 -> host02 ]
[ MAC: router2 -> router3 ]
+-------------------------+
router3 asks itself:
Directly connected? Yes!
Send frame:
+------------------------+
[ IP: host01 -> host02 ]
[ MAC: router3 -> host02 ]
+------------------------+
The important thing:
If one of the routers is doing Network Address Translation (NAT), also called IP Masquerading, then at some point a lie is told about the original sender's IP address. Click here to see how NAT works.
The description above is all you need to get IP routing working. Back in the day, when the Internet was a far more cooperative place, that's all you needed. But things have changed and security mechanisms must be added.
Cisco 2514 router, Cisco 2912XL Catalyst switch, Cisco 4500 router
A set of packet filtering rules, sometimes called an Access Control List (ACL), is a common security function performed by routers. Another common function is something that goes by three different names: Sanity Checking, Ingress Filtering, or Egress Filtering. Sanity Checking is the general term. The other terms refer to doing it just in one direction.
As explained above, all any host needs to consider for next-hop delivery is the destination IP address. The filtering added by Sanity Checking also looks at the source IP address, in order to drop those packets obviously using a spoofed source address in an attempt to make the destination host trust them. A router does not necessarily know the location of the claimed source IP address, but if it does, and if the topology makes no sense (or is insane) based on the interface where the packet arrives compared to the known network location, that packet is dropped.
Look at this simple network diagram, and the table of packets that do and do not make sense at our border router. Let's assume that we use the 44.0.0.0/8 IP block inside and we are not running NAT, just to keep this simple.
(-------------)
( ) (------)
( +--------+ +--------+ ( our )
( | ISP | WAN link | our | ( internal )
( The Internet | border +~~~~~~~~~~~~+ border +----+ 44.0.0.0/8 )
( | router | ^| router |^ ( networks )
( +--------+ |+--------+| ( )
( ) exterior interior (------)
(-------------) interface interface
| Arriving at interface | Source | Destination | Valid? |
| exterior | 44.*.*.* | anything | NO! It makes no sense for a packet from our internal networks to arrive from the outside world! This must be a spoofed packet, so drop it! To be specific, this is ingress filtering since we are applying to inbound packets. |
| exterior | anything other than 44.*.*.* | 44.*.*.* | Who knows? Our border router doesn't know where everything is, but this isn't obviously a lie so accept and forward it. |
| interior | 44.*.*.* | anything other than 44.*.*.* | Yes! Of course, our border router doesn't know if the destination is really routeable or not, but let's try. |
| interior | anything other than 44.*.*.* | anything | NO! It makes no sense because all we have inside is the 44/8 network. Some host inside our organization is either horribly misconfigured or trying an IP spoofing attack against some outside host. Drop the packet! To be specific, this is egress filtering since we are applying to outbound packets. The Internet would be a much better place if every organization and ISP did egress filtering. For example, if an ISP does it, then their customers cannot launch IP spoofing attacks. |
Cisco calls sanity checking Unicast Reverse Path Forwarding or Unicast RPF. To enable it, you would do something like the following in the startup configuration:
interface Serial 0 ip address 1.2.3.4 255.255.255.255 ip verify unicast reverse-path no ip redirects no ip directed-broadcast no ip proxy-arp
|
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell Sep 2010. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |
