Routing

Introduction

Kernel Routing Algorithm

Interior vs. Exterior Routing protocols

• Interior Routing Protocols
• Exterior Routing Protocols
• Classless and Classful Routing Protocols

Routing Table

• Displaying the Route Table

Static Routes

• Associating Network Name and Network Number
• Configuring Static Routes Using route Utility
• Default routes
• Using the /etc/gateways File to Add Static Routes

Selected routing algorithms

• RIP
• RDISC
• OSPF
• BGP Protocol

Summary

Routing table can be viewed using netstat -r (with host resolution) and netstat- rn (without). See netstat

Route command can be used to (we will use Solaris as example. For Linux see Linux route command) :

1. Add a route # route add net 128.50.3.0 tuna
2. Add a default route # route add default tomato 1
3. Manual manipulation of the routing table: [host|net] dest. [ gateway
4. Delete a route # route delete net 128.50.3.0 sword-r
5. Lookup and display the route for a destination # route get 128.50.2.0
6. Get routing reports continuously

   # route monitor

7. Flush the routing table # route flush
   
8. Add the multicast path for 224.0.0.0 # route add 224.0.0.0 `uname -n` 0
9. Use the "route add net" command with the -netmask option to make the route command to take the netmask specified on the command line :

   # route add net 192.168.68.0 128.50.1.250 1 -netmask 255.255.255.192

Introduction

Imagine that you are a courier, and your run always starts at the local courier depot. You're given a list of addresses, which are associated with a set of packages, and your goal is to deliver them in as little time as possible, subject to the following constraints:

• The number of roads you take to deliver each package must be minimized.
• You must avoid deadends and accidents.
• You can only determine which roads to take by consulting a street directory and by crosschecking street names along your path with those in your directory.

If this seems like a fairly trivial task for a courier, consider how much more difficult the job if

• the number of possible roads increases exponentially each year.
• There is no way of knowing, in advance, which roads are "under construction" and currently not acccesible.
• The street directory you have is completely out of date.

This scenario describes the difficulties faced by internet routing. In order for a packet of data to be transferred from host A to host B, a path must be identified for the packet to travel. There is no central lookup service that decides how to route each packet between all possible combinations of two hosts on the Internet (i.e., between the sender and the receiver). This means routes must be either defined statically or generated dynamically. (The only exceptions to this rule are certain situations where a predictable static route may be installed.)

When transferring data around the Internet or between subnets, intermediate hosts must be responsible for transferring packets between networks; these hosts are called routers and are responsible for routing packets between hosts, which can be separated by single subnets or by entire continents.

Often more then a dozen routers are involved in transfer packets between the sender and the receiver. In addition, the observed response times can be quite slow. It is possible for attempted connections to time out. This can be very useful when trying to identify which intermediate host and/or network is having problems when your remote connection to a host half a world away suddenly dies!

Static routing is the best in simple configurations, for example when only one router is assessible from a workstations as well as when dynamic routing would be a security risk. For example, if your local network has three subnets that need to share data, a static route could be created between each router and the other two routers in the network. The number of specific routes required to allow data to flow seamlessly between networks is directly proportional to the square of the number of routers on the network. Every time a change is made to the network topology, these routes will have to be modified manually. If that sounds like too much hard work, consider the situation where it might be desirable: a secure database server that can be accessible only by knowing the route to the host and is not publicly announced. Instead of permitting route discovery, a static route is an appropriate technique here. This could be implemented by creating a point-to-point routing table.

Routing took place at the Internet layer of TCP/IP protocol.

1. TCP/IP Layers
   1. Application Layer
   2. Transport Layer
   3. Internet Layer <- routing
   4. Network Interface Layer
2. Hardware Layer.

A simple definition of routing is "learning how to get from here to there." (routes are both source and destination dependent; i.e., that knowing how to get there isn't enough, you have to know where you are starting from as well.) In some cases, the term routing is used in a very strict sense to refer only to the process of obtaining and distributing information ("learning"), but not to the process of using that information to actually get from one place to another (for which a different term, forwarding,is reserved). Since it is difficult to grasp the usefulness of information that is acquired but never used, we employ the term routing to refer in general to all the things that are done to discover and advertise paths from here to there and to actually move packets from here to there when necessary.

There are two types of routing: direct and indirect.

• Direct Routing. Direct routing occurs when the destination host is attached to the same physical network as the source host. The source host can send the IP datagram using the physical network frame without any involvement from the router.
  
• Indirect Routing. Indirect routing is used when the network numbers of the source and destination do not match. In this case the packet must be forwarded to a node that knows how to reach the destination (a router).
  The address of the first router (the first hop) is called an indirect route. A default route contains the router information to use for all destinations that do not have an explicit route table entry.

Kernel Routing Algorithm

When implementing routing Solaris kernel:

1. Checks local LAN for destination hosts. The kernel extracts the destination IP address from the IP datagram and computes the destination network number. The destination network number is then compared with the network numbers of all local interfaces (an interface physically attached to the system) for a match. If one of the destination network numbers matches that of a local interface network number, the kernel encapsulates the packet and sends it through the matching local interface for delivery.
2. Checks routing table for matching IP host address. If no local interface network number matches the destination network number, the kernel searches the routing table for a matching host IP address.
   
3. Checks routing table for matching network number (see Subnetting and CIDR). If no specific IP host address matches the destination IP address, the kernel searches the routing table for a matching network number. If found, the kernel sets the destination Ethernet address to that of the corresponding router. It completes the encapsulation of the packet, leaving the destination IP address unchanged, so that the next router will execute the routing algorithm again.
4. Checks for a default entry in the routing table. If there is no matching network number in the routing table, the kernel checks for a default entry in the routing table. If found, the kernel encapsulates the packet, setting the destination Ethernet address to that of the default router, leaving the destination IP address unchanged, and delivers the packet through the interface that is local to the default router.
5. If there is route to host, generate ICMP error message. If no matching address is found and no default router entry is found in the routing table, the kernel cannot forward the packet and an error message from ICMP is generated. The error message will state No route to host or network is unreachable.

The ICMP handles control and error messages. ICMP on a router or gateway sends reports of problems to the original source. ICMP also includes an echo request or reply that is used to test whether a destination is reachable or not. The ping command uses this protocol.

ICMP redirects are most commonly used when a host is using default routing. If the router determines a more efficient way to forward the packet, it redirects the datagram using the best route and reports the correct route to the sender.

The sending host's route table is updated with the new information. The drawback to this method of routing is that for every ICMP redirect, there is a separate entry in the sending host's route table. This can lead to a large route table. However, it also ensures that the packets going to all reachable hosts are taking the shortest route.

Common ICMP messages:

• Echo request and reply messages from ping command
• Report unreachable destinations
• Control congestion and datagram flow
• Route change requests from gateways to hosts
• Detect circular or excessively long routes
  
• Clock synchronization and transit time estimation
• Report other problems

Interior vs. Exterior Routing protocols

A single routing protocol cannot efficiently handle all situations because networks can be connected in many different ways.

An autonomous system (AS) is a collection of networks and routers under a single administrative control. This broad definition was incorporated into the Internet in an attempt to reduce excessively large route tables.

An autonomous system number is a unique 16-bit address that is assigned by the Internet Corporation for Assigned Names and Numbers (ICANN).

An autonomous system's exterior routers maintain route tables by using autonomous system numbers that represent exterior routes because the numbers create unique paths. An autonomous system's interior routers also have interior route entries in their route tables for subnets within the organization.

There are two major types of routing protocols:

• interior routing protocols (IGP): are used between organizations or sites, for example, a large wide area network (WAN), such as the Internet or a large corporation's intranet. IGP is a route table protocol within an autonomous system. IGPs typiclly are used within an organization or an organization's site.
• exterior routing protocols that are used between autonomous systems. EGP and the Border Gateway Protocol (BGP) are the two principal protocols that exchange route table information among autonomous systems.

Interior Routing Protocols

Interior routing protocols pass route table information within an autonomous system (AS).T here are to major interior routing protocols:

• RIP. RIP is a distance-vector protocol that exchanges route information between IP routers. Distance-vector algorithms obtain their name from the fact that they compute the least-cost path by using information that is exchanged with other routers that describes reachable networks with their distances in the form of hop counts.
• Open Shortest Path First (OSPF) Protocol. OSPF is a link-state protocol. OSPF maintains a map of the network topology instead of computing route paths that are based on distance vectors in the way that RIP computes the route paths. OSPF provides a global view of the network and provides the shortest path choices on routes. The map on each OSPF router is updated regularly.

Exterior Routing Protocols

An exterior routing protocol is a routing protocol that communicates routes between autonomous systems. EGP and the Border Gateway Protocol (BGP) are the two principal protocols that exchange route table information among autonomous systems.

• EGP was developed in the early 1980s. It was a distance vector protocol. The concept of an autonomous system developed out of the research and development of EGP.
• BGP was developed in the mid 1990s to replace EGP. BGP replaces the distance-vector algorithm of EGP with a path-vector algorithm. The path vector that is implemented by BGP causes the route table information to include a complete path (all autonomous system numbers) from the source to the destination. This eliminates the possibility of looping problems that might arise from complex network topologies, such as the Internet. A loop is detected by BGP when the path it receives has an autonomous system listed twice. If this occurs, BGP generates an error condition.

Classless and Classful Routing Protocols

For routers in a variably subnetted network to properly update each other, they must send masks in their routing updates. Without subnet information in the routing updates, routers would have nothing but the address class and their own subnet mask to go on. Only routing protocols that ignore the rules of address class and use classless prefixes work properly with VLSM. Table below lists common classful and classless routing protocols.

Note: Only Solaris 10 supports RIP version 2 out of the box.

Routing Table

Routes are kept is a special table called routing table. The Solaris kernel stores it in memory. It contains two types of entries:

• Static routes are permnent entries in the route table. After such a route is in the table, you can only remove it manually. The most common static entries are the direct routes that a system creates to its local networks. During boot, the ifconfig utility updates the route table with static entries for the networks that are directly connected to the local network interfaces. Therefore, even in the single-user mode, a system can route directly to the local networks because the interfaces are initialized by the ifconfig utility. Static routes can also be added to your system's route table manually by the /etc/defaultrouter file or by entries placed in the /etc/gateways file. These static entries define the network destinations that are not directly connected but are reachable through another system or device called a router.
• Dynamic routes are added to or removed from the route table by various processes, such as the in.routed or in.rdisc processes. When the route table is updated with information about routers and other reachable networks, the identified router can forward or deliver datagrams to these networks. In Solaris 9 the /etc/rc2.d/S69inet script starts the two daemons that implement dynamic routing at run level 2:
  • The Routing Information Protocol (RIP) is implemented by the in.routed process (in Solaris 10 RIP2 is used). It also implements ICMP Router discovery protocol.
  • The Router Discovery Protocol (RDISC) is implemented by the in.rdisc process.

  Routers advertise the networks that they know about. Other hosts and routers listen to these periodic announcements and update their route table with the most current and correct information. Only those entries calculated to be the best paths to a network destination remain in the route table.

Displaying the Route Table

To display the contents of a system's route table without interpreting the names of the systems, use the netstat utility with the -r and -n options:

• The -r option causes the route table to be displayed.
• The -n option causes the IP addresses to be displayed instead of resolving them to names.

# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              10.201.12.1          UG        1     348856
10.201.12.0          10.201.13.251        U         1      20398 bge0
10.201.28.0          10.201.29.251        U         1       3170 bge2
224.0.0.0            10.201.13.251        U         1          0 bge0
127.0.0.1            127.0.0.1            UH       19     319784 lo0
	

Introducing Route Table Entries

Routing table entries:

• Destination The destination network or host address.
• Gateway The system that delivers or forwards the datagram.
• Flags The status of this route. This field uses the following flags:
  • U–The interface is up.
  • H–The destination is a system, not a network.
  • G–The delivery system is another system (an indirect path).
  • D–The entry was added dynamically by an ICMP redirect.
• Ref The current number of routes that share the same network interface (Ethernet) address.
• Use The number of datagrams that are using this route. For the localhost entry, it is a snapshot of the number of datagrams that are received.
• Interface The local interface that reaches the destination.

Static Routes

You can configure a route that does not change or time-out. This type of route is called a static route. See Static Routing

You can use the route utility to define a static direct route. A static route is a route that is not automatically removed by the in.routed process if a more efficient route is identified. The ifconfig utility initially builds the direct route entries when the network interface is configured during system startup. To view the results of the utility, perform the command: netstat -r

The localhost entry in the local routing table is a loopback route to the local host that is created when the lo0 pseudo interface is configured.

Configuring Static Routes Using route Utility

The Solaris route command enables manual manipulation of the route table The syntax of the command is somewhat complicated:

route [-fn] add|delete [net|host|default] destination gateway

With keywords add and delete the default for optional [net|host|default] troika is host.

For example, to add a direct static route between the systems alpha and beta, perform a command similar to the following:

# route add beta alpha
add host beta: gateway alpha

This is equivalent to:

# route add host beta alpha

To delete the route between beta and alpha, perform a command similar to the following:

# route delete beta alpha
delete host beta: gateway alpha

To define a default route using the system sigma , perform a command similar to the following:

# route add default sigma
add net default: gateway sigma

The route utility can also to retrieve information about a specific route. For example, to retrieve information about the default route:

# route get default
   route to: default
destination: default
       mask: default
    gateway: 10.201.12.1
  interface: bge0
      flags: 
 recvpipe  sendpipe  ssthresh    rtt,ms rttvar,ms  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0
	

To change the route table, use the change option with the route utility. For example, to change the default route from sigma to gamma, perform a command similar to the following:

# route change default gamma
change net default: gateway gamma

To continuously report any changes to the route table, route lookup misses, or suspected network partitionings, use the monitor option:

# route monitor
got message of size 124
RTM_DELETE: Delete Route: len 124, pid: 633, seq 1, errno 0,
flags:<UP,GATEWAY,DONE,STATIC>
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>

192.168.3.0 alphaext 255.255.255.0

To flush (remove) the route table of all gateway entries, use the flush option (only indirect routing table entries would be removed):

# route flush

192.168.9 beta done
two beta done
two alphaext done
default 172.20.4.248 done

you can also flush the route table before any command with -f option:

# route -f add net 192.168.4.0 alphaext
add net 192.168.4.0: gateway alphaext

In case you accidentally deleted mulcast entry you can restore it manually (you can consult the command syntax in the /etc/rc2.d/S72inetsvc startup file). For example to add a route to the multicast address range of 224 through 239, perform the command:

# route add 224.0/4 'uname -n'

To define a route that uses a specific netmask, use the netmask option with the route utility. For example, to add a route to the 192.168.3.0 network that uses a netmask of 255.255.255.224, perform the command:

# route add net 192.168.3.0 deltaext -netmask 255.255.255.224
add net 192.168.3.0: gateway deltaext

More concise way of doing the same would be to specify 192.168.3.0/27 :

# route add net 192.168.3.0/27 deltaext
add net 192.168.3.0/27: gateway deltaext

Note: The in.routed process does not automatically detect route table changes. Therefore, do not perform changes while the in.routed process is running. Instead, shut down the in.routed process, make the required changes, and then restart the in.routed process. This ensures that the in.routed process use the latest version of the routing table.

You can use the route utility to define a static routes. A static route is a route that is not automatically removed by the in.routed process if a more efficient route is identified.

Associating Network Name and Network Number

In Solaris the file /etc/inet/networks associates a network name to a network number. The file /etc/networks is a symbolic link to the /etc/inet/networks

There are three fields in the /etc/inet/networks file:

• network name
• network number
• nicknames.

# tail -2 /etc/inet/networks

one 192.168.1 one
two 192.168.2 two

To add a route to the network that is not defined in the /etc/inet/networks file you can use vi or command route:

# route add net 192.168.3.0 192.168.30.31
add net 192.168.3.0: gateway 192.168.30.31

To add a route to the network defined as "two" network you can use the command:

# route add net two 192.168.30.31
add net two: gateway 192.168.30.31

To view how defined networks are displayed in the output from the netstat utility, use the netstat utility with the -r option:

# netstat -r

Observe how the destination networks are now displayed by name instead of by network address. Loopback address is replaced by its entry from the /etc/inet/hosts

Here is Solaris 9 man page for this file:

networks - network name database

SYNOPSIS

/etc/inet/networks /etc/networks

DESCRIPTION

The networks file is a local source of information regarding the networks which comprise the Internet. The networks file can be used in conjunction with, or instead of, other net- works sources, including the NIS maps networks.byname and networks.byaddr and the NIS+ table networks. Programs use the getnetbyname(3SOCKET) routines to access this informa- tion. The network file has a single line for each network, with the following information: official-network-name network-number aliases Items are separated by any number of SPACE or TAB charac- ters. A `#' indicates the beginning of a comment. Characters up to the end of the line are not interpreted by routines which search the file. This file is normally created from the official network database maintained at the Network Information Control Center (NIC), though local changes may be required to bring it up to date regarding unofficial aliases and/or unknown networks. Network numbers may be specified in the conventional dot (`.') notation using the inet_network routine from the Internet address manipulation library, inet(7P). Network names may contain any printable character other than a field delimiter, NEWLINE, or comment character.

SEE ALSO

getnetbyaddr(3SOCKET), getnetbyname(3SOCKET), inet(3SOCKET), nsswitch.conf(4), inet(7P)

NOTES

The official SVR4 name of the networks file is /etc/inet/networks. The symbolic link /etc/networks exists for BSD compatibility. The network number in networks database is the host address shifted to the right by the number of 0 bits in the address mask. For example, for the address 24.132.47.86 that has a mask of fffffe00, its network number is 803351. This is obtained when the address is shifted right by 9 bits. The address maps to 12.66.23. The trailing 0 bits should not be SunOS 5.9 Last change: 17 Jan 2002 1 File Formats networks(4) specified. The network number here is different from that described in netmasks(4). For this example, the entry in netmasks would be 24.132.46.0fffffe00.

Default routes

A default route is a route table entry that allows a host to define default routers to use if no other specific route is available. The default routers must be reliable. There is no need to define every reachable network. All indirectly connected packet destinations go to the default router.

A default router can be identified by creating the /etc/defaultrouter file that contains hostname or IP address entries that identify one or more routers. Upon rebooting, this prevents the startup of the in.routed and in.rdisc daemons. Default route table entries may also be added by the in.rdisc daemon.

Some advantages of default routing are:

• The /etc/defaultrouter file prevents unneeded routing processes from starting.
• The default entries result in a smaller route table, which reduces the processing time spent on each IP datagram.
• Multiple default routers can be identified, which eliminate single points-of-failure within a network.
• Systems that use default route entries do not depend on actual routing protocols.

Some disadvantages of default routing are:

• The default entries created by the /etc/defaultrouter file or the route utility are always present, even when the default router is not available. The system does not learn about other possible routes.
• All systems must have a local /etc/defaultrouter file properly configured because this file cannot be administered by a name service. This can be an administrative problem on large, evolving networks.

A default route is a route table entry that defines the default routers to use if no other specific route is available. Default route entries can be either static entries or dynamic entries. The default routers must be reliable. You do not need to define every reachable network because datagrams that are addressed to non-local destinations use a default router in the absence of an explicit route.

Using the /etc/gateways File to Add Static Routes

During the initialization the in.routed router process reads the /etc/gateways file if it exists. This file can contains additional static routes and represents an alternative way to add such routes. The fields in the /etc/gateways file are:

net | host destination gateway gateway metric hops passive | active

For example:

# cat /etc/gateways
net 192.168.4.0 gateway gammaext metric 2 passive

Note – if the host name is used it should be resolved in /etc/hosts

Directives in the gateways file can also be used to prevent in.routed daemon from sending/recievieng advertizements from the specified interface. Use the noripin directive when you want your system to ignore route information that can be received on a specific interface. For example, to ignore route information received on the qfe3 interface, use the following noripin directive in the gateways file:

noripin qfe3

You can use the noripout directive to prevent a multihomed system (system with multiple physical interfaces) from acting as a router and advertising routes. For example, to ensure that no route information is sent out of the qfe3 interface, use the following noripout directive in the gateways file:

noripout qfe3

You can choose to use both the noripin and noripout directives or replace them with a single norip directive. For example, to ignore route information and to not allow route information to be sent out of the qfe3 interface, use the following norip directive in the gateways file:

norip qfe3

Selected routing algorithms

Routing algorithms should:

• Scale well
• Support many different subnetwork types and multiple qualities of service
• Adapt to topology changes quickly and efficiently (i.e., with minimum overhead and complexity)
• Provide controls that facilitate the "safe" connection of multiple organizations

As we already briefly discussed above classic routing algorithms are

• RIP
• RDISC
• OSPF
• BGP Protocol

---

Top Visited					Switchboard
					Latest
					Past week
					Past month

---

NEWS CONTENTS

• 20061128 : [SAGE] technical help with routing on Solaris 10 ( [SAGE] technical help with routing on Solaris 10, Nov 28, 2006 )
• 20061128 : HOW TO INSTALL ROUTING IN SOLARIS 10 ( HOW TO INSTALL ROUTING IN SOLARIS 10, Nov 28, 2006 )
• 20061128 : Solaris 10 routing problems ( Solaris 10 routing problems, )
• 20061128 : Solaris 8 Administrators Guide Chapter 4 Network Configuration ( Solaris 8 Administrator's Guide Chapter 4 Network Configuration, )
• 20061128 : Solaris 8 Administrators Guide Chapter 4 Network Configuration ( Solaris 8 Administrator's Guide Chapter 4 Network Configuration, )
• 20061115 : Miscellaneous Solaris notes ( Miscellaneous Solaris notes, Nov 15, 2006 )
• 20060724 : GigaOM " Open Source Router Launched ( GigaOM " Open Source Router Launched, Jul 24, 2006 )

Old News ;-)

[Nov 28, 2006] [SAGE] technical help with routing on Solaris 10

I sent the following to sun-managers, but haven't gotten much help there.
I'm thinking this may be a more generic networking problem, so I'm hoping
one of you might be able to help.

I have what seems to be a weird problem with routing that I hope y'all can help
with.

I have a Sun Fire V210 running Solaris 10 with a recommended patch cluster a
couple of weeks old.

It's got 8 interfaces -- the four on board plus a quad gigaswift (ce) card.

[Nov 28, 2006] HOW TO INSTALL ROUTING IN SOLARIS 10

I have already installed my Solaris 10 Server, I was tryin to implement the routing in the file /etc/init.d/inetsvc (/etc/rc2.d/S98inetsvc) as in Solaris 8.

!! this file does not exists!!

How install routings in Solaris 10 6/06 ??

thanks

=====
And this is why you should never mess with binary / system files but stick to configuration files. Editing rc.d scripts directory is very poor administration.

What you should be doing is looking into the routeadm(1M) command for starters. Further good readings are the manual pages for 'ifconfig(1M)' and 'in.routed(1M)'.

Solaris 10 routing problems

Anyone have routing working on Solaris 10?

Running S10_72 on a Dell Gx110 w/ 2 NICs. Trying to set it up to replace my Netgear router (and eventually configure IPv6 tunnel). having problems getting it to route packets. I turned off all of my ipfilters for debugging.

2 networks 10.10.1.x and 10.1.1.x no routing daemon, just static routes
Here are the parts of the ifconfig that matter, the output from routeadm and the routing table, along with a ping to hosts on each side and a tcpdump from the input interface elxl0 (the packets to be routed arrive here) the tcpdump on the side the packets should come out is empty (there are DNS packets and the like from the host, but no routed packets). What am I missing here?

elxl0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4>
inet 10.1.1.1 netmask ffffff00 broadcast 10.1.1.255
ether 0:b0:d0:85:e0:b4
iprb0: flags=1104843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,ROUTER,IPv4 >
inet 10.10.1.67 netmask ffffff00 broadcast 10.10.1.255
ether 0:a0:c9:98:1d:6b
# routeadm
Configuration Current Current
Option Configuration System State
------------------------------------------------------------ ---
IPv4 forwarding enabled enabled
IPv4 routing default (disabled) disabled
IPv6 forwarding disabled disabled
IPv6 routing disabled disabled

IPv4 routing daemon "/usr/sbin/in.routed"
IPv4 routing daemon args ""
IPv4 routing daemon stop "kill -TERM `cat /var/tmp/in.routed.pid`"
IPv6 routing daemon "/usr/lib/inet/in.ripngd"
IPv6 routing daemon args "-s"
IPv6 routing daemon stop "kill -TERM `cat /var/tmp/in.ripngd.pid`"

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
10.10.1.0 10.10.1.67 U 1 26 iprb0
10.1.1.0 10.1.1.1 U 1 2 elxl0
224.0.0.0 10.10.1.67 U 1 0 iprb0
default 10.10.1.1 UG 1 1 iprb0
127.0.0.1 127.0.0.1 UH 7 7281 lo0

PING 10.10.1.1: 56 data bytes
64 bytes from 10.10.1.1: icmp_seq=0. time=1.67 ms
----10.10.1.1 PING Statistics----
1 packets transmitted, 1 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 1.54/1.61/1.67/-NaN
PING 10.1.1.2: 56 data bytes
64 bytes from 10.1.1.2: icmp_seq=0. time=0.659 ms
----10.1.1.2 PING Statistics----
1 packets transmitted, 1 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 0.592/0.625/0.659/-NaN

tcpdump -vv -e -i elxl0
15:24:17.414252 00:c0:9f:20:16:a8 > 00:b0:d0:85:e0:b4, ethertype IPv4 (0x0800), length 98: IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84) 10.1.1.2 > 10.10.1.1: icmp 64: echo request seq 30213

Solaris 8 Administrator's Guide Chapter 4 Network Configuration/Routing

Imagine that you are a courier, and your run always starts at the local courier depot. You're given a list of addresses, which are associated with a set of packages, and your goal is to deliver them in as little time as possible, subject to the following constraints:

• The number of roads you take to deliver each package must be minimized.
• You must avoid deadends and accidents.
• You can only determine which roads to take by consulting a street directory and by crosschecking street names along your path with those in your directory.

If this seems like a fairly trivial task for a courier, consider how much more difficult the job would be if the following conditions prevailed:

• The number of possible roads increases exponentially each year. You might be asked to take roads you've never heard of before!
• There is no way of knowing, in advance, where accidents or deadends might occur.
• The street directory you have is completely out of date, because the number of highways increases exponentially each year.

This scenario describes the difficulties faced by the emergence of the Internet and the massive interconnections between hosts and networks. In order for a packet of data to be transferred from host A to host B, a physical path must be identified for the packet to travel.

There is no central lookup service that decides how to route each packet between all possible combinations of two hosts on the Internet (i.e., between the sender and the receiver). This means routes must be generated dynamically. (The only exceptions to this rule are certain situations where a predictable static route may be installed.)

When transferring data around the Internet or between subnets, intermediate hosts must be responsible for transferring packets between networks; these hosts are called routers and are responsible for routing packets between hosts, which can be separated by single subnets or by entire continents. To gain insight into how many routers a packet transfer may involve, let's use the traceroute command to display the "hops" required to connect from a host in Sydney, Australia, to the Sun Microsystems web server:

bash-2.03$ traceroute wwwwseast.usec.sun.com/
Tracing route to wwwseast.usec.sun.com [192.9.49.30]
over a maximum of 30 hops:
  1   184 ms   142 ms   138 ms  202.10.4.131
  2   147 ms   144 ms   138 ms  202.10.4.129
  3   150 ms   142 ms   144 ms  202.10.1.73
  4   150 ms   144 ms   141 ms  atm11-0-0-11.ia4.optus.net.au [202.139.32.17]
  5   148 ms   143 ms   139 ms  202.139.1.197
  6   490 ms   489 ms   474 ms  hssi9-0-0.sf1.optus.net.au [192.65.89.246]
  7   526 ms   480 ms   485 ms  g-sfd-br-02-f12-0.gn.cwix.net [207.124.109.57]
  8   494 ms   482 ms   485 ms  core7-hssi6-0-0.SanFrancisco.cw.net [204.70.10.9]
  9   483 ms   489 ms   484 ms  corerouter2.SanFrancisco.cw.net [204.70.9.132]
 10   557 ms   552 ms   561 ms  xcore3.Boston.cw.net [204.70.150.81]
 11   566 ms   572 ms   554 ms  sun-micro-system.Boston.cw.net [204.70.179.102]
 12   577 ms   574 ms   558 ms  wwwwseast.usec.sun.com [192.9.49.30]
Trace complete.

Here, we can see that some 12 hosts are required to transfer packets between the sender and the receiver. In addition, the observed response times can be quite slow--often more than half a second. It is possible for attempted connections to time out. This can be very useful when trying to identify which intermediate host and/or network is having problems when your remote connection to a host half a world away suddenly dies!

In this section, we'll examine how Solaris solves a number of the classic routing problems.

Static routing typically involves creating a direct physical connection between two hosts, where the implementation of dynamic routing would be wasteful or a security risk. For example, if your local network has three subnets that need to share data, a static route could be created between each router and the other two routers in the network. The number of specific routes required to allow data to flow seamlessly between networks is directly proportional to the square of the number of routers on the network. Every time a change is made to the network topology, these routes will have to be modified manually. If that sounds like too much hard work, consider the situation where it might be desirable: a secure database server that can be accessible only by knowing the route to the host and is not publicly announced. Instead of permitting route discovery, a static route is an appropriate technique here. This could be implemented by creating a point-to-point configuration using ifconfig on a secondary interface, as discussed in the network interface configuration section.

The alternative to static routing is dynamic routing, which involves two daemons: the routing daemon proper (in.routed) and the route discovery daemon (in.rdisc). The in.routed daemon implements the Routing Information Protocol, and is responsible for updating and managing entries in the kernel's routing tables. It uses UDP (port 520) for performing routing operations and operates on all network interfaces that have been plumbed and are identified as up.

If the /etc/notrouter file does not exist, and given that two or more operational interfaces can be found, the host begins to act as a router. Data can then be exchanged between data received on one interface, destined to be transmitted from another interface. For a local area network, the interface that connects to all local hosts is usually known as the internal interface, while the interface that is visible downstream to an ISP or another subnet is known as the external interface. By using packet filtering, it is possible to specify a set of rules governing what type (TCP or UDP) of packets can be transferred between interfaces and on which ports. This is obviously important for protecting local networks, since services that are available to local hosts may not be appropriate for public access.

The route discovery daemon, in.rdisc, implements the Internet Control Message Protocol (ICMP). In terms of route discovery, in.rdisc running on host systems listens for multicast broadcasts on the 224.0.0.1 (ALL_HOSTS) address. These messages are prioritized, and the default router is selected based on its proximity to the host. On routers, in.rdisc broadcasts its availability using multicast on 224.0.0.1, and listens for requests on 224.0.0.2 (ALL_ROUTERS). Hosts may request a router directly by broadcasting on 224.0.0.2.

Solaris 8 Administrator's Guide Chapter 4 Network Configuration

The kernel maintains a table of routes, constructed by the routing daemon, in.routed. The various routes that have been configured are always viewable by checking the routing statistics:

bash-2.03$ netstat -r
 
Routing Table: IPv4
Destination          Gateway              Flags Ref   Use    Interface
-------------------- -------------------- ----- ----- ------ ---------
10.64.18.0           austin                U        1      5  eri0
224.0.0.0            austin                U        1      0  eri0
localhost            localhost             UH      25 215051  lo0

Here, we can see there are two network routes available for packets on the primary Ethernet interface eri0: the 10.64.18.0 network and the 224.0.0.0 multicast network. In addition, the loopback interface (lo0) has the local host interface, which is commonly used for troubleshooting and testing. These routes are all IPv4; however, IPv6 routing details are also displayed:

Routing Table: IPv6
Destination/Mask            Gateway                     Flags Ref Use    If
--------------------------- --------------------------- ----- --- ------ -----
fe80::/10                   fe80::203:baff:fe04:a4e8    U       1      0 eri0
ff00::/8                    fe80::203:baff:fe04:a4e8    U       1      0 eri0
default                     fe80::203:baff:fe04:a4e8    U       1      0 eri0
localhost                   localhost                   UH      5     28 lo0

[Nov 15, 2006] Miscellaneous Solaris notes

"Blackhole"/null routing a destination IP address:

route add destination_IP 127.0.0.1 -blackhole

Note that this seems to work without the -blackhole flag, and can be used on most Unices.

All network traffic destined to destination_IP will not leave the network interface, as it is given a "next hop" of 127.0.0.1 (localhost). Note that destination_IP can still reach the host, although response traffic will not reach destination_IP, making it appear that communication is broken.

Solaris routing with multiple interfaces

In this example, we have an hme2 network interface with an IP address of 65.201.213.117, a network address of 65.201.213.112, and a subnet mask of 255.255.255.240. The interface was initially enabled using the default subnet mask and broadcast address.

ifconfig hme2
hme2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 65.201.213.117 netmask ff000000 broadcast 65.255.255.255

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
65.0.0.0 65.201.213.117 U 1 8 hme2

To correct the routing table:

1. Specify the correct subnet mask and broadcast address with ifconfig.
ifconfig 65.201.213.117 netmask 255.255.255.240 broadcast 65.201.213.127

2. Add an /etc/netmasks entry for the correct netmask to be used after system reboot.
65.201.213.112 255.255.255.240

Corrected routing table:

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
65.201.213.112 65.201.213.117 U 1 1 hme2

[Jul 24, 2006] GigaOM " Open Source Router Launched

Vyatta, a San Mateo, Calif.-based start-up is close to releasing an open source router platform, that runs on standard x86 hardware and can perform equally well as some of the more commercial products. Vyatta plans to target the corporate market with its own devices, but anyone can download the software, officially called, the Vyatta Open Flexible Router (OFR), and roll their own … router.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

• [PDF] Routing in the ARPANET

• Understanding routing for Solaris by Lance Spitzner (9 March, 2000)
  

• Solaris 8 Administrator's Guide Chapter 4 Network Configuration
  

• BigAdmin - Submitted Tech Tip Implementing Persistent Host and Network Routes on Solaris Systems
  

• Miscellaneous Solaris notes
  

• Solaris 8 Administrator's Guide Chapter 4 Network Configuration

Some routing protocols descriptions from Cisco

• Classless Interdomain Routing (CIDR) Classless interdomain routing. IP addressing technique supported by BGP4 and based on route aggregation. CIDR allows routers to group routes together to minimize the quantity of routing information carried by the core routers.

• Routing Information Protocol (RIP) The Routing Information Protocol (RIP) is a distance-vector protocol that uses hop count as its metric. RIP is widely used for routing traffic in the global Internet and is an interior gateway protocol (IGP), which means that it performs routing within a single autonomous system.

• Open Shortest Path First (OSPF) Open Shortest Path First (OSPF) is a routing protocol developed for Internet Protocol (IP) networks by the interior gateway protocol (IGP) working group of the Internet Engineering Task Force (IETF).

• Border Gateway Protocol (BGP) BGP performs interdomain routing in Transmission-Control Protocol/Internet Protocol (TCP/IP) networks. BGP is an exterior gateway protocol (EGP), which means that it performs routing between multiple autonomous systems or domains and exchanges routing and reachability information with other BGP systems.

Tutorials

• Internetworking Technology Overview
  • Routing Basics
• IBM Redbook
  • 3.1 Basic IP Routing -- from IBM Red Book
  • 3.6 Border Gateway Protocol (BGP-4)
• Introduction to IP Routing
• TCPIP and IPX routing tutorial
• Cisco - BGP4 Case StudiesTutorial Section 1
• The BGP Page

Lecture Courses

Class Schedule and Reading Assignments (4197)

Lecture Slides and Notes (4197)

• EE4074 Lecture 7 -- slides

EE4074 Spring'97 Network Technology Sites

Index of publiccomputinginternetripelocal-irtraining

The Computer Communication and Applications Course Syllabus

• Introduction ps, html
• Physical Layer ps, html
• Modems ps, html
• ISDN ps, html
• Switching ps, html
• Data Framing ps, html
• Error Detection ps, html
• Automatic Repeat reQuest (ARQ) Protocol ps, html
• Local Area Networks (LANs), Medium Access (MAC) Layer ps, html
• Transport Layer handouts-ps, slides-ps
• TCP part 1 handouts-ps, slides-ps
• TCP part 2 handouts-ps, slides-ps
• Compression handouts-ps, slides-ps
• Encryption handouts-ps, slides-ps
• DNS handouts-ps, slides-ps
• NFS handouts-ps, slides-ps

Internet Technology Protocols and Services -- slides in PDF

IPng Mail Archive (IPng 190) Neighbor Discovery slides from WG meeting

ANS Papers and Drafts - Presentation Slides

204421 Computer Networks Class Schedule

Spring 1998 - CS 138c Special Topics in Networking Student Topics

CSc425525 Home Page -- good, contains slides

Cable Modems Myths and Reality

CSCI-3780 Course Page

Reference

• rfc1771 A Border Gateway Protocol 4 (BGP-4)
• rfc1772 Application of the Border Gateway Protocol
• rfc1773 Experience with the BGP-4 protocol
• rfc1774 BGP-4 Protocol Analysis
• rfc 1965 Autonomous System Confederations for BGP
• rfc1966 BGP Route Reflection
• rfc1997 BGP Communities Attribute
• rfc1998 BGP Community Attribute in Multi-home Routing
• rfc1657 The BGP MIB
• CIDR FAQ
• IETF BGP Working Group Document (historical)

Multihoming

• MCI's Routing Page
• Multihoming for the Small ISP FAQ
• Dual-Homing

Random Findings

Quiz

Q1. The ______ command may be used to add or remove routes from the routing table.

a. netstat

b. rdisc

c. rip

d. route

Syntax: route [-fn] add|delete [host|net] destination [gateway [metric]]

Q2. ______ is a file that contains hostname or IP addresses of one or more routes to the network.

a. /etc/defaultrouter

b. /etc/inet/networks

c. /etc/gateways

d. /etc/hosts

Q3. If there are two IP addresses, or entries in the /etc/gateways file, ______ is enabled and the in.routed(RIP) or in.rdisc (RDISC) processes start.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019