25.9 Additional Examples

We now return to some earlier problems we encountered in the text, and use SNMP to understand what's happening.

Interface MTU

Recall our experiment in Section 11.6, in which we tried to determine the MTU of the SLIP link from netb to sun. We can now use SNMP to obtain this MTU. We first obtain the interface number ( ipRouteIfIndex ) of the SLIP link (140.252.1.29) from the IP routing table. Using this we go into the interface table and fetch the MTU (along with the description and type) of the SLIP link:

 sun  % snmpi -a netb -c secret  snmpi>  get ipRouteIfIndex.140.252.1.29  ipRouteIfIndex.140.252.1.29=12     snmpi>  get ifDescr.12 ifType.12 ifMtu.12  ifDescr.12="Telebit NetBlazer dynamic dial virtual interface"     ifType.12=other(1)     ifMtu.12=1500

We see that even though the link is a SLIP link, the MTU is set to the Ethernet value of 1500, probably to avoid fragmentation.

Routing Tables

Recall our discussion of address sorting performed by the DNS in Section 14.4. We showed how the first IP address returned by the name server was the one that shared a subnet with the client. We also mentioned that using the other IP address would probably work, but could be less efficient. Let's look at using the alternative IP address and see what happens. We'll use SNMP to look at a routing table entry, and tie together many concepts from earlier chapters dealing with IP routing.

The host gemini is multihomed , with two Ethernet interfaces. First let's verify that we can Telnet to both addresses:

 sun  % telnet 140.252.1.11 daytime  Trying 140.252.1.11 ...     Connected to 140.252.1.11.     Escape character is '^]'.     Sat Mar 27 09:37:24 1993     Connection closed by foreign host.     sun %  telnet 140.252.3.54 daytime  Trying 140.252.3.54 ...     Connected to 140.252.3.54.     Escape character is '^]'.     Sat Mar 27 09:37:35 1993     Connection closed by foreign host.

So there is no connectivity difference between the two addresses. Now we'll use traceroute to see if there is a different route for each address:

 sun %  traceroute 140.252.1.11  traceroute to 140.252.1.11 (140.252.1.11), 30 hops max, 40 byte packets      1 netb (140.252.1.183) 299 ms 234 ms 233 ms      2 gemini (140.252.1.11) 233 ms 228 ms 234 ms     sun %  traceroute 140.252.3.54  traceroute to 140.252.3.54 (140.252.3.54), 30 hops max, 40 byte packets      1 netb (140.252.1.183) 245 ms 212 ms 234 ms      2 swnrt (140.252.1.6) 233 ms 229 ms 234 ms      3 gemini (140.252.3.54) 234 ms 233 ms 234 ms

There is an extra hop if we use the address on subnet 140.252.3. Let's find the reason for the extra hop. (The router swnrt is R3 from Figure 3.6.)

Figure 25.29 shows the arrangement of the systems. We can tell from the traceroute output that the host gemini and the router swnrt are both connected to two networks: 140.252.1 and 140.252.3.

Figure 25.29. Topology of systems being used for example.

Recall in Figure 4.6 that we explained how proxy ARP is used by the router netb to make it appear as though sun was directly connected to the Ethernet 140.252.1. We've also omitted the modems on the SLIP link between sun and netb, since they're not relevant to this discussion.

In Figure 25.29 we show the path of the Telnet data using dashed arrows, when the address 140.252.3.54 is specified. How do we know that the return packets go directly from gemini to netb, and don't go back the way they came? We use our version of traceroute with loose source routing from Section 8.5:

 sun %  traceroute -g 140.252.3.54 sun  traceroute to sun (140.252.13.33), 30 hops max, 40 byte packets      1 netb (140.252.1.183) 244 ms 256 ms 234 ms      2 * * *      3 gemini (140.252.3.54) 285 ms 227 ms 234 ms      4 netb (140.252.1.183) 263 ms 259 ms 294 ms      5 sun (140.252.13.33) 534 ms 498 ms 504 ms

When we specify loose source routing, the router swnrt never responds. If we look at the earlier output from traceroute, without source routing, we see that swnrt is indeed the second hop. The reason for the timeouts must be that the router does not generate the ICMP time exceeded errors when the datagram specifies loose source routing. What we are looking for in this traceroute output is that the return path from gemini (TTLs 3, 4, and 5) goes directly to netb, and not through the router swnrt.

The question that we need SNMP to answer is what does the routing table entry on netb look like for the destination network 140.252.3? It is netb that sends the packets to swnrt and not directly to gemini. We use the get command to fetch the value of the next -hop router for this destination:

 sun %  snmpi -a netb -c secret get ipRouteNextHop.140.252.3.0  ipRouteNextHop.140.252.3.0=140.252.1.6

This routing table entry tells netb to send the packets to swnrt, which is what we see happen.

Why does gemini send the packets directly back through netb? Because on gemini the destination address of the return packets is 140.252.1.29, and that network (140.252.1) is on a directly connected interface.

What we're seeing in this example is a policy routing decision. The default route to network 140.252.3 is through the router swnrt because gemini is intended to be a multihomed host, not a router. This is an example of a multihomed host that does not want to be a router.