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.
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
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).
Busines
Hiburan
6:52 AM
Cable Access (Ethernet Interfaces)
6:35 AM
DSL Access
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)
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)
6:33 AM
Route Cloning
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
Related Topic Router
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
6:30 AM
Floating Static Routes
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.
6:22 AM
Classification of Dynamic Routing Protocols
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.
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.
6:07 AM
Introduction to Link-State Routing Protocols
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.
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.
6:00 AM
OSPFv2
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.
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.
5:58 AM
Route Filtering and Redistribution
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
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
5:55 AM
OSPF Authentication
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
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
5:47 AM
IS-IS (Intermediate System-to-Intermediate System)
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
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
Subscribe to:
Posts (Atom)
