Cisco elearning

UTP CABLE WAYS LOADING

2010-07-10T20:17:00.000-07:00

Shielded twisted pair (STP or STP-A), shielded twisted pair or STP is a twisting pair cable that has protection from metal to protect the cable from external electromagnetic intereferensi. For network installation at this point is usually used category 5 UTP cabling.

How to installation of cable in order for the second color system. you can see the image below

UTP CABLE WAYS LOADING

Hopefully useful for those who want to know how the composition of network cabling (LAN)

The IP Route Command

2009-09-30T11:01:00.000-07:00

The IP Route Command

The command for configuring a static route is ip route. The complete syntax for configuring a static route is:

Router(config)#ip route prefix mask {ip-address | interface-type interface-number [ip-address]} [distance] [name] [permanent] [tag tag]

Most of these parameters are not relevant for this chapter or for your CCNA studies. As shown in the figure, we will use a simpler version of the syntax:

Router(config)#ip route network-address subnet-mask {ip-address | exit-interface }

The following parameters are used:
network-address - Destination network address of the remote network to be added to the routing table
subnet-mask - Subnet mask of the remote network to be added to the routing table. The subnet mask can be modified to summarize a group of networks.

One or both of the following parameters must also be used:
ip-address - Commonly referred to as the next-hop router's IP address
exit-interface - Outgoing interface that would be used in forwarding packets to the destination network

Note: The ip-address parameter is commonly referred to as the "next-hop" router's IP address. The actual next-hop router's IP address is commonly used for this parameter. However, the ip-address parameter could be any IP address, as long as it is resolvable in the routing table. This is beyond the scope of this course, but we've added this point to maintain technical accuracy.

Purpose and Command Syntax OF IP Route

2009-09-30T10:55:00.000-07:00

Purpose and Command Syntax of ip route

As we have discussed previously, a router can learn about remote networks in one of two ways:
Manually, from configured static routes
Automatically, from a dynamic routing protocol

The rest of this chapter focuses on configuring static routes. Dynamic routing protocols are introduced in the next chapter.

Static routes

Static routes are commonly used when routing from a network to a stub network. A stub network is a network accessed by a single route. For an example, see the figure. Here we see that any network attached to R1 would only have one way to reach other destinations, whether to networks attached to R2 or to destinations beyond R2. Therefore, network 172.16.3.0 is a stub network and R1 is a stub router.

Running a routing protocol between R1 and R2 is a waste of resources because R1 has only one way out for sending non-local traffic. Therefore, static routes are configured for connectivity to remote networks that are not directly connected to a router. Again, referring to the figure, we would configure a static route on R1 to the LAN attached to R2. We will also see how to configure a default static route from R1 to R2 later in the chapter so that R1 can send traffic to any destination beyond R2.

Alexa traffic smallest

2009-06-21T22:43:00.000-07:00

Alexa traffic is traffic to our blog, the more traffic to our blog the small number of nominal figures we blog in Alexa’s eyes, and this is a sign of good alexa toolbar although sometimes confusing. Alexa indeed apply logic to the google rankings, blogs, if we are considered “important” google, it will increase the nominal amount of numbers we blog on google, while Alexa, the more we visited blog other bloggers, the small number of our nominal Alexa. Alexa rating determines your blog. The higher the ranking of a blog, the more “job / task” that you will receive, and also the more money that flows to your paypal. There are a few tips that can improve the ranking in the Alexa blog. among others:

1. Alexa Widget

Place the Alexa site widget stat in your website. Alexa stat this site contains javascript that accompany every visitor data (ping) to the server so that Alexa Alexa statistics become more accurate.
Scriptnya can be taken at the Alexa website. Live copy and paste. No need to install the Alexa widget ashamed when we rank blog is far, to achieve the desired results of course there is the price that must be paid.

2. Alexa Toolbar

Using a browser that Alexa toolbar installed can increase your website ranking. In fact not only your website, every website visited by a browser which is installed Alexa toolbar also get “value” that will be in the ranking. Then, the visitor is not sure of the website you are yourself? So, if your browser already installed the toolbar, then the addition of point ranking akan happen automatically. Nah, Alexa toolbar for Firefox can be installed

Router Connections

2009-04-27T01:42:00.001-07:00

Router Connections

Connecting a router to a network requires a router interface connector to be coupled with a cable connector. As you can see in the figure, Cisco routers support many different connector types.

Serial Connectors

Picture Router Connections

For WAN connections, Cisco routers support the EIA/TIA-232, EIA/TIA-449, V.35, X.21, and EIA/TIA-530 standards for serial connections, as shown. Memorizing these connection types is not important. Just know that a router has a DB-60 port that can support five different cabling standards. Because five different cable types are supported with this port, the port is sometimes called a five-in-one serial port. The other end of the serial cable is fitted with a connector that is appropriate to one of the five possible standards.

Note: The documentation for the device to which you want to connect should indicate the standard for that device.

Newer routers support the smart serial interface that allows for more data to be forwarded across fewer cable pins. The serial end of the smart serial cable is a 26-pin connector. It is much smaller than the DB-60 connector used to connect to a five-in-one serial port. These transition cables support the same five serial standards and are available in either DTE or DCE configurations.

Note: For a thorough explanation of DTE and DCE, see Lab 1.5.1, "Cabling a Network and Basic Router Configuration."

These cable designations are only important to you when configuring your lab equipment to simulate a "real-world" environment. In a production setting, the cable type is determined for you by the WAN service you are using.

Ethernet Connectors

UTP CABLE

A different connector is used in an Ethernet-based LAN environment. An RJ-45 connector for the unshielded twisted-pair (UTP) cable is the most common connector used to connect LAN interfaces. At each end of an RJ-45 cable, you should be able to see eight colored strips, or pins. An Ethernet cable uses pins 1, 2, 3, and 6 for transmitting and receiving data.

DTE SERIAL
DTE SMART SERIAL

Two types of cables can be used with Ethernet LAN interfaces:
A straight-through, or patch cable, with the order of the colored pins the same on each end of the cable
A crossover cable, with pin 1 connected to pin 3, and pin 2 connected to pin 6

Straight-through cables are used for:
Switch-to-router
Switch-to-PC
Hub-to-PC
Hub-to-server

Crossover cables are used for:
Switch-to-switch
PC-to-PC
Switch-to-hub
Hub-to-hub
Router-to-router
Router-to-server

Note: Wireless connectivity is discussed in another course.
Related Topic Router

Role Of The Router

2009-04-26T23:53:00.000-07:00

The router is a special-purpose computer that plays a key role in the operation of any data network. Routers are primarily responsible for interconnecting networks by:

Determining the best path to send packets
Forwarding packets toward their destination

Routers perform packet forwarding by learning about remote networks and maintaining routing information. The router is the junction or intersection that connects multiple IP networks. The routers primary forwarding decision is based on Layer 3 information, the destination IP address.

The router's routing table is used to find the best match between the destination IP of a packet and a network address in the routing table. The routing table will ultimately determine the exit interface to forward the packet and the router will encapsulate that packet in the appropriated data link frame for that outgoing interface.
Related Topic Router

Best Path Best Path And Metric

2009-03-02T08:44:00.000-08:00

Determining a router's best path involves the evaluation of multiple paths to the same destination network and selecting the optimum or "shortest" path to reach that network. Whenever multiple paths to reach the same network exist, each path uses a different exit interface on the router to reach that network. The best path is selected by a routing protocol based on the value or metric it uses to determine the distance to reach a network. Some routing protocols, such as RIP, use simple hop-count, which the number of routers between a router and the destination network. Other routing protocols, such as OSPF, determine the shortest path by examining the bandwidth of the links, and using the links with the fastest bandwidth from a router to the destination network.

Dynamic routing protocols typically use their own rules and metrics to build and update routing tables. A metric is the quantitative value used to measure the distance to a given route. The best path to a network is the path with the lowest metric. For example, a router will prefer a path that is 5 hops away over a path that is 10 hops away.

The primary objective of the routing protocol is to determine the best paths for each route to include in the routing table. The routing algorithm generates a value, or a metric, for each path through the network. Metrics can be based on either a single characteristic or several characteristics of a path. Some routing protocols can base route selection on multiple metrics, combining them into a single metric. The smaller the value of the metric, the better the path.

Comparing Hop Count and Bandwidth Metrics

Two metrics that are used by some dynamic routing protocols are:
Hop count-Hop count is the number of routers that a packet must travel through before reaching its destination. Each router is equal to one hop. A hop count of four indicates that a packet must pass through four routers to reach its destination. If multiple paths are available to a destination, the routing protocol, such as RIP, picks the path with the least number of hops.
Bandwidth-Bandwidth is the data capacity of a link, sometimes referred to as the speed of the link. For example, Cisco's implementation of the OSPF routing protocol uses bandwidth as its metric. The best path to a network is determined by the path with an accumulation of links that have the highest bandwidth values, or the fastest links. The use of bandwidth in OSPF will be explained in Chapter 11.

Note: Speed is technically not an accurate description of bandwidth because all bits travel at the same speed over the same physical medium. Bandwidth is more accurately defined as the number of bits that can be transmitted over a link per second.

When hop count is used as the metric, the resulting path may sometimes be suboptimal. For example, consider the network shown in the figure. If RIP is the routing protocol used by the three routers, then R1 will choose the suboptimal route through R3 to reach PC2 because this path has fewer hops. Bandwidth is not considered. However, if OSPF is used as the routing protocol, then R1 will choose the route based on bandwidth. Packets will be able to reach their destination sooner using the two, faster T1 links as compared to the single, slower 56 Kbps link.

Packet Fields and Frame Fields

2009-03-02T08:35:00.000-08:00

As we discussed previously, routers make their primary forwarding decision by examining the destination IP address of a packet. Before sending a packet out the proper exit interface, the IP packet needs to be encapsulated into a Layer 2 data link frame. Later in this section we will follow an IP packet from source to destination, examining the encapsulation and decapsulation process at each router. But first, we will review the format of a Layer 3 IP packet and a Layer 2 Eternet frame.

Internet Protocol (IP) Packet Format

The Internet Protocol specified in RFC 791 defines the IP packet format. The IP packet header has specific fields that contain information about the packet and about the sending and receiving hosts. Below is a list of the fields in the IP header and a brief description for each one. You should already be familiar with destination IP address, source IP address, version, and Time To Live (TTL ) fields. The other fields are important but are outside the scope of this course.
Version - Version number (4 bits); predominant version is IP version 4 (IPv4)
IP header length - Header length in 32-bit words (4 bits)
Precedence and type of service - How the datagram should be handled (8 bits); the first 3 bits are precedence bits (this use has been superseded by Differentiated Services Code Point [DSCP], which uses the first 6 bits [last 2 reserved])
Packet length - Total length (header + data) (16 bits)
Identification - Unique IP datagram value (16 bits)
Flags - Controls fragmenting (3 bits)
Fragment offset - Supports fragmentation of datagrams to allow differing maximum transmission units (MTUs) in the Internet (13 bits)
Time to Live (TTL) - Identifies how many routers can be traversed by the datagram before being dropped (8 bits)
Protocol - Upper-layer protocol sending the datagram (8 bits)
Header checksum - Integrity check on the header (16 bits)
Source IP address - 32-bit source IP address (32 bits)
Destination IP address - 32-bit destination IP address (32 bits)
IP options - Network testing, debugging, security, and others (0 or 32 bits, if any)

MAC Layer Frame Format

The Layer 2 data link frame usually contains header information with a data link source and destination address, trailer information, and the actual transmitted data. The data link source address is the Layer 2 address of the interface that sent the data link frame. The data link destination address is the Layer 2 address of the interface of the destination device. Both the source and destination data link interfaces are on the same network. As a packet is forwarded from router to router, the Layer 3 source and destination IP addresses will not change; however, the Layer 2 source and destination data link addresses will change. This process will be examined more closely later in this section.

Note: When NAT (Network Address Translation) is used, the destination IP address does change, but this process is of no concern to IP and is a process performed within a company's network. Routing with NAT is discussed in a later course.

The Layer 3 IP packet is encapsulated in the Layer 2 data link frame associated with that interface. In this example, we will show the Layer 2 Ethernet frame. The figure shows the two compatible versions of Ethernet. Below is a list of the fields in an Ethernet frame and a brief description of each one.
Preamble - Seven bytes of alternating 1s and 0s, used to synchronize signals
Start-of-frame (SOF) delimiter - 1 byte signaling the beginning of the frame
Destination address - 6 byte MAC address of the sending device on the local segment
Source address - 6 byte MAC address of the receiving device on the local segment
Type/length - 2 bytes specifying either the type of upper layer protocol (Ethernet II frame format) or the length of the data field (IEEE 802.3 frame format)
Data and pad - 46 to 1500 bytes of data; zeros used to pad any data packet less than 46 bytes
Frame check sequence (FCS) - 4 bytes used for a cyclical redundancy check to make sure the frame is not corrupted

Routing Table Principles

2009-03-02T08:34:00.000-08:00

At times in this course we will refer to three principles regarding routing tables that will help you understand, configure, and troubleshoot routing issues. These principles are from Alex Zinin's book, Cisco IP Routing.

1. Every router makes its decision alone, based on the information it has in its own routing table.

2. The fact that one router has certain information in its routing table does not mean that other routers have the same information.

3. Routing information about a path from one network to another does not provide routing information about the reverse, or return, path.

What is the effect of these principles? Let's look at the example in the figure.

1. After making its routing decision, router R1 forwards the packet destined for PC3 to router R2. R1 only knows about the information in its own routing table, which indicates that router R2 is the next-hop router. R1 does not know whether or not R2 actually has a route to the destination network.

2. It is the responsibility of the network administrator to make sure that all routers within their control have complete and accurate routing information so that packets can be forwarded between any two networks. This can be done using static routes, a dynamic routing protocol, or a combination of both.

3. Router R2 was able to forward the packet toward PC3's destination network. However, the packet from PC2 to PC1 was dropped by R2. Although R2 has information in its routing table about the destination network of PC1, we do not know if it has the information for the return path back to PC1's network.

Asymmetric Routing

Because routers do not necessarily have the same information in their routing tables, packets can traverse the network in one direction, using one path, and return via another path. This is called asymmetric routing. Asymmetric routing is more common in the Internet, which uses the BGP routing protocol than it is in most internal networks.

This example implies that when designing and troubleshooting a network, the network administrator should check the following routing information:
Is there a path from source to destination available in both directions?
Is the path taken in both directions the same path? (Asymmetrical routing is not uncommon, but sometimes can pose additional issues.)
Related Topic Router

Dynamic Routing

2009-03-02T08:18:00.000-08:00

Remote networks can also be added to the routing table by using a dynamic routing protocol. In the figure, R1 has automatically learned about the 192.168.4.0/24 network from R2 through the dynamic routing protocol, RIP (Routing Information Protocol). RIP was one of the first IP routing protocols and will be fully discussed in later chapters.

Note: R1's routing table in the figure shows that R1 has learned about two remote networks: one route that dynamically used RIP and a static route that was configured manually. This is an example of how routing tables can contain routes learned dynamically and configured statically and is not necessarily representative of the best configuration for this network.

Dynamic routing protocols are used by routers to share information about the reachability and status of remote networks. Dynamic routing protocols perform several activities, including:
Network discovery
Updating and maintaining routing tables

Automatic Network Discovery

Network discovery is the ability of a routing protocol to share information about the networks that it knows about with other routers that are also using the same routing protocol. Instead of configuring static routes to remote networks on every router, a dynamic routing protocol allows the routers to automatically learn about these networks from other routers. These networks - and the best path to each network - are added to the router's routing table and denoted as a network learned by a specific dynamic routing protocol.

Maintaining Routing Tables

After the initial network discovery, dynamic routing protocols update and maintain the networks in their routing tables. Dynamic routing protocols not only make a best path determination to various networks, they will also determine a new best path if the initial path becomes unusable (or if the topology changes). For these reasons, dynamic routing protocols have an advantage over static routes. Routers that use dynamic routing protocols automatically share routing information with other routers and compensate for any topology changes without involving the network administrator.

IP Routing Protocols

There are several dynamic routing protocols for IP. Here are some of the more common dynamic routing protocols for routing IP packets:
RIP (Routing Information Protocol)
IGRP (Interior Gateway Routing Protocol)
EIGRP (Enhanced Interior Gateway Routing Protocol)
OSPF (Open Shortest Path First)
IS-IS (Intermediate System-to-Intermediate System)
BGP (Border Gateway Protocol)

Note: RIP (versions 1 and 2), EIGRP, and OSPF are discussed in this course. EIGRP and OSPF are also explained in more detail in CCNP, along with IS-IS and BGP. IGRP is a legacy routing protocol and has been replaced by EIGRP. Both IGRP and EIGRP are Cisco proprietary routing protocols, whereas all other routing protocols listed are standard, non-proprietary protocols.

Once again, remember that in most cases, routers contain a combination of static routes and dynamic routes in the routing tables. Dynamic routing protocols will be discussed in more detail in Chapter 3, "Dynamic Routing Protocols."
Related Topic Router

Static Routing

2009-03-02T07:48:00.000-08:00

Remote networks are added to the routing table either by configuring static routes or enabling a dynamic routing protocol. When the IOS learns about a remote network and the interface that it will use to reach that network, it adds that route to the routing table as long as the exit interface is enabled.

A static route includes the network address and subnet mask of the remote network, along with the IP address of the next-hop router or exit interface. Static routes are denoted with the code S in the routing table as shown in the figure. Static routes are examined in detail in the next chapter.

When to Use Static Routes

Static routes should be used in the following cases:
A network consists of only a few routers. Using a dynamic routing protocol in such a case does not present any substantial benefit. On the contrary, dynamic routing may add more administrative overhead.
A network is connected to the Internet only through a single ISP. There is no need to use a dynamic routing protocol across this link because the ISP represents the only exit point to the Internet.
A large network is configured in a hub-and-spoke topology. A hub-and-spoke topology consists of a central location (the hub) and multiple branch locations (spokes), with each spoke having only one connection to the hub. Using dynamic routing would be unnecessary because each branch has only one path to a given destination-through the central location.

Typically, most routing tables contain a combination of static routes and dynamic routes. But, as stated earlier, the routing table must first contain the directly connected networks used to access these remote networks before any static or dynamic routing can be used.

Building Routing Table

2009-03-02T07:41:00.000-08:00

Introducing the Routing Table

The primary function of a router is to forward a packet toward its destination network, which is the destination IP address of the packet. To do this, a router needs to search the routing information stored in its routing table.

A routing table is a data file in RAM that is used to store route information about directly connected and remote networks. The routing table contains network/next hop associations. These associations tell a router that a particular destination can be optimally reached by sending the packet to a specific router that represents the "next hop" on the way to the final destination. The next hop association can also be the outgoing or exit interface to the final destination.

The network/exit-interface association can also represent the destination network address of the IP packet. This association occurs on the router's directly connected networks.

A directly connected network is a network that is directly attached to one of the router interfaces. When a router interface is configured with an IP address and subnet mask, the interface becomes a host on that attached network. The network address and subnet mask of the interface, along with the interface type and number, are entered into the routing table as a directly connected network. When a router forwards a packet to a host, such as a web server, that host is on the same network as a router's directly connected network.

A remote network is a network that is not directly connected to the router. In other words, a remote network is a network that can only be reached by sending the packet to another router. Remote networks are added to the routing table using either a dynamic routing protocol or by configuring static routes. Dynamic routes are routes to remote networks that were learned automatically by the router, using a dynamic routing protocol. Static routes are routes to networks that a network administrator manually configured.

Note: The routing table-with its directly-connected networks, static routes, and dynamic routes-will be introduced in the following sections and discussed in even greater detail throughout this course.

The following analogies may help clarify the concept of connected, static, and dynamic routes:
Directly Connected Routes - To visit a neighbor, you only have to go down the street on which you already live. This path is similar to a directly-connected route because the "destination" is available directly through your "connected interface," the street.
Static Routes - A train uses the same railroad tracks every time for a specified route. This path is similar to a static route because the path to the destination is always the same.
Dynamic Routes - When driving a car, you can "dynamically" choose a different path based on traffic, weather, or other conditions. This path is similar to a dynamic route because you can choose a new path at many different points on your way to the destination.

The show ip route command

As shown in the figure the routing table is displayed with the show ip route command. At this point, there have not been any static routes configured nor any dynamic routing protocol enabled. Therefore, the routing table for R1 only shows the router's directly connected networks. For each network listed in the routing table, the following information is included:
C - The information in this column denotes the source of the route information, directly connected network, static route or a dynamic routing protocol. The C represents a directly connected route.
192.168.1.0/24 - This is the network address and subnet mask of the directly connected or remote network. In this example, both entries in the routing table, 192.168.1./24 and 192.168.2.0/24, are directly connected networks.
FastEthernet 0/0 - The information at the end of the route entry represents the exit interface and/or the IP address of the next-hop router. In this example, both FastEthernet 0/0 and Serial0/0/0 are the exit interfaces used to reach these networks.

When the routing table includes a route entry for a remote network, additional information is included, such as the routing metric and the administrative distance. Routing metrics, administrative distance, and the show ip route command are explained in more detail in later chapters.

PCs also have a routing table. In the figure, you can see the route print command output. The command reveals the configured or acquired default gateway, connected, loopback, multicast, and broadcast networks. The output from route print command will not be analyzed during this course. It is shown here to emphasize the point that all IP configured devices should have a routing table.
Adding a Connected Network to the Routing Table

As stated in the previous section, when a router's interface is configured with an IP address and subnet mask, that interface becomes a host on that network. For example, when the FastEthernet 0/0 interface on R1in the figure is configured with the IP address 192.168.1.1 and the subnet mask 255.255.255.0, the FastEthernet 0/0 interface becomes a member of the 192.168.1.0/24 network. Hosts that are attached to the same LAN, like PC1, are also configured with an IP address that belongs to the 192.168.1.0/24 network.

When a PC is configured with a host IP address and subnet mask, the PC uses the subnet mask to determine what network it now belongs to. This is done by the operating system ANDing the host IP address and subnet mask. A router uses the same logic when an interface is configured.

A PC is normally configured with a single host IP address because it only has a single network interface, usually an Ethernet NIC. Routers have multiple interfaces; therefore, each interface must be a member of a different network. In the figure, R1 is a member of two different networks: 192.168.1.0/24 and 192.168.2.0/24. Router R2 is also a member of two networks: 192.168.2.0/24 and 192.168.3.0/24.

After the router's interface is configured and the interface is activated with the no shutdown command, the interface must receive a carrier signal from another device (router, switch, hub, etc.) before the interface state is considered "up." Once the interface is "up," the network of that interface is added to the routing table as a directly connected network.

Before any static or dynamic routing is configured on a router, the router only knows about its own directly connected networks. These are the only networks that are displayed in the routing table until static or dynamic routing is configured. Directly connected networks are of prime importance for routing decisions. Static and dynamic routes cannot exist in the routing table without a router's own directly connected networks. The router cannot send packets out an interface if that interface is not enabled with an IP address and subnet mask, just as a PC cannot send IP packets out its Ethernet interface if that interface is not configured with an IP address and subnet mask.

Note: The process of configuring router interfaces and adding network address to the routing table are discussed in the following chapter.
Related Topic Router

Basic Router Configuration

2009-03-02T07:36:00.000-08:00

When configuring a router, certain basic tasks are performed including:
Naming the router
Setting passwords
Configuring interfaces
Configuring a banner
Saving changes on a router
Verifying basic configuration and router operations

You should already be familiar with these configuration commands; however, we will do a brief review. We begin our review with the assumption that the router does not have a current startup-config file.

The first prompt appears at user mode. User mode allows you to view the state of the router, but does not allow you to modify its configuration. Do not confuse the term "user" as used in user mode with users of the network. User mode is intended for the network technicians, operators, and engineers who have the responsibility to configure network devices.

Router>

The enable command is used to enter the privileged EXEC mode. This mode allows the user to make configuration changes on the router. The router prompt will change from a ">" to a "#" in this mode.

Router>enable
Router#

Hostnames and Passwords

The figure shows the basic router configuration command syntax used to configure R1 in the following example. You can open Packet Tracer Activity 1.2.2 and follow along or wait until the end of this section to open it.

First, enter the global configuration mode.

Router#config t

Next, apply a unique hostname to the router.

Router(config)#hostname R1
R1(config)#

Now, configure a password that is to be used to enter privileged EXEC mode. In our lab environment, we will use the password class. However, in production environments, routers should have strong passwords. See the links at the end of this section for more information on creating and using strong passwords.

Router(config)#enable secret class

Next, configure the console and Telnet lines with the password cisco. Once again, the password cisco is used only in our lab environment. The command login enables password checking on the line. If you do not enter the command login on the console line, the user will be granted access to the line without entering a password.

R1(config)#line console 0
R1(config-line)#password cisco
R1(config-line)#login
R1(config)#line vty 0 4
R1(config-line)#password cisco
R1(config-line)#login

Configuring a Banner

From the global configuration mode, configure the message-of-the-day (motd) banner. A delimiting character, such as a "#" is used at the beginning and at the end of the message. The delimiter allows you to configure a multiline banner, as shown here.

R1(config)#banner motd #
Enter TEXT message. End with the character '#'.
******************************************
WARNING!! Unauthorized Access Prohibited!!
******************************************
#

Configuring an appropriate banner is part of a good security plan. At a very minimum, a banner should warn against unauthorized access. Never configure a banner that "welcomes" an unauthorized user.

Links

For discussions about using strong passwords, see:

"Cisco Response to Dictionary Attacks on Cisco LEAP," at http://www.cisco.com/en/US/products/hw/wireless/ps430/prod_bulletin09186a00801cc901.html#wp1002291

"Strong passwords: How to create and use them," at http://www.microsoft.com/athome/security/privacy/password.mspx

Router Interface Configuration

You will now configure the individual router interfaces with IP addresses and other information. First, enter the interface configuration mode by specifying the interface type and number. Next, configure the IP address and subnet mask:

R1(config)#interface Serial0/0
R1(config-if)#ip address 192.168.2.1 255.255.255.0

It is good practice to configure a description on each interface to help document the network information. The description text is limited to 240 characters. On production networks a description can be helpful in troubleshooting by providing information about the type of network that the interface is connected to and if there are any other routers on that network. If the interface connects to an ISP or service carrier, it is helpful to enter the third party connection and contact information; for example:

Router(config-if)#description Ciruit#VBN32696-123 (help desk:1-800-555-1234)

In lab environments, enter a simple description that will help in troubleshooting situations; for example:

R1(config-if)#description Link to R2

After configuring the IP address and description, the interface must be activated with the no shutdown command. This is similar to powering on the interface. The interface must also be connected to another device (a hub, a switch, another router, etc.) for the Physical layer to be active.

Router(config-if)#no shutdown

Note: When cabling a point-to-point serial link in our lab environment, one end of the cable is marked DTE and the other end is marked DCE. The router that has the DCE end of the cable connected to its serial interface will need the additional clock rate command configured on that serial interface. This step is only necessary in a lab environment and will be explained in more detail in Chapter 2, "Static Routing."

R1(config-if)#clock rate 64000

Repeat the interface configuration commands on all other interfaces that need to be configured. In our topology example, the FastEthernet interface needs to be configured.

R1(config)#interface FastEthernet0/0
R1(config-if)#ip address 192.168.1.1 255.255.255.0
R1(config-if)#description R1 LAN
R1(config-if)#no shutdown

Each Interface Belongs to a Different Network

At this point, note that each interface must belong to a different network. Although the IOS allows you to configure an IP address from the same network on two different interfaces, the router will not activate the second interface.

For example, what if you attempt to configure the FastEthernet 0/1 interface on R1 with an IP address on the 192.168.1.0/24 network? FastEthernet 0/0 has already been assigned an address on that same network. If you attempt to configure another interface, FastEthernet 0/1, with an IP address that belongs to the same network, you will get the following message:

R1(config)#interface FastEthernet0/1
R1(config-if)#ip address 192.168.1.2 255.255.255.0
192.168.1.0 overlaps with FastEthernet0/0

If there is an attempt to enable the interface with the no shutdown command, the following message will appear:

R1(config-if)#no shutdown
192.168.1.0 overlaps with FastEthernet0/0
FastEthernet0/1: incorrect IP address assignment

Notice that the output from the show ip interface brief command shows that the second interface configured for the 192.168.1.0/24 network, FastEthernet 0/1, is still down.

R1#show ip interface brief

FastEthernet0/1 192.168.1.2 YES manual administratively down down
Verifying Basic Router Configuration

Currently in the example, all of the previous basic router configuration commands have been entered and were immediately stored in the running configuration file of R1. The running-config file is stored in RAM and is the configuration file used by IOS. The next step is to verify the commands entered by displaying the running configuration with the following command:

R1#show running-config

Now that the basic configuration commands have been entered, it is important to save the running-config to the nonvolatile memory, the NVRAM of the router. That way, in case of a power outage or an accidental reload, the router will be able to boot with the current configuration. After the router's configuration has been completed and tested, it is important to save the running-config to the startup-config as the permanent configuration file.

R1#copy running-config startup-config

After applying and saving the basic configuration, you can use several commands to verify that you have correctly configured the router. Click the appropriate button in the figure to see a listing of each command's output. All of these commands are discussed in detail in later chapters. For now, begin to become familiar with the output.

R1#show running-config

This command displays the current running configuration that is stored in RAM. With a few exceptions, all configuration commands that were used will be entered into the running-config and implemented immediately by the IOS.

R1#show startup-config

This command displays the startup configuration file stored in NVRAM. This is the configuration that the router will use on the next reboot. This configuration does not change unless the current running configuration is saved to NVRAM with the copy running-config startup-config command. Notice in the figure that the startup configuration and the running configuration are identical. They are identical because the running configuration has not changed since the last time it was saved. Also notice that the show startup-config command also displays how many bytes of NVRAM the saved configuration is using.

R1#show ip route

This command displays the routing table that the IOS is currently using to choose the best path to its destination networks. At this point, R1 only has routes for its directly connected networks via its own interfaces.

R1#show interfaces

This command displays all of the interface configuration parameters and statistics. Some of this information is discussed later in the curriculum and in CCNP.

R1#show ip interface brief

This command displays abbreviated interface configuration information, including IP address and interface status. This command is a useful tool for troubleshooting and a quick way to determine the status of all router interfaces.
Related Topic Router

Implementing Basic Addressing Schemes

2009-03-02T07:34:00.000-08:00

When designing a new network or mapping an existing network, document the network. At a minimum, the documentation should include a topology diagram that indicates the physical connectivity and an addressing table that lists all of the following information:
Device names
Interfaces used in the design
IP addresses and subnet masks
Default gateway addresses for end devices, such as PCs

Populating an Address Table

The figure shows a network topology with the devices interconnected and configured with IP addresses. Under the topology is a table used to document the network. The table is partially populated with the data documenting the network (devices, IP addresses, subnet masks, and interfaces).

Router R1 and host PC1 are already documented. Finish populating the table and the blank spaces on the diagram dragging the pool of IP addresses shown below the table to the correct locations.

Routers and the Network Layer

2009-03-02T07:30:00.000-08:00

The main purpose of a router is to connect multiple networks and forward packets destined either for its own networks or other networks. A router is considered a Layer 3 device because its primary forwarding decision is based on the information in the Layer 3 IP packet, specifically the destination IP address. This process is known as routing.

When a router receives a packet, it examines its destination IP address. If the destination IP address does not belong to any of the router's directly connected networks, the router must forward this packet to another router. In the figure, R1 examines the destination IP address of the packet. After searching the routing table, R1 forwards the packet onto R2. When R2 receives the packet, it also examines the packet's destination IP address. After searching its routing table, R2 forwards the packet out its directly connected Ethernet network to PC2.

When each router receives a packet, it searches its routing table to find the best match between the destination IP address of the packet and one of the network addresses in the routing table. Once a match is found, the packet is encapsulated in the layer 2 data link frame for that outgoing interface. The type of data link encapsulation depends on the type of interface, such as Ethernet or HDLC.

Eventually the packet reaches a router that is part of a network that matches the destination IP address of the packet. In this example, router R2 receives the packet from R1. R2 forwards the packet out its Ethernet interface, which belongs to the same network as the destination device, PC2.

This sequence of events is explained in more detail later in this chapter.
Routers Operate at Layers 1, 2, and 3

A router makes its primary forwarding decision at Layer 3, but as we saw earlier, it participates in Layer 1 and Layer 2 processes as well. After a router has examined the destination IP address of a packet and consulted its routing table to make its forwarding decision, it can forward that packet out the appropriate interface toward its destination. The router encapsulates the Layer 3 IP packet into the data portion of a Layer 2 data link frame appropriate for the exit interface. The type of frame can be an Ethernet, HDLC, or some other Layer 2 encapsulation - whatever encapsulation is used on that particular interface. The Layer 2 frame is encoded into the Layer 1 physical signals that are used to represent bits over the physical link.

To understand this process better, refer to the figure. Notice that PC1 operates at all seven layers, encapsulating the data and sending the frame out as a stream of encoded bits to R1, its default gateway.

R1 receives the stream of encoded bits on its interface. The bits are decoded and passed up to Layer 2, where R1 decapsulates the frame. The router examines the destination address of the data link frame to determine if it matches the receiving interface, including a broadcast or multicast address. If there is a match with the data portion of the frame, the IP packet is passed up to Layer 3, where R1 makes its routing decision. R1 then re-encapsulates the packet into a new Layer 2 data link frame and forwards it out the outbound interface as a stream of encoded bits.

R2 receives the stream of bits, and the process repeats itself. R2 decapsulates the frame and passes the data portion of the frame, the IP packet, to Layer 3 where R2 makes its routing decision. R2 then re-encapsulates the packet into a new Layer 2 data link frame and forwards it out the outbound interface as a stream of encoded bits.

This process is repeated once again by router R3, which forwards the IP packet, encapsulated inside a data link frame and encoded as bits, to PC2.

Each router in the path from source to destination performs this same process of decapsulation, searching the routing table, and then re-encapsulation. This process is important to your understanding of how routers participate in networks. Therefore, we will revisit this discussion in more depth in a later section.
Related Topic Router

Router Interface

2009-03-02T07:27:00.000-08:00

Management Ports

Routers have physical connectors that are used to manage the router. These connectors are known as management ports. Unlike Ethernet and serial interfaces, management ports are not used for packet forwarding. The most common management port is the console port. The console port is used to connect a terminal, or most often a PC running terminal emulator software, to configure the router without the need for network access to that router. The console port must be used during initial configuration of the router.

Another management port is the auxiliary port. Not all routers have auxiliary ports. At times the auxiliary port can be used in ways similar to a console port. It can also be used to attach a modem. Auxiliary ports will not be used in this curriculum.

The figure shows the console and AUX ports on the router.

Router Interfaces

The term interface on Cisco routers refers to a physical connector on the router whose main purpose is to receive and forward packets. Routers have multiple interfaces that are used to connect to multiple networks. Typically, the interfaces connect to various types of networks, which means that different types of media and connectors are required. Often a router will need to have different types of interfaces. For example, a router usually has FastEthernet interfaces for connections to different LANs and various types of WAN interfaces to connect a variety of serial links including T1, DSL and ISDN. The figure shows the FastEthernet and serial interfaces on the router.

Like interfaces on a PC, the ports and interfaces on a router are located on the outside of the router. Their external location allows for convenient attachment to the appropriate network cables and connectors.

Note: A single interface on a router can be used to connect to multiple networks; however, this is beyond the scope of this course and is discussed in a later course.

Like most networking devices, Cisco routers use LED indicators to provide status information. An interface LED indicates the activity of the corresponding interface. If an LED is off when the interface is active and the interface is correctly connected, this may be an indication of a problem with that interface. If an interface is extremely busy, its LED will always be on. Depending on the type of router, there may be other LEDs as well. For more information on LED displays on the 1841, see the link below.

Links

"Troubleshooting Cisco 1800 Series Routers (Modular)," http://www.cisco.com/en/US/products/ps5853/products_installation_guide_chapter09186a00802c36b8.html
Interfaces Belong to Different Networks

As shown in the figure, every interface on the router is a member or host on a different IP network. Each interface must be configured with an IP address and subnet mask of a different network. Cisco IOS will not allow two active interfaces on the same router to belong to the same network.

Router interfaces can be divided into two major groups:
LAN interfaces - such as Ethernet and FastEthernet
WAN interfaces - such as serial, ISDN, and Frame Relay

LAN Interfaces

As the name indicates, LAN interfaces are used to connect the router to the LAN, similar to how a PC Ethernet NIC is used to connect the PC to the Ethernet LAN. Like a PC Ethernet NIC, a router Ethernet interface also has a Layer 2 MAC address and participates in the Ethernet LAN in the same way as any other hosts on that LAN. For example, a router Ethernet interface participates in the ARP process for that LAN. The router maintains an ARP cache for that interface, sends ARP requests when needed, and responds with ARP replies when required.

A router Ethernet interface usually uses an RJ-45 jack that supports unshielded twisted-pair (UTP) cabling. When a router is connected to a switch, a straight-through cable is used. When two routers are connected directly through the Ethernet interfaces, or when a PC NIC is connected directly to a router Ethernet interface, a crossover cable is used.

Use the Packet Tracer Activity later in this section to test your cabling skills.

WAN Interfaces

WAN interfaces are used to connect routers to external networks, usually over a larger geographical distance. The Layer 2 encapsulation can be of different types, such as PPP, Frame Relay, and HDLC (High-Level Data Link Control). Similar to LAN interfaces, each WAN interface has its own IP address and subnet mask, which identifies it as a member of a specific network.

Note: MAC addresses are used on LAN interfaces, such as Ethernet, and are not used on WAN interfaces. However, WAN interfaces use their own Layer 2 addresses depending on the technology. Layer 2 WAN encapsulation types and addresses are covered in a later course.

Router Interfaces

The router in the figure has four interfaces. Each interface has a Layer 3 IP address and subnet mask that configures it for a different network. The Ethernet interfaces also have Layer 2 Ethernet MAC addresses.

The WAN interfaces are using different Layer 2 encapsulations. Serial 0/0/0 is using HDLC and Serial 0/0/1 is using PPP. Both of these serial point-to-point protocols use a broadcast address for the Layer 2 destination address when encapsulating the IP packet into a data link frame.

In the lab environment, you are restricted as to how many LAN and WAN interfaces you can use to configure hands-on labs. With Packet Tracer, however, you have the flexibility to create more complex network designs.
Related Topic Router

Router Bootup Process

2009-03-02T07:22:00.000-08:00

There are four major phases to the bootup process:

1. Performing the POST

2. Loading the bootstrap program

3. Locating and loading the Cisco IOS software

4. Locating and loading the startup configuration file or entering setup mode

1. Performing the POST

The Power-On Self Test (POST) is a common process that occurs on almost every computer during bootup. The POST process is used to test the router hardware. When the router is powered on, software on the ROM chip conducts the POST. During this self-test, the router executes diagnostics from ROM on several hardware components including the CPU, RAM, and NVRAM. After the POST has been completed, the router executes the bootstrap program.

2. Loading the Bootstrap Program

After the POST, the bootstrap program is copied from ROM into RAM. Once in RAM, the CPU executes the instructions in the bootstrap program. The main task of the bootstrap program is to locate the Cisco IOS and load it into RAM.

Note: At this point, if you have a console connection to the router, you will begin to see output on the screen.

3. Locating and Loading Cisco IOS

Locating the Cisco IOS software. The IOS is typically stored in flash memory, but can also be stored in other places such as a TFTP (Trivial File Transfer Protocol) server.

If a full IOS image can not be located, a scaled-down version of the IOS is copied from ROM into RAM. This version of IOS is used to help diagnose any problems and can be used to load a complete version of the IOS into RAM.

Note: A TFTP server is usually used as a backup server for IOS but it can also be used as a central point for storing and loading the IOS. IOS management and using the TFTP server is discussed in a later course.

Loading the IOS. Some of the older Cisco routers ran the IOS directly from flash, but current models copy the IOS into RAM for execution by the CPU.

Note: Once the IOS begins to load, you may see a string of pounds signs (#), as shown in the figure, while the image decompresses.

4. Locating and Loading the Configuration File

Locating the Startup Configuration File. After the IOS is loaded, the bootstrap program searches for the startup configuration file, known as startup-config, in NVRAM. This file has the previously saved configuration commands and parameters including:
interface addresses
routing information
passwords
any other configurations saved by the network administrator

If the startup configuration file, startup-config, is located in NVRAM, it is copied into RAM as the running configuration file, running-config.

Note: If the startup configuration file does not exist in NVRAM, the router may search for a TFTP server. If the router detects that it has an active link to another configured router, it sends a broadcast searching for a configuration file across the active link. This condition will cause the router to pause, but you will eventually see a console message like the following one:

%Error opening tftp://255.255.255.255/network-confg (Timed out)
%Error opening tftp://255.255.255.255/cisconet.cfg (Timed out)

Executing the Configuration File. If a startup configuration file is found in NVRAM, the IOS loads it into RAM as the running-config and executes the commands in the file, one line at a time. The running-config file contains interface addresses, starts routing processes, configures router passwords and defines other characteristics of the router.

Enter Setup Mode (Optional). If the startup configuration file can not be located, the router prompts the user to enter setup mode. Setup mode is a series of questions prompting the user for basic configuration information. Setup mode is not intended to be used to enter complex router configurations, and it is not commonly used by network administrators.

When booting a router that does not contain a startup configuration file, you will see the following question after the IOS has been loaded:

Would you like to enter the initial configuration dialog? [yes/no]: no

Setup mode will not be used in this course to configure the router. When prompted to enter setup mode, always answer no. If you answer yes and enter setup mode, you can press Ctrl-C at any time to terminate the setup process.

When setup mode is not used, the IOS creates a default running-config. The default running-config is a basic configuration file that includes the router interfaces, management interfaces, and certain default information. The default running-config does not contain any interface addresses, routing information, passwords, or other specific configuration information.

Command Line Interface

Depending on the platform and IOS, the router may ask the following question before displaying the prompt:

Would you like to terminate autoinstall? [yes]:
Press the Enter key to accept the default answer.
Router>

Note: If a startup configuration file was found, the running-config may contain a hostname and the prompt will display the hostname of the router.

Once the prompt displays, the router is now running the IOS with the current running configuration file. The network administrator can now begin using IOS commands on this router.

Note: The bootup process is discussed in more detail in a later course.
Verifying Router Bootup Process

The show version command can be used to help verify and troubleshoot some of the basic hardware and software components of the router. The show version command displays information about the version of the Cisco IOS software currently running on the router, the version of the bootstrap program, and information about the hardware configuration, including the amount of system memory.

The output from the show version command includes:

IOS version

Cisco Internetwork Operating System Software
IOS (tm) C2600 Software (C2600-I-M), Version 12.2(28), RELEASE SOFTWARE (fc5)

This is the version of the Cisco IOS software in RAM and that is being used by the router.

ROM Bootstrap Program

ROM: System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)

This shows the version of the system bootstrap software, stored in ROM memory, that was initially used to boot up the router.

Location of IOS

System image file is "flash:c2600-i-mz.122-28.bin"

This shows where the boostrap program is located and loaded the Cisco IOS, and the complete filename of the IOS image.

CPU and Amount of RAM

cisco 2621 (MPC860) processor (revision 0x200) with 60416K/5120K bytes of memory

The first part of this line displays the type of CPU on this router. The last part of this line displays the amount of DRAM. Some series of routers, like the 2600, use a fraction of DRAM as packet memory. Packet memory is used for buffering packets.

To determine the total amount of DRAM on the router, add both numbers. In this example, the Cisco 2621 router has 60,416 KB (kilobytes) of free DRAM used for temporarily storing the Cisco IOS and other system processes. The other 5,120 KB is dedicated for packet memory. The sum of these numbers is 65,536K, or 64 megabytes (MB) of total DRAM.

Note: It may be necessary to upgrade the amount of RAM when upgrading the IOS.

Interfaces

2 FastEthernet/IEEE 802.3 interface(s)
2 Low-speed serial(sync/async) network interface(s)

This section of the output displays the physical interfaces on the router. In this example, the Cisco 2621 router has two FastEthernet interfaces and two low-speed serial interfaces.

Amount of NVRAM

32K bytes of non-volatile configuration memory.

This is the amount of NVRAM on the router. NVRAM is used to store the startup-config file.

Amount of Flash

16384K bytes of processor board System flash (Read/Write)

This is the amount of flash memory on the router. Flash is used to permanently store the Cisco IOS.

Note: It may be necessary to upgrade the amount of flash when upgrading the IOS.

Configuration Register

Configuration register is 0x2102

The last line of the show version command displays the current configured value of the software configuration register in hexadecimal. If there is a second value displayed in parentheses, it denotes the configuration register value that will be used during the next reload.

The configuration register has several uses, including password recovery. The factory default setting for the configuration register is 0x2102. This value indicates that the router will attempt to load a Cisco IOS software image from flash memory and load the startup configuration file from NVRAM.

Note: The configuration register is discussed in more detail in a later course.

Internetwork Operating System

2009-03-02T07:20:00.000-08:00

The operating system software used in Cisco routers is known as Cisco Internetwork Operating System (IOS). Like any operating system on any computer, Cisco IOS manages the hardware and software resources of the router, including memory allocation, processes, security, and file systems. Cisco IOS is a multitasking operating system that is integrated with routing, switching, internetworking, and telecommunications functions.

Although the Cisco IOS may appear to be the same on many routers, there are many different IOS images. An IOS image is a file that contains the entire IOS for that router. Cisco creates many different types of IOS images, depending upon the model of the router and the features within the IOS. Typically the more features in the IOS, the larger the IOS image, and therefore, the more flash and RAM that is required to store and load the IOS. For example, some features include the ability to run IPv6 or the ability for the router to perform NAT (Network Address Translation).

As with other operating systems Cisco IOS has its own user interface. Although some routers provide a graphical user interface (GUI), the command line interface (CLI) is a much more common method of configuring Cisco routers. The CLI is used throughout this curriculum.

Upon bootup, the startup-config file in NVRAM is copied into RAM and stored as the running-config file. IOS executes the configuration commands in the running-config. Any changes entered by the network administrator are stored in the running-config and are immediately implemented by the IOS. In this chapter, we will review some of the basic IOS commands used to configure a Cisco router. In later chapters, we will learn the commands used to configure, verify, and troubleshoot static routing and various routing protocols such as RIP, EIGRP, and OSPF.

Note: Cisco IOS and the bootup process is discussed in more detail in a later course.

Router CPU And Memory

2009-03-02T07:18:00.000-08:00

Router Components and their Functions

Like a PC, a router also includes:
Central Processing Unit (CPU)
Random-Access Memory (RAM)
Read-Only Memory (ROM)

Roll over components in the figure to see a brief description of each.

CPU

The CPU executes operating system instructions, such as system initialization, routing functions, and switching functions.

RAM

RAM stores the instructions and data needed to be executed by the CPU. RAM is used to store these components:
Operating System: The Cisco IOS (Internetwork Operating System) is copied into RAM during bootup.
Running Configuration File: This is the configuration file that stores the configuration commands that the router IOS is currently using. With few exceptions, all commands configured on the router are stored in the running configuration file, known as running-config.
IP Routing Table: This file stores information about directly connected and remote networks. It is used to determine the best path to forward the packet.
ARP Cache: This cache contains the IPv4 address to MAC address mappings, similar to the ARP cache on a PC. The ARP cache is used on routers that have LAN interfaces such as Ethernet interfaces.
Packet Buffer: Packets are temporarily stored in a buffer when received on an interface or before they exit an interface.

RAM is volatile memory and loses its content when the router is powered down or restarted. However, the router also contains permanent storage areas, such as ROM, flash and NVRAM.

ROM

ROM is a form of permanent storage. Cisco devices use ROM to store:
The bootstrap instructions
Basic diagnostic software
Scaled-down version of IOS.

ROM uses firmware, which is software that is embedded inside the integrated circuit. Firmware includes the software that does not normally need to be modified or upgraded, such as the bootup instructions. Many of these features, including ROM monitor software, will be discussed in a later course. ROM does not lose its contents when the router loses power or is restarted.

Flash Memory

Flash memory is nonvolatile computer memory that can be electrically stored and erased. Flash is used as permanent storage for the operating system, Cisco IOS. In most models of Cisco routers, the IOS is permanently stored in flash memory and copied into RAM during the bootup process, where it is then executed by the CPU. Some older models of Cisco routers run the IOS directly from flash. Flash consists of SIMMs or PCMCIA cards, which can be upgraded to increase the amount of flash memory.

Flash memory does not lose its contents when the router loses power or is restarted.

NVRAM

NVRAM (Nonvolatile RAM) does not lose its information when power is turned off. This is in contrast to the most common forms of RAM, such as DRAM, that requires continual power to maintain its information. NVRAM is used by the Cisco IOS as permanent storage for the startup configuration file (startup-config). All configuration changes are stored in the running-config file in RAM, and with few exceptions, are implemented immediately by the IOS. To save those changes in case the router is restarted or loses power, the running-config must be copied to NVRAM, where it is stored as the startup-config file. NVRAM retains its contents even when the router reloads or is powered off.

ROM, RAM, NVRAM, and flash are discussed in the following section which introduces the IOS and the bootup process. They are also discussed in more detail in a later course relative to managing the IOS.

It is more important for a networking professional to understand the function of the main internal components of a router than the exact location of those components inside a specific router. The internal physical architecture will differ from model to model.

Links

View the "Cisco 1800 Series Portfolio Multimedia Demo," http://www.cisco.com/en/US/products/ps5875/index.html

Inside Routing

2009-03-02T07:14:00.000-08:00

Routers are Computers

A router is a computer, just like any other computer including a PC. The very first router, used for the Advanced Research Projects Agency Network (ARPANET), was the Interface Message Processor (IMP). The IMP was a Honeywell 316 minicomputer; this computer brought the ARPANET to life on August 30, 1969.

Note: The ARPANET was developed by Advanced Research Projects Agency (ARPA) of the United States Department of Defense. The ARPANET was the world's first operational packet switching network and the predecessor of today's Internet.

Routers have many of the same hardware and software components that are found in other computers including:

CPU
RAM
ROM
Operating System

Typical users may be unaware of the presence of numerous routers in their own network or in the Internet. Users expect to be able to access web pages, send e-mails, and download music - whether the server they are accessing is on their own network or on another network half-way around the world. However, networking professionals know it is the router that is responsible for forwarding packets from network-to-network, from the original source to the final destination.

A router connects multiple networks. This means that it has multiple interfaces that each belong to a different IP network. When a router receives an IP packet on one interface, it determines which interface to use to forward the packet onto its destination. The interface that the router uses to forward the packet may be the network of the final destination of the packet (the network with the destination IP address of this packet), or it may be a network connected to another router that is used to reach the destination network.

Each network that a router connects to typically requires a separate interface. These interfaces are used to connect a combination of both Local Area Networks (LANs) and Wide Area Networks (WANs). LANs are commonly Ethernet networks that contain devices such as PCs, printers, and servers. WANs are used to connect networks over a large geographical area. For example, a WAN connection is commonly used to connect a LAN to the Internet Service Provider (ISP) network.

In the figure, we see that routers R1 and R2 are responsible for receiving the packet on one network and forwarding the packet out another network toward the destination network.
The primary responsibility of a router is to direct packets destined for local and remote networks by:
Determining the best path to send packets
Forwarding packets toward their destination

The router uses its routing table to determine the best path to forward the packet. When the router receives a packet, it examines its destination IP address and searches for the best match with a network address in the router's routing table. The routing table also includes the interface to be used to forward the packet. Once a match is found, the router encapsulates the IP packet into the data link frame of the outgoing or exit interface, and the packet is then forwarded toward its destination.

It is very likely that a router will receive a packet that is encapsulated in one type of data link frame, such as an Ethernet frame and when forwarding the packet, the router will encapsulate it in a different type of data link frame, such as Point-to-Point Protocol (PPP). The data link encapsulation depends on the type of interface on the router and the type of medium it connects to. The different data link technologies that a router connects to can include LAN technologies, such as Ethernet, and WAN serial connections, such as T1 connection using PPP, Frame Relay, and Asynchronous Transfer Mode (ATM).

In the figure, we can follow a packet from the source PC to the destination PC. Notice that it is the responsibility of the router to find the destination network in its routing table and forward the packet on toward its destination. In this example, router R1 receives the packet encapsulated in an Ethernet frame. After decapsulating the packet, R1 uses the destination IP address of the packet to search its routing table for a matching network address. After a destination network address is found in the routing table, R1 encapsulates the packet inside a PPP frame and forwards the packet to R2. A similar process is performed by R2.

Static routes and dynamic routing protocols are used by routers to learn about remote networks and build their routing tables. These routes and protocols are the primary focus of the course and will be discussed in detail in later chapters along with the process that routers use in searching their routing tables and forwarding the packets.

Introducing Routing And Packet Forwading

2009-03-02T07:09:00.001-08:00

Today's networks have a significant impact on our lives - changing the way we live, work, and play. Computer networks - and in a larger context the Internet - allow people to communicate, collaborate, and interact in ways they never did before. We use the network in a variety of ways, including web applications, IP telephony, video conferencing, interactive gaming, electronic commerce, education, and more.

At the center of the network is the router. Stated simply, a router connects one network to another network. Therefore, the router is responsible for the delivery of packets across different networks. The destination of the IP packet might be a web server in another country or an e-mail server on the local area network. It is the responsibility of the routers to deliver those packets in a timely manner. The effectiveness of internetwork communications depends, to a large degree, on the ability of routers to forward packets in the most efficient way possible.

Routers are now being added to satellites in space. These routers will have the ability to route IP traffic between satellites in space in much the same way that packets are moved on Earth, thereby reducing delays and offering greater networking flexibility.

In addition to packet forwarding, a router provides other services as well. To meet the demands on today's networks, routers are also used to:
Ensure 24x7 (24 hours a day, 7 days a week) availability. To help guarantee network reachability, routers use alternate paths in case the primary path fails.
Provide integrated services of data, video, and voice over wired and wireless networks. Routers use Quality of service (QoS) prioritization of IP packets to ensure that real-time traffic, such as voice, video and critical data are not dropped or delayed.
Mitigate the impact of worms, viruses, and other attacks on the network by permitting or denying the forwarding of packets.

All of these services are built around the router and its primary responsibility of forwarding packets from one network to the next. It is only because of the router's ability to route packets between networks that devices on different networks can communicate. This chapter will introduce you to the router, its role in the networks, its main hardware and software components, and the routing process itself.

Cable Access (Ethernet Interfaces)

2009-01-16T06:52:00.000-08:00

Cable access can be deployed easily. The vast majority of providers deliver a CPE device (cable modem) that terminates the coax network frequency bands that carry data, TV, and telephony, and provide a standard Ethernet/POTS/ISDN interface as the demarcation point.

To get telephony out of the RF side, an additional termination unit is needed. In contrast to DSL architectures, no additional software or stack components (PPTP, PPPoA, PPPoE) are required on the attached end system or gateway. The cable modem connects via coaxial drop and trunk cables as well as signal repeaters to a carrier's cable head-end. Mixed architectures featuring optical-electrical converters for optical trunk cables are used, too. In contrast to DSL, this is a shared medium; therefore, VLAN architectures and MAC-based access control are commonly deployed and addresses delivered to the customer via Dynamic Host Configuration Protocol (DHCP).

DSL Access

2009-01-16T06:35:00.000-08:00

Historically, DSL has been an asymmetric service (ADSL), evolving into a symmetric one (G.SHDSL) designed to replace E1 TDM circuits and provide voice, ATM, raw IP, and ISDN transport.

DSL copper cables are terminated at a central office (CO) DSLAM port (digital subscriber access line multiplexer). The DSLAM serves two purposes:

One is to physically terminate the subscriber line and separate the voice band from the data bands utilizing an integrated splitter device similar to the one on the customer end; the voice signal is delivered directly to the PSTN network on OSI Layer 1.

The second purpose is to relay the data traffic to an IP backbone, usually based on ATM or Ethernet. Aggregation and service-selection gateways constitute the distribution layer of modern DSL provider architectures.

Almost all open-source UNIX operating systems provide mature PPTP support required for the PPPoA architectures that are popular in some European countries. Linux, OpenBSD, and FreeBSD support native PPPoE. PPPoA or PPPoE support of your favorite operating system usually requires a modified/patched version of the PPP toolset. Discussion goes beyond the scope of this book, but you can find easily several cookbooks for setup via your favorite search engine or Linux repository. Several DSL NICs are also available (ATM25, splitterless operation). Some of their important characteristics are as follows:

DSL modes of operation: PPPoA, PPPoE, bridging mode

DSL flavors: ADSL, HDSL, SDSL, G.SHDSL, G.Lite, VDSL, and so on

Software requirements of DSL access: PPPoE or PPPoA stack support, PPTP (for example, via Netgraph/mpd daemon under FreeBSD)

Route Cloning

2009-01-16T06:33:00.000-08:00

Cloned routes are a concept unique to BSD networks stacks. The concept refers to on-demand generation (cloning) of host routes (/32). In other words (quoted from the FreeBSD arp(4) manual page), "The ARP cache is stored in the system routing table as dynamically created host routes. The route to a directly attached Ethernet network is installed as a 'cloning' route (one with the RTF_CLONING flag set), causing routes to individual hosts on that network to be created on demand."[1] The actual cloning template (or parent) is marked with (C = generate new routes on use), the instantiated cloned host route (child) with (W = was cloned) in the system routing table. The associated ref_counter indicates how many existing connections use that particular entry, which is also correlated with an expire_timer (usually 3600 seconds). Cloned routes time out periodically after initial validation as long as they are not used.

Examples 8-3 through 8-5 show the differences in arp and netstat command output on OpenBSD, Linux, and FreeBSD operating systems to demonstrate the connection between next-hop/interface Media Access Control (MAC) resolution and similarities between route and netstat commands. In addition, interface statistics with netstat are presented, as are usage statistics of routing table entries. All routing tables present prefix entries, flags, a reference counter for the number of uses of a prefix, and a usage counter for the number of packets that were forwarded along that route out of the associated physical interface. Additional parameters of netstat output are system-specific.

Example 8-3. OpenBSD arp and netstat Output

