Previous Page
Next Page

IPv6 Interior Gateway Protocols

Every modern IPv4 IGP has either an IPv6 version counterpart or an extension that enables it to support IPv6. The following subsections review the four IGPs available on Cisco routers: RIPng, EIGRP for IPv6, OSPFv3, and IS-IS for IPv6.

Routing Information Protocol next-generation

RIP is a simple protocol in the distance vector family. That means it is simple to understand and configure, but it also means it does have some limitations. The main ones are convergence times and scaling. RIPng is basically RIP version 2 (RFC 2453) extended to handle IPv6 prefixes and next hops.

Support for IPv6

The IPv6 version of RIP is described in RFC 2080. It is called RIPng (RIP next generation); this reflects the code name used for the next-generation IP protocol.

It has been argued that RIP should be left to "Rest In Peace." Because it is an easy protocol to implement, it was the first protocol to be supported by vendors, and therefore it saw some deployment in the early days of IPv6. Now that OSPF and IS-IS are supported, RIP is used in small deployments (for example, in a multihomed host or to pass on a default route from an ISP to a customer's CPE).

There is not much new and exciting about RIPng. It supports split horizon and poison reverse as its IPv4 counterpart. It has the same limitations, such as a maximum hop count of 15, and does counting to infinity for certain routing loops.

The differences between RIP (used for IPv4) and RIPng are as follows:

  • In IPv4, RIP runs per subnet. Two neighboring routers need to be a part of the same IPv4 subnet to exchange routes. Because IPv6 neighbors always are on the same link-local subnet (FE80::/10), this restriction is removed. The consequence of this, however, is that a router will have to advertise its own prefix on a link, out that interface.

  • Because IPv6 does not use broadcast, RIP messages are sent to the "all RIP routers" link-local multicast address (FF02::9).

  • In IPv4, RIP relies on some specific RIP authentication mechanism to secure routing exchanges. RIPng relies on the IP Authentication Header and the IP Encapsulating Security Payload to ensure integrity and authentication/confidentiality of routing exchanges.

RIP does not directly support multiple instances of the protocol on a link. There is no instance identifier or anything like that in the message format, so if you require this functionality you will have to run RIP on a different UDP port, or use a different RIP multicast address (default FF02::9). The Cisco IOS implementation supports a maximum of four RIPng instances.

Configuration Example

Configuring RIP on Cisco routers is straightforward. It requires that RIP be enabled on each interface, as illustrated here:

interface Ethernet0/0
 ipv6 address 2001:200::2/64
 ipv6 rip foo enable
end

You can change the metric and summary information on a per-interface basis. The IPv6 router RIP mode allows for configuration of redistribution, distribute lists, and knobs for tuning RIP behavior. For example, poison reverse and split horizon can be turned on or off, and the default RIP timers can be changed for better convergence times.

To verify that RIP works correctly, you can use the show command shown in Example 4-1.

Example 4-1. Checking RIP Status

Router#show ipv6 rip
RIP process "foo", port 521, multicast-group FF02::9, pid 26
     Administrative distance is 120. Maximum paths is 16
     Updates every 30 seconds, expire after 180
     Holddown lasts 0 seconds, garbage collect after 120
     Split horizon is on; poison reverse is off
     Default routes are not generated
     Periodic updates 14, trigger updates 2
  Interfaces:
    Ethernet0/0
  Redistribution:
    Redistributing protocol static

The show ipv6 rip command shows the status of the RIP process(es). The output includes most of the details you need to know; timers, redistribution status, and on which interfaces RIP is enabled.

Routing information is stored in a local database called a routing table, also referred to as Routing Information Base (RIB). The RIB essentially contains all routes available for selection. Essentially, it is the sum of all routes learned via dynamic RPs (including RIP, for instance), all directly attached networks (networks that a given router has interfaces connected to), and any additional configured routes such as static routes. There is one RIB for IPv4, and a separate one for IPv6. There may be more than one if the VPN feature is enabled (see Chapter 7, "VPN IPv6 Architecture and Services").

Example 4-2. Rip Database Display

Router#show ipv6 rip database
RIP process "foo", local RIB
 2001:200::/64, metric 2
     Ethernet0/0/FE80::A8BB:CCFF:FE02:8B00, expires in 159 secs
 DEAD:BEEF:CAFE::/64, metric 2, installed
     Ethernet0/0/FE80::A8BB:CCFF:FE02:8B00, expires in 159 secs

In addition, each RP, such as RIPng, has its own database, which you can view.

The show ipv6 rip database command lists the routing database for RIP. You might see entries in this database that are not in the IPv6 RIB. For example, the RIB might already have a route with a better administrative distance. The keyword installed after a prefix indicates that it is installed in the RIB.

EIGRP for IPv6

The Cisco proprietary Enhanced Interior Gateway Protocol (EIGRP) was developed to bridge the gap between the traditional distance vector protocols (IGRP, RIP) and the advanced link-state protocols (OSPF, IS-IS). It integrates some of the proven capabilities of the latter to improve the operation and the scalability of the former. Nevertheless, the intent was to avoid some of the topological constraints that are sometimes associated with link-state protocols. The result is a simple yet fast converging, resilient, and scalable routing protocol that is largely adopted in many enterprise networks as well as the edge of some ISP networks.

The protocol is extensively discussed in the book EIGRP Network Design Solutions, by Ivan Pepelnjak; but in summary, EIGRP is a distance vector routing protocol based on IGRP that offers the following improvements:

  • Diffusing update algorithm (DUAL) used to determine whether a path advertised by a neighbor is loop-free and to identify alternate paths without waiting on updates from other routers.

  • It stores all routes learned, not only the best one learned from neighbors.

  • EIGRP actively queries neighbors when destinations become unreachable, and that leads to competitive convergence times.

  • Use of Hello packets to maintain neighbor state leads to faster convergence.

  • Use of reliable transport protocol for the exchange of updates eliminates the need for periodic, full updates.

  • EIGRP uses complex metrics that provide flexibility in route selection.

To meet the routing needs of enterprise networks, EIGRP has a modular design with protocol-independent core functionality and protocol-dependent modules that enable it to be used for IPv4, IPX, and AppleTalk.

Support for IPv6

The large deployed base for EIGRP drove the demand for extending its capabilities to support IPv6. The modular implementation of EIGRP simplifies the implementation. It requires the introduction of another protocol-dependent module for IPv6 (protocol identifier 88 was chosen, the same as IPv4) and three new TLVs (IPv6_REQUEST_TYPE [0X0401], IPv6_METRIC_TYPE [0X0402] and IPv6_EXTERIOR_TYPE [0X0403]).

EIGRP for IPv4 and EIGRP for IPv6 have strong similarities. Both implement the "diffusing update algorithm," developed by J. J. Garcia-Luna-Aceves based on work by E. W. Dijkstra and C. S. Scholten in 1980. A few differences exist due to some specific aspects of IPv6:

  • The router ID for the EIGRP process remains 32 bits long. It is derived from an IPv4 address found on one of the configured interfaces or is manually configured.

    Note

    On an IPv6-only router, the EIGRP process does not start until the ID is manually configured.


  • The source address (SA) of the EIGRP Hello is the link-local address of the transmitting interface; the destination address (DA) is FF02::A (the all EIGRP routers, link-scope multicast address).

    Note

    This format of the Hello packet implies that two neighbor routers do not have to share the same prefix on the link to see each other's Hellos. Packets sent to specific peers are unicasted, in which case, sharing the same prefix on the link becomes relevant.


  • EIGRP for IPv4 uses MD5 for authentication, and similar support is provided by EIGRP for IPv6. Although not yet available by the time of this writing, support for IPsec authentication will also be provided on Cisco routers.

  • Automatic summarization enabled by default in EIGRP for IPv4 is disabled in EIGRP for IPv6 because IPv6 is classless.

  • Unlike EIGRP for IPv4, there is no split horizon in EIGRP for IPv6 because in IPv6 multiple prefixes could be present on the same interface of a router.

EIGRP for IPv6 will be enabled to operate within virtual private networks (VPNs) in a similar way as EIGRP for IPv4. Scalability characteristics of EIGRP for IPv6 differ from EIGRP for IPv4 mainly due to the need for extra memory resources.

Configuration Example

Similar to all other IPv6 RPs, EIGRP for IPv6 is enabled on a per-interface basis. If a router is able to acquire its ID from an IPv4 address existent on it, the EIGRP for IPv6 protocol configuration is simple, as illustrated here:

interface Ethernet0
 ipv6 enable
 ipv6 eigrp 100

Note

The EIGRP process does not start on an interface unless the ipv6 enable command is present under that interface.


If the router is IPv6 only, a router ID has to be explicitly configured under the EIGRP process, as illustrated here:

ipv6 router eigrp 100
 Router-id 10.10.10.1

Note

When configured, the EIGRP process is by default shut down and an explicit no shutdown is necessary to get it started.


Once configured, you can use the following show command to display EIGRP-relevant operational parameters.

Example 4-3. Displaying EIGRP Parameters

Router1#show ipv6 protocol
IPv6 Routing Protocol is "eigrp 100"
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Interfaces:
    FastEthernet0/1.1
  Redistribution:
    None
  Maximum path: 16
  Distance: internal 90 external 170

When established, adjacencies are pointing to the link-local address of the neighbor, as shown in Example 4-4.

Example 4-4. EIGRP Neighbor Status

Router1#show ipv6 eigrp neighbor
IPv6-EIGRP neighbors for process 100
H   Address                 Interface     Hold Uptime    SRTT   RTO  Q  Seq
                                          (sec)          (ms)       Cnt Num
0   FE80::2B0:4AFF:FE5C:ACA Fa0/1.1         14 00:01:43     1  4500  0  1

The EIGRP for IPv6 topology is independent of IPv4, and when queried, the all-links option should be used to view all equal-cost paths when present, as shown in the following show command.

Example 4-5. EIGRP Topology

Router1#show ipv6 eigrp topology all-links
IPv6-EIGRP Topology Table for AS(100)/ID(10.10.10.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 2001:FFFF:FFFF::/64, 1 successors, FD is 28160, serno 1
        via Connected, FastEthernet0/1.1
        via FE80::2B0:4AFF:FE5C:ACA9 (30720/28160), FastEthernet0/1.1

With minor syntax modifications, the commands available for tweaking or troubleshooting EIGRP for IPv4 are available for IPv6, too. For example, the command that enables MD5 authentication for a given interface would in this case be ipv6 authentication mode eigrp 100 md5. Considering their similar mode of operation, you should use the same configuration and troubleshooting guidelines for IPv6 as for IPv4, such as those discussed in the book EIGRP Network Design Solutions, by Ivan Pepelnjak.

OSPFv3

OSPF is an IGP used to distribute routing information between routers of a single autonomous system. OSPF is based on link-state technology, described briefly in the "Overview" section. The IPv4 version is specified in RFC 2328.

Routers running OSPF advertise link state, link prefix/mask, link weight, and other local connectivity parameters in link-state advertisements (LSAs). These LSAs are flooded reliably to other routers in the network to ensure that every OSPF router has a complete and consistent view of the topology.

On broadcast and Non-Broadcast Multiple Access (NBMA) networks, a designated router (DR), elected during neighboring relationship establishment (Hello protocol) can help reduce the amount of control traffic necessary for this operation, by acting as a relay between OSPF routers for LSAs. A backup designated router (BDR) is also elected. The BDR picks up the functions of a failed DR with no need of a new election process.

OSPF allows sets of networks to be grouped together into regions called areas. A router maintains a topology database for each area it participates in, and the topology of an area is hidden from the rest of the autonomous system. Areas constitute a useful concept that enables a two-level routing hierarchy, a concept that helps improve scalability. Routers do not need to maintain a topology database for areas they do not belong to, which leads to significant reduction in routing traffic. Route summarization can occur on the area borders, another way to reduce the routing traffic.

For securing routing distribution and installation, OSPFv2 defines fields AuType and Authentication in its protocol header (RFC 2328).

Finally, OSPF has built-in support for classless interdomain routing (CIDR). (Each route distributed by OSPF has a destination and mask.)

For in-depth information on OSPF, refer to the book OSPF: Anatomy of an Internet Routing Protocol, by John T. Moy.

Support for IPv6

OSPFv3 extends OSPF to provide support for IPv6, as specified in RFC 2740. The basic mechanisms already used by OSPFv2, such as flooding, DR election, area support, SPF calculations, and so on, remain applicable to OSPFv3. Neighboring routers are still identified by the 32-bit router ID in OSPFv3. However, changes in protocol semantics between IPv4 and IPv6, as well as changes in the address format, have led to significant changes in OSPFv3 compared to OSPFv2.

The two versions of the OSPF protocol operate independently of each other, on disjoint databases. There is no backward compatibility from OSPFv3 to OSPFv2.

Extensions have been proposed to adapt OSPFv3 as an "integrated model," where OSPFv3 would be extended to calculate IPv4 routes. This is still a work in progress at the IETF. Two proposals are being discussed: "Multi-topology routing in OSPFv3" (Internet Draft; Sina Mirtorabi, Abhay Roy) and "Support of address families in OSPFv3" (Internet Draft; Mirtorabi, S., et al.). A Cisco implementation is already available that provides a unified command-line interface (CLI), as shown in Example 4-6.

Example 4-6. Unified OSPF Configuration Example

interface serial0
    ipv6 ospf 1 area 0
    ipv6 ospf cost 12
    ospfv3 2 area 0 instance 64 address-family ipv4
    ospfv3 instance 64 cost 22

A main goal of OSPFv3 was to create a routing protocol independent of any specific network layer. To achieve this, OSPFv3's inter-router messages have been redesigned, and addressing semantics have been removed from OSPF packets and from the basic LSAs. In OSPFv3, LSAs such as router LSAs and network LSAs only carry topology information. The following LSAs have been created to carry IPv6 addresses and prefixes:

  • Link LSAs announce the router's IPv6 link-local address to neighbors on the link, inform these neighbors of a list of IPv6 addresses to associate with the link, and announce the set of options.

  • Intra-area prefix LSAs carry all IPv6 prefix information to all OSPFv3 routers within an area. (This information in IPv4 is carried by the router and network LSAs.)

The following LSAs have been modified:

  • Router link state advertisements and network LSAs no longer carry prefix information. In OSPFv3, these LSAs only carry topology information, making them network-protocol independent.

  • Inter-area prefix replaces the network summary or type 3 LSA. An inter-area prefix LSA advertises internal networks to routers in other areas. With IPv6, those LSAs are expressed as <prefix, prefix length> rather than <prefix, mask>.

  • Inter-area router replaces the Autonomous System Boundary Router (ASBR) summary LSA (type 4). It advertises the location of an ASBR.

OSPFv3 runs on a per-link basis rather than on a perIP subnet basis as in OSPFv2. When OSPF peering occurs over a physical link, OSPF packets are sent using the interface link-local unicast address as source. The flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header (AH) and Encapsulating Security Payload (ESP). Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses.

OSPFv3 supports the ability to run multiple OSPF protocol instances on a single link. The OSPFv3 packet header includes an 8-bit instance ID used to demultiplex the protocol packets. Each OSPFv3 process sets its configured instance value in the OSPFv3 packets that it sends, and ignores received packets with instance values from other OSPFv3 processes.

Instance IDs can control communication between routers sharing a physical network and OSPF area, without relying on complex authentication schemes or access lists, as needed in the past. It enables the providers to run separate OSPF routing domains even though they have one or more physical network segments in common.

Configuration Example

Configuring OSPFv3 on Cisco routers on a broadcast network is straightforward. It requires just enabling OSPF on each interface participating in the OSPF area, as illustrated in Example 4-7.

Example 4-7. OSPF Configuration Example

interface Ethernet1/0
 ipv6 address 2001:200::2/64
 ipv6 ospf 100 area 1
end

On NBMA interfaces, the neighbor is explicitly configured.

Example 4-8. OSPF Configuration on Interface

Interface Serial1/0
  ipv6 enable
  ipv6 ospf 100 area 0
  encapsulation frame-relay
  frame-relay map ipv6 FE80::A8BB:CCFF:FE00:C01 120
  ipv6 ospf neighbor FE80::A8BB:CCFF:FE00:C01

In addition, if the OSPF router does not have an IPv4 address configured, a router ID must be configured. This is done under IPv6 router mode.

Other useful options can be configured under IPv6 router mode, such as enabling routes summarization at an area boundary or enabling authentication for an OSPF area, as illustrated in Example 4-9.

Example 4-9. OSPF Options

ipv6 router ospf 100
 router-id 200.11.11.1
 area range 1 2001::/48
 area 1 authentication ipsec spi 678 md5 1234567890ABCDEF1234567890ABCDEF

Finally, to verify proper OSPF configuration, you can use the following show command.

Example 4-10. OSPF Status

Router#show ipv6 ospf
 Routing Process "ospfv3 100" with ID 200.11.11.1
 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
    Area 1
        Number of interfaces in this area is 2
        SPF algorithm executed 4 times
        Area ranges are
          2001::/48 Passive Advertise
        Number of LSA 12. Checksum Sum 0x04F3D1
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

The show commands display the process ID and OSPF router ID, the configured LSA timer values, the number of areas, and details about each.

IS-IS for IPv6

The Intermediate System-to-Intermediate System (IS-IS) protocol is described in ISO Standard 10589. This link-state, OSI routing protocol was not originally developed for IP but rather to provide the routing functionality between the routers of Connectionless Network Protocol (CLNP)-based networks. With the addition of IPv4 support (RFC 1195), the protocol, sometimes referred to as Integrated IS-IS (I/IS-IS), was widely adopted as the IGP of choice for many ISP and large enterprise networks. (For more information, refer to the book IS-IS: Deployment in IP Networks, by Russ White and Alvaro Retana.

In many respects, IS-IS is similar to OSPF, but some terminology and implementation differences do exist. For example, packet encoding in IS-IS is Type Length Value (TLV) based and makes the protocol easily extensible. Nested TLVs also offer granularity in the protocol extensions.

The link state, link prefix/mask, link weight, and other local connectivity parameters are advertised in link state packets (LSPs). Unlike the OSPF LSAs that are exchanged at the IP level, the IS-IS LSPs are exchanged at layer 2. This makes IS-IS less vulnerable to spoofing or other attacks.

Note

Before deploying IS-IS in an IPv6 network using tunnels, it is important to make sure that the tunneling mechanisms used can forward the IS-IS LSPs.


Similar to OSPF, IS-IS also elects a DR, called a designated intermediate system (DIS). The DIS, however, does not select a BDR. Should the DIS fail, a new DIS election process is started. Notably, IS-IS does not have direct support for NBMA networks.

IS-IS implements a two-level routing hierarchy as well, an important feature for scalability. Despite that, most IS-IS deployments are rather flat. Unlike OSPF, where interfaces are bound to areas (thus enabling routers to belong to multiple areas), in IS-IS the routers belong to a single area. A router (called intermediate system, or IS) performing intra-area functions is a level 1 router. A router performing inter-area functions is a level 2 router.

IS-IS, like OSPF, supports authentication, it supports CIDR, and it transports MPLS traffic engineering link information. Both protocols are deployed in enterprise as well as ISP networks (with OSPF more common in enterprise networks, and IS-IS more common in large ISP networks).

Support for IPv6

The third network protocol supported by I/IS-IS is IPv6 (draft-ietf-isis-ipv6-02.txt). The implementation required a new protocol ID (0X8E) that was set to be used by the IPv6 routers to signal their capability to support ISISv6 and two new TLVs: IPv6_Reachability (0XEC) and IPv6_Interface_Address (0XE8). Extending IS-IS to support IPv6 is an exercise similar to extending it to support IPv4, unlike OSPF where a new protocol had to be developed. For this reason, IS-ISv6 is operationally similar to IS-ISv4. Few IPv6-specific differences exist. Neighbors are listed in the adjacency table with their link-local address. Because the link-local is used in the Hello packets, adjacencies can be built between neighbors even if they do not share the same prefix. From a user perspective, a new address family was added for IPv6. Most configuration commands available for IS-ISv4 are also available for IS-ISv6 with minimal format changes.

IS-IS uses a single topology and runs the same SPF calculation for all protocols supported. This mode of operation leads to certain deployment constraints.

Single Topology

By default, IS-IS runs with a single topology for all protocols supported and a single instance of the SPF calculation per level (1 = area, 2 = domain). This could be a benefit in that fewer resources are being used by the routers to operate it. On the other hand, the single topology mode comes with some restrictions:

  • All routers within an area (level 1 or level 2) must support the same set of address families on all interfaces. This ensures topology consistency. It also means that the single topology mode is not suitable in IPv4 networks where only some islands of IPv6 will be deployed.

  • The interface configured metric applies to both IPv4 and IPv6.

This need for capabilities consistency raises this question: What will happen when an IS-ISv4 network is migrated to the IS-ISv4+IS-ISv6 network? Because routers are configured with the additional IPv6 address family, the adjacencies will be dropped until the consistency is reestablished. To avoid impacting the operating IPv4 service, you can disable the adjacency checking.

Note

To avoid inconsistencies in the operational network, only disable adjacency checking during the migration process.


Multitopology

IS-IS was later enhanced to support independent topologies and SPF calculations for each protocol (draft-ietf-isis-wg-multi-topology.txt). In this case, various routers can support different sets of address families. To add multitopology support for IPv6, a new Multi_Topology_Reachable_IPv6_Prefixes TLV is defined. The multitopology operation can be enabled under the IPv6 address family. In this mode of operation, you can set the IPv6 metric independently of the IPv4 one.

To facilitate the migration from single topology to multitopology, you can enable a transition mode. In this case, both types of TLVs are advertised in LSPs. Larger LSPs are thus traded off for a smooth transition.

Configuration Example

The simplest way to configure a router to run IS-IS for IPv6 is to enable the protocol on an interface with an IPv6 address. No changes are needed to the configuration of the IS-IS process for IPv4, as illustrated in Example 4-11.

Example 4-11. IS-IS Configuration Example

router isis example-area
 net 49.0001.0000.0000.0001.00
!
interface FastEthernet0/1
 ip address 10.7.1.33 255.255.255.252
 ip router isis example-area
 ipv6 address 2001:FFFF:FFFF::2/64
 ipv6 enable
 ipv6 router isis example-area

Note

You must configure IPv6 on the interface for the IS-ISv6 process to start.


In this example, IS-IS is operating in single-topology mode. The show ipv6 protocol command indicates that IS-IS is running on the interface (highlighted below). The adjacencies built with other routers show both IP protocol addresses, as highlighted in Example 4-12.

Example 4-12. ISIS Neighbor Status

Router1#show clns is-neighbors detail
System Id      Interface   State  Type Priority  Circuit Id         Format
Router2        Fa0/1       Up     L1L2 64/64     Router2.01     Phase V
  Area Address(es): 49.0001
  IP Address(es):  10.7.1.34*
  IPv6 Address(es): FE80::2B0:4AFF:FE5C:ACA9
  Uptime: 00:01:25
  NSF capable

The IPv6 adjacency is identified through the link-local address, so the global prefix configured on the interface is not relevant for it. A look at the database reveals the capabilities of the neighbors. The following output obtained from the show isis command illustrates the level 1 circuit of the Router2 neighbor.

Example 4-13. IS-IS Database

Router1#show isis database verbose level-1
...
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
Router2.00-00         0x0000000B   0xAB35        1020              0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 0x8E
  Hostname: Router2
  IP Address:   10.7.1.34
  Metric: 10         IP 10.7.1.32 255.255.255.252
  IPv6 Address: 2001:FFFF:FFFF::1
  Metric: 10         IPv6 2001:FFFF:FFFF::/64
  Metric: 10         IS Router2.01

The protocol ID number 8E indicates the support for IPv6. Because in this case IS-IS runs a single topology, no distinction is made in the output between IPv4 and IPv6. By the same token, there is no output for show isis ipv6 topology.

Further protocol customization can be done similar to IPv4, from enabling authentication and summarization to adjusting metrics. The important thing to remember is that in the single-topology mode, you cannot configure the changes on a per-protocol basis.

If the network design requires the two IP protocols to operate independently at the cost of more router resources used by the two instances of the protocol, you can migrate IS-IS to a multitopology mode. In this case, you specifically configure the IPv6 address family under the IS-IS process, as shown in the configuration excerpt in Example 4-14.

Example 4-14. Migrating IS-IS to Multitopology Mode

router isis example-area
 net 49.0001.0000.0000.0001.00
 metric-style wide transition
 !
 address-family ipv6
 multi-topology transition

The transition option is elected to allow routers in different modes to coexist during the migration. You should remote this option when the migration is completed.

With the change to the new operation mode, the outputs of the show commands reflect the existence of two distinct topologies for the two IP protocols.

Example 4-15. Multitopology IS-IS Neighbor Details

Router1#show clns is-neighbors detail
System Id      Interface   State  Type Priority   Circuit Id         Format
Router2        Fa0/1       Up     L1L2 64/64      Router2.01     Phase V
  Area Address(es): 49.0001
  IP Address(es):  10.7.1.34*
  IPv6 Address(es): FE80::2B0:4AFF:FE5C:ACA9
  Uptime: 00:00:14
  NSF capable
  Topology: IPv4, IPv6

You can now view the IPv6-specific topology.

Example 4-16. Multitopology IS-IS Topology

Router1#show isis ipv6 topology level-1
IS-IS IPv6 paths to level-1 routers
System Id            Metric     Next-Hop      Interface    SNPA
Router2              10         Router2       Fa0/1        00b0.4a5c.aca9

The database information also reflects the multitopology mode of operation.

Example 4-17. Mutiltopology IS-IS Database

Router1#show isis database verbose level-1
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num     LSP Checksum    LSP Holdtime    ATT/P/OL
Router2.00-00     0x00000014   0x8B3E           1086              0/0/0
  Area Address: 49.0001
  Topology:     IPv4 (0x0) IPv6 (0x2)
  NLPID:        0xCC 0x8E
  Hostname: Router2
  IP Address:   10.7.1.34
  Metric: 10         IP 10.7.1.32/30
  IPv6 Address: 2001:FFFF:FFFF::1
  Metric: 10         IPv6 (MT-IPv6) 2001:FFFF:FFFF::/64
  Metric: 10         IS (MT-IPv6) Router2.01

Again, the configuration can be detailed further as it is done in IPv4. In this mode, however, you can tweak the IS-IS operation independently for each protocol with commands such as isis ipv6 metric that adjust the metric on an interface only for IPv6.


Previous Page
Next Page