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:
- IPv6
- Cryptographic authentication
- TE extensions
- Mesh groups
Lab 9-8: IS-IS Flat Backbone Area
IS-IS is currently available only at an early stage as an extension to the Zebra/Quagga package, not as production-grade yet. The configurations in Example 9-26 are provided without the usual accompanying routing table output because of the early development stage of the Zebra isisd. Redistribution is not yet implemented, and neither is passive interfaces or autosummary.
In contrast to Cisco IOS Zebra, isisd does not support ECMP. The clns routing statement on Cisco routers is automatically added by Cisco IOS Software and can be safely removed for plain IP operation (no clns routing).
Note that three static alias names were added to the Cisco IOS configuration for demonstration purposes only. The router tagging DEAD is optional under Cisco IOS Software, but it is mandatory under Zebra isisd right now. The Cisco IOS maximum-paths 6 statement configures ECMP for up to six equal-cost paths.
Example 9-26. Configuring an IS-IS Backbone Area
castor-isisd# sh running-config Current configuration: ! hostname castor-isisd password zebra enable password zebra log file /var/log/isisd.log ! interface ed0 ip router isis DEAD ip address 192.168.7.7/24 interface xl0 interface lp0 interface sl0 interface sl1 interface ds0 interface stf0 interface faith0 interface vlan0 interface vlan1 interface lo0 interface ppp0 interface ppp1 interface vlan8 ! router isis DEAD net 49.0001.1921.6800.7007.00 metric-style wide ! line vty ! end callisto-isisd# sh running-config Current configuration: ! hostname callisto-isisd password zebra enable password zebra log file /var/log/isisd.log ! interface eth0 ip router isis DEAD ip address 192.168.14.1/24 interface lo interface eth1 interface ipsec0 interface ipsec1 interface ipsec2 interface ipsec3 interface eth1:1 ! router isis DEAD net 49.0001.1921.6801.4001.00 metric-style wide ! line vty ! end scar# sh running-config ... clns routing ! interface Loopback0 ip address 192.168.201.2 255.255.255.255 ! interface Ethernet0 ip address 192.168.14.254 255.255.255.0 ip router isis DEAD ip load-sharing per-packet no ip mroute-cache ! interface Ethernet1 ip address 192.168.7.254 255.255.255.0 ip router isis DEAD ip load-sharing per-packet no ip mroute-cache ! router isis DEAD redistribute connected redistribute static ip passive-interface Serial0 passive-interface Serial1 maximum-paths 6 default-information originate net 49.0001.1921.6820.1002.00 metric-style wide log-adjacency-changes ! clns host castor 49.0001.1921.6800.7007.00 clns host callisto 49.0001.1921.6801.4001.00 clns host laurel 49.0001.1921.6820.1002.00 ! ...
Lab 9-9: IS-IS Backbone and Leaf Area
As mentioned, IS-IS directly uses Layer 2, not IP, for protocol communication. The sniffer trace in Example 9-27 verifies this statement.
Example 9-27. Sniffing IS-IS Traffic
[root@callisto:~#] tethereal -V -i eth0
Frame 2 (1514 bytes on wire, 1514 bytes captured)
Arrival Time: Feb 4, 2003 14:31:44.653860000
Time delta from previous packet: 0.005838000 seconds
Time relative to first packet: 0.005838000 seconds
Frame Number: 2
Packet Length: 1514 bytes
Capture Length: 1514 bytes
IEEE 802.3 Ethernet
Destination: 01:80:c2:00:00:15 (ISIS-all-level-2-IS's)
Source: 00:e0:b0:6a:69:7e (Cisco_6a:69:7e)
Length: 1500
Logical-Link Control
DSAP: ISO Network Layer (0xfe)
IG Bit: Individual
SSAP: ISO Network Layer (0xfe)
CR Bit: Command
Control field: U, func = UI (0x03)
000. 00.. = Unnumbered Information
.... ..11 = Unnumbered frame
ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
Intra Domain Routing Protocol Discriminator: ISIS (0x83)
PDU Header Length : 27
Version (==1) : 1
System ID Length : 0
PDU Type : L2 HELLO (R:000)
Version2 (==1) : 1
Reserved (==0) : 0
Max.AREAs: (0==3) : 0
ISIS HELLO
Circuit type : Level 1 and 2, reserved(0x00 == 0)
System-ID {Sender of PDU} : 1921.6820.1002
Holding timer : 10
PDU length : 1497
Priority : 64, reserved(0x00 == 0)
System-ID {Designated IS} : 1921.6820.1002.01
Protocols Supported (1)
NLPID(s): IP (0xcc)
Area address(es) (4)
Area address (3): 49.0001
IP Interface address(es) (4)
IPv4 interface address : 192.168.14.254 (192.168.14.254)
Padding (255)
Padding (255)
Padding (255)
Padding (255)
Padding (255)
Padding (168)
Now we will put callisto in a different area. The only change necessary to assign callisto to area 2 as well is demonstrated in Example 9-28. Remember that the only factor that constitutes a backbone is a contiguous assembly of Layer 2 intermediate systems.
Example 9-28. IS-IS Area Configuration
callisto-isisd# configure terminal callisto-isisd(config)# router isis DEAD callisto-isisd(config)# net 49.0002.1921.6801.4001.00
Lab 9-10: OSPF Point-to-Point Lab
For this special setup, we combine the topologies of Figure 9-3 and Figure 4-1 (see Chapter 4, "Gateway WAN/Metro Interfaces") to include a point-to-point link between callisto and castor featuring Cisco HDLC as a Layer 2 line protocol. This point-to-point link is assigned to the backbone OSPF area.
The configuration and output of Examples 9-29 and 9-30 focus on callisto and castor. The highlighted configuration emphasizes the point-to-point configuration aspect and the /30 link network added to the OSPF router configuration.
Example 9-29. Castor OSPF Configuration with Point-to-Point Link
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 ! interface wpachdlc0 ip ospf network point-to-point ! 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 network 192.168.99.0/30 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-30. Callisto OSPF Configuration with Point-to-Point Link
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 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 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 0 0 ! end
Exercise 9-4: Dynamic Routing in Point-to-Multipoint Scenarios
Connect several WAN NICs to a router with Frame Relay switching enabled. Configure a point-to-multipoint (hub-and-spoke) topology with the hub injecting a default route into the Frame Relay network.
Advanced OSPF FeaturesThis section introduces traffic-engineering (TE) extensions to OSPF, opaque LSA types, and a specialty of the Quagga OSPF implementation: the OSPF application programming interface (API).
Traffic-Engineering Extensions
The issue of TE extensions to link-state routing protocols has largely been driven by enthusiastic adoption of the MPLS paradigm. Nowadays, TE extensions are strongly related to MPLS-TE.
To be able to set up LSPs (MPLS label-switched paths) to forward similar traffic belonging to forwarding equivalence classes (FECs), traditional link information stored in an LSDB has proven inadequate and insufficient. Therefore, TE extensions were developed for OSPF and IS-IS, which led to the notion of OSPF-TE and IS-IS (TE). The extended TE topology (link bandwidth and administrative constraints) results in the population of a separate TE-LSDB and the deployment of the extended CSPF (constrained SPF) algorithm for computation. TE introduces additional issues and difficulties at area boundaries as well as increased computation burden on OSPF nodes.
Opaque LSAs
The vehicles used to accommodate the new sets of information discussed in the previous section are opaque LSAs (LSA Type 9,10,11) for OSPF (RFC 2370) and sub-TLVs for IS-IS, which serve the same purpose. This topological knowledge forms the basis for two signaling alternatives, CR-LDP and RSVP-TE, to establish end-to-end unidirectional TE circuits (LSPs in MPLS notation).
The preceding explanation of opaque LSAs is extremely high level, but it is enough to put things into perspective and to sufficiently understand why there exists an MPLS-TE feature for the Zebra ospfd. Early versions of RSVP-TE, CR-LDP, and LDP exist for Linux and some other open-source operating systems. There exist similarities as well as fundamental differences to policy routing approaches.
Opaque LSAs per se are a flexible and generic vehicle to disseminate arbitrary information by flooding mechanisms, because the payload information contained in these LSA types is completely transparent for the OSPF routing process. According to RFC 2370, "The link-state type field of the opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the flooding scope." These LSAs can be picked up and processed by other modules such as MPLS-TE or dedicated applications such as SRRD (Service Routing Redundancy daemon).
Quagga's Implementation
Quagga's OSPF implementation is flexible and supports both opaque LSAs and OSPF-TE. The capability opaque configuration statement in the ospfd router configuration section indicates this. In addition, the OSPF LSDB of the OSPF daemon can be accessed via a generic interface, the OSPF API.
Besides LSDB access, the API allows origination and dissemination of opaque LSAs and hence provides an interface to arbitrary payload information contained within opaque LSAs. Figure 9-4 demonstrates the architecture (courtesy of Dr. Ralph Keller of the Swiss Federal Institute of Technology). The OSPF API itself consists of a client and server module and is capable of dealing with concurrent client requests. It can retrieve and originate opaque LSAs.
The SRRD uses the opaque LSAs to manage cluster resources based on proven OSPF signaling concepts and timers in contrast to conventional unicast or multicast heartbeat approaches or proprietary cluster management. This results in failover times of less than 30 seconds and significantly improves availability of multi-interface nodes, because a cluster constituent is available as long as one of its interfaces is reachable, thanks to OSPF.
According to my correspondence with SRRD's author, Amir Guindehi, "SRRD uses opaque LSAs for service discovery (member service), service selection, as well as service state and configuration flooding. It then creates service routes by conventional means (interface aliases plus OSPF host routes) using these for service routing to the active node."[3] Therefore, the cluster nodes can be distributed over an entire OSPF domain and even span WANs, which greatly improves redundancy in terms of single-site disasters. This is an especially intriguing concept if OSPF is your choice of IGP anyway; just enable opaque LSAs in Quagga at compile time. Cisco IOS Software supports opaque LSAs as well.
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