[root@ganymed:~#] arp -an

? (192.168.1.1) at 52:54:05:e3:51:87

? (192.168.1.2) at 08:00:46:64:74:1b

? (192.168.2.7) at 00:10:5a:c4:2c:04

? (111.11.117.1) at 00:05:9a:5b:23:fc

[root@ganymed:~#] netstat -rna -f inet

Routing tables

Internet:

Destination Gateway Flags Refs Use Mtu Interface

default 111.11.117.1 UGS 3 11991 1500 ne5

127/8 127.0.0.1 UGRS 0 0 33224 lo0

127.0.0.1 127.0.0.1 UH 2 0 33224 lo0

192.168.1/24 link#1 UC 0 0 1500 ne3

192.168.1.1 52:54:5:e3:51:87 UHL 0 8801 1500 ne3

192.168.1.2 8:0:46:64:74:1b UHL 1 4451 1500 ne3

192.168.1.254 127.0.0.1 UGHS 0 0 33224 lo0

192.168.2/24 link#2 UC 0 0 1500 ne4

192.168.2.7 0:10:5a:c4:2c:4 UHL 0 2111 1500 ne4

192.168.44.1 192.168.44.1 UH 0 0 33224 lo1

192.168.45/24 link#1 UC 0 0 1500 ne3

111.11.117/24 link#3 UC 0 0 1500 ne5

111.11.117.1 0:5:9a:5b:23:fc UHL 1 0 1500 ne5

[root@ganymed:~#] netstat -in -f inet

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls

lo0 33224 0 0 0 0 0

lo0 33224 fe80::/64 fe80::1 0 0 0 0 0

lo0 33224 ::1/128 ::1 0 0 0 0 0

lo0 33224 127/8 127.0.0.1 0 0 0 0 0

lo1 33224 0 0 0 0 0

lo1 33224 192.168.44/ 192.168.44.1 0 0 0 0 0

lo1 33224 fe80::/64 fe80::1 0 0 0 0 0

lo1 33224 ::1/128 ::1 0 0 0 0 0

ne3 1500 48:54:e8:8c:0a:3f 17263 0 13427 0 329

ne3 1500 192.168.1/2 192.168.1.254 17263 0 13427 0 329

ne3 1500 fe80::/64 fe80::4a54:e8ff:f 17263 0 13427 0 329

ne3 1500 192.168.45/ 192.168.45.254 17263 0 13427 0 329

ne4 1500 52:54:05:e3:e4:2f 2503 234 2247 0 0

ne4 1500 192.168.2/2 192.168.2.254 2503 234 2247 0 0

ne4 1500 fe80::/64 fe80::5054:5ff:fe 2503 234 2247 0 0

ne5 1500 52:54:05:e3:51:87 11531 1253 12040 0 0

ne5 1500 111.11.117/ 111.11.117.206 11531 1253 12040 0 0

ne5 1500 fe80::/64 fe80::5054:5ff:fe 11531 1253 12040 0 0

[root@ganymed:~#] netstat -rs

routing:

0 bad routing redirects

0 dynamically created routes

0 new gateways due to redirects

10 destinations found unreachable

0 uses of a wildcard route

Example 8-4 also demonstrates an advanced feature of Linux: TCP parameters such as the TCP Maximum Segment Size (MSS) and the TCP Window Size, which can be altered on a per-prefix basis (shaded text). For a better understanding, consider the following technical details quoted from the Linux route(8) manual page:

mss M:

set the TCP Maximum Segment Size (MSS) for connections over this route to M bytes. The default is the device MTU minus headers, or a lower MTU when path mtu discovery occurred [sic]. This setting can be used to force smaller TCP packets on the other end when path mtu discovery does not work (usually because of misconfigured firewalls that block ICMP Fragmentation Needed)

window W:

set the TCP window size for connections over this route to W bytes. This is typically only used on AX.25 networks and with drivers unable to handle back to back frames.[2]

Example 8-4. Linux arp and netstat Output

[root@callisto:~#] arp -an

? (192.168.1.2) at 08:00:46:64:74:1B [ether] on eth1

? (192.168.1.254) at 48:54:E8:8C:0A:3F [ether] on eth1

[root@callisto:~#] netstat -rnva

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1

192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 ipsec0

192.168.14.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo

0.0.0.0 192.168.1.254 0.0.0.0 UG 40 0 0 eth1

[root@callisto:~#] netstat -i

Kernel Interface table

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

eth0 1500 0 276 0 0 0 166 0 0 0 BMRU

eth1 1500 0 14889 0 0 0 9260 0 0 0 BMRU

ipsec 16260 0 0 0 0 0 0 0 0 0 ORU

lo 16436 0 64 0 0 0 64 0 0 0 LRU

[root@callisto:~#] route -nee

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface MSS Window irtt

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 40 0 0

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 40 0 0

192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 40 0 0

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 40 0 0

0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1 40 0 0

The highlighted text in Example 8-5 emphasizes the timer correlation of ARP cache entries and the forwarding table on FreeBSD for cloned routes (ARP neighbors). On BSD systems, you can manually adjust the route_expire sysctl parameter net.inet.ip.rtexpire, which defaults to 3600 seconds. Connected routes are created for each interface attached to the local host. Examples of the ip Linux facility are left to the lab because it is specific only to Linux, whereas netstat and route are generic tools of all Unices.

Example 8-5. FreeBSD arp and netstat Output

[root@castor:~#] arp -an

? (192.168.2.254) at 52:54:05:e3:e4:2f on xl0 [ethernet]

? (192.168.7.254) at 00:00:0c:1a:a9:a8 on ed0 [ethernet]

[root@castor:~#] netstat -rnaW -f inet

Routing tables

Internet:

Destination Gateway Flags Refs Use Mtu Netif Expire

default 192.168.2.254 UGSc 4 6 1500 xl0

127.0.0.1 127.0.0.1 UH 0 0 16384 lo0

192.53.103.103 192.168.2.254 UGHW3 0 63 1500 xl0 3314

192.53.103.104 192.168.2.254 UGHW 1 64 1500 xl0

192.168.1.2 192.168.2.254 UGHW 1 1207 1500 xl0

192.168.2 link#1 UC 2 0 1500 xl0

192.168.2.254 52:54:05:e3:e4:2f UHLW 3 3 1500 xl0 1028

192.168.7 link#2 UC 1 0 1500 ed0

192.168.7.254 00:00:0c:1a:a9:a8 UHLW 1 5 1500 ed0 1038

195.34.133.10 192.168.2.254 UGHW3 0 14 1500 xl0 3440

[root@castor:~#] netstat -i -f inet

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

xl0 1500 192.168.2 192.168.2.7 2260 - 3303 - -

ed0 1500 192.168.7 castor 260 - 1214 - -

lo0 16384 your-net localhost 0 - 0 - -

[root@castor:~#] netstat -rs

routing:

0 bad routing redirects

0 dynamically created routes

0 new gateways due to redirects

3 destinations found unreachable

0 uses of a wildcard route

1 route not in table but not freed

Floating Static Routes

2009-01-16T06:30:00.000-08:00

Floating static routes are a useful and simple measure to provide backup routes via another hop or link. However, a floating static route just "lurks" there and does not provide load balancing! This can be as simple as two default routes that just differ in terms of metric or cost. As long as the preferred route with the better metric is available, the floating static route with the less attractive metric floats unused but suddenly takes over if the preferred route disappears. A requirement is an operating system that supports metrics for static routes. Lab 8-1 shows an example of this setup.

Classification of Dynamic Routing Protocols

2009-01-16T06:22:00.000-08:00

Dynamic routing protocols are based on an algorithm, such as Bellman-Ford-Fulkerson, Dijkstra SPF (Shortest Path First), or the Enhanced Interior Gateway Routing Protocol (EIGRP) DUAL (Diffuse Update Algorithm). Based on these algorithms, dynamic IGPs can be classified in link-state and distance-vector protocols.

NOTE

The Border Gateway Protocol (BGP) discussed in the next chapter represents a path-vector protocol essentially based on a distance-vector approach as well.

The main task of these protocols is path determination and calculation. With multiple paths to a destination prefix, the protocol makes intrinsic decisions based on metrics/cost/preference assigned to routes. Such a label is a measure of preference within a particular routing protocol. It can be simple, such as hop count for RIP, or a composite metric such as with EIGRP based on load, reliability, delay, and bandwidth, or cost based in a generic way such as with OSPF.

Link-State Protocols
Link-state protocols such as OSPF are cost-based, and the cost is usually derived from the link bandwidth. When a protocol has a stable view of the topology, it is referred to as having converged or achieved equilibrium. Do not confuse this view with the notion of converged networks meaning voice, video, data, and storage over one consolidated IP infrastructure.

The task of computing shortest paths in a network is a mathematical problem tackled with graph theory. You will read more about that in the section "Introduction to Link-State Routing Protocols" later in this chapter. Nevertheless, one cannot argue that link-state protocols are superior in every aspect per se.

Distance-Vector Protocols
Distance-vector protocols usually broadcast full table updates. Deviation from this case is referred to as an asynchronous, triggered, flash, or incremental update.

Note the following:

The name distance vector is derived from the fact that routes are advertised as vectors of (distance, direction), where distance is defined in terms of a metric and direction is defined in terms of the next-hop router.[1]

For loop prevention, simple split horizon or split horizon with poisoned reverse is used in distance-vector protocols. A thorough discussion of loop detection, prevention, and termination goes beyond the scope of this book. I recommend Jeff Doyle's two volumes of Routing TCP/IP (Cisco Press; 1998 and 2001, respectively) for further information.

Introduction to Link-State Routing Protocols

2009-01-16T06:07:00.000-08:00

Link-state routing protocols are based on Edsger W. Dijkstra's Shortest Path First (SPF) algorithm, a result of applied graph theory. Link-state protocols establish and maintain adjacencies via hello packets (connection-oriented) with their neighbors (peers), speaking the same routing protocol. The name link-state stems from the underlying concept that every participant distributes (floods) all the information states and conditions of its directly attached links.

The routers communicate via link-state advertisements (LSAs) with all their established neighbors. This behavior is referred to as flooding. The receiving routers never alter the LSA information, but add a copy to their link-state databases. After some convergence time, all the participants have a full, identical, and complete view (graph) of the area topology stored in their topology databases. Every router now calculates its own best paths (SPF) for all prefixes from its individual point of view and position in this topology. Hellos are also used as a keepalive mechanism between adjacent neighbors.

NOTE

A new approach referred to as incremental SPF (iSPF) or incremental Dijkstra allows SPF protocols to converge faster under certain conditions by recomputing only the part of the shortest path tree (SPT) that has changed. This calculation is considerably faster only under special circumstances. For more information, search Cisco.com for "incremental SPF" or "incremental Dijkstra." At the time of this writing, the implementation solely is a proprietary vendor playground.

The following discussion introduces two fundamental concepts of organizing routing realms: areas and autonomous systems.

Area Concepts
Areas are smaller realms (subsets) of a routing domain (autonomous system). It became obvious during the design of link-state protocols that the intrinsic mechanisms become problematic in large flat topologies with several hundreds to thousands of nodes. This involved convergence time, link bandwidth, node memory, and CPU consumption. The designers' response was a subdivision-area concept and, recently, incremental approaches to SPF.

Area separation in terms of a contiguous backbone area and attached leaf areas via area border routers (ABRs) considerably improved the matter by restricting LSA flooding to the area boundaries. This resulted in smaller topology databases, faster SPF computation with less memory/CPU consumption, and ultimately improved convergence behavior.

ABRs maintain several databases and need to be consulted for interarea routing. In general, ABRs inject default routes into the leaf area. OSPF has a "rich" repertoire of leaf-area flavors: stub areas, total stub areas, not so stubby areas (NSSAs), and NSSA total stub. For a concise discussion of the differences, see the "Recommended Reading" section at the end of this chapter.

All leaf areas need to have at least one connection to the backbone area. If this is not possible because of migration constraints or topology limitations, OSPF virtual links are used to establish backbone connectivity via a transit area. This concept is not implemented (or necessary) in IS-IS. Both protocols use a contiguous backbone.

Table 9-1 shows the four different area specifiers used within Cisco IOS Software and their GateD and Zebra counterparts if applicable.

Table 9-1. OSPF Area Flavors Area Specifier
GateD Notation
Zebra Notation

Stub
Stub
Stub

Total stub
Stub + restrict clause
Stub, no summary

NSSA
Not implemented
NSSA

NSSA total stub
Not implemented
NSSA, no summary

NOTE

One short bit of advice: Do not expect OSPF to compensate for poorly designed topologies or address planning!

The Full Picture—Autonomous Systems and Areas
Figure 9-2 shows a complete view of the macroscopic world. Autonomous systems can be organized into areas—either a flat backbone area or a backbone area with multiple connected leaf areas. Autonomous systems are not isolated; they communicate via Exterior Gateway Protocols (EGPs) with other autonomous systems, upstream carriers, or public peering points. BGPv4 is the dominant EGP used in today's Internet.

OSPFv2

2009-01-16T06:00:00.000-08:00

OSPF (Open Shortest Path First) is the most popular among the link-state routing protocols. The current IPv4 version, OSPFv2, is widely deployed throughout carrier, ISP, and enterprise networks. OSPFv3 essentially is an IPv6-enabled OSPF. It is a well documented protocol in terms of standards, books, guides, and white paper density.

The knowledge level is high among those who deploy and operate OSPFv2. Integrated IS-IS, however, is catching up in popularity, although those familiar with its addressing already appreciate its simplicity. OSPF is multicast-based (224.0.0.5 = AllSPFRouters, 224.0.0.6 = AllDRouters).

OSPF facilitates 11 different LSA types. This is the biggest obstacle and source for confusion that OSPF apprentices face. OSPF and IS-IS both support Equal-Cost Multi-Path (ECMP), an important feature for optimal link utilization. OSPF uses an arbitrary metric (cost) that is based on link bandwidth in the Cisco implementation.

The Cisco IOS implementation will do equal-cost load balancing for up to six equal-cost routes for OSPF and IS-IS. This condition is characterized by including all routes in the forwarding table. Route tagging and authentication are additional features of modern implementations. Traffic-engineering extensions to OSPF (OSPF-TE) via TE-LSAs are available as well. Traffic engineering in combination with leaf-area concepts is particularly difficult to implement, given the intrinsic behavior of link-state routing protocols.

Route Filtering and Redistribution

2009-01-16T05:58:00.000-08:00

shows an example for the Zebra redistribution commands. They pretty much work as under Cisco IOS Software. Consult Cisco.com for further information. Note that GateD provides similar route-filter facilities.

Example 9-24. Zebra Redistribution Example

callisto-ospfd# show running-config

Current configuration:

!

hostname callisto-ospfd

password 8 m6eyKycFMHniQ

enable password 8 bjYlnA9YLBWyM

log file /var/log/ospfd.log

service advanced-vty

service password-encryption

!

!

!

interface lo

!

interface eth0

!

interface eth1

ip ospf message-digest-key 1 md5 zebra

!

interface ipsec0

!

interface ipsec1

!

interface ipsec2

!

interface ipsec3

!

interface eth1:1

ip ospf message-digest-key 1 md5 zebra

!

interface lo1

!

interface wp1chdlc

ip ospf network point-to-point

!

router ospf

ospf router-id 192.168.1.1

compatible rfc1583

redistribute connected

redistribute static

redistribute rip route-map REDIMAP

network 192.168.1.0/24 area 0

network 192.168.14.0/24 area 5

network 192.168.45.0/24 area 0

network 192.168.99.0/30 area 0

area 0.0.0.0 authentication message-digest

area 5 virtual-link 192.168.201.4

distribute-list DISTRIMAP out static

capability opaque

!

access-list 1 remark vty-protection

access-list 1 permit 127.0.0.1

access-list 1 permit 192.168.1.0 0.0.0.255

!

route-map DISTRIMAP permit 1

match ip address 1

set metric 10

!

route-map REDIMAP permit 1

match ip address 1

set metric-type type-1

!

line vty

access-class 1

exec-timeout 0 0

!

end

OSPF Authentication

2009-01-16T05:55:00.000-08:00

Configuring authentication for OSPF or RIP is pretty straightforward under Zebra. You have the choice between clear-text passwords and MD5 hashes (Example 9-25). However, consider that this contributes to CPU load.

Example 9-25. Configuring MD5 Authentication for Zebra OSPF

castor-ospfd# show running-config

Current configuration:

!

hostname castor-ospfd

password 8 4DwwIFdKLWvU.

enable password 8 dV8x4MhxDAuaw

log file /var/log/ospfd.log

service advanced-vty

service password-encryption

!

!

!

interface xl0

ip ospf message-digest-key 1 md5 zebra

!

interface ed0

ip ospf message-digest-key 1 md5 zebra

!

interface lp0

ip ospf network point-to-point

!

interface sl0

ip ospf network point-to-point

!

interface sl1

ip ospf network point-to-point

!

interface ds0

!

interface stf0

!

interface faith0

!

interface vlan0

!

interface vlan1

!

interface lo0

!

interface ppp0

ip ospf network point-to-point

!

interface ppp1

ip ospf network point-to-point

!

interface vlan8

ip ospf message-digest-key 1 md5 zebra

!

interface lo1

!

router ospf

ospf router-id 192.168.2.7

compatible rfc1583

redistribute connected

redistribute static

network 192.168.2.0/24 area 0

network 192.168.7.0/24 area 0

network 192.168.80.0/24 area 0

area 0 authentication message-digest

capability opaque

!

access-list 1 remark vty-protection

access-list 1 permit 127.0.0.1

access-list 1 permit 192.168.1.0 0.0.0.255

!

line vty

access-class 1

exec-timeout 15 0

!

end

IS-IS (Intermediate System-to-Intermediate System)

2009-01-16T05:47:00.000-08:00

I have included this section to raise more appreciation for the IS-IS routing protocol. In Open System Interconnection (OSI) CLNS environments, CLNP provides a network layer service to peer CLNS entities. CLNP can be seen as the ISO equivalent of (connectionless) IP datagram delivery.

The following dynamic routing approaches can be used to route CLNP:

IS-IS (Intermediate System-to-Intermediate System)

ES-IS (End System-to-Intermediate System)

Cisco proprietary ISO IGRP (Interior Gateway Routing Protocol), capable of routing between CLNP domains

Static CLNS routes can be configured as well. All of these protocols travel via native Layer 2; they do not travel on top of IP, in contrast to OSPF.

An intermediate system represents a router in OSI lingo, and an end-system represents a workstation. IS-IS is a dynamic classless OSI link-state routing protocol based on the Dijkstra SPF algorithm. It essentially originated from DECnet Phase V routing. It supports a two-level area hierarchy, similar to OSPF, resembling a backbone (Level 2) and leaf areas (Level 1) to support large routing domains. IS-IS does not have a backbone area like the OSPF area 0. A contiguous collection of Level 2 routers resembles the backbone. In contrast to OSPF, the border between areas is on the link that connects two routers that are located in different areas.

IS-IS is popular among Tier-1/2 carriers and some ISPs. Originally, it was designed for CLNS, but it was later extended to support IP as a network layer protocol as well. IS-IS with IP support is referred to as integrated or dual IS-IS.

Disadvantages of IS-IS
The point that makes IS-IS difficult to grasp is the issue of the network service access point (NSAP) addresses required for node identification in combination with CLNP as an additional network layer protocol. In contrast to IP, one intermediate system in general has only one NSAP address. For more detailed information about addressing and IS-IS operation, see the "Recommended Reading" section at the end of this chapter.

Advantages of IS-IS
One of the big advantages of IS-IS is its exceptional convergence behavior in combination with its scalability to support large areas of several hundred intermediate systems without considerable SPF performance degradation. One can argue whether IS-IS TLVs (Type-Length-Values) or OSPF LSAs (link-state advertisements) are more complicated to understand. IS-IS appears simpler in that respect because the area concept is more straightforward. IS-IS does not implement virtual links. Cisco IOS Software provides some additional features such as route leaking, overload bit, and multi-area routing.

IS-IS is an elegant protocol and in some aspects easier to grasp and easier to manage than OSPF. I consider the only reason for its lack of popularity among noncarrier staff the "strange" NSAP addresses it depends on, its relationship with CLNS/CLNP, and the fact that it uses Layer 2 for transport. Cisco offers an excellent implementation of IS-IS. IS-IS can be deployed or additionally used for "IP out-of-band" management of network nodes, because of the integrated/dual character of IS-IS and its independence of a Layer 3 network protocol for transport.

Relevant IS-IS Standards
To raise more appreciation for IS-IS design and benefits, I have included an exhaustive collection of relevant standards:

ISO 7498, "Open System Interconnection Model"

ISO 10589, "ISO IS-IS"

RFC 1142, "OSI IS-IS Intra-Domain Routing Protocol"

RFC 2763, "Dynamic Hostname Exchange Mechanisms for IS-IS"

RFC 2966, "Domain-Wide Prefix Distribution with Two-Level IS-IS"

RFC 2973, "IS-IS Mesh Groups"

RFC 1195, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (Integrated IS-IS)"

ISO 9542/RFC 995, "ISO ES-IS"

ISO 8473/RFC 994/RFC 1069, "ISO CLNS/CLNP"

ISO 8348-Ad2/RFC 1629, "NSAP Address Formats"

RFC 3559, "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System"

draft-ietf-isis-traffic-04.txt, "TE Extensions to IS-IS" (new TLVs and sub-TLVs)

Current IS-IS Developments
After a quiet period, IS-IS development is quite active again. The following list introduces aspects of current IS-IS evolution:

Management Information Bases (MIBs)

IPv6

Cryptographic authentication

TE extensions

Mesh groups

User-Space Tunneling

2008-12-15T10:55:00.000-08:00

User-space tunnels are not an integral part of the operating system. They carry out their duty on top of TCP and UDP. This section discusses several representative examples, but a much larger variety exists. Several approaches are designed to circumvent corporate security by creating transparent tunnels (tcp80/tcp443) over HTTP(S) proxies or SOCKS5 relays.

Note that I do not discuss these approaches; they are potentially dangerous for corporate security. In addition, to a large extent, they are responsible for deployments of expensive and performance-impaired application layer gateways. Security compromises from the inside are difficult to tackle, time-consuming, and considerably increase administrative and logging burden. Proxies are there for good reasons and add security to corporate Internet architectures. Transparent proxies are one building block of modern security architectures; their caching purpose is of diminishing importance. Olaf Titz, from the CIPE Project,[3] says it best:

There are several different places where encryption can be built in to an existing network infrastructure, corresponding to the different protocol layers:

On the network level— Packets traveling between hosts on the network are encrypted. The encryption engine is placed near the driver, which sends and receives packets. An implementation is found in CIPE.

On the socket level— A logical connection between programs running on different hosts (TCP connection; transport or session layer in OSI) is encrypted. The encryption engine intercepts or proxies connections. SSH and SSL work this way.

On the application level— Applications contain their own encryption engine and encrypt data themselves. The best-known example is PGP for encrypting mail.

CIPE (Crypto IP Encapsulation)
CIPE is an established tunnel approach in the Linux community, based on tunneling IP datagrams over encrypted UDP carrier datagrams. This procedure offers transparency in contrast to TCP-tied approaches such as secure shell (SSH) or Secure Sockets Layer (SSL). CIPE creates point-to-point tunnels differentiated by port number. Because of its lightweight and elegant design, its performance characteristics are impressive. It behaves well in NAT and SOCKS5 relay environments, can to some extent handle dynamic IP addresses, and is based on Blowfish/IDEA cryptographic algorithms with a 128-bit key length.

CIPE also was ported to the Windows 2000 Server platform. The CIPE protocol performs two main tasks: encryption and checksumming of the payload packets, and dynamic key exchange. The CIPE suite consists of a kernel module, which resembles a pseudo network device, the ciped driver, and the pkcipe utility for key management. pkcipe introduced Diffie-Hellman key exchange and RSA signatures to tackle the security problem of long-lived static keys and administrative burden with many tunnels. As we know from partial or full-meshed IPSec architectures, point-to-point tunnels scale horribly (one issue successfully addressed by MPLS VPNs). For installation and operational details, consult the CIPE page at http://sites.inka.de/sites/bigred/devel/cipe.html. The next version of CIPE will take advantage of the Linux CryptoAPI, thus marking another major step toward a homogeneous architecture on Linux.

CIPE links can be qualified as belonging to different classes of carriers. Those classes are based on how they are able to reach the Internet:[4]

Direct connection on a static IP address

Direct connection on a dynamic IP address

Indirect connection through a SOCKS server

Indirect connection through a NAT (masquerading) router

Example 11-10 demonstrates a static CIPE setup between two Linux gateways and a configuration with pkcipe.

Example 11-10. Linux CIPE Tunnel Setup

[root@callisto:~#] modprobe cipcb cipe_debug=0

[root@callisto:/etc/cipe#] ls -al

total 36

drwx------ 3 root root 4096 Aug 15 16:27 ./

drwxr-xr-x 86 root root 8192 Aug 15 10:15 ../

-rw-r----- 1 root root 272 Aug 15 12:37 identity

-r-------- 1 root root 887 Aug 15 12:37 identity.priv

-rwxr-x--- 1 root root 620 Feb 22 2002 ip-down*

-rwxr-x--- 1 root root 1632 Feb 22 2002 ip-up*

-rw------- 1 root root 679 Aug 15 12:40 options

drwx------ 2 root root 4096 Aug 15 12:37 pk/

[root@callisto:/etc/cipe#] cat options

# This is probably the minimal set of options that has to be set

# Without a "device" line, the device is picked dynamically

# the peer's IP address

ptpaddr 10.1.1.2

mask 255.255.255.252

# our CIPE device's IP address

ipaddr 10.1.1.1

# my UDP address. Note: if you set port 0 here, the system will pick

# one and tell it to you via the ip-up script. Same holds for IP 0.0.0.0.

me 192.168.1.1:6789

# ...and the UDP address we connect to. Of course no wildcards here.

peer 192.168.1.2:6543

# The static key. Keep this file secret!

# The key is 128 bits in hexadecimal notation.

key 3248fd20adf9c00ccf9ecc2393bbb3e4

[root@callisto:/etc/cipe/pk#] cat pollux

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDl3o1MUEQN8IjZ9g74OwO1i8Cn

+nveaW0rqsH8qDmgwe2ofQH2RdHADhd+OgbWDzODxlKp/iSTPAExeDo2gvfy+V3f

cFn04T+Zsng5uDl6YZ/h35r937l9ve/XoxDGzIyg1RSnl6xvIsO9BFu6J7dc5JES

+bzICr4T58q6kauTlwIDAQAB

-----END PUBLIC KEY-------

ipaddr 10.1.1.1

ptpaddr 10.1.1.2

mask 255.255.255.252

[root@callisto:~#] modprobe cipcb cipe_debug=1 cipe_maxdev=10

[root@callisto:~#] ciped-cb -o /etc/cipe/options

[root@callisto:~#] ifconfig -a

cipcb0 Link encap:IPIP Tunnel HWaddr

inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.252

UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:42 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:0 (0.0 b) TX bytes:7104 (6.9 Kb)

[root@callisto:/etc/xinetd.d#] cat pkcipe

service pkcipe

{

socket_type = stream

protocol = tcp

wait = no

user = root

server = /usr/local/sbin/pkcipe

server_args = -s 963

disable = no

}

[root@pollux:~#] pkcipe -c 192.168.1.1:pkcipe

V-TUN (Virtual Tunnel)
V-TUN (http://vtun.sourceforge.net/) runs on Linux, BSD, and Solaris platforms. I consider it the most flexible and feature-rich package for VPN deployments outside kernel space. It supports encryption, traffic shaping, and compression for TCP-/UDP-based tunnels for point-to-point VPN or mobile IP architectures via IP, PPP, SLIP, Ethernet, and other tunnel types. V-TUN requires the universal TUN/TAP driver, which resembles a virtual point-to-point network device or virtual Ethernet network device respectively and can be found at http://vtun.sourceforge.net/tun/index.html.

The good news is that on all tested current operating systems (Linux 2.4, OpenBSD 3.3, FreeBSD 4.6, NetBSD 1.6.1), the TUN/TAP driver is an integral part or module of the kernel. It requires recompiling of the kernels but no additional software besides V-TUN. For additional information, consult the man pages vtund(8) and vtund.conf(5).

Examples 11-11 and 11-12 demonstrate a V-TUN setup between Linux and OpenBSD.

Example 11-11. V-TUN Tunnel Setup on Linux

[root@callisto:~#] modprobe tun

[root@callisto:/etc#] cat vtund.myconfig

options {

port 5000; # Listen on this port.

# Syslog facility

syslog daemon;

# Path to various programs

ppp /usr/sbin/pppd;

ifconfig /sbin/ifconfig;

route /sbin/route;

firewall /sbin/iptables;

ip /sbin/ip;

}

default {

compress no; # Compression is off by default

speed 0; # By default maximum speed, No shaping

keepalive yes; # Keepalives

stat yes;

encrypt yes;

}

pollux {

passwd cisco; # Password

type tun; # IP tunnel

proto udp; # UDP protocol

compress lzo:9; # LZO compression level 9

device tun0;

encrypt yes; # Encryption

keepalive yes; # Keep connection alive

stat yes;

speed 128:64; # Tunnel shaping Kbps IN:OUT

up {

ifconfig "%% 10.2.2.1 pointopoint 10.2.2.2 mtu 1450";

};

down {

};

}

castor {

passwd cisco; # Password

type tun; # IP tunnel

proto udp; # UDP protocol

compress lzo:9; # LZO compression level 9

device tun1;

encrypt yes; # Encryption

keepalive yes; # Keep connection alive

stat yes;

up {

ifconfig "%% 10.3.3.1 pointopoint 10.3.3.2 mtu 1450";

};

}

europa {

passwd cisco; # Password

type tun; # IP tunnel

proto udp; # UDP protocol

compress lzo:9; # LZO compression level 9

device tun2;

encrypt yes; # Encryption

keepalive yes; # Keep connection alive

stat yes;

up {

ifconfig "%% 10.4.4.1 pointopoint 10.4.4.2 mtu 1450";

};

}

*** Start the vtund in server mode ***

[root@callisto:~#] vtund -s -f /etc/vtund.myconfig

[root@callisto:~#] ifconfig –a

...

tun2 Link encap:Point-to-Point Protocol

inet addr:10.4.4.1 P-t-P:10.4.4.2 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1450 Metric:1

RX packets:7 errors:0 dropped:0 overruns:0 frame:0

TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10

RX bytes:588 (588.0 b) TX bytes:840 (840.0 b)

...

[root@callisto:~#] ps ax | )grep vtun

2404 ? S< 0:00 vtund[s]: europa tun tun2

6103 pts/4 S 0:00 grep vtun

Example 11-12. V-TUN Tunnel Setup on OpenBSD

[root@europa:~#] modprobe tun

[root@europa:/etc#] cat vtund.myconfig

options {

port 5000; # Connect to this port.

timeout 60; # General timeout

# Path to various programs

ppp /usr/sbin/pppd;

ifconfig /sbin/ifconfig;

route /sbin/route;

firewall /sbin/ipf;

}

default {

keepalive yes; # Keepalives

}

europa {

passwd cisco; # Password

device tun1; # Device tun1

#persist yes; # Persist mode

up {

ifconfig "%% 10.4.4.2 10.4.4.1 mtu 1450";

ifconfig "%% up";

#route "add -net 192.168.45.0/24 gw 10.4.4.1";

};

}

*** Start the vtund in client mode ***

[root@europa:~#] vtund -f /etc/vtund.myconfig europa 192.168.1.1

[root@europa:~#] ifconfig -A

...

tun1: flags=51 mtu 1450

inet 10.4.4.2 --> 10.4.4.1 netmask 0xff000000

...

[root@europa:~#] ping 10.4.4.1

PING 10.4.4.1 (10.4.4.1): 56 data bytes

64 bytes from 10.4.4.1: icmp_seq=0 ttl=64 time=1.350 ms

64 bytes from 10.4.4.1: icmp_seq=1 ttl=64 time=1.288 ms

64 bytes from 10.4.4.1: icmp_seq=2 ttl=64 time=1.227 ms

--- 10.4.4.1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/std-dev = 1.227/1.288/1.350/0.058 ms

[root@callisto:~#] tcpdump -i tun2

tcpdump: listening on tun2

18:32:32.081336 10.4.4.2 > 10.4.4.1: icmp: echo request

18:32:32.081351 10.4.4.1 > 10.4.4.2: icmp: echo reply

18:32:33.091594 10.4.4.2 > 10.4.4.1: icmp: echo request

18:32:33.091611 10.4.4.1 > 10.4.4.2: icmp: echo reply

18:32:34.101714 10.4.4.2 > 10.4.4.1: icmp: echo request

18:32:34.101730 10.4.4.1 > 10.4.4.2: icmp: echo reply

WARNING

Be aware of the fact that user-space tunneling solutions interfere with each other when run simultaneously. This might cause problems with binding to sockets or several programs controlling one and the same tun device. This is most certainly the case with V-TUN and OpenVPN. Never run these tools at the same time on the same gateway!

OpenVPN
OpenVPN (http://openvpn.sourceforge.net/) and V-TUN are somewhat related approaches, because both rely on the universal TUN/TAP driver to tunnel an IP subnet or virtual Ethernet adapter. OpenVPN is the most portable solution I came across in my evaluation. It can connect MAC OS X, Linux, BSD, Solaris, and Microsoft Windows via a VPN user-space daemon over TCP/UDP ports and a highly evolved SSL/TLS protocol integration (OpenSSL) with PKI support. It can handle dynamic IP addresses and operate in NAT environments. It offers tunnel bandwidth shaping, compression, encryption, and authentication featuring preshared key conventional encryption or certificate-based public key encryption. Example 11-13 demonstrates an example setup between Linux and OpenBSD.

Example 11-13. Callisto-to-Europa (OpenVPN Tunnel with Static-Key Security (Preshared Secret)

[root@europa:~#] openvpn --remote 192.168.14.1 --dev tun3 --ifconfig 10.5.5.2 10.5.5.1

--verb 5 --secret /etc/openvpn.key &

[root@europa:~#] ifconfig –A

...

tun3: flags=51 mtu 1256

inet 10.5.5.2 --> 10.5.5.1 netmask 0xffffffff

...

[root@callisto:~#] openvpn --remote 192.168.14.3 --dev tun3 --ifconfig 10.5.5.1 10.5.5.2

--verb 5 --secret /etc/openvpn.key &

[root@callisto:~#] ifconfig –a

...

tun3 Link encap:Point-to-Point Protocol

inet addr:10.5.5.1 P-t-P:10.5.5.2 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1256 Metric:1

RX packets:4 errors:0 dropped:0 overruns:0 frame:0

TX packets:30 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10

RX bytes:336 (336.0 b) TX bytes:2520 (2.4 Kb)

...

[root@callisto:~#] ping 10.5.5.2

PING 10.5.5.2 (10.5.5.2) from 10.5.5.1 : 56(84) bytes of data.

WR64 bytes from 10.5.5.2: icmp_seq=1 ttl=255 time=1.36 ms

WR64 bytes from 10.5.5.2: icmp_seq=2 ttl=255 time=1.40 ms

WR64 bytes from 10.5.5.2: icmp_seq=3 ttl=255 time=1.12 ms

--- 10.5.5.2 ping statistics ---

3 packets transmitted, 3 received, 0% loss, time 2016ms

rtt min/avg/max/mdev = 1.129/1.298/1.403/0.124 ms

Stunnel/SSLwrap—SSL/TLS-Based "Wrapped" Tunnels and SSL Proxying/Relaying
SSL-based wrapper approaches work only for the TCP transport protocol. For example, Stunnel can encrypt TCP connections via SSL transport encryption acting as a multiplatform SSL tunneling proxy. Almost all open-source implementations are based on the OpenSSL (http://www.openssl.org) library. As mentioned at http://www.stunnel.org, "Stunnel can allow you to secure non-SSL aware daemons and protocols (like POP, IMAP, LDAP, etc) by having Stunnel provide the encryption, requiring no changes to the daemon's code."[5] SSLwrap takes a similar approach.

Secure Shell (SSH)
Although there is probably no need to introduce secure shell, I want to put it in context with our tunnel discussion. SSH uses port 21/tcp, sftp port 115/tcp, and its home base is at http://www.openssh.org. It evolved from an initial replacement for Telnet, rlogin, FTP, and rexec into a versatile and highly secure transport tunnel/relay solution with integrated strong authentication and single-sign-on capabilities. Although encrypted, the scp/sftp transfer performs extremely well. Many of OpenSSH's cryptography features rely on the OpenSSL library.

The following is a list of OpenSSH features:[6]

Open-source project

Free licensing

Strong encryption (3DES, Blowfish)

X11 forwarding (encrypt X Window System traffic)

Port forwarding (encrypted channels for legacy protocols)

Strong authentication (public key, one-time password, and Kerberos authentication)

Agent forwarding (single sign-on)

Interoperability (compliance with SSH 1.3, 1.5, and 2.0 protocol standards)

sftp client and server support in both SSH1 and SSH2 protocols

Kerberos and AFS ticket passing

Data compression

At the time of this writing, Cisco devices support only SSHv1, and there are no plans to support SSHv2 in the foreseeable future because of a focus on the IPSec architectures as a strategic platform. Cisco implements SSH server and client features and SSH terminal-line access. To figure out which Cisco IOS releases support SSH, consult Cisco.com. For example configurations, look at the Cisco.com document "Configuring Secure Shell on Routers and Switches Running Cisco IOS." SSH is straightforward to set up, but only as an integral part of authentication, authorization, and accounting (AAA).

IPSec Foundation

2008-12-15T10:53:00.000-08:00

IPSec is a suite of protocols operating at the network layer to secure communication between IPSec peers, either client to gateway, host to host, or gateway to gateway. IPSec tunnel connections can originate from gateways (routers, firewalls), hosts, or IPSec hardware/software clients and can terminate at VPN concentrators, hosts, or gateways (routers, firewalls).

IPSec provides both authentication and encryption services. Encryption renders intercepted payload over intrinsically hostile or untrusted infrastructures useless, and authentication ensures that packets are from a legitimate peer and have not been altered in transit or maliciously injected (man-in-the-middle attacks).

Figure 11-4 demonstrates the most popular applications for IPSec. Although IPSec introduces some caveats with regard to NAT and MTU issues, it is still the approach of choice to secure IP datagram transport transparently over hostile or untrusted (shared) environments, such as the Internet per se or wireless or powerline infrastructures. A lot of work is going on right now to make IPSec more "NAT-friendly" (NAT-Traversal). For further details about current work in the IPSec area, visit the IPSec Charter of the IETF (http://www.ietf.org/html.charters/ipsec-charter.html).

NOTE

IPSec is an extension of IPv4 and a mandatory part of IPv6.

The protocol suite consists of the following major building blocks:

The IPSec security architecture for the Internet (RFC 2401)

IKE key management (RFC 2409)

ESP (RFC 2406) and AH (RFC 2402) to protect IP traffic

ISAKMP security association (SA) management (RFC 2408)

IPSec DOI for ISAKMP (RFC 2407)

The OAKLEY key determination protocol (RFC 2412)

PKI X.509v3 certificate management protocol (RFC 2510, RFC 2527)

IPSec is a complex architecture because it has to handle complex tasks. This makes the concepts difficult to grasp. It would require hundreds of pages to cover IPSec appropriately, and even more for an introduction to cryptography and PKI (Public Key Infrastructure); therefore, you are referred to the standard documents and Internet resources.

IPSec ESP/AH and Tunnel and Transport Mode
IPSec offers two services: authentication and encryption. These can be used separately, but they often are used in combination. The protocols Encapsulating Security Payload (ESP) and Authenticated Header (AH) form the heart of the IPSec architecture. They provide authenticity, integrity, and replay protection and, in the case of ESP, confidentiality (based on payload encryption). Central to the ESP and AH concept is an abstraction referred to as security association (SA), which is explained later. ESP/AH protocol information is inserted between the IP header and the payload portion of the IP datagram. This example is referred to as IPSec transport mode, protection of payload, and transport of self-originated IP datagrams. In the case of a VPN setup, IPSec tunnel mode is used. This means that IPSec gateways deliver IP datagrams on behalf of other hosts/secure network segments. In this case, the gateway adds a completely new outer transport header, and the entire original IP datagram is encrypted. ESP most often is the approach of choice because it supports authentication and encryption and has a better chance of working with NAT gateways.

Manual/Automatic Keying, Preshared Secrets, and Certificates
Manual key management is tedious, less secure (no rekeying), more error prone, and (even worse) does not scale at all. It requires pregenerated keys to be distributed securely. If no key management daemon (such as racoon or isakmpd) is running (with the added benefit of automatic rekeying), manual keys have to suffice. This also means that SA setup has to be handled manually. The following scenarios are deployed commonly:

IPSec with manual key. (IPSec secret key will not change over time.)

IPSec with IKE with preshared secret. (IPSec secret key changes over time.)

IPSec with IKE with X.509v3 certificates. (IPSec secret key changes over time, requires a PKI.)

IKE Phase 1 and 2: Main Mode and Aggressive Mode
IKE uses a two-phase process for establishing IPSec parameters between two IPSec peering nodes that would otherwise have to be configured manually (for instance, by OpenBSD ipsecadm(8)). IKE phase 1 deals with initially establishing a secure and authenticated channel (a security association = SA) between IPSec peers with either preshared keys or X.509v3 certificates to ensure that the other side is who it claims to be. This can work either in main mode or aggressive mode and forms the foundation for phase 2. That is, "main mode sends the various authentication information in a certain sequence, providing identity protection. Aggressive mode does not provide identity protection because all of the authentication information is sent at the same time."[7]

In phase 2, unidirectional endpoint SAs are negotiated on behalf of IPSec and deal with the actual key exchange necessary for data encryption. Because phase 1 has already established and verified the credentials of the peers, Quick mode suffices in phase 2.

Resolving the IKE, PKI, SA, ISAKMP, and Oakley Confusion
Internet Key Exchange (IKE) is a somewhat generic hybrid protocol that approaches the issue of negotiation and provisioning of keying material for security associations in a protected manner. It does not per se claim to be compatible with Oakley or SKEME. IKE takes into consideration client mode negotiation (negotiation proxies) independent of the actual endpoints of SAs. An SA qualitatively is a logical point-to-point security channel between two security entities (peer IP addresses).

Security associations are by their nature connection-oriented and unidirectional. From the view of IKE, an SA is nothing more than "a set of policies and key(s) used to protect information. The ISAKMP SA is the shared policy and key(s) used by the negotiating peers in this protocol to protect their communication" (quoted from RFC 2409). IKE negotiations have two phases: UDP/500 (phase 1 and phase 2).

ISAKMP provides a framework for authentication, SA management, and cryptographic key exchange, but it was designed to be intrinsically key exchange independent and thus not defining a specific key exchange. Oakley specifically describes a series of key exchanges. SKEME describes a specific, versatile key exchange technique. Oakley and SKEME are designed to be compatible with the ISAKMP framework; however, they do not form a hierarchy.

A key exchange specification essentially defines a protocol by which two already authenticated parties or peers can agree on secure and secret keying material. Public Key Infrastructure (PKI) essentially brings into play X.509v3 certificates (digital signatures), frameworks, and architectures to deal with certificates (certificate authorities [CAs], dissemination and revocation of certificates, tokens, and so on). Certificates identify organizations, sites, entities, accounts, services, and individuals. LDAP interfaces to PKI are the most common way of interfacing with other systems.

What Is Opportunistic Encryption (OE)?
You can find the basic principles of OE in context with IPSec, IKE, and DNSsec in draft-richardson-ipsec-opportunistic-12.txt (available from the http://www.ietf.org drafts archive). Linux FreeS/WAN was among the first strong supporters and contributors to this idea. The general idea is to provide a method for ad-hoc encryption for secure communication without a lot of effort for prearrangements involving the end systems/parties. The approach relies on DNS (DNS TXT resource records [RRs] in the case of FreeS/WAN) for public key distribution and can be secured via DNSsec. This requires intervention from system administrators to add ancillary DNS records for opportunistic encryption support. This approach certainly has architectural drawbacks. For further information, consult the work of the IETF IPSec and ISAKMP/Oakley Work Group and the IETF DNSEXT Work Group, where DNSsec work is done.

What Is NAT-Traversal (NAT-T)?
NAT in context with IPSec is almost always a source for trouble. Try to avoid this combination, or at least perform NAT and IPSec tunnel termination on the same box and always use ESP. See draft-ietf-ipsec-nat-reqts-04.txt for an excellent introduction as to why and in what way NAT breaks IPSec in most cases. STUN (RFC 3489) offers another solution to the NAT problem. On the plus side, tunnels in general can be the solution for NAT-ignorant protocols such as H.323 (for example, Microsoft NetMeeting).

You will find that draft-ietf-ipsec-nat-t-ike-06.txt "describes how to detect one or more Network Address Translation devices (NATs) between IPSec hosts, and how to negotiate the use of UDP encapsulation of the IPSec packets through the NAT boxes in Internet Key Exchange (IKE)." The NAT-T capability negotiation with remote gateways is done in IKE phase 1 and allows safe IPSec traversal through firewalls performing NAT. In addition, the path between the two gateways is checked for NAT presence. The negotiation of UDP-encapsulated IPSec packets is performed in IKE Quick mode.

DHCP Provisioning over IPSec Tunnel Mode
RFC 3456, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPSec Tunnel Mode," describes a mechanism that allows remote hosts to be assigned addresses of a corporate address space. Therefore, the host would appear to be part of the intranet it securely connects to via IPSec.

IPSec Implementations
The VPNC IPSec/IKE conformance test suite uses KAME/racoon and OpenBSD's isakmpd as reference code. This should demonstrate the maturity, interoperability, and reliability of the open-source code base. It works extremely well with Cisco IPSec implementations and IPSec client software. Nevertheless, it took the IPSec vendors a long time to work out interoperability issues. Occasionally I get the impression that some vendors, for awkward commercial reasons, deliberately break what took them years to fix. This is an especially big problem with IPSec intervendor client-to-gateway interoperability. (You are invited to draw your own conclusion.)

Linux IPSec
Until recently, Linux FreeS/WAN (http://www.freeswan.org) was the most popular implementation of IPSec and IKE for the Linux 2.2/2.4 kernel (IPv4 only). A related project called Super FreeS/WAN (http://www.freeswan.ca) included all the latest-and-greatest patches and early development features (NAT-Traversal, AES, X.509, ALG [all ciphers/hashes as modules], Dead Peer Detection IETF Draft, and so on). Because of disagreements about the evolution of FreeS/WAN and some peculiar points of view (removal of AH, focus on opportunistic encryption, and lack of interest in IPSec standard compliance and interoperability), the project has been discontinued and is no longer actively maintained.

The OpenSWAN Project (http://www.openswan.org) has started as a code fork of FreeS/WAN and will continue the work. The FreeS/WAN maintainer had a strategic interest in pushing a new approach to IPSec tunnel/VPN provisioning referred to as "opportunistic encryption" involving advanced DNS features, plug-and-play friendliness at the cost of IPSec generic compliance, and reduced security. It escaped the attention of some people that FreeS/WAN gateways do not necessarily talk only to FreeS/WAN gateways. This led to a misjudgment of the community support of that strategic direction.

OpenSWAN is a huge kernel patch and module with accompanying user-space tools that never made it into the mainstream kernel. KLIPS is the kernel IPSec module, and pluto is the IKE daemon. The new 2.6 Linux kernel drastically changed this picture. The current state of affairs is this: "As of Linux 2.5.47, there is a native IPSec implementation in the kernel. It was written by Alexey Kuznetsov and Dave Miller, inspired by the work of the USAGI IPv6 group. With its merge, James Morris' CrypoAPI also became part of the kernel—it does the actual crypting. As of 2.5.49, IPSec works without further patches."[8]

Linux native IPSec for the new 2.6 Linux kernel is based on the KAME Project's IKE daemon racoon, which is a big leap forward for consistent IPSec interoperability between BSD platforms and Linux. OpenBSD's isakmpd also has been ported to Linux, and OpenSWAN is completing 2.6 integration support of their own implementation. OpenSWAN is easy to install; just follow the ReadMe that comes with the sources. IPSec-Tools is a port of KAME's IPSec utilities to the Linux 2.6 including racoon/setkey. isakmpd and racoon/setkey can be retrieved from the following resources:

http://bender.thinknerd.de/~thomas/IPsec/isakmpd-linux.html

http://ipsec-tools.sourceforge.net/

KAME
The KAME Project is a software kit that provides reference implementations of IPv6 and IPSec (both IPv4/IPv6) for BSD operating systems as well as the alternate queuing framework (ALTQ) discussed in Chapter 13, "Policy Routing, Bandwidth Management, and QoS." KAME's IKE daemon is called racoon.

During IPSec setup, the kernel needs to know what traffic to encrypt or secure and how. This is referred to as establishing an IPSec security policy. On BSD systems, this information is stored in a table in the kernel known as the security policy database (SPD).

The setkey(8) utility is the tool to manipulate the SPD. Another table (the security association database [SAD]) stores the various encryption keys needed to secure communications between hosts, clients, and gateways. In case of manual keying, the setkey(8) program also is used to configure the manual keys in the SAD. With an IKE approach, racoon will handle the adding and deleting of entries from the SAD automatically.

FreeBSD
To add IPSec support to your FreeBSD kernel, add the code in Example 11-14 to your kernel config file, and then recompile and install the new kernel. You essentially need the two utilities setkey and the IKE daemon racoon.

Example 11-14. FreeBSD IPSec Kernel Configuration Options

options IPSEC #IP security

options IPSEC_ESP #IP security

options IPSEC_DEBUG #debug for IP security

device gif 4 #For IPSec Tunnel Mode

FreeBSD IPSec configuration includes the following steps:

Retrieve and install the racoon daemon from ports by using cd /usr/ports/security/racoon followed by make all, make install, make clean.

Define the IPSec security policy via setkey -DFP (for manual policy management) and setkey -f /etc/ipsec.conf.

You also can do that dynamically via the IKE daemon racoon. It requires two configuration files: /usr/local/etc/racoon/psk.txt (for preshared keys) and /usr/local/etc/racoon/racoon.conf.

Then start racoon via racoon -l /var/log/racoon -f usr/local/etc/racoon/racoon.conf.

NOTE

IPSec tunnel connections between two FreeBSD gateways require the configuration of the gif pseudo-interface for proper routing between the protected private (RFC 1918) networks behind these gateways (Example 11-15).

Example 11-15. Castor gif Pseudo-Interface Setup

[root@castor:~#] gifconfig gif0 192.168.2.7 192.168.2.254

[root@castor:~#] ifconfig gif0 inet 192.168.7.7 netmask 255.255.255.0 192.168.45.254

netmask 255.255.255.0

[root@castor:~#] gifconfig gif0

[gif0: flags=8051 mtu 1280

inet6 fe80::210:5aff:fec4:2c04%gif0 prefixlen 64

inet 192.168.7.7 --> 192.168.45.254 netmask 0xffffff00

physical address inet 192.168.2.7 --> 192.168.2.254

[root@castor:~#] netstat -rn -f inet

Routing tables

Internet:

Destination Gateway Flags Refs Use Netif Expire

default 192.168.2.254 UGSc 3 121 xl0

10.0.0.4 10.0.0.4 UH 0 0 lo0

127.0.0.1 127.0.0.1 UH 1 32 lo0

192.168.2 link#1 UC 2 0 xl0

192.168.2.7 00:10:5a:c4:2c:04 UHLW 3 4 lo0

192.168.2.254 52:54:05:e3:e4:2f UHLW 5 446 xl0 402

192.168.7 link#2 UC 0 0 ed0

192.168.45.254 192.168.7.7 UH 0 0 gif0

192.168.80 link#15 UC 0 0 vlan8

NOTE

Consult http://www.freebsd.org/doc/en_USISO88591/books/handbook/ipsec.html for further details.

OpenBSD
isakmpd is the OpenBSD ISAKMP/Oakley (a.k.a. IKE) key management daemon. The isakmpd daemon is responsible for the establishment of management of security associations for encrypted or authenticated network traffic. It is the only scalable alternative to manual keying with tedious and error-prone manual SA setups and ESP/AH flows on top. isakmpd is also available for NetBSD. There you have the luxury to choose between isakmpd and racoon. Example 11-16 shows the kernel configuration options required by OpenBSD and related sysctl parameters.

Example 11-16. OpenBSD IPSec Kernel Configuration Options

### kernel config:

option CRYPTO # Cryptographic Framework

option IPSEC # IPSec VPN

#option KEY # KEY implied by IPSec

pseudo-device enc 4 # Encapsulation device used by IPSec

### sysctl:

[root@ganymed:~#] sysctl -w net.inet.esp.enable=1

[root@ganymed:~#] sysctl -w net.inet.ah.enable=1

[root@ganymed:~#] sysctl -w net.inet.ip.forwarding=1

[root@ganymed:~#] sysctl -w net.inet6.ip6.forwarding=1

[root@ganymed:~#] sysctl -w net.inet.ipcomp.enable = 1

An OpenBSD IPSec setup consists of these components:

/etc/rc.vpn (for manual keying only, manual SAs, and IPSec flows)

/etc/isamkmpd/isakmpd.conf

/etc/isamkmpd/isakmpd.policy

isakmpd (not required for manual keying)

The keynote utility (optional, man pages 1, 3, 4, 5; RFC 2704), public/private key generation, and trust management

ipsecadm (generic admin interface for manual setup)

The enc(4) pseudo-interface for encryption (adjust your firewall filters accordingly)

NOTE

photurisd is an alternative key management daemon for OpenBSD. It is based on RFC 2522 and RFC 2523. A word of wisdom: Stay away from the OpenBSD photurisd. It has major limitations, and the whole community is using ISAKMP anyway. photurisd was removed from the OpenBSD tree with version 3.3 for good reason and can be considered deprecated.

Advice About IPSec Lab Scenarios

2008-12-15T10:49:00.000-08:00

Host-to-host security hardly is used anymore today, and the same is true for manual IPSec keying and manual SA setup. IKE dominates the picture with rapid acceptance of X.509v3 certificate integration. The most widespread deployments of IPSec feature gateway-to-gateway and road-warrior-to-gateway configurations. VPN client software is required on the road warrior (PDA, notebook).

Because OpenSWAN and native kernel IPSec for 2.6 kernels is rapidly approaching its final stage of consolidation, we will wait until the dust settles and focus on FreeBSD and OpenBSD IKE here. Dynamically negotiated IPSec requires configuration of the IKE daemons and a policy that defines qualified traffic that triggers SA establishment (for example, network to network via tunnel mode).

Lab 11-8: An IPSec with IKE (racoon/isakmpd) Scenario (Gateway-to-Gateway Tunnel Mode)
In this lab, we require the discussed gif tunnel setup on the FreeBSD side. Example 11-17 demonstrates the setup and output of the IPSec gateway ganymed (OpenBSD), and Example 11-18 shows the configuration of the IPSec peer castor (FreeBSD). FreeBSD has a dedicated configuration file for the IPSec policy, and OpenBSD isakmpd contains everything in a single configuration file. The tunnel operation is verified via extended pings from castor and callisto in combination with sniffer traces. The highlighted text emphasizes successful SA establishment.

Example 11-17. OpenBSD IPSec with ISAKMPD and Preshared Key

[root@ganymed:/etc/isakmpd#] cat isakmpd.policy

KeyNote-Version: 2

Authorizer: "POLICY"

Licensees: "passphrase:cisco"

Conditions: app_domain == "IPsec policy" &&

esp_present == "yes" &&

esp_enc_alg == "3des" &&

esp_auth_alg == "hmac-md5" -> "true";

[root@ganymed:/etc/isakmpd#] cat isakmpd.conf

#

# A configuration sample VPN for the isakmpd ISAKMP/Oakley (a.k.a. IKE) daemon.

# "ganymed" and "castor" are the respective security gateways (a.k.a. VPN nodes).

#

[General]

Retransmits= 5

Exchange-max-time= 120

Listen-on= 192.168.2.254

[Phase 1]

192.168.2.7= ISAKMP-peer-castor

[Phase 2]

Connections= IPsec-ganymed-castor

[ISAKMP-peer-castor]

Phase= 1

Transport= udp

Local-address= 192.168.2.254

Address= 192.168.2.7

Authentication= cisco

Configuration= Default-main-mode

[IPsec-ganymed-castor]

Phase= 2

ISAKMP-peer= ISAKMP-peer-castor

Configuration= Default-quick-mode

Local-ID= Net-ganymed

Remote-ID= Net-castor

[Net-ganymed]

ID-type= IPV4_ADDR_SUBNET

Network= 192.168.45.0

Netmask= 255.255.255.0

[Net-castor]

ID-type= IPV4_ADDR_SUBNET

Network= 192.168.7.0

Netmask= 255.255.255.0

[Default-main-mode]

EXCHANGE_TYPE= ID_PROT

Transforms= 3DES-MD5-GRP2

[Default-quick-mode]

DOI= IPSEC

EXCHANGE_TYPE= QUICK_MODE

Suites= QM-ESP-3DES-MD5-PFS-GRP2-SUITE

### Proof of the two uni-directional SAs ###

[root@ganymed:~#] cat /kern/ipsec

Hashmask: 31, policy entries: 2

SPI = 0ea713d5, Destination = 192.168.2.7, Sproto = 50

Established 416 seconds ago

Source = 192.168.2.254

Flags (00011082) =

Crypto ID: 1

xform =

Encryption = <3DES>

Authentication =

3528 bytes processed by this SA

Last used 378 seconds ago

Expirations:

Hard expiration(1) in 784 seconds

Soft expiration(1) in 664 seconds

SPI = b6297e4e, Destination = 192.168.2.254, Sproto = 50

Established 416 seconds ago

Source = 192.168.2.7

Flags (00001082) =

Crypto ID: 2

xform =

Encryption = <3DES>

Authentication =

3696 bytes processed by this SA

Last used 378 seconds ago

Expirations:

Hard expiration(1) in 784 seconds

Soft expiration(1) in 664 seconds

### The encap routing situation as derived from the VPN policy setup

(isakmpd.policy) ###

[root@ganymed:~#] netstat -f encap -rn

Routing tables

Encap:

Source Port Destination Port Proto SA(Address/Proto/Type/Direction)

192.168.7/24 0 192.168.45/24 0 0 192.168.2.7/50/use/in

192.168.45/24 0 192.168.7/24 0 0 192.168.2.7/50/require/out

### Detailed Protocol Statistics for ESP/AH ###

[root@ganymed:~#] netstat -p esp

esp:

42 input ESP packets

42 output ESP packets

0 packets from unsupported protocol families

0 packets shorter than header shows

0 packets dropped due to policy

0 packets for which no TDB was found

0 input packets that failed to be processed

0 packets with bad encryption received

0 packets that failed verification received

0 packets for which no XFORM was set in TDB received

0 packets were dropped due to full output queue

0 packets where counter wrapping was detected

0 possibly replayed packets received

0 packets with bad payload size or padding received

0 packets attempted to use an invalid tdb

0 packets got larger than max IP packet size

0 packets that failed crypto processing

3696 input bytes

3528 output bytes

[root@ganymed:~#] netstat -p ah

ah:

0 input AH packets

0 output AH packets

0 packets from unsupported protocol families

0 packets shorter than header shows

0 packets dropped due to policy

0 packets for which no TDB was found

0 input packets that failed to be processed

0 packets that failed verification received

0 packets for which no XFORM was set in TDB received

0 packets were dropped due to full output queue

0 packets where counter wrapping was detected

0 possibly replayed packets received

0 packets with bad authenticator length received

0 packets attempted to use an invalid tdb

0 packets got larger than max IP packet size

0 packets that failed crypto processing

0 input bytes

0 output bytes

### And the sniffer traces to prove that we are really encrypting ###

[root@castor:~#] ping -S 192.168.7.7 192.168.45.1

PING 192.168.45.1 (192.168.45.1) from 192.168.7.7: 56 data bytes

64 bytes from 192.168.45.1: icmp_seq=0 ttl=63 time=2.412 ms

64 bytes from 192.168.45.1: icmp_seq=1 ttl=63 time=2.382 ms

64 bytes from 192.168.45.1: icmp_seq=2 ttl=63 time=2.320 ms

^C

--- 192.168.45.1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 2.320/2.371/2.412/0.038 ms

[root@callisto:~#] ping -I 192.168.45.1 192.168.7.7

PING 192.168.7.7 (192.168.7.7) from 192.168.45.1 : 56(84) bytes of data.

64 bytes from 192.168.7.7: icmp_seq=1 ttl=63 time=3.84 ms

64 bytes from 192.168.7.7: icmp_seq=2 ttl=63 time=2.64 ms

64 bytes from 192.168.7.7: icmp_seq=3 ttl=63 time=2.51 ms

--- 192.168.7.7 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2018ms

rtt min/avg/max/mdev = 2.515/3.002/3.846/0.600 ms

[root@ganymed:~#] tethereal -i ne4

Capturing on ne4

0.000000 castor.nerdzone.org -> 192.168.2.254 ESP ESP (SPI=0x2b76d234)

0.001213 192.168.2.254 -> castor.nerdzone.org ESP ESP (SPI=0x01a960cc)

0.272924 192.168.2.254 -> castor.nerdzone.org ESP ESP (SPI=0x01a960cc)

0.273586 castor.nerdzone.org -> 192.168.2.254 ESP ESP (SPI=0x2b76d234)

1.001848 castor.nerdzone.org -> 192.168.2.254 ESP ESP (SPI=0x2b76d234)

1.003015 192.168.2.254 -> castor.nerdzone.org ESP ESP (SPI=0x01a960cc)

1.282909 192.168.2.254 -> castor.nerdzone.org ESP ESP (SPI=0x01a960cc)

1.283591 castor.nerdzone.org -> 192.168.2.254 ESP ESP (SPI=0x2b76d234)

[root@ganymed:~#] tethereal -i enc0

Capturing on enc0

0.000000 -> UNKNOWN WTAP_ENCAP = 0

0.001566 -> UNKNOWN WTAP_ENCAP = 0

0.668721 -> UNKNOWN WTAP_ENCAP = 0

0.669053 -> UNKNOWN WTAP_ENCAP = 0

1.009968 -> UNKNOWN WTAP_ENCAP = 0

1.011561 -> UNKNOWN WTAP_ENCAP = 0

1.670448 -> UNKNOWN WTAP_ENCAP = 0

1.670744 -> UNKNOWN WTAP_ENCAP = 0

Example 11-18. FreeBSD IPSec with racoon and Preshared Key

### gif tunnel setup for routing ###

[root@castor:~#] gifconfig gif0 192.168.2.7 192.168.2.254

[root@castor:~#] ifconfig gif0 inet 192.168.7.7 netmask 255.255.255.0 192.168.45.254

netmask 255.255.255.0

[root@castor:~#] gifconfig gif0

[gif0: flags=8051 mtu 1280

inet6 fe80::210:5aff:fec4:2c04%gif0 prefixlen 64

inet 192.168.7.7 --> 192.168.45.254 netmask 0xffffff00

physical address inet 192.168.2.7 --> 192.168.2.254

[root@castor:~#] netstat -rn -f inet

Routing tables

Internet:

Destination Gateway Flags Refs Use Netif Expire

default 192.168.2.254 UGSc 3 121 xl0

10.0.0.4 10.0.0.4 UH 0 0 lo0

127.0.0.1 127.0.0.1 UH 1 32 lo0

192.168.2 link#1 UC 2 0 xl0

192.168.2.7 00:10:5a:c4:2c:04 UHLW 3 4 lo0

192.168.2.254 52:54:05:e3:e4:2f UHLW 5 446 xl0 402

192.168.7 link#2 UC 0 0 ed0

192.168.45.254 192.168.7.7 UH 0 0 gif0

192.168.80 link#15 UC 0 0 vlan8

### IPsec configurations ###

[root@castor:~#] cat /etc/ipsec.conf

spdadd 192.168.7.0/24 192.168.45.0/24 any -P out ipsec

esp/tunnel/192.168.2.7-192.168.2.254/require;

spdadd 192.168.45.0/24 192.168.7.0/24 any -P in ipsec

esp/tunnel/192.168.2.254-192.168.2.7/require;

[root@castor:~#] cat /usr/local/etc/racoon/psk.txt

# IPv4/v6 addresses

192.168.2.254 cisco

[root@castor:~#] cat /usr/local/etc/racoon/racoon.conf

path include "/usr/local/etc/racoon" ;

# search this file for pre_shared_key with various ID key.

path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

# racoon will look for certificate file in the directory,

# if the certificate/certificate request payload is received.

path certificate "/usr/local/etc/cert" ;

# "log" specifies logging level. It is followed by either "notify," "debug,"

# or "debug2."

#log debug;

# "padding" defines some parameter of padding. You should not touch these.

padding

{

maximum_length 20; # maximum padding length.

randomize off; # enable randomize length.

strict_check off; # enable strict check.

exclusive_tail off; # extract last one octet.

}

# if no listen directive is specified, racoon will listen to all

# available interface addresses.

listen

{

isakmp 192.168.2.7 [500];

#admin [7002]; # administrative port by kmpstat.

strict_address; # all addresses must be bound.

}

# Specification of various default timers.

timer

{

# These value can be changed per remote node.

counter 5; # maximum trying count to send.

interval 20 sec; # maximum interval to resend.

persend 1; # the number of packets per a send.

# timer for waiting to complete each phase.

phase1 30 sec;

phase2 15 sec;

}

### gateway-to-gateway ###

remote 192.168.2.254

{

exchange_mode main,aggressive;

doi ipsec_doi;

situation identity_only;

my_identifier address 192.168.2.7;

peers_identifier address 192.168.2.254;

nonce_size 16;

lifetime time 1 min; # sec,min,hour

proposal {

encryption_algorithm 3des;

hash_algorithm md5;

authentication_method pre_shared_key ;

dh_group 2 ;

}

}

sainfo address 192.168.2.7 any address 192.168.2.254 any

{

pfs_group 2 ;

lifetime time 30 sec;

encryption_algorithm 3des ;

authentication_algorithm hmac_md5;

compression_algorithm deflate ;

}

[root@castor:~#] cat /var/log/racoon

2004-04-04 13:44:36: INFO: main.c:174:main(): @(#)internal version 20001216 sakane@kame.net

2004-04-04 13:44:36: INFO: main.c:175:main(): @(#)This product linked OpenSSL 0.9.7c 30

Sep 2003 (http://www.openssl.org/)

2004-04-04 13:44:36: INFO: isakmp.c:1358:isakmp_open(): 192.168.2.7[500] used as isakmp

port (fd=5)

2004-04-04 13:44:51: INFO: isakmp.c:894:isakmp_ph1begin_r(): respond new phase 1

negotiation: 192.168.2.7[500]<=>192.168.2.254[500]

2004-04-04 13:44:51: INFO: isakmp.c:899:isakmp_ph1begin_r(): begin Identity Protection mode.

2004-04-04 13:44:51: WARNING: isakmp_inf.c:1281:isakmp_check_notify(): ignore

INITIAL-CONTACT notification, because it is only accepted after phase1.

2004-04-04 13:44:51: WARNING: ipsec_doi.c:3099:ipsecdoi_checkid1(): ID value mismatched.

2004-04-04 13:44:51: INFO: isakmp.c:2412:log_ph1established(): ISAKMP-SA established 192

.168.2.7[500]-192.168.2.254[500] spi:1340537a78e1b7d8

:d25809b27e1f5e75

2004-04-04 13:44:52: INFO: isakmp.c:1049:isakmp_ph2begin_r(): respond new phase 2

negotiation: 192.168.2.7[0]<=>192.168.2.254[0]

2004-04-04 13:44:52: INFO: pfkey.c:1134:pk_recvupdate(): IPsec-SA established: ESP/Tunnel

192.168.2.254->192.168.2.7 spi=245830613(0xea713d5)

2004-04-04 13:44:52: INFO: pfkey.c:1357:pk_recvadd(): IPsec-SA established: ESP/Tunnel 192

.168.2.7->192.168.2.254 spi=3056172622(0xb6297e4e)

2004-04-04 13:45:51: INFO: isakmp.c:1516:isakmp_ph1expire(): ISAKMP-SA expired 192.168.2

.7[500]-192.168.2.254[500] spi:1340537a78e1b7d8:d2580

9b27e1f5e75

2004-04-04 13:45:52: INFO: isakmp.c:1564:isakmp_ph1delete(): ISAKMP-SA deleted 192.168.2

.7[500]-192.168.2.254[500] spi:1340537a78e1b7d8:d2580

9b27e1f5e75

Road-Warrior Scenarios (Road Warrior-to-OpenBSD/FreeBSD Gateway with IKE)

2008-12-15T10:43:00.000-08:00

Road warriors (multiuser configurations) are roaming user clients with dynamically assigned IP addresses unknown to the home IPSec gateway or VPN concentrator. Hence the configuration has to rely on other means of authentication such as deployment of signatures or certificates. This requires a PKI.

Deployment of preshared secrets does not scale and often compromises entire architectures that rely on only one key. Because of an architectural change in the Cisco IPSec client for group authentication, interoperability with UNIX IPSec implementations has severely suffered (although arguably added benefit to Cisco-to-Cisco connections).

OpenBSD, FreeBSD, and Linux IPSec clients offer excellent granularity to adjust to interoperability requirements. As a rule of thumb, the same IPSec implementation on the client and the gateway saves lots of headaches and debugging effort. For sample road-warrior setups, see http://www.ipsec-howto.org, http://www.linuxsecurity.com/resource_files/cryptography/ipsec-howto/HOWTO.html, and http://www.allard.nu/openbsd/index.html. This last website covers certificate handling in depth.

Example 11-19 provides a certificate-based racoon example for road-warrior access.

Example 11-19. FreeBSD Gateway racoon Configuration for Road-Warrior Access

### Road Warrior to Gateway ####

path include "/usr/local/etc/racoon" ;

# search this file for pre_shared_key with various ID key.

path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

# racoon will look for certificate file in the directory,

# if the certificate/certificate request payload is received.

path certificate "/usr/local/etc/cert" ;

# "log" specifies logging level. It is followed by either "notify," "debug,"

# or "debug2."

#log debug;

remote anonymous {

exchange_mode main;

generate_policy on;

passive on;

certificate_type x509 "my_certificate.pem" "my_private_key.pem";

my_identifier cisco;

peers_identifier cisco;

proposal {

encryption_algorithm 3des;

hash_algorithm md5;

authentication_method rsasig;

dh_group modp1024;

}

}

sainfo anonymous {

pfs_group modp1024;

encryption_algorithm 3des;

authentication_algorithm hmac_md5;

compression_algorithm deflate;

}

Dynamic Routing Protocols

2008-12-15T10:34:00.000-08:00

Dynamic Routing Protocols over Point-to-Point Tunnels—Transparent Infrastructure VPN
In general, IPSec tunnel setups cannot transfer routing protocols such as OSPF. IPSec does not always support the notion of an interface on which a routing engine (such as ospfd) can rely. (Remember, IPSec deals with SAs.) This can be accomplished by deploying OSPF over IP-IP/GRE tunnels over IPSec or out-of-band routing signaling not taking the crypto path.

Given the caveat mentioned with regard to TTL (TTL=1 breaks tunnel and multicasting) and MTUs, dynamic routing protocols work over tunnels pretty much the same way as over regular point-to-point links, as long as the routing engine can recognize the special interfaces associated with tunnels. Zebra/Quagga can deal with most implementations thanks to sound interface abstraction. For example setups of GRE over IPSec, see http://www.freeswan.ca/docs/HA/HA_VPNS_With_FreeSWAN.html.

IPSec Development and Evolution
The current efforts focus on specification of IKEv2, NAT-Traversal and firewall traversal, opportunistic encryption, DHCP over IKE, tight AES integration, and IPSec domains of interpretation (DOIs) for secure group communication and final touches to the IPv6 architecture. Currently, there is a significant trend toward hardware crypto-accelerator cards and chipsets that relieve the CPU from performing 3DES/AES encryption (and, most recently, that perform hashing calculations in hardware).

AES has improved crypto efficiency greatly; however, sustainable gigabit crypto throughput is still a domain of expensive commercial firewalls. An interesting addition to IPSec is the keynote trust management system that remedies some of the disadvantages of PKIs (introduced in RFC 2704 and RFC 2796). Also visit http://www1.cs.columbia.edu/~angelos/keynote.html.

Designing for High Availability

2008-12-15T10:32:00.000-08:00

High-availability architectures represent a wide-ranging subject of interlocked complexity stretching over all layers of the OSI (Open System Interconnection) stack.

Keep in mind that the end-user's perception of service availability is the ultimate and most relevant criterion; perception will be favorable if you did your job right. Toward that end, high-availability architectures satisfy the following needs:

Redundancy— This includes equipment (node) and topology (link) redundancy precautions and redundant services available for a user base.

Load balancing— Naturally, load balancing primarily serves the purpose of distributing load among candidates of a pool or farm of devices. Next-hop redundancy considerations and load balancing are important aspects of such an overall design. Dynamic DNS can accomplish this also with different means.

Clustering— This involves logical grouping of constituents to a service. Clustering groups might include performance clusters, load-balancing clusters, or fault-tolerance clusters. It is another generic approach to presenting one highly robust virtual service to the outside world with a group of real servers behind the scene. Dedicated cluster management software maintains the overall picture of cluster controllers and component servers, thus increasing overall availability, robustness, and performance.

Heartbeat/keepalives— Heartbeat/keepalive protocols and agents monitor the availability and operational parameters of network elements and services.

(D)DoS defenses— Robust high-availability architectures can more likely withstand or mitigate the effects of (D)DoS attacks or are an attribute of a sound design.

Network failover strategies— These approaches in general include VRRP/HSRP mechanisms in combination with gratuitous ARP for the purpose of providing a gateway failover mechanism.

Reliable failure detection and fast recovery/restoration of service— This is the domain of routing protocols. The general goal of modern routing designs is subsecond convergence. This is a mandatory requirement for real-time traffic such as voice or video.

This chapter discusses support for such services from a networker's point of view (OSI Layers 1 through 4). The application layers (Layers 5 through 7) are intentionally underrepresented in this chapter because they use other mechanisms beyond the scope of a network/transport layer discussion.
Increasing Availability
The essential questions for high-availability (HA) designers have always been (and will continue to be) "How can I increase the overall availability of a special service or application, and what do I have to do to eliminate weak links in the chain or single points of failure? Tackling these challenges involves thorough planning across all OSI layers and the removal of all single points of failure wherever possible. A chain is as strong as its weakest link. Therefore, it is highly advisable to have at least one backup system, link, or resource available at all times.

Of course, the efforts and costs associated with such an endeavor can get out of hand easily and should, therefore, be governed by common sense and commercial feasibility. This is a particularly interesting topic in times of "best effort" services. Best effort is always a commercial dictate. The particular task of network engineers is to provide highly robust IP infrastructures to support higher-layer redundancy approaches, and the task of systems engineers is to accomplish OS resilience with concepts such as clustering or distributed architectures. This is the foundation for high-availability applications (services); a good implementation should result in robust and stable services from the point of view of the end user. How this is accomplished means little to the customer.

Withstanding a (D)DoS Attack

2008-12-15T10:31:00.000-08:00

In light of recent Internet attacks, whether a sound HA architecture should withstand a massive (distributed) denial-of-service ([D]DoS) attack or be able to mitigate its effects has become a legitimate question. From my point of view, a state-of-the-art HA architecture should have some inherent self-healing capabilities; HA architects should also add another line of defense to assist in at least crippling or weakening (D)DoS attacks and their progeny. Several, sometimes complementary and orthogonal, lines of defense are crucial to prevent (D)DoS attacks, as they are to overall security architectures.

HA in terms of almost 100 percent service availability within strict service level agreements (SLAs) and monitored key performance indicators (KPIs) represents a significant challenge for today's finest engineers and designers. The problem with any (D)DoS defense is that every system's strength defines its weaknesses, too. For example, handing over control of a firewall ruleset to a network intrusion detection system (NIDS) means that any successful trigger of this defense mechanism (spoofing) effectively locks out legitimate networks from crucial services. Therefore, a system designed to protect or prevent might become the perfect DoS trap.

NOTE

Recent hostile activities on the Internet have proven to me that, in general, operational staff are overwhelmed by and overburdened with reactive actions because of weak underlying network design and planning.

Network HA Approaches
The fundamental principle, and the foundation of network HA, is network link redundancy and redundant hardware (network elements).

Redundant Paths
The underlying design principle is that, for a critical service, at least two equivalent systems should be provided and topologies chosen in a way that there always exist, at the least, two redundant paths to the next device. This is why for so many years many robust and scalable photonic network approaches have been based successfully on protected ring topologies (for example, Synchronous Digital Hierarchy/Synchronous Optical Network [SDH/SONET]) and Resilient Packet Ring (RPR). Just because a lot of folks disliked Token Ring technology for no apparent reason does not mean that ring topologies per se are inferior to bus architectures or star topologies; on the contrary. With a small number of network elements, point-to-point links will suffice. Usually a collapsed network core consists of three or four network elements (as shown in
My approach to network redundancy is that more than one alternative link is unnecessary and unjustifiable commercially.

Standby Equipment
Another concept is the provisioning of cold- and hot-standby equipment, meaning components that need power up and hardware configuration (versus up-and-running failover candidates). Occasionally, engineers or management throw hardware resources at a simple design problem. However, HA concepts that are too exhaustive add considerable complexity to networks, occasionally defeating the purpose (and at unjustifiable expense).

As an introduction to the challenge of HA, Figure 12-2 presents a typical corporate Internet connectivity example in two variants.

Simple but Effective Approaches to Server HA

2008-12-15T10:29:00.000-08:00

Let us consider the network vicinity of a server in the context of its connected network interface cards (NICs), its LAN switch environment, VLAN membership, and exit gateways. Note that two or more NICs attached to redundant switch access ports provide sufficient redundancy, and channel bonding or interface teaming provides another useful combination of link aggregation (with an added redundancy benefit).

Route equalizing per destination or per packet can be configured to exit the two VLAN broadcast domains to which a server is usually hooked up. Beyond VLANs, dynamic routing protocols provide sufficiently fast rerouting around failures. It is fairly straightforward to provide redundant VLAN trunks and trunk termination (redundant routers on a stick) via Virtual Router Redundancy Protocol (VRRP) or Hot Standby Router Protocol (HSRP). This can be combined with equalized default routes (Linux) or floating static route concepts. Manual load distribution can be manipulated via manually tuned more-specific prefix routes. Return-packet load balancing originating from distant sites is an entirely different story; Domain Name System round-robin (DNS RR), Border Gateway Protocol (BGP) approaches (MED or path prepending), or dedicated load-balancing devices represent possible solutions.

When experimenting with special load-distribution approaches, keep in mind that Internet Control Message Protocol (ICMP) redirects might affect what you try to accomplish. sysctl provides a hook to disable dissemination of ICMP redirect messages (as shown in Example 12-1).

Example 12-1. Disabling ICMP Redirects for Special Cases

[root@ganymed:~#] sysctl -a | grep redirect

net.inet.ip.redirect = 1

net.inet6.ip6.redirect = 1
Address Resolution Protocol (ARP) cache latency is another issue that considerably affects certain setups. How long an ARP entry remains in a cache until it is removed is implementation-specific and might require manual intervention. To compensate for long timeouts, failover concepts such as VRRP/HSRP use gratuitous ARP featuring unsolicited updates.

Split-view DNS setups are popular, especially in enterprise networks where Network Address Translation (NAT) is used. Split-view DNS essentially means that an internal name server responds to queries for names associated with corporate RFC 1918 addresses and consults the external name server if it fails to resolve global records. Therefore, for true redundancy, two internal and two external DNS servers are advisable.

Dynamic Routing Protocols

2008-12-15T10:26:00.000-08:00

Dynamic routing is the most flexible and effective approach to provide redundancy for alternative paths and the only way to detect network node, port, or link failures reliably. Routing and standby protocols rely on the simple principle that if a speaker hasn't heard from a neighbor in a certain time, something must be wrong. Load balancing over multiple links can be accomplished in several ways: BGP "pseudo" load balancing can be achieved in dual-homed Internet service provider (ISP) architectures, Multilink PPP, and link-state Equal-Cost Multi-Path (ECMP) for interior gateway protocol (IGP) paths. It is a good idea to fine-tune protocol parameters for fast-converging resilient architectures or deploy incremental SPF (iSPF). Routing provides the signaling protocols to detect and route around failures within highly meshed nondeterministic IP networks.
DNS Shuffle Records and Round-Robin (DNS RR)
DNS round-robin (DNS RR), as shown in Example 12-2, is the concept of entering multiple IP addresses for one fully qualified domain name (FQDN). It is qualitatively described in RFC 1794, "DNS Support for Load Balancing." When a DNS resolver (client) request reaches the server, it answers in an unweighted round-robin fashion. Although the server answers with the complete round-robin set, most clients consider only the first entry, which works as long as the server cycles the entries. This results in almost equal but crude and inefficient (unweighted) load distribution to resources of equal content or services. Nevertheless, this approach has several drawbacks, such as DNS caching problems and a considerable percentage of the requests directed lost when just one constituent of the DNS RR group becomes unavailable.

DNS RR essentially is deployed for migration scenarios, load balancing, and in poor-man redundancy architectures. For the Internet Systems Consortium's (ISC) point of view regarding the implications on Berkeley Internet Name Domain (BIND), read the excellent BIND load-balancing comment at http://www.isc.org/products/BIND/docs/bind-load-bal.html. For BIND-specific configuration options, consult the documentation that comes with your version of BIND.

Example 12-2. DNS RR Server Setup

www.iktech.net 300 IN A 192.168.1.1

www.iktech.net 300 IN A 192.168.2.1

www.iktech.net 300 IN A 192.168.3.1

To my knowledge, DNS servers support the following approaches to round-robin-like regimes:[1]

Shuffle— Only one address at any given time from a list of address candidates is presented to the resolver (not possible in BIND, but with commercial load balancers).

SRV records— An added weight integer specifically describes the ordering (weighted DNS RR). This requires application support, however.

Sortlists (Example 12-3)— This refers to sorting of all address pools according to the source address of the querying resolver. For a detailed discussion, consult the BIND documentation at http://www.isc.org/products/BIND/.

Example 12-3. BIND Sortlist

sortlist {

{ localhost;

{ localnets;

192.168.1/24;

{ 192,168.2/24; 192.168.3/24; }; }; };

{ 192.168.1/24;

{ 192.168.1/24;

{ 192.168.2/24; 192.168.3/24; }; }; };

};

Rrset order (Example 12-4)— When a DNS response contains multiple records, it might be useful to configure the order in which the records are placed into the response (shuffle, cyclic round-robin, user-defined).

Example 12-4. BIND Rrset Order

rrset-order {

class IN type A name "www.iktech.net" order random;

order cyclic;

};

An alternative to these server-side approaches is to put the intelligence into the resolver/client application. However, this is difficult to predict and to deploy because resolvers are often part of an application.

If you want to manipulate the amount of traffic a specific round-robin participant receives, you can add alias addresses to the server and add additional entries to the DNS configuration. That's pretty much all you can do to alter the unweighted behavior. Be aware of possible caching issues and nondeterministic behavior and have a client-side sniffer ready to debug the queries and responses.

In closing, note that going one step further to ensure that the receiving server is up and available requires commercial-grade load-balancing solutions such as the Cisco server load balancing (SLB) IOS feature or the Cisco Local Director. Consult Cisco.com for a feature overview.

NOTE

For a flexible load-balancing name server written in Perl, by Roland Schemers, see the resources at http://www.stanford.edu/~riepel/lbnamed/.

Clustering and Distributed Architectures

2008-12-15T10:15:00.000-08:00

The basic idea behind redundant systems and services is to provide at least a second resource that can either take over the duty in a hot-standby fashion or, even better, is a member of a server/service farm that constantly contributes via load-balancing schemes. One step further would distribute such architecture geographically, and that would pretty much define the boundaries (not limits) of such an architecture.

One big advantage of a loosely coupled load-sharing cluster approach is that it is independent of the failure of one component. This approach affects overall cluster performance only to a certain extent, depending on the capacity planning of the cluster architect. One major reason for such deployments is the possibility to schedule maintenance for a cluster constituent without affecting normal operation in high-availability networks.

Historically, clustering is a domain of the (Open)VMS world. OpenVMS is a product of HP after HP bought Compaq and Compaq bought Digital. If you are interested in OpenVMS, look at http://www.openvms.org and Hewlett Packard's web page.

The apex of clustering is a tight integration (virtual supercomputer) of an almost arbitrary number of multiprocessor systems to form a modern cluster under the control of redundant cluster controllers with distributed storage, memory, sockets, and I/O. Examples of such an approach are high-performance clusters (HPC). In contrast, GRID architectures (computing grids) for scientific number crunching such as the well-known SET@Home project (http://setiathome.ssl.berkeley.edu) have evolved, where every home or office workstation contributes to a calculation when idle. A thorough discussion of cluster concepts, such as MOSIX and Beowulf, goes beyond the scope of this book. Nevertheless, the following sections cover three prominent examples of Linux HA approaches.

Linux Virtual Server Project (LVSP)
The LVSP is a scalable and transparent load-balancing architecture based on the Linux operating system. It requires a kernel patch and a user-space administration tool, ipvsadm. The constituent servers of a load-balancing group can be dispersed geographically and still can be Layer 4 controlled by the LVS architecture.

Detection of node or daemon failures and the appropriate reconfiguring of the system lead to high availability. IP-level load balancing offers performance and transparency advantages over application-level solutions such as caches and proxies. The virtual server uses three different load-balancing techniques and a repertoire of scheduling algorithms. The load-balancing techniques are as follows:

Virtual server via NAT— Based on Port Address Translation and port forwarding.

Virtual server via IP tunneling— The virtual server sends requests to physical servers via IP-IP tunnels.

Virtual server via direct routing— The return packets to client requests are routed directly from the real servers without involving the load balancer.

The scheduling algorithms are as follows

Least connection

Weighted least-connection

Round-robin (allocates connections evenly to all real servers)

Weighted round-robin

Locality-based least connection

Locality-based least connection with replication

Destination hashing

Source hashing

For further configuration details and ancillary tools, consult http://www.linuxvirtualserver.org/.

Connection Integrity Issues
Modern director approaches such as LVS support connection-integrity maintenance. Connection integrity refers to the capability of the director to maintain a connection in a way that it never changes the real server after the first scheduling decision has been made based on the initial packets. This is necessary for certain protocols such as Secure Sockets Layer (SSL) and File Transfer Protocol (FTP). This is sometimes referred to as stateful load balancing. Optionally, the connection behavior of a service can be marked persistent. Persistency can be accomplished via manual configuration, whereas connection-integrity tracking works on a per-connection basis with finer granularity.

LVS—Virtual Services
You can configure Linux Director virtual service definition in these ways:

IP address— The virtual IP address of a global service.

TCP/UDP port— The port of a service.

Protocol— For example, HTTPS of FTP.

Linux netfilter/iptables firewall marks— A firewall mark can be matched to virtual services. This adds another level of flexibility and granularity (for example, for persistency setups).

Linux Ultra Monkey
Ultra Monkey is a project to create load-balanced and highly available services on a LAN using open-source components on the Linux operating system. Figure 12-3 describes the entire architecture
Ultra Monkey includes the following key features/components:

Layer 4 switching using the Linux Virtual Server (LVS)

High availability provided by Heartbeat protocol

Service-level monitoring using ldirectord

Supports highly available or load-balanced topologies

Integrates with Super Sparrow

Supports monitoring of HTTP, HTTPS, FTP, IMAP, POP, SMTP, LDAP, and NNTP

IP Address Takeover with Heartbeat
The takeover approach chosen largely depends on topology and effective switchover timer requirements. As a rule of thumb, MAC address takeover works fastest, IP address takeover is a little bit slower, and dynamic DNS reconfiguration takes its time. Heartbeat is an integral part of the Ultra Monkey architecture, based on ARP spoofing/gratuitous ARP for takeover with the help of an additional physical interface or an IP alias.

All Heartbeat protocols are based on the assumption that keepalive messages (hence the name heartbeat) are exchanged between systems. If a message is not received in due time, a failure is assumed and takeover or master node re-election activities are triggered. The useful thing about the heartbeat protocol is that it works over serial links, PPP links, and Ethernet and incorporates aspects of VRRP such as virtual addresses. It is much more cost-effective to use RS232 interfaces instead of committing dedicated, although almost idle, Ethernet NIC resources.

The Service Routing Redundancy Daemon (SRRD)
You have already learned a fair bit about SRRD in Chapter 9, "Dynamic Routing Protocols—Interior Gateway Protocols." For purposes of this discussion, just be aware that SRRD can do without an external heartbeat mechanism and instead just requires Quagga Open Shortest Path First (OSPF) for signaling based on opaque link-state advertisements (LSAs). Undeservedly, this elegant concept is underrepresented in HA architectures. According to http://www.srrd.org, "SRRD is fully configurable over the web and supports SSL and PKI client and server authentication. It implements cluster server features like Service Groups, Service Dependencies, as well as Critical Services."[2]

A Few Words About Content Caches and Proxies

2008-12-15T10:13:00.000-08:00

Content-caching architectures and engines such as in the Cisco product palette deal with the challenge to deliver content reliably, efficiently, and effectively to the network edge and access layer where customers subscribe to certain content. Vice versa, they are necessary to provide sufficiently clustered server farms to feed these requests.

NOTE

Historically, caching was the initial purpose of proxies and proxy chaining. Protection of expensive and rare WAN bandwidth was their prime directive. Today, with cheap bandwidth in abundance, the focus has shifted toward intelligent security, content screening, and load-balancing content and cache-engine architectures. However, these are Layer 4 through 7 issues and not the focus of this chapter. For a background on caching strategies, look at the Internet's most popular open-source proxy, squid, at http://www.squid-cache.org/, and the proxy capabilities of the Apache web server, at http://www.apache.org.

Modern proxies fall in different categories:

Transparent caching proxies

Security (intercepting) proxies

Load-balancing proxies

Mangling proxies (packet rewrites)

Reverse proxies

Cisco HA and Load-Balancing Approaches

2008-12-15T10:08:00.000-08:00

Cisco offers several architectural approaches to high availability, ranging from lower-layer concepts such as resilient packet ring and Multiprotocol Label Switching (MPLS) node protection up to protocol-intrinsic or application layer approaches.

The lower-layer concepts (Layers 1 through 3) are summarized under the Cisco Global Resilient IP Framework (GRIP). This framework consists of the following building blocks:

Stateful NAT (SNAT) for translation groups

IPSec stateful failover (VPN HA in combination with HSRP)

Multicast subsecond convergence

GLBP

Nonstop forwarding with stateful switchover

MPLS fast reroute

Approaches that are relevant to the transport and application layers are discussed briefly in the following two subsections.

Cisco IOS Server Load Balancing (SLB) Feature
The Cisco IOS SLB feature is available for certain Cisco IOS routers and catalyst switches. It provides two load-balancing algorithms: weighted round-robin and weighted least connections. With SLB enabled, a virtual server (VIP) represents a cluster of real servers. Clients are configured to connect to the IP address of the virtual server (directed or dispatched redirection mode). DNS records usually point to the virtual IP address.

The Cisco IOS SLB intelligence picks a real server to satisfy the requesting client based on one of the load-balancing algorithms mentioned earlier. It can perform NAT, provide added security by hiding real servers, and provide rudimentary DoS protection such as maximum connection limits and SYNGuard (SYN flooding protection).

IOS SLB for Layer 3 switches works with HSRP to prevent single points of failure for virtual IP addresses. In contrast to crude round-robin approaches, the cluster constituents provide input into the IP load-balancing device by means of the Dynamic Feedback Protocol (DFP), indicating the level of CPU utilization, application, and user identity. DFP is implemented with workload agents (Windows, UNIX) that reside on IP server platforms. For further configuration information, consult the Cisco.com document "Configuring Server Load Balancing."

Cisco Content Networking Devices and Software
These devices, software and hardware, operate at Layers 4 through 7 and consist of the following products:

Local Director (local traffic distribution)

Network Director

Distributed Director (geographically disperse traffic distribution)

Content engines

Content routers (redirect the user to the most suitable site on a network based on a set of metrics such as delay topology, server load, and a set of policies such as location of content)

Content networking software (carries out the same duty without a dedicated appliance)

The main features of these approaches are caching, intelligent content delivery, traffic distribution, intelligent DNS services, and load balancing.

2008-12-15T09:46:00.000-08:00

VRRP
Gateway redundancy protocols solve the problem of eliminating single points of failure in a LAN environment for clients that require a reliable HA default path and next hop. Provisioning of a default route/multiple routes can, in general, be achieved in various ways:

Dynamic Host Configuration Protocol (DHCP) with default gateway provisioning

Manual default route entry/entries plus load balancing (optional Linux feature)

Dynamic routing protocols on the client workstation

Internet Router Discovery Protocol (IRDP) clients

Virtual Router Redundancy Protocol/Hot Standby Router/Protocol/Gateway Load Balancing Protocol (VRRP/HSRP/GLBP)

The concept of a secondary default route (floating static route) does not work on multi-access networks. The affected workstation has no standardized and reliable way of telling that a particular gateway just went down, and an incomplete ARP entry does not trigger a route removal from the forwarding table. This is implementation-specific and different on point-to-point links with line protocols.

VRRP (RFC 2338) is essentially an election protocol that elects a master from a pool of candidate routers and takes care of associated Layer 3 and Layer 2 virtual and real addresses for resilient LAN forwarding responsibility. The virtual router that is associated with each alternate path under VRRP uses the same IP address and MAC address as the routers for other paths. As a result, the host's gateway information does not change, no matter which path is used. This applies to both the IP and MAC address used for the actual frame delivery.

VRRP is related to the Cisco proprietary and highly successful HSRP and supplemented by GLBP. Look at the Cisco.com document "Virtual Router Redundancy Protocol" for more information. The Cisco implementation requires Cisco IOS Release 12.2(T)or 12.0ST.

CAUTION

HSRP is not compatible with VRRP.

The following sections discuss two implementations of VRRP for UNIX.

VRRPd
VRRPd is a Linux implementation of the Virtual Router Redundancy Protocol originally developed by ImageStream and released to the public as a GNU project.

VRRP's primary design goal is eliminating a single point of failure represented by a next-hop gateway for static LAN routes, often routes of last resort. Figure 12-5 presents the lab layout used for the following configurations. The specification of VRRP was influenced considerably by the Cisco HSRP protocol. In addition to this primary function (next-hop redundancy), RFC 2338 also states that the protocol should

Minimize the duration of black holes.

Minimize the steady-state bandwidth overhead and processing complexity.

Function over a variety of multiaccess LAN technologies that support IP traffic.

Provide for election of multiple virtual routers on a network for load balancing.

Support multiple logical IP subnets on a single LAN segment

OpenBSD CARP
Because of patent issues with VRRP and the Internet Engineering Task Force's (IETF) point of view about patented technology in standards (that is, RAND [reasonable and nondiscriminatory]), the OpenBSD community developed their own redundancy protocol, Common Address Redundancy Protocol (CARP), which was introduced in the OpenBSD 3.5 release. One positive aspect of that architecture is the tight integration with the pf firewall and pf's clustering capabilities via pfsync.

For more information about OpenBSD CARP, look at the CARP man page at http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4. Notable features are ARP-based Layer 2 load-balancing capabilities, support for both IPv4 and IPv6, and hash protection for enhanced protocol security. Example setups are provided at http://www.countersiege.com/docpfsync-carp/.
Freevrrpd
Freevrrpd is part of the HUT Project. A feature overview according to the HUT Project includes the following:

Provides an RFC 2338-compliant daemon

Implements virtual addresses

Supports multiple virtual router IDs (VRIDs)

Enables master state announcement (by sending multicast packets via BPF)

Changes routes and IP in 3 seconds

Performs gratuitous ARP requests to clean the cache of all hosts

Elects from among different slave servers

Allows the same host to be slave and master simultaneously

Automatically downgrades to slave if a master is up again

Provides anti-address-conflict system

Provides multithreaded vrrp daemon

Supports plain-text passwords

Supports netmask for virtual IP address(es)

Simple version of "monitored circuits"

Supports executing master/backup scripts during transition state

Comparison of the VRRP Implementations
Example 12-9 provides a comparison of different VRRP implementations.

Example 12-9. VRRP Lab (Linux VRRPd, CISCO IOS Architecture, and FreeBSD freevrrpd)

scar# show running-config

...

interface ethernet 1/0

ip address 192.168.14.254 255.255.255.0

vrrp 1 priority 50

vrrp 1 ip 192.168.14.10

...

[root@castor:~#] cat /usr/local/etc/freevrrpd.conf

# Each VRID section must begin with [VRID] keyword

[VRID]

# serverid is needed to specify the number of the VRID, here VRID = 1

serverid = 1

# you must set the interface with a real interface name of your system

interface = ed0

# priority = 255 is a MASTER of the VRID

# priority < 255 is a BACKUP with a priority 0 to 254

# 254 is a higher BACKUP priority

priority = 100

# addr option is needed to specify ip address(es) associated with the VRID

# you can specify multiple addresses separated by ','

# netmask is specified with CIDR notation, so numbers after '/' represent the

# number of bits set to 1 for the netmask.

# eg: /24 is 11111111 11111111 11111111 00000000 = 255.255.255.0

addr = 192.168.14.10/24

[root@castor:~#] freevrrpd –f /usr/local/etc/freevrrpd.conf

[root@callisto~#] vrrpd i eth0 –p 255 –v 1 192.168.14.10

IRDP

2008-12-15T09:43:00.000-08:00

The Internet Router Discovery Protocol (IRDP, RFC 1256), sometimes also referred to as the ICMP Router Discovery Protocol, is the ancestor of redundancy concepts such as VRRP or HSRP. It is a timelessly elegant concept that recently has attracted renewed attention because of its essential role in mobile IP deployments (RFC 3344). Extensions to the original protocol were necessary to provide for the requirements of mobile node-to-agent communication.

The IRDP is a protocol based on multicast route discovery ICMP messages. It eliminates the need for manual configuration of router addresses and is independent of any specific routing protocol. Therefore, it supplements a statically configured default router.

The ICMP router discovery messages are called router advertisements and router solicitations. By default, neither router discovery advertisements nor solicitations are sent over point-to-point links (for example, PPP). As the advertisement address, the router defaults to 224.0.0.1 if the router supports IP multicast on the interface; otherwise, 255.255.255.255 is used. Router solicitations are sent to 224.0.0.2. For further information, consult the RFC and the BSD manual page routed(8).

Example 12-10 demonstrates the IRDP featuring advertisements and client solicitations. In the gated example, IRDP server (advertiser) is running on ganymed, the Cisco IOS IRDP server on scar, callisto is listening via rdisc client, and castor is running routed -q "quiet mode" to demonstrate routed's IRDP client behavior; no dynamic routing protocols are running.

The preference statements (as highlighted in Example 12-10) allow weighting of the two available gateways. (This also works with two gateways on the same network.) The server side of the ICMP router discovery protocol is supported by Cisco IOS architecture, routed, and gated and can be tuned with preference statements. The command ip irdp multicast turns off the Cisco default broadcast behavior (also highlighted in Example 12-10).

Note that MRTd and Zebra do not support IRDP currently. Experimental code was added recently to Quagga's Zebra daemon, though. GateD and routed can run in either server or client mode. Linux provides a client implementation with the rdisc(8) tool. As you can see from the configurations and output, ganymed and scar are acting as IRDP advertisers (servers), whereas castor and callisto act as IRDP clients sending IRDP solicitations to trigger responses from candidate IRDP routers on directly connected networks.

Example 12-10. IRDP Server and Client Operation

[root@ganymed:~#] cat /etc/gated.cfg

### IRDP section ###

routerdiscovery server yes{

traceoptions state;

address 192.168.1.254 preference 100 multicast;

};

#routerdiscovery client yes{

# traceoptions state;

# interface ne3 multicast solicit;

#};

icmp{

traceoptions routerdiscovery;

};

[root@castor:~#]routed –q –T /var/log/routed.log

scar# show running-config

...

interface Ethernet1

ip address 192.168.14.254 255.255.255.0

no ip proxy-arp

ip irdp

ip irdp preference 10

ip irdp multicast

no ip route-cache

no ip mroute-cache

media-type 10BaseT

!

interface Ethernet0

ip address 192.168.7.254 255.255.255.0

no ip proxy-arp

ip irdp

ip irdp multicast

ip irdp preference 20

no ip route-cache

no ip mroute-cache

media-type 10BaseT

...

scar(config-if)# ip irdp ?

address addresses to proxy-advertise

holdtime how long a receiver should believe the information

maxadvertinterval maximum time between advertisements

minadvertinterval minimum time between advertisements

multicast advertisements are sent with multicasts

preference preference level for this interface

scar# show ip irdp ethernet 1

Ethernet1 has router discovery enabled

Advertisements will occur between every 450 and 600 seconds.

Advertisements are sent with multicasts.

Advertisements are valid for 1800 seconds.

Default preference will be 10.

[root@callisto:~#] rdisc -vst

Sending solicitation to ALL-ROUTERS.MCAST.NET (224.0.0.2)

ICMP Router Advertise from 192.168.14.254, lifetime 1800

address 192.168.14.254, preference 0xa

ICMP Router Advertise from ganymed (192.168.1.254), lifetime 1800

address ganymed (192.168.1.254), preference 0x64

address 192.168.45.254, preference 0x0

ICMP Router Advertise from 192.168.45.254, lifetime 1800

address ganymed (192.168.1.254), preference 0x64

address 192.168.45.254, preference 0x0

[root@castor:~#]cat /var/log/routed.log

...

turn on Router Discovery client using 192.168.7.254 via ed0

Add 0.0.0.0 -->192.168.7.254 metric=15 ed0

...

[root@callisto:~#] tethereal -i eth0

Capturing on eth0

0.000000 192.168.14.1 -> 224.0.0.2 ICMP Router solicitation

0.001527 192.168.14.254 -> 192.168.14.1 ICMP Router advertisement

...

167.026360 192.168.14.254 -> 224.0.0.1 ICMP Router advertisement

[root@callisto:~#] tethereal –i eth1

0.343388 192.168.1.1 -> 224.0.0.2 ICMP Router solicitation

0.344884 192.168.45.253 -> 224.0.0.2 ICMP Router solicitation

2.360836 192.168.1.254 -> 192.168.1.1 ICMP Router advertisement

2.361085 192.168.45.254 -> 192.168.45.253 ICMP Router advertisement

[root@callisto:~#] netstat -rne

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0

192.168.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

192.168.45.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1

Policy Routing

2008-12-15T09:33:00.001-08:00

Policy Routing

Policy routing is the art of deviating from destination-based shortest-path routing decisions of dynamic routing protocols. Policy routing considers aspects such as source/destination address, ports, protocol, type of service (ToS), and entry interfaces; do not confuse it with a routing policy or traffic policing. Traffic policing and shaping are sometimes summarized as traffic conditioning. Linux offers by far the most evolved policy routing approach of all Unices via multiple routing tables, the Routing Policy Database (RPDB), and the iproute2 (ip and tc) package for administration. Most other UNIX implementations implement policy routing via firewall marks and packet-mangling hooks.

Policy Routing on BSD

Policy-routing setup on BSD platforms is pretty straightforward, limited, and essentially integrated into firewall architectures. Examples 13-1 and 13-2 demonstrate its use by forwarding certain traffic based on source address or incoming interface (highlighted text).

Firewalling, NAT, and policy enforcement are done by basically the same "packet-mangling" structures.

Example 13-1. Policy-Routing Example with FreeBSD ipfilter

pass out quick on fxp0 to fxp1:192.168.2.1 from 192.168.2.200 to any

Example 13-2. Policy-Routing Example with OpenBSD Packet Filter (pf)

pass out log quick on xl0 route-to tl0:192.168.1.1 proto icmp from tl0 to any  pass out log quick on xl0 proto icmp from any to any

Linux iproute2 Policy Routing

The Linux OS can place routes within multiple routing tables that are identified by an 8-bit numeric ID or by a pseudo-name that is mapped in the file /etc/iproute2/rt_tables. By default, three tables exist: the default, the local, and the main (ID 254), as follows:

The default table can be discarded safely. It is reserved for last-resort postprocessing for the unlikely case that previous rules/routing tables did not process the packet.
The important local table (ID 255) consists of routes for local and broadcast addresses (as directly connected interfaces in Cisco lingo). The kernel maintains this table automatically. As a rule of thumb, it should not be tampered with.
By default, all route manipulations act on the main routing table (forwarding table). The RPDB supervises the different routing tables. Policy routing is configured via the ip rule and ip route commands.

Multiple routing tables come into play when policy routing is used, for traffic control and in the context of Multiprotocol Label Switching (MPLS) multiple routing instances (VRFs, or virtual routing and forwarding instances). In policy routing, the routing table identifier becomes one additional criterion capable of handling otherwise-identical prefix routes in different tables that will not conflict because of this tiebreaker mechanism. Example 13-3 illustrates the capabilities of the Linux policy-routing toolbox. Example 13-4 offers an example of a custom policy-routing table.

Example 13-3. Policy-Routing iproute2 Commands

[root@callisto:~#] ip rule help  Usage: ip rule [ list | add | del ] SELECTOR ACTION  SELECTOR := [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark FWMARK ]              [ dev STRING ] [ pref NUMBER ]  ACTION := [ table TABLE_ID ] [ nat ADDRESS ]            [ prohibit | reject | unreachable ]            [ realms [SRCREALM/]DSTREALM ]  TABLE_ID := [ local | main | default | NUMBER ]    [root@callisto:~#] ip rule list  0:      from all lookup local  32766:  from all lookup main  32767:  from all lookup default  [root@callisto:~#] ls -al /etc/iproute2/  total 36  drwxr-xr-x    2 root     root         4096 Aug 28 08:10 ./  drwxr-xr-x   86 root     root         8192 Aug 28 08:03 ../  -rw-r--r--    1 root     root          299 Mar 15  2002 rt_dsfield  -rw-r--r--    1 root     root          296 Mar 15  2002 rt_protos  -rw-r--r--    1 root     root          114 Mar 15  2002 rt_realms  -rw-r--r--    1 root     root           98 Mar 15  2002 rt_scopes  -rw-r--r--    1 root     root           81 Aug 28 08:10 rt_tables    [root@callisto:~#] cat /etc/iproute2/rt_tables  #  # reserved values  #  255     local  254     main  253     default  0       unspec    #  # local values  #  1       lab    [root@callisto:~#] cat /etc/iproute2/rt_scopes  #  # reserved values  #  #0      global  #255    nowhere  #254    host  #253    link    #  # pseudo-reserved  #  #200    site    [root@callisto:~#] ip route help  Usage: ip route { list | flush } SELECTOR         ip route get ADDRESS [ from ADDRESS iif STRING ]                              [ oif STRING ]  [ tos TOS ]         ip route { add | del | change | append | replace | monitor } ROUTE  SELECTOR := [ root PREFIX ] [ match PREFIX ] [ exact PREFIX ]              [ table TABLE_ID ] [ proto RTPROTO ]              [ type TYPE ] [ scope SCOPE ]  ROUTE := NODE_SPEC [ INFO_SPEC ]  NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]               [ table TABLE_ID ] [ proto RTPROTO ]               [ scope SCOPE ] [ metric METRIC ]  INFO_SPEC := NH OPTIONS FLAGS [ nexthop NH ]...  NH := [ via ADDRESS ] [ dev STRING ] [ weight NUMBER ] NHFLAGS  OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ]             [ rtt NUMBER ] [ rttvar NUMBER ]             [ window NUMBER] [ cwnd NUMBER ] [ ssthresh REALM ]             [ realms REALM ]  TYPE := [ unicast | local | broadcast | multicast | throw |            unreachable | prohibit | blackhole | nat ]  TABLE_ID := [ local | main | default | all | NUMBER ]  SCOPE := [ host | link | global | NUMBER ]  FLAGS := [ equalize ]  NHFLAGS := [ onlink | pervasive ]  RTPROTO := [ kernel | boot | static | NUMBER ]    [root@callisto:~#] ip route list table local  local 192.168.1.1 dev eth1  proto kernel  scope host  src 192.168.1.1  local 192.168.45.253 dev eth1  proto kernel  scope host  src 192.168.45.253  broadcast 192.168.1.0 dev eth1  proto kernel  scope link  src 192.168.1.1  broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1  broadcast 192.168.14.255 dev eth0  proto kernel  scope link  src 192.168.14.1  broadcast 192.168.45.255 dev eth1  proto kernel  scope link  src 192.168.45.253  broadcast 192.168.1.255 dev eth1  proto kernel  scope link  src 192.168.1.1  broadcast 192.168.14.0 dev eth0  proto kernel  scope link  src 192.168.14.1  broadcast 192.168.45.0 dev eth1  proto kernel  scope link  src 192.168.45.253  local 192.168.14.1 dev eth0  proto kernel  scope host  src 192.168.14.1  broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1  local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1  local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1    [root@callisto:~#] ip route list table main  192.168.1.0/24 dev eth1  scope link  192.168.14.0/24 dev eth0  scope link  192.168.45.0/24 dev eth1  proto kernel  scope link  src 192.168.45.253  127.0.0.0/8 dev lo  scope link  default via 192.168.1.254 dev eth1    [root@callisto:~#] ip route list table main scope link  192.168.1.0/24 dev eth1  192.168.14.0/24 dev eth0  192.168.45.0/24 dev eth1  proto kernel  src 192.168.45.253  127.0.0.0/8 dev lo

Example 13-4. Creating and Populating a Custom Routing Table

[root@callisto:~#] echo 1 lab >> /etc/iproute2/rt_tables  [root@callisto:~#] echo 1 lab >> /etc/iproute2/rt_realms  [root@callisto:~#] ip rule del pref 32767  [root@callisto:~#] ip rule add from 192.168.14.0/24 to 192.168.7.0/24 table lab pref                      32765 realms lab/lab    [root@callisto:~#] ip rule list  0:      from all lookup local  32765:  from 192.168.14.0/24 to 192.168.7.0/24 lookup lab realms lab/lab  32766:  from all lookup main  [root@callisto:~#] ip route add default via 192.168.14.254 table lab    [root@callisto:~#] ip route flush cache    [root@callisto:~#] ip route list table lab  default via 192.168.14.254 dev eth0    [root@callisto:~#] rtacct lab  Realm      BytesTo    PktsTo     BytesFrom  PktsFrom  lab        0          0          0          0

Linux routing also incorporates the concept of realms. A routing realm essentially can be compared to a route aggregate in Border Gateway Protocol (BGP) lingo; however, it is a grouping based on human logic and not necessarily on bitmasks. Realms often are used for tracking, traffic control, and packet path-accounting purposes that can be inspected via the rtacct utility. Realms are demonstrated in Example 13-4, too. Each route can be assigned to a realm either dynamically by a routing daemon or statically via the REALM option of the ip route command. I am aware of a patched version of GateD with patches from Alexej Kuznetsov that can classify prefixes to realms and can handle multiple Linux routing table IDs. For a concise discussion of realms and scope, check out the original writings of Alexej Kuznetsov, the creator of the iproute2 toolbox, at http://www.policyrouting.org/.

Cisco IOS Policy-Routing Example

Policy-based routing (PBR) enables you to classify traffic based on extended access list criteria or assign the traffic to different service classes via an IP precedence setting. Consult the Cisco.com article "Configuring Policy-Based Routing" for further information. Example 13-5 demonstrates the use of policy route maps to achieve this goal.

Example 13-5. Cisco IOS Policy Route Map for Different Next Hops and Priority

...  !  access-list 1 permit ip 192.168.1.1  access-list 2 permit ip 192.168.2.1  !  interface ethernet 1   ip policy route-map LAB  !  route-map LAB permit 10   match ip address 1   set ip precedence priority   set ip next-hop 192.168.3.1  !  route-map LAB permit 20   match ip address 2   set ip precedence critical   set ip next-hop 192.168.3.2  !  ...

Traffic Shaping, Queuing, Reservation, and Scheduling

2008-12-15T09:32:00.000-08:00

Queuing works only for packets in the outbound (egress) direction. The only viable way to improve this situation is to enable bidirectional queuing on adjacent routers—for example, by configuring committed access rate (CAR)/rate limits on Cisco IOS architecture. Adjacency essentially means connected via point-to-point links or Ethernet crossover links. When no other queuing regimes are activated, almost all stack implementations resort to default first-in/first-out (FIFO) behavior.

The actual tasks involved in traffic shaping and implementing QoS include reserving resources, buffering, and scheduling behind the scenes. The choice of a queuing discipline is tricky, depending on the load on a link, and requires a thorough understanding of the internal workings of the queuing mechanism.

Queuing disciplines are a classical area of academic and applied research and go beyond the scope of this book. They are essentially procedures or measures that influence the way data is sent, delayed, and queued. You will find excellent resources for further information about queuing in the "Recommended Reading" section at the end of this chapter.

Queuing disciplines essentially come in two flavors: classless queuing disciplines (no subdivision granularity; reschedule, delay, or drop on a flat scale) and classful (class-context) queuing disciplines. The most popular queuing regimes are as follows:

CBQ— Class-based queuing
RED— Random early detection
WFQ— Weighted fair queuing
PRIQ— Priority queuing

Permanently saturated links require other strategies than bursty traffic patterns. Nothing really prevents permanently overburdened queues and interface buffers from dropping datagrams/frames. Proactively dealing with that problem is the art of congestion avoidance/management. Queuing is an integral part of the IP stack and forwarding engine and, therefore, the responsibility of the kernel. User-space utilities for administration complement the implementations. Shaping serves two purposes: limiting available bandwidth, and smoothing the use of virtual pipes.

Traffic conditioning is the art of dealing with incoming (ingress) traffic via a policer or shaper. A policer just enforces a rate limit, whereas a shaper smoothes the traffic flow to a specified rate by the use of buffers. Standard mechanisms of the Cisco IOS architecture are CAR, generic traffic shaping (GTS), and Frame Relay traffic shaping (FRTS).

Linux QoS

2008-12-15T09:31:00.001-08:00

Linux provides a powerful and feature-rich subsystem for traffic control (traffic shaping, queuing disciplines, classification, prioritizing, sharing, filter chains), of both ingress and egress traffic. You configure such by having multiple sets of routing tables (iproute2) and by using the tc tool.

The main application of realms is in conjunction with the tc route classifier, where they help assign packets to traffic classes for accounting, policing, and scheduling. The tc tool handles these tasks:

Setup of queuing disciplines (QDISC) such as CBQ, RED, and SFQ
Setup of parent and child classes for classful queuing
Flexible filtering of classful queuing disciplines
Combinations of all these features

You also can shape inbound via the ingress option of the tc utility. It is up to you to decide whether inbound policing makes sense. Examples 13-6 through 13-10 demonstrate classless QDISCs.

Note that Example 13-6 facilitates a simple token-bucket filter (TBF) applied to interface eth0 (highlighted text), with certain parameters that influence shaping and allow short bursts while reacting with delays and drops to lasting overload conditions. In the current implementation, tokens correspond to bytes, not packets. A similar effect is achieved via a shaper device attached to eth0 in Example 13-7.

NOTE

For more details on TBF and an in-depth discussion of classful and classless queuing disciplines, see the "Linux Advanced Routing & Traffic Control HOWTO," especially for generic RED, weighted RED, and weighted round-robin (WRR).

Example 13-6. Interface Shaping with a TBF

[root@callisto:~#] tc qdisc add dev eth0 root tbf rate 220kbit latency 50ms burst 1540



[root@callisto:~#] tc -d qdisc

qdisc tbf 8001: dev eth0 rate 220Kbit burst 1539b/8 mpu 0b lat 61.0ms



[root@callisto:~#] tc -s qdisc

qdisc tbf 8001: dev eth0 rate 220Kbit burst 1539b lat 61.0ms

Sent 425 bytes 5 pkts (dropped 0, overlimits 0)

Example 13-7. Alternative Interface Shaping with the Shaper Device

[root@callisto:~#] insmod shaper

Using /lib/modules/2.4.21/kernel/drivers/net/shaper.o



[root@callisto:~#] shapecfg -?

shapecfg attach  

shapecfg speed  



[root@callisto:~#] shapecfg attach shaper0 eth0



[root@callisto:~#] shapecfg speed shaper0 2000000



[root@callisto:~#] ifconfig shaper0 192.168.80.1 netmask 255.255.255.0 up



[root@callisto:~#] ifconfig -a

eth0      Link encap:Ethernet  HWaddr 00:10:5A:D7:93:60

         inet addr:192.168.14.1  Bcast:192.168.14.255  Mask:255.255.255.0

         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

         RX packets:0 errors:0 dropped:0 overruns:0 frame:0

         TX packets:476 errors:0 dropped:0 overruns:0 carrier:0

         collisions:0 txqueuelen:100

         RX bytes:0 (0.0 b)  TX bytes:53487 (52.2 Kb)

         Interrupt:5 Base address:0xd800



eth1      Link encap:Ethernet  HWaddr 52:54:05:E3:51:87

         inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0

         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

         RX packets:19895 errors:0 dropped:0 overruns:0 frame:0

         TX packets:14777 errors:0 dropped:0 overruns:0 carrier:0

         collisions:43 txqueuelen:100

         RX bytes:5879639 (5.6 Mb)  TX bytes:1302730 (1.2 Mb)

         Interrupt:9 Base address:0xd400



eth1:1    Link encap:Ethernet  HWaddr 52:54:05:E3:51:87

         inet addr:192.168.45.253  Bcast:192.168.45.255  Mask:255.255.255.0

         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

         Interrupt:9 Base address:0xd400



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:72 errors:0 dropped:0 overruns:0 frame:0

         TX packets:72 errors:0 dropped:0 overruns:0 carrier:0

         collisions:0 txqueuelen:0

         RX bytes:5416 (5.2 Kb)  TX bytes:5416 (5.2 Kb)



shaper0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00

         inet addr:192.168.80.1  Mask:255.255.255.0

         UP RUNNING  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:10

         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Stochastic fair queuing (SFQ), as shown in Example 13-8, represents an "almost" fair queuing mechanism with reduced calculation burden. It helps on saturated links to distribute utilization in a fair way among sessions.

Example 13-8. Stochastic Fair Queuing

[root@callisto:~#] tc qdisc add dev eth0 root sfq perturb 10 quantum 2



[root@callisto:~#] tc -s -d qdisc list

qdisc sfq 8003: dev eth0 quantum 2b limit 128p flows 128/1024 perturb 10sec

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

Example 13-9. pFIFO-Fast

[root@callisto:~#] tc qdisc add dev eth0 root pfifo limit 200k



[root@callisto:~#] tc -s -d qdisc list

qdisc pfifo 8004: dev eth0 limit 204800p

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

Example 13-10. Random Early Detect/Discard with Explicit Congestion Notification

[root@callisto:~#] tc qdisc add dev eth0 root red limit 100 min 80 max 90 avpkt 10 burst

 10 probability 1 bandwidth 200 ecn



[root@callisto:~#] tc -s -d qdisc list

qdisc red 8006: dev eth0 limit 100b min 80b max 90b ecn ewma 2 Plog 4 Scell_log 17

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

 marked 0 early 0 pdrop 0 other 0

In contrast to the previous examples, Example 13-11 offers a variant of classful queuing (priority queuing) in combination with filter chains. Class-based queuing (CBQ) is a huge field that is covered exhaustively in the HOWTO.

Example 13-11. Priority Queuing (PRIQ)

[root@callisto:~#] tc qdisc add dev eth0 root handle 1: prio



[root@callisto:~#] tc -s -d qdisc

qdisc prio 1: dev eth0 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Sent 1097 bytes 5 pkts (dropped 0, overlimits 0)



[root@callisto:~#] tc qdisc add dev eth0 parent 1:1 handle 10: sfq



[root@callisto:~#] tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600

 limit 3000



[root@callisto:~#] tc qdisc add dev eth0 parent 1:3 handle 30: sfq



[root@callisto:~#] tc -s -d qdisc

qdisc sfq 30: dev eth0 quantum 1514b limit 128p flows 128/1024

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

qdisc tbf 20: dev eth0 rate 20Kbit burst 1599b/8 mpu 0b lat 667.6ms

Sent 85 bytes 1 pkts (dropped 0, overlimits 0)



qdisc sfq 10: dev eth0 quantum 1514b limit 128p flows 128/1024

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)



qdisc prio 1: dev eth0 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Sent 1182 bytes 6 pkts (dropped 0, overlimits 0)



[root@callisto:~#] tc -s -d qdisc list dev eth0

qdisc sfq 30: quantum 1514b limit 128p flows 128/1024

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)



qdisc tbf 20: rate 20Kbit burst 1599b/8 mpu 0b lat 667.6ms

Sent 85 bytes 1 pkts (dropped 0, overlimits 0)



qdisc sfq 10: quantum 1514b limit 128p flows 128/1024

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)



qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Sent 1182 bytes 6 pkts (dropped 0, overlimits 0)



[root@callisto:~#] tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport

 22 0xffff flowid 1:1



[root@callisto:~#] tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip sport

 80 0xffff flowid 1:1

[root@callisto:~#] tc -s -d filter list dev eth0

filter parent 1: protocol ip pref 1 u32

filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1

filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0   flowid 1

:1 match 00000016/0000ffff at 20

filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0   flowid 1

:1 match 00500000/ffff0000 at 20

Layer 3 QoS: IP ToS, Precedence, CoS, IntServ, and DiffServ Codepoints

2008-12-15T09:29:00.000-08:00

QoS definitions vary by service and approach chosen. For data communication networks, typical QoS characteristics and metrics include bandwidth, delay (latency), delay variation (jitter), and reliability, as follows:

Bandwidth— Peak data rate (PDR), sustained data rate (SDR), minimum data rate (MDR).
Delay/latency— End-to-end or round-trip delay, delay variation (jitter), node-processing delay.
Reliability— Availability (as percent of uptime), mean time between failures/mean time to repair (MTBF/MTTR), errors, and packet loss.

The IP header contains a Type of Service (ToS) field (see Example 13-12). Applications can set the three precedence bits of this ToS field at the network interface card (NIC) level according to their requirements.

Example 13-12. IPv4 Header with ToS Field

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  | Version |  IHL  | Type of Service |          Total Length     |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |         Identification         | Flags |      Fragment Offset |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |  Time to Live |    Protocol   |         Header Checksum       |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |                       Source Address                          |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |                    Destination Address                        |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |                    Options                     |    Padding   |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the context of IP QoS considerations, a 3-bit field in the ToS byte of the IP header is referred to as precedence (see Example 13-13). Using IP precedence, a network administrator can assign values from 0 (the default) to 7 to classify and prioritize types of traffic.

Example 13-13. ToS and Precedence

       0     1     2     3     4     5     6     7

     +-----+-----+-----+-----+-----+-----+-----+-----+

     |                 |     |           |     |     |

     |    PRECEDENCE   | STRM|RELIABILITY| S/R |SPEED|

     |                 |     |           |     |     |

     +-----+-----+-----+-----+-----+-----+-----+-----+

Many applications and routers support IP precedence. The ToS and differentiated services (DiffServ) approach directly tag the traffic itself, which therefore contains in-band QoS markings. An out-band approach is the Resource Reservation Protocol (RSVP). An integrated services (IntServ) approach provides end-to-end QoS in IP networks and relies on per-flow state information and integration with RSVP as a signaling protocol at every involved hop. (IntServ is considered to have some weaknesses.)

DiffServ takes a simpler approach with less signaling overhead and no QoS-aware intermediate network nodes for the entire path. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path (RFC 2475). The DiffServ (DS) field is supposed to succeed the IPv4 ToS field in the IPv4 header, which is deprecated and in IPv6 context "rejuvenated" as the traffic-class octet (see Example 13-14).

NOTE

For DiffServ internals, see RFC 2474, "Definition of Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers."

Example 13-14. DiffServ Codepoints

The DS field structure is presented below (RFC 2474):



       0   1   2   3   4   5   6   7

     +---+---+---+---+---+---+---+---+

     |         DSCP          |  CU   |

     +---+---+---+---+---+---+---+---+



       DSCP: Differentiated services codepoint

       CU:   Currently unused (reserved)

Note that when you are dealing with DiffServ, two expressions are used frequently: PHB (per-hop behavior) and DSCP (DiffServ codepoint). In current architectures, IP precedence values are mapped into DSCPs

802.1P/Q Tagging/Priority—QoS at the Data-Link/MAC Sublayer

802.1P provides for eight traffic classes drawn from priority fields in 802.1Q VLAN tags. The IEEE 802.1P standard describes important methods for providing QoS at the MAC level and defines traffic-class expediting (3 bits) and dynamic-multicast filtering to ensure traffic does not traverse the boundaries of Layer 2-switched networks.

NOTE

Both 802.1P and 802.1Q are part of 802.1D.

Most vendors support 802.1P/Q in their Layer 2/3 equipment and modern NICs. This means that QoS tagging is pushed out to the network edge down to the NIC level. However, privileged treatment of these frames still is best effort in Layer 2-switched networks and does not involve reservation setup. The 3 priority bits can be mapped easily into the Layer 3 IP precedence bits or a subset of DSCPs. Therefore, we have coherent tagging, which is easy to implement. The remaining question—and there exists no uniform approach—is how to implement queuing for these priority flows at Layer 2 and Layer 3.

There is no 802.1P without 802.1Q VLAN tagging. The VLAN tag carries VLAN information—the VLAN ID (12 bits) and prioritization (3 bits). The Prioritization field was never defined in the VLAN standard, so 802.1P steps in and actually brings it to life. This effort defines a 32-bit tag header that is inserted after a frame's normal destination and source address header info. Switches, routers, servers, and even desktop systems can set these priority bits.

802.1Q priority is supported only rudimentary on UNIX. Linux vconfig can set these bits (see Example 13-15). Whether this works depends on the 802.1Q VLAN implementation of the OS.

Example 13-15. 802.1Q Priority Setting on Linux

[root@callisto:~#] vconfig add eth0 1

[root@callisto:~#] vconfig set_egress_map eth0.1 8

[root@callisto:~#] ifconfig –a

...

eth0.1    Link encap:Ethernet  HWaddr 00:10:5A:D7:93:60

         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:0

         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

...

[root@callisto:~#] cat /proc/net/vlan/eth0.1

eth0.1  VID: 1   REORDER_HDR: 1  dev->priv_flags: 1

total frames received:            0

total bytes received:             0

Broadcast/Multicast Rcvd:         0

total frames transmitted:         0

total bytes transmitted:          0

total headroom inc:               0

total encap on xmit:              0

Device: eth0

INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0

EGRESSS priority Mappings: 8:0

MPLS Exp Field and MPLS Traffic Engineering

2008-12-15T09:28:00.000-08:00

The 3-bit MPLS Exp field (see Example 13-16) of the MPLS shim header (Layer 2 label-insertion header) can support eight different service classes (CoS, or class of service); thus DiffServ edge marking can be carried over.

Example 13-16. MPLS Label Stack Entry

The label stack is represented as a sequence of "label stack entries." Each label stack

 entry is represented by 4 octets. The label stack entries appear after the data link layer

 headers, but before any network layer headers. The top of the label stack appears earliest

 in the packet, and the bottom appears latest. The network layer packet immediately follows

 the label stack entry, which has the S bit set. (RFC 3032, "MPLS Label Stack Encoding")

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label

|                 Label                 | Exp |S|      TTL      | Stack

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry



                   Label:  Label Value, 20 bits

                   Exp:    Experimental Use, 3 bits

                   S:      Bottom of Stack, 1 bit

                   TTL:    Time To Live, 8 bits

This mechanism adds QoS to MPLS label-switched paths (LSPs). Integrated MPLS and DiffServ architectures are state-of-the art and the subject of active research and standard development. In addition, from a phenomenological point of view, CoS maps nicely into the MPLS concept of forwarding equivalence classes (FECs). FECs are a concept of treating equivalent traffic the same generic way.

MPLS uses RSVP-TE (traffic engineering) and Constraint-based Label-Distribution Protocol (CR-LDP) for special-purpose signaling. According to the recent Internet Engineering Task Force (IETF) activities, it looks as if RSVP-TE has won the race. There is a lot of work going on in the DiffServ/MPLS-TE integration area, too. This appears to be the only viable approach to the scalability problem that ISPs and carriers face when dealing with flows and service classes.

NOTE

For further information, consult the "Quality of Service" white paper at Cisco.com.

You can find more information about UNIX MPLS activities at the following website:

DiffServ and RSVP/RSVP-TE Implementations for UNIX

2008-12-15T09:26:00.000-08:00

It appears that the most active work in this area is done in the context of integrating DiffServ, RSVP-TE, Open Shortest Path First traffic engineering (OSPF-TE), and MPLS/LDP implementations, mostly on Linux platforms. The main Linux DiffServ resource is http://diffserv.sourceforge.net/. I am aware of two RSVP packages available at http://www.isi.edu/div7/rsvp/rsvp.html and http://www.kom.e-technik.tu-darmstadt.de/rsvp/.

Cisco IOS QoS and Queuing Architectures

The Cisco QoS architecture has evolved quite significantly over time with a strong foundation in (distributed [D]) CAR, (CB) WFQ, PRIQ, custom queuing, WRED, and the new D-WRED. It has evolved into a complete architecture that incorporates the capabilities of Frame Relay (discard eligibility [DE]) and ATM (cell loss priority [CLP]); IP to ATM CoS; in addition to 802.1P/Q marking, IntServ/RSVP and DiffServ, and a strong focus on MPLS-TE and MPLS QoS.

As in most IP stacks, FIFO queuing is the default behavior. Because of lab constraints, I am unable to present labs with 802.1P/Q, DiffServ, and advanced features here.

Recently, AutoQoS was added to the Cisco portfolio, which essentially covers the following in a more proactive way:

QoS classification and marking
QoS configuration and monitoring
QoS congestion avoidance
QoS congestion management
QoS link-efficiency mechanisms
QoS policing and shaping
QoS signaling
ATM/Frame Relay QoS
LAN switching QoS

UNIX Firewalling Engines and Queuing

2008-12-15T09:24:00.000-08:00

In the UNIX world, traffic conditioning, policy routing, and shaping are tied closely to the packet filters available for the different platforms, forming conceptual pairs such as packet filter/ALTQ (Alternate Queuing), ipfirewall/dummynet, or iptables/tc. The reason for this design is simple: Packet filters already provide the necessary hooks within the forwarding engine of the IP network stack.

On Linux, the relationship between netfilter/iptables and the iproute2 package (ip/tc/rtmon) constitutes a firewall-marking and packet-mangling symbiosis to build sophisticated QoS routers. Packet mangling (manipulation) is the altering of certain bits of the IP header—for example, the ToS field or DSCP.

Table 13-1 shows an overview of the platform availability of these components. Figure 13-1 shows the lab layout for the following subsections.

OpenBSD ALTQ+pf

Packet filter (pf) is OpenBSD's stateful-inspection firewall system, packet filter, and NAT engine. It has been ported to NetBSD and FreeBSD recently. pf also is capable of normalizing and conditioning TCP/IP traffic and providing bandwidth control and packet prioritization via ALTQ. The ALTQ system is a framework to manage queuing disciplines on network interfaces.

Starting with OpenBSD 3.3, ALTQ has been integrated into pf (http://www.benzedrine.cx/pf.html). OpenBSD's ALTQ implementation supports CBQ and PRIQ schedulers (see Examples 13-17 and 13-18). It also supports RED and explicit congestion notification (ECN). The /etc/pf.conf file is the only relevant configuration file (pf.conf(5), pf(4), pfctl(8), pflogd(8), ftp-proxy(8)).

Example 13-17. OpenBSD pf/ALTQ PRIQ Example

[root@europa:~#] cat /etc/pf.conf

#

# Queuing: rule-based bandwidth control

#

# PRIQ Example

altq on xl0 bandwidth 2Mb priq queue {dflt engineering testlab}

queue dflt priority 7 qlimit 50 priq(default red ecn)

queue engineering priority 6 qlimit 50 priq(red ecn)

queue testlab priority 5 qlimit 50 priq(rio ecn)



# Filtering:

pass in log all

pass out on xl0 proto tcp from any to any port 22 queue dflt

pass out on xl0 proto icmp from any to any queue testlab

pass out on xl0 from 172.16.0.0/16 to any queue engineering

pass out log all



[root@europa:~#] pfctl -s queue -v

queue dflt priority 7 priq( red ecn default )

[ pkts:        468  bytes:      47560  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

queue engineering priority 6 priq( red ecn )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

queue testlab priority 5 priq( red ecn rio )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]



[root@europa:~#] pfctl -s queue -v -v

queue dflt priority 7 priq( red ecn default )

[ pkts:        495  bytes:      50376  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

queue engineering priority 6 priq( red ecn )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

queue testlab priority 5 priq( red ecn rio )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]



queue dflt priority 7 priq( red ecn default )

[ pkts:        511  bytes:      52212  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

[ measured:     3.2 packets/s, 2.93Kb/s ]

queue engineering priority 6 priq( red ecn )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

[ measured:     0.0 packets/s, 0 b/s ]

queue testlab priority 5 priq( red ecn rio )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

[ measured:     0.0 packets/s, 0 b/s ]



queue dflt priority 7 priq( red ecn default )

[ pkts:        532  bytes:      54538  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

[ measured:     4.2 packets/s, 3.71Kb/s ]

queue engineering priority 6 priq( red ecn )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

[ measured:     0.0 packets/s, 0 b/s ]

queue testlab priority 5 priq( red ecn rio )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50 ]

[ measured:     0.0 packets/s, 0 b/s ]



[root@europa:~#] pfctl -s rules -v

scrub in all random-id fragment reassemble

[ Evaluations: 2979      Packets: 1482      Bytes: 0           States: 0     ]



pass in log all

[ Evaluations: 1536      Packets: 759       Bytes: 64806       States: 0     ]



pass out on xl0 proto tcp from any to any port = ssh queue dflt

[ Evaluations: 1539      Packets: 0         Bytes: 0           States: 0     ]



pass out on xl0 proto icmp all queue testlab

[ Evaluations: 783       Packets: 0         Bytes: 0           States: 0     ]



pass out on xl0 inet from 172.16.0.0/16 to any queue engineering

[ Evaluations: 786       Packets: 0         Bytes: 0           States: 0     ]



pass out log all

[ Evaluations: 789       Packets: 789       Bytes: 73176       States: 0     ]

Example 13-18. OpenBSD pf/ALTQ CBQ Example

[root@europa:~#] cat /etc/pf.conf

#

# Queuing: rule-based bandwidth control

#

# CBQ Example

altq on xl0 bandwidth 2Mb cbq queue {dflt engineering testlab}

queue dflt bandwidth 50% priority 7 qlimit 50 cbq(default red ecn)

queue engineering priority 6 bandwidth 30% qlimit 50 cbq(red ecn borrow)

queue testlab priority 5 bandwidth 20% qlimit 50 cbq(red ecn)



# Filtering

pass in log all

pass out on xl0 proto tcp from any to any port 22 queue dflt

pass out on xl0 proto icmp from any to any queue testlab

pass out on xl0 from 172.16.0.0/16 to any queue engineering

pass out log all



[root@europa:~#] pfctl -s queue -v

queue root_xl0 bandwidth 2Mb priority 0 cbq( wrr root ) {dflt, engineering, testlab}

[ pkts:         25  bytes:       2256  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

queue  dflt bandwidth 1Mb priority 7 cbq( red ecn default )

[ pkts:         25  bytes:       2256  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

queue  engineering bandwidth 600Kb priority 6 cbq( red ecn borrow )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

queue  testlab bandwidth 400Kb priority 5 cbq( red ecn )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]



[root@europa:~#] pfctl -s queue -v -v

queue root_xl0 bandwidth 2Mb priority 0 cbq( wrr root ) {dflt, engineering, testlab}

[ pkts:         60  bytes:       6010  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

queue  dflt bandwidth 1Mb priority 7 cbq( red ecn default )

[ pkts:         60  bytes:       6010  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

queue  engineering bandwidth 600Kb priority 6 cbq( red ecn borrow )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

queue  testlab bandwidth 400Kb priority 5 cbq( red ecn )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]



queue root_xl0 bandwidth 2Mb priority 0 cbq( wrr root ) {dflt, engineering, testlab}

[ pkts:         80  bytes:       8454  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

[ measured:     4.0 packets/s, 3.90Kb/s ]

queue  dflt bandwidth 1Mb priority 7 cbq( red ecn default )

[ pkts:         80  bytes:       8454  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

[ measured:     4.0 packets/s, 3.90Kb/s ]



queue  engineering bandwidth 600Kb priority 6 cbq( red ecn borrow )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

[ measured:     0.0 packets/s, 0 b/s ]

queue  testlab bandwidth 400Kb priority 5 cbq( red ecn )

[ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]

[ qlength:   0/ 50  borrows:      0  suspends:      0 ]

[ measured:     0.0 packets/s, 0 b/s ]



[root@europa:~#] pfctl -s rules -v

scrub in all random-id fragment reassemble

[ Evaluations: 584       Packets: 287       Bytes: 0           States: 0     ]



pass in log all

[ Evaluations: 10        Packets: 5         Bytes: 380         States: 0     ]



pass out on xl0 proto tcp from any to any port = ssh queue dflt

[ Evaluations: 10        Packets: 0         Bytes: 0           States: 0     ]



pass out on xl0 proto icmp all queue testlab

[ Evaluations: 5         Packets: 0         Bytes: 0           States: 0     ]



pass out on xl0 inet from 172.16.0.0/16 to any queue engineering

[ Evaluations: 5         Packets: 0         Bytes: 0           States: 0     ]



pass out log all

[ Evaluations: 5         Packets: 5         Bytes: 380         States: 0     ]

FreeBSD ipfilter+ALTQ

In contrast to OpenBSD pf, ipfilter and ALTQ do not form an integrated architecture. ALTQ does not natively ship with FreeBSD; it is now part of the KAME Project (http://www.kame.net/). The original web page is located at http://www.csl.sony.co.jp/~kjc/software.html#ALTQ.

ALTQ is concerned with queuing disciplines and resource-sharing QoS approaches. Remember, a queuing discipline controls outgoing traffic only. It provides stubs for RSVP and DiffServ support and enforces the following queuing regimes:

CBQ— Class-based queuing
HFSC— The hierarchical fair service curve algorithm for Link sharing, real-time, and priority service
JoBS— Joint buffer management and scheduling algorithm
RED— Random early detection
RIO— RED with in/out
Blue— A queue-management algorithm focusing on eliminating packet loss in congestion situations (an alternative to RED)
WFQ— Weighted fair queuing
PRIQ— Priority queuing

CBQ, HFSC, and RED are the most mature and recommended approaches. Relevant management tools and man pages are as follows:

tbrconfig(8)— Configure a token-bucket regulator for an output queue
altq(9)— Kernel interfaces for manipulating output queues on network interfaces
altq.conf(5)— ALTQ configuration file for altqd(8)
altqd(8)— The ALTQ daemon
altqstat(1)— Show ALTQ status
pf.conf(5)— Packet filter configuration file
pfctl(8)— Control the packet filter (PF) and NAT device

You can use the ALTQ token-bucket regulator to rate-limit an interface (see Example 13-19).

Example 13-19. Interface Rate-Limiting Without Queuing Discipline

[root@castor:~#] tbrconfig ed0 30M auto

       ed00: tokenrate 30.00M(bps)  bucketsize 36.62K(bytes)



[root@castor:~#] tbrconfig -d ed0

       deleted token bucket regulator on ed0

FreeBSD IP Firewall(ipfw) + dummynet

FreeBSD's ipfw(4) is the utility that is responsible for controlling the ipfirewall(4) and dummynet(4) system facilities. ipfirewall is used for filtering, redirection, accounting, and NAT, whereas dummynet is a flexible bandwidth manager and delay emulator for traffic shaping and networking protocol testing on the FreeBSD operating system. dummynet supports a variant of WFQ and can be used on any type of workstation or gateway acting as either a router or bridge (see Example 13-20). For a detailed introduction, check out the following excellent man pages: divert(4), ipfirewall(4), ipfw(4), ipfw-graph(8), ipfw-al(1).

Example 13-20. Traffic Shaping on a Crossover-Link FreeBSD with RED and WF2Q+ <--> Cisco IOS Architecture with CAR/GTS and RED on the Cisco Side

[root@castor:~#] ipfw add pipe 1 icmp from any to any out xmit ed0

[root@castor:~#] ipfw pipe 1 config bw 8Kbit/s queue 10 delay 10ms red

[root@castor:~#] ipfw queue 1 config pipe 1 weight 1 red



[root@castor:~#] ping 192.168.7.254

PING 192.168.7.254 (192.168.7.254): 56 data bytes

64 bytes from 192.168.7.254: icmp_seq=0 ttl=255 time=94.281 ms

64 bytes from 192.168.7.254: icmp_seq=1 ttl=255 time=95.006 ms

64 bytes from 192.168.7.254: icmp_seq=2 ttl=255 time=95.030 ms

64 bytes from 192.168.7.254: icmp_seq=3 ttl=255 time=95.002 ms



scar# show running-config

...

!

interface Ethernet0

bandwidth 10000

ip address 192.168.14.254 255.255.255.0

media-type 10BaseT

random-detect

traffic-shape rate 8000 8000 8000 1000

!

interface Ethernet1

ip address 192.168.7.254 255.255.255.0

rate-limit output 8000 1500 2000 conform-action transmit exceed-action drop

media-type 10BaseT

random-detect

!...



scar# show traffic-shape ethernet 0



Interface   Et0

      Access Target    Byte   Sustain   Excess    Interval  Increment Adapt

VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active

-             8000      2000   8000      8000      1000      1000      -



scar# show traffic-shape statistics ethernet 0

                 Access Queue   Packets   Bytes     Packets   Bytes     Shaping

I/F               List   Depth                       Delayed   Delayed   Active

Et0                      0       351       32902     0         0         no



scar# show int ethernet 1 rate-limit

Ethernet1

 Output

   matches: all traffic

     params:  8000 bps, 1500 limit, 2000 extended limit

     conformed 340 packets, 33320 bytes; action: transmit

     exceeded 0 packets, 0 bytes; action: drop

     last packet: 940ms ago, current burst: 0 bytes

     last cleared 00:12:30 ago, conformed 0 bps, exceeded 0 bps

scar# ping 192.168.7.7


Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.7.7, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 108/112/116 ms
dummynet works in symbiosis with ipfw by "intercepting packets  and passing them through one or more objects called queues and pipes, which  simulate the effects of bandwidth limitations, propagation delays, bounded-size  queues, packet losses, and multipath."^[1]

Pipes represent fixed-bandwidth channels that can contain one or multiple queues. Think of a pipe as analogous to ATM virtual paths (VPs) and virtual channels (VCs). You can control the utilization and, as a consequence, the proportional bandwidth share of a pipe by associating queues with a weight.

Linux Firewall Marking and iproute2 (ip/tc)

netfilter and iptables are elements of the firewalling, NAT/NAPT, policy router, and packet-mangling architecture for the 2.4.x and 2.6.x Linux kernels. netfilter and iptables(8) allow marking and tagging of a packet with a number via the --set-mark facility. This is a mark of local significance only (packet metadata) and does not alter the IP header after forwarding. This mark can assign a different routing table (routing policy), as demonstrated in Example 13-21.

Example 13-21. Policy Routing Based on iptables Markings

[root@callisto:~#] iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 25 -j MARK

 --set-mark 1

[root@callisto:~#] echo 1 lab >> /etc/iproute2/rt_tables

[root@callisto:~#] ip rule add fwmark 1 table lab

[root@callisto:~#] ip rule list

0:     from all lookup local

32764: from all fwmark        1 lookup lab

32766: from all lookup main

32767: from all lookup default



[root@callisto:~#] ip route add default via 192.168.14.254 table lab

Bell Labs' Eclipse—An Operating System with QoS Support

The Eclipse operating system (http://www.bell-labs.com/project/eclipse/release/) is a QoS test platform from Lucent Technologies. It is an independent OS approach that is compatible with FreeBSD and provides a simple application-programming interface (API) for fine-grained QoS support.

Multicast Architectures

2008-12-15T09:22:00.000-08:00

In contrast to my original intention, I have decided not to just offer some hints about multicast architecture, but also to offer a quick qualitative introduction to UNIX multicast issues, routing, MBONE tunneling, and multicast-monitoring and -debugging techniques. I hope this provides just enough of a teaser to put things into perspective and to encourage you to play with intradomain multicast issues and eventually create enough interest that you seek out additional interdomain details. Three example applications are used to demonstrate multicasting:

nte (a network text editor)
ntpd (Network Time Protocol) in multicast mode
mtest (send and receive)

Multicast Deployments

Multicast is one-to-many (1:n) or many-to-many (n:m) source-to-sink data delivery for multicast applications over multicast-enabled transport networks and data link layers. The most obvious reason for multicast deployments is bandwidth and server resource conservation with regard to efficient content distribution. That can be summarized as efficient and scalable multicasting, instead of costly unicast services, by simultaneously delivering a single stream of information to thousands of subscribers or recipients.

This potential is especially interesting as an additional mechanism in modern converged networks with regard to videoconferencing, video on demand, Internet audio, interactive gaming, multimedia events, e-learning software distribution, newscasts, and content delivery. Converged networks transport voice, video, data, and storage traffic over multipurpose IP networks. This variety of applications spans multimedia and data-only uses with or without real-time (latency, jitter) and high-availability requirements. The following discussion separates multicasting into data link layer, network layer, and application layer multicasting. Because of its intrinsically connectionless mode of operation, multicast uses User Datagram Protocol (UDP) as its transport protocol. Occasionally, raw IP sockets are used. These are exceptions to the common UDP rule.

Multicasting essentially can be seen from both intradomain and interdomain points of view, similar to intra-and interdomain traditional unicast routing. An in-depth discussion of multiprotocol (multicast) BGP used for interdomain signaling goes beyond the scope of this book. Note that we have to abandon a client/server perception when discussing multicasting and think instead in terms of content sources, transport networks, and sinks. Another important aspect is the distribution of multicast sinks (group subscribers), which can be either dense or sparse. Some algorithms have proven more suitable for the former, and some others for the latter. As a rule of thumb, dense distributions correlate with LANs or small campus networks, whereas metropolitan networks or the global Internet show a sparse distribution of multicast participants. The purpose of multicast signaling protocols is to build efficient multicast distribution trees for each multicast group of subscribers and not to burden routers and links with group traffic when no associated recipients exist. The process of adding and removing branches to this tree is referred to as grafting and pruning.

Multicasting is easy to configure, but its foundation is quite complex, especially the interface between intra and interdomain multicasting. Therefore, I recommend extensive research before deploying multicast architectures.

NOTE

Currently we face a "hen and egg" problem: Internet service providers (ISPs) complain about the lack of multicast applications to make multicast service offerings commercially feasible, and application developers counter with the lack of multicast-enabled autonomous systems and interdomain multicast deployments. However, one thing is certain: Conventional unicast streams cause a horrible waste of network and server resources.

Multicast Addresses and Scope

2008-12-15T09:19:00.000-08:00

On a single LAN segment, you need to map multicast groups to special MAC addresses for proper delivery to a network interface card (NIC). You accomplish this by mapping the least significant 23 bits of the multicast IP address into the least significant 23 bits of the Ethernet MAC address. In addition, all multicast MAC addresses start with the leading sequence 01:00:5E. For example, the multicast MAC address for RIPv2 routers (224.0.0.9) is represented as 01:00:5E:00:00:09.

Every address in the 224.0.0.0/4 Class D aggregate is referred to as multicast group. This is similar to FF:FF:FF:FF:FF:FF representing a subnet broadcast. This Class D address space is organized as presented in Table 14-1. However, from a modern classless point of view, you should avoid referring to "Class D" addresses.

Table 14-1. Important Multicast Address Ranges
Class	Range
Reserved link-local addresses	224.0.0.0/24
Globally scoped addresses	224.0.1.0–238.255.255.255
Source-specific multicast (SSM)	232.0.0.0/8
GLOP addresses	233.0.0.0/8
Limited-scope addresses	239.0.0.0/8

GLOP integrates the autonomous system number (ASN) of a domain into the second and third octet of the 233.x.x.0/8 prefix to accomplish uniqueness for interdomain multicast routing. Relevant additional resources include the following:

RFC 3180/RFC 3138, "GLOP"
RFC 2365, "Administrative Scoped Multicast"
RFC 3171, "IANA Guidelines for IPv4 Multicast Address Assignments"
"Source-Specific Protocol Independent Multicast in 232/8," draft-ietf-mboned-ssm232-06.txt
"IPv4 Multicast Unusable Group And Source Addresses," draft-ietf-mboned-ipv4-mcast-unusable-01.txt

It is particularly interesting to ping the group address 224.0.0.1 (all multicast hosts on this subnet) and 224.0.0.2 (all multicast routers on this subnet) to figure out which hosts are multicast enabled on your LAN or act as multicast routers. For a complete list, see the Internet Assigned Numbers Authority (IANA) Internet multicast address summary at http://www.iana.org/assignments/multicast-addresses.

Some important multicast group addresses of the reserved local control block are printed in Table 14-2. Most likely, you will find a couple of familiar addresses. No multicast router—regardless of its Time To Live (TTL)—should ever forward IP datagrams with these destination addresses. Hence the name local scope.

Table 14-2. Important Reserved Local Multicast Group Addresses (Local Network Control Block, Local Scope Only)
Address	Multicast Group Assignment
224.0.0.0	Base address (reserved)
224.0.0.1	All systems on this subnet
224.0.0.2	All routers on this subnet
224.0.0.3	Unassigned
224.0.0.4	DVMRP routers
224.0.0.5	All OSPF routers
224.0.0.6	All OSPF designated routers
224.0.0.7	Internet Stream Protocol V2+ (ST2+) routers
224.0.0.8	Internet Stream Protocol V2+ (ST2+) hosts/agents
224.0.0.9	RIPv2 routers
224.0.0.10	IGRP routers
224.0.0.11	Mobile agents
224.0.0.12	DHCP server/relay agent
224.0.0.13	All PIM routers
224.0.0.18	VRRP
224.0.0.102	HSRP

NOTE

It is necessary to set net.inet.icmp.bmcastecho to 1 on BSD systems for pings to multicast groups to succeed. Either add this entry to /etc/sysctl.conf or set it manually by typing sysctl -w net.inet.icmp.bmcastecho=1.

Administratively Scoped IP Multicast

Scoping is the art of limiting multicast traffic distribution to certain administrative boundaries defined by boundary routers capable of per-interface scoped IP multicast configurations and filters (RFC 2365). Historically, TTL scoping (topological scoping) has been used to control the distribution of multicast traffic, especially within the multicast backbone (MBONE). However, TTL scoping negatively impacts Distance Vector Multicast Routing Protocol (DVMRP) pruning efficiency.

The administratively scoped IPv4 multicast address space is defined as 239.0.0.0/8. Scoped addresses are required to be unique only within administrative boundaries. According to RFC 2365, "The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL is greater than the threshold."

Cisco boundary filters can be configured with the ip multicast boundary {ACL} interface command. mrouted scope examples are provided with the manual page and default configuration file; the setup is straightforward.

The Multicast Protocol Cocktail

An entire zoo of protocols is related to multicast and can be divided into intra- and interdomain multicast protocols.

The intradomain multicast protocols are as follows:

DVMRP— Distance Vector Multicast Routing Protocol, RFC 1075
PIM-SM/PIM-DM— Protocol Independent Multicast Sparse/Dense Mode, RFC 2362
IGMPv1/v2/v3— Internet Group Management Protocol, RFCs 2236 and 3376
CGMP— Cisco (proprietary) Group Management Protocol
MOSPF— Multicast OSPF, RFCs 1584 and 1585
CBTv2/v3— Core-Based Tree Multicast Protocol, RFC 2189
RGMP— Router-Port Group Management Protocol (IETF draft)
SDP— Session Directory Protocol
PGM— Pragmatic General Multicast, RFC 3208
MLD— Multicast Listener Discovery Protocol, RFC 3590

The interdomain multicast protocols are as follows:

MBGP— Multiprotocol BGP, a.k.a. "Multicast" BGP
MSDP— Multicast Source Discovery Protocol, RFC 3618
BGMP— Border Gateway Multicast Protocol, draft-ietf-bgmp-spec-05.txt

Although these really are a lot of standards and protocols, do not be intimidated. Although they all serve specific and structured purposes, this chapter deals only with IGMP, DVMRP, and PIM-DM/PIM-SM. These protocols are presented in a LAN context in Figure 14-1.

There exists a clear differentiation between multicast signaling information and actual data forwarding (reverse-path forwarding to be precise). Some approaches rely on their own signaling (mrouted), whereas others require additional unicast routing information (for example, PIM). For an excellent introduction to these protocols, consult the Cisco.com article "Configuring IP Multicast Routing."

Internet Group Management Protocol (IGMP) and Cisco Group Management Protocol (CGMP)

2008-12-15T09:18:00.000-08:00

By design, a conventional Layer 2 LAN switch is supposed to flood multicast and broadcast traffic within the broadcast domain (VLAN). This results in wasted resources when no recipients of multicast traffic are present on its physical ports, uplinks, or VLAN trunks.

In a switched network, you can restrain multicast traffic in two ways:

IGMP snooping— This is a feature of modern Layer 2/3 switches.
CGMP— CGMP is used on Cisco Layer 2 switches.

Availability depends greatly on the model and OS version of your Cisco equipment. I am not aware of any noncommercial UNIX implementations that implement IGMP snooping. (It only makes sense on switches.) Cisco IOS architecture defaults to IGMPv2, whereas Linux and BSD operating systems implement IGMPv1/v2 (with early IGMPv3 packages available).

IGMPv1 Operation

The purpose of IGMP is to report end-system application group memberships to multicast routers in its vicinity, which easily can be identified via 224.0.0.2. The protocol has evolved from v1 up to v3.

IGMPv1 works as follows: When a host joins a particular group for the first time, it sends an unsolicited group membership report to the relevant group address. In addition, multicast routers periodically submit IGMP query messages to 224.0.0.1 that trigger IGMP group membership reports from all multicast-enabled hosts. IGMP protocol packets are always sent with a TTL of 1 and are not supposed to be forwarded. If a router does not hear from a registered host for a while, it assumes the host has left the group. If the requesting router receives no reports, the group is removed ("pruned") from the distribution tree. Therefore, this concept is referred to as flood and prune.

NOTE

On Linux systems, you can alter the default IGMP group membership limit of 20 via the net.ipv4.igmp_max_memberships sysctl parameter.

IGMPv2 Operation

IGMPv2 offers an important improvement over IGMPv1: explicit leave_group_messages that reduce the timeout-based leave group latency of IGMPv1 from several minutes to a few seconds, which dramatically reduces traffic on busy network segments. Join latencies are of no concern in this picture. Hosts send explicit leave_group_messages to 224.0.0.2 when they want to leave a subscribed group immediately. Examples 14-1 and 14-2 demonstrate IGMP-relevant commands and their output for Linux and BSD. The highlighted text emphasizes the mapping between multicast IP and MAC addresses.

Example 14-1. Linux IGMP Status Information

[root@callisto:~#] netstat -g

IPv6/IPv4 Group Memberships

Interface       RefCnt Group

--------------- ------ ---------------------

lo              1      ALL-SYSTEMS.MCAST.NET

eth0            1      ALL-ROUTERS.MCAST.NET

eth0            1      DVMRP.MCAST.NET

eth0            1      ALL-SYSTEMS.MCAST.NET

eth1            1      224.2.2.2

eth1            1      ALL-ROUTERS.MCAST.NET

eth1            1      DVMRP.MCAST.NET

eth1            1      NTP.MCAST.NET

eth1            1      ALL-SYSTEMS.MCAST.NET



[root@callisto:~#] netstat -gn

IPv6/IPv4 Group Memberships

Interface       RefCnt Group

--------------- ------ ---------------------

lo              1      224.0.0.1

eth0            1      224.0.0.2

eth0            1      224.0.0.4

eth0            1      224.0.0.1

eth1            1      224.2.2.2

eth1            1      224.0.0.2

eth1            1      224.0.0.4

eth1            1      224.0.1.1

eth1            1      224.0.0.1



[root@callisto:~#] ip mroute

(192.168.2.7, 224.2.2.2)         Iif: eth1       Oifs: eth0

(192.168.1.2, 224.2.2.2)         Iif: eth1       Oifs: eth0

(192.168.1.1, 224.2.2.2)         Iif: eth1       Oifs: eth0

(192.168.1.1, 224.0.1.1)         Iif: eth1



[root@callisto:~#] ip maddr

1:      lo



       inet  224.0.0.1

2:      eth0

       link  01:00:5e:00:00:02

       link  01:00:5e:00:00:04

       link  01:00:5e:00:00:01

       inet  224.0.0.2

       inet  224.0.0.4

       inet  224.0.0.1

3:      eth1

       link  01:00:5e:02:02:02

       link  01:00:5e:00:00:02

       link  01:00:5e:00:00:04

       link  01:00:5e:00:01:01

       link  01:00:5e:00:00:01

       inet  224.2.2.2

       inet  224.0.0.2

       inet  224.0.0.4

       inet  224.0.1.1

       inet  224.0.0.1

Example 14-2. BSD IGMP Status Information

[root@castor:~#]  netstat –g –f inet



Virtual Interface Table

Vif   Thresh   Rate   Local-Address   Remote-Address    Pkts-In   Pkts-Out

 0         1      0   192.168.2.7                          1373       5237

 1         1      0   192.168.7.7                          1007       5174

 2         1      0   192.168.80.1                            0          0



IPv4 Multicast Forwarding Cache

Origin          Group             Packets In-Vif  Out-Vifs:Ttls

192.168.2.7     224.2.2.2            4230    0    1:1

192.168.1.1     224.2.2.2            2347    0    1:1



[root@castor:~#]  netstat -gs -f inet

IPv4 multicast forwarding:

       7898 multicast forwarding cache lookups

       3 multicast forwarding cache misses

       3 upcalls to mrouted

       0 upcall queue overflows

       0 upcalls dropped due to full socket buffer

       0 cache cleanups

       3 datagrams with no route for origin

       0 datagrams arrived with bad tunneling

       0 datagrams could not be tunneled

       1006 datagrams arrived on wrong interface

       0 datagrams selectively dropped

       0 datagrams dropped due to queue overflow

       0 datagrams dropped for being too large

IGMPv3 Implementations

IGMPv3 allows joining a specific group with the addition of source-specific granularity, via source-specific include/exclude reports (S,G). This is the reason why it is often mentioned in an SSM context (single-source multicast). When a multicast router receives an IGMPv3 (S,G) join report, it must be able to build the source-specific tree with a source-aware multicast routing protocol such as PIM-SM. The IGMPv2 leave group message was extended to support source-specific operation.

If you want to play with it on Linux, try the Cisco implementation at http://www.multicasttech.com/igmpv3/ or http://www-sop.inria.fr/planete/Hitoshi.Asaeda/igmpv3/ for NetBSD, or http://www.kloosterhof.com/~wilbert/igmpv3.html for FreeBSD.

Cisco IOS Multicast Router Configuration and IGMP/CGMP Operation

Example 14-3 shows the Cisco IOS configuration that enables scar to communicate with mrouted DVMRP gateways via the PIM-DVMRP compatibility mechanism. In addition, the configuration includes an example DVMRP tunnel setup to communicate with ganymed regardless of possible non-multicast-capable gateways in its topological path. The ip igmp join-group 224.2.2.2 statement is just an example of manual IGMP configuration. IGMP-relevant show and debug sequences conclude Example 14.3.

Example 14-3. Cisco IOS General Multicast Setup and IGMP Configuration

scar# show running-config

...

!

ip multicast-routing

ip multicast route-limit 100

!

interface Loopback0

ip address 10.0.0.1 255.255.255.255

!

interface Tunnel0

ip unnumbered Loopback0

ip pim sparse-dense-mode

ip igmp join-group 224.2.2.2

tunnel source 192.168.14.254

tunnel destination 192.168.1.254

tunnel mode dvmrp

!

interface Ethernet0

bandwidth 10000

ip address 192.168.7.254 255.255.255.0

no ip proxy-arp

ip pim sparse-dense-mode

ip load-sharing per-packet

no ip route-cache

ip igmp join-group 224.2.2.2

ip cgmp

no ip mroute-cache

media-type 10BaseT

random-detect

!

interface Ethernet1

bandwidth 10000

ip address 192.168.14.254 255.255.255.0

no ip proxy-arp

ip pim sparse-dense-mode

ip load-sharing per-packet

no ip route-cache

ip ospf network broadcast

ip igmp join-group 224.2.2.2

ip cgmp

no ip mroute-cache

media-type 10BaseT

random-detect

!

...



scar# show ip igmp groups

IGMP Connected Group Membership

Group Address    Interface                Uptime    Expires   Last Reporter

224.0.1.111      Ethernet0                00:16:51  00:01:09  192.168.7.254

224.0.1.40       Ethernet0                00:16:49  00:01:05  192.168.7.254

224.2.2.2        Ethernet1                00:16:51  00:02:02  192.168.14.254

224.2.2.2        Ethernet0                00:16:51  00:01:02  192.168.7.254

224.2.2.2        Tunnel0                  00:16:51  stopped   0.0.0.0



scar# debug ip igmp

IGMP debugging is on

01:11:01: IGMP: Send v2 general Query on Ethernet1

01:11:01: IGMP: Set report delay time to 5.6 seconds for 224.0.1.40 on Ethernet1

01:11:07: IGMP: Send v2 Report for 224.0.1.40 on Ethernet1

01:11:07: IGMP: Received v2 Report on Ethernet1 from 192.168.14.254 for 224.0.1.40

01:11:07: IGMP: Received Group record for group 224.0.1.40, mode 2 from 192.168.14.254 for

 0 sources

01:11:07: IGMP: Updating EXCLUDE group timer for 224.0.1.40

01:11:30: IGMP: Previous querier for Ethernet0 has timed out.

01:11:30: IGMP: v2 querier for Ethernet0 is this system.

01:11:30: IGMP: Send v2 init Query on Ethernet0



scar# show ip igmp interface tunnel 0

Tunnel0 is up, line protocol is up

 Interface is unnumbered. Using address of Loopback0 (10.0.0.1)

 IGMP is enabled on interface

 Current IGMP host version is 2

 Current IGMP router version is 2

 IGMP query interval is 60 seconds

 IGMP querier timeout is 120 seconds

 IGMP max query response time is 10 seconds

 Last member query count is 2

 Last member query response interval is 1000 ms

 Inbound IGMP access group is not set

 IGMP activity: 1 joins, 0 leaves

 Multicast routing is enabled on interface

 Multicast TTL threshold is 0

 IGMP querying router is 0.0.0.0 (this system)

 DVMRP/mrouted neighbors present for 00:27:02

    [version mrouted 3.255] [flags: GPM]

 2 DVMRP neighbor up transitions since system restart

 6 DVMRP routes + 0 poison-reverse routes received in last 00:01:00

 2/4 Unicast/DVMRP routes last advertised by DVMRP

 DVMRP output report delay is 100 ms, with burst size of 2

 Multicast groups joined by this system (number of users):

     224.2.2.2(1)



scar# show ip igmp interface ethernet 0

Ethernet0 is up, line protocol is up

 Internet address is 192.168.7.254/24

 IGMP is enabled on interface

 Current IGMP host version is 2

 Current IGMP router version is 2

 CGMP is enabled on interface

 IGMP query interval is 60 seconds

 IGMP querier timeout is 120 seconds

 IGMP max query response time is 10 seconds

 Last member query count is 2

 Last member query response interval is 1000 ms

 Inbound IGMP access group is not set

 IGMP activity: 2 joins, 0 leaves

 Multicast routing is enabled on interface

 Multicast TTL threshold is 0

 Multicast designated router (DR) is 192.168.7.254 (this system)

 IGMP querying router is 192.168.7.7

 DVMRP/mrouted neighbors present for 02:27:24

 DVMRP interface ordinal mask: FFFFFFFD

 DVMRP neighbors:

   192.168.7.7, ordinal: 1, [version mrouted 3.255] [flags: GPM]

 1 DVMRP neighbor up transitions since system restart

 0 DVMRP routes + 0 poison-reverse routes received in last 00:00:02

 2/4 Unicast/DVMRP routes last advertised by DVMRP

 DVMRP output report delay is 100 ms, with burst size of 2

 Multicast groups joined by this system (number of users):

     224.0.1.40(1)  224.2.2.2(1)



scar# show ip interface ethernet 0

Ethernet0 is up, line protocol is up

 Internet address is 192.168.7.254/24

 Broadcast address is 255.255.255.255

 Address determined by non-volatile memory

 MTU is 1500 bytes

 Helper address is not set

 Directed broadcast forwarding is disabled

 Multicast reserved groups joined: 224.0.0.1 224.0.0.2 224.0.0.22 224.0.0.13

 Outgoing access list is not set

 Inbound  access list is not set

 Proxy ARP is disabled

 Security level is default

 Split horizon is enabled

 ICMP redirects are always sent

 ICMP unreachables are always sent

 ICMP mask replies are never sent

 IP fast switching is disabled

 IP fast switching on the same interface is disabled

 IP Flow switching is disabled

 IP CEF switching is disabled

 IP Fast switching turbo vector

 IP multicast fast switching is disabled

 IP multicast distributed fast switching is disabled

 IP route-cache flags are No CEF

 Router Discovery is enabled

 IP output packet accounting is disabled

 IP access violation accounting is disabled

 TCP/IP header compression is disabled

 RTP/IP header compression is disabled

 Probe proxy name replies are disabled

 Policy routing is disabled

 Network address translation is disabled

 WCCP Redirect outbound is disabled

 WCCP Redirect inbound is disabled

 WCCP Redirect exclude is disabled

 BGP Policy Mapping is disabled

 IP multicast multilayer switching is disabled

Cisco Group Management Protocol (CGMP)

Cisco CGMP runs between Cisco switches and Cisco routers and limits the forwarding of IP multicast packets to only those switch ports that serve IP multicast recipients. These hosts automatically join and leave groups that receive IP multicast traffic, and the switch dynamically changes its forwarding behavior according to these requests after consulting the subnet's/VLAN's router via CGMP. In contrast to IGMP snooping, the switch does not need to provide its own intelligence to intercept IGMP, but instead relies on the intelligence of Cisco multicast routers. CGMP can be configured per router interface with the ip cgmp command. There are no router show commands available for CGMP; however, debug ip cgmp provides sufficient details. CGMP leave processing is a new feature of this protocol that uses the leave group message extension of IGMPv2.

The Cisco IOS Multicast Routing Monitor (MRM)

The MRM feature is a Cisco IOS component that is useful for multicast deployments and surveillance. MRM consists of three components, which usually reside on three different routers:

Manager
Test sender
Test receiver

A detailed discussion of this versatile tool goes beyond the scope of this chapter. Consult the Cisco.com article "Using IP Multicast Tools" (IOS 12.2) for a detailed discussion