Overview of IPv6 Unicast Routing in Cisco IOS
So that you can better understand how to transport IPv6 over MPLS, this section offers a brief overview of the IPv6 unicast routing protocols. Not that much has changed. The IP routing protocols have just been adapted to work for IPv6. Open Shortest Path First (OSPF) for IPv6 (OSPFv3) has changed more than any of the other protocols, but it is still similar to OSPFv2. The most significant change in configuring the IPv6 routing protocols in Cisco IOS is the change to enabling the routing protocol on the interface directly. To enable routing for IPv4, you had to specify the network command—that covers the IP addresses of the interfaces—under the router process. To enable IPv6 for Border Gateway Protocol (BGP), you must just activate the address family for IPv6.
Another change with IPv4 is the use of link-local addresses by routing protocols for IPv6. Link-local addresses are for use on a single link only. Link-local addresses are of the form FE80::/64, with the lower 64 bits being the interface ID. You can use these addresses for auto-address configuration, for neighbor discovery, or if no routers are present on the link. IPv6 packets with link-local addresses as the source or destination address are never forwarded onto another link.
IPv6 RIP (RIPng)
RIPng, or RIP next generation, is the RIP (Routing Information Protocol) for IPv6. RIP for IPv4 (originally defined in RFC 1058) was a simple distance vector routing protocol that was useful for small networks. It was later enhanced with small changes and made classless when RIP version 2 (RIPv2) was defined (RFC 2453). The limitations—such as a hop limit of 15 and the counting to infinity problem—remained, but the enhancements allowed some additional information to be carried by RIPv2. The most significant changes with RIPv2 are the use of a multicast address (224.0.0.9) as the destination address of the routing updates instead of using the broadcast address 255.255.255.255, the introduction of a subnet mask for the prefixes, the possibility for simple authentication, and route tags. Route tags are just numbers—used as an attribute—that can be used to "tag" prefixes when they are redistributed from one routing protocol into another. The RIPng routing protocol is based on the RIPv2 specification, and nothing important was changed. All of the functional aspects of RIPv2 were kept for RIPng. This means that RIPng is a limited routing protocol that is only suitable for use as a quick-and-dirty routing protocol for the smallest of networks. RIPng is described in RFC 2080.
In the Cisco IOS software implementation of RIPng, each RIPng process maintains a local database. RIPng tries to insert every nonexpired route from its local database into the master IPv6 routing information base (RIB), also known as the IPv6 routing table. If the same route has been learned from a different routing protocol with a better administrative distance than RIPng, the RIP route is not added to the IPv6 RIB, but the RIP route remains in the RIPng database. RIPng runs on top of UDP, port 521. The same timers exist in RIPng as they do in RIP: update period, route timeout period, router holddown period, and router garbage collection period.
Example 9-1 shows the basic configuration for RIPng.
Example 9-1 Basic Configuration for RIPng ipv6 unicast-routing ipv6 cef
interface Serial4/0 ipv6 address 2001:DB8:4::1/64 ipv6 enable ipv6 rip joene enable
ipv6 router rip joene maximum-paths 2
NOTE Notice that ipv6 unicast-routing and ipv6 cef are not enabled by default and thus must be configured. Also notice that RIP routing processes have names and that they have to be enabled on each interface.
You can verify the RIPng database as shown in Example 9-2. Example 9-2 Verifying the RIPng Database
|
new-york#show ipv6 rip joene database |
||
|
RIP process "joene", local RIB |
||
|
2001:DB8:4::/64, metric 2 |
||
|
Serial4/0/FE80::204:C0FF:FEF1:8820, |
expires in |
179 secs |
|
2001:DB8:10::/64, metric 2, installed |
||
|
Serial4/0/FE80::204:C0FF:FEF1:8820, |
expires in |
179 secs |
NOTE Notice that the IPv6 routing protocols use the link-local addresses as next-hop addresses.
Example 9-3 shows you how to look at the IPv6 RIP prefixes in the IPv6 RIB and what the characteristics are of the RIP process.
Example 9-3 Verifying the RIPng Prefixes in the IPv6 RIB
new-york#show ipv6 route rip
IPv6 Routing Table - 5 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external
via FE80::204:C0FF:FEF1:8820, Serial4/0
new-york#show ipv6 rip next-hops
RIP process "joene", Next Hops FE80::204:C0FF:FEF1:8820/Serial4/0 [2 paths]
new-york#show ipv6 rip joene
RIP process "joene", port 521, multicast-group FF02::9, pid 146 Administrative distance is 120. Maximum paths is 2 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 9, trigger updates 0 Interfaces: Serial4/0 Redistribution: None
The multicast address used by RIPng is FF02::9. Pinging this address from a certain interface on the router returns the IPv6 nodes running RIPng on that link. Look at Example 9-4 to see the result of pinging the RIPng multicast address. In addition, debug ipv6 rip shows you the sent and received RIPv6 updates.
Example 9-4 Pinging the RIPng Multicast Address new-york#ping ipv6 ff02::9
Output Interface: serial4/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::9, timeout is 2 seconds: Packet sent with a source address of FE80::203:6CFF:FEC8:9800
Reply to request 0 received from FE80:
Reply to request 1 received from FE80:
Reply to request 2 received from FE80:
Reply to request 3 received from FE80:
Reply to request 4 received from FE80:
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms 5 multicast replies and 0 errors.
new-york#debug ipv6 rip RIP Routing Protocol debugging is on new-york#
|
4 0 2 |
C0FF |
FEF1 |
8820, |
0 |
ms |
|
4 0 2 |
C0FF |
FEF1 |
8820, |
0 |
ms |
|
4 0 2 |
C0FF |
FEF1 |
8820, |
0 |
ms |
|
4 0 2 |
C0FF |
FEF1 |
8820, |
0 |
ms |
|
4 0 2 |
C0FF |
FEF1 |
8820, |
0 |
ms |
|
01 |
41 |
49: |
RIPng: |
response received from FE80: |
:204:C0FF:FEF1:8820 |
|
01 |
41 |
49: |
src=FE80::204:C0FF:FEF1:8820 |
(Serial4/0) |
|
|
01 |
41 |
49: |
dst=FF02::9 |
||
|
01 |
41 |
49: |
sport=521, dport=521, length |
=52 |
|
|
01 |
41 |
49: |
command=2, version=1, mbz=0, |
#rte=2 |
|
|
01 |
41 |
49: |
tag=0, metric=1, prefix=2001 |
:DB8:4::/64 |
|
|
01 |
41 |
49: |
tag=0, metric=1, prefix=2001 |
:DB8:10::/64 |
|
|
01 |
41 |
55: |
RIPng: |
Sending multicast update on |
Serial4/0 for joene |
|
01 |
41 |
55: |
src=FE80::203:6CFF:FEC8:9800 |
||
|
01 |
41 |
55: |
dst=FF02::9 (Serial4/0) |
||
|
01 |
41 |
55: |
sport=521, dport=521, length |
=32 |
|
|
01 |
41 |
55: |
command=2, version=1, mbz=0, |
#rte=1 |
|
|
01 |
41 |
55: |
tag=0, metric=1, prefix=2001 |
:DB8:4::/64 |
OSPF for IPv6 or OSPFv3
OSPFv2 is defined in RFC 2328. However, OSPF could not easily be extended to support IPv6 prefixes for the following reasons:
■ OSPFv2 has rigid formatting that could not easily be extended.
■ Because IPv6 is different from IPv4 in the way it works, some changes had to be made.
■ The new specification for IPv6 was an opportunity to do things differently and better.
That is why OSPFv3 was specified in a completely new document (RFC 2740), but it borrowed heavily from OSPFv2. Some of the changes in OSPFv3 include these:
■ Bigger addresses (128 instead of 32 bits)
■ Different flooding scopes
■ Per-link, instead of per-subnet protocol processing
■ Use of link-local addresses
■ No authentication in OSPF
■ Multiple addresses possible per interface
■ Changed options
Multiple IPv6 addresses per link are possible in IPv6. Different IPv6 prefixes can even exist on connecting IPv6 neighbors, without a common IPv6 prefix shared by both neighbors. That is why the protocol processing has changed from per-subnet in OSPFv2 to per-link in OSPFv3.
The use of link-local addresses in IPv6 has led to further changes in the OSPF specification. The direct result of the use of link-local addresses is the new link-local flooding scope. The link-local addresses are used for neighbor discovery, auto-configuration, and so on.
OSPFv3 does not need authentication because IPv6 provides that. OSPFv3 uses the IPv6 Authentication Header and Encapsulating Security Payload for security.
These changes have led to the differences in the newly defined OSPF packet formats. Two new link-state advertisements (LSA) also were added: Link LSA and Intra-Area LSA. The Link LSA serves three purposes:
■ Advertising the link-local address to all routers that are attached to the link
■ Advertising IPv6 prefixes on the link to the routers that are attached to the link
■ Advertising options
The Intra-Area LSA serves either of the following two purposes:
■ Associating a list of IPv6 prefixes with a transit network by referencing a network LSA
■ Associating a list of IPv6 prefixes with a router by referencing a router LSA (In OSPFv2, these prefixes were included in the router or network LSA.)
The obvious change from 32-bit to 128-bit addresses led to the redesign of the OSPF packet formats. The flooding of LSAs has changed and was made easier. Three flooding scopes are defined:
■ Link-local scope
■ Autonomous System (AS) scope
■ OSPFv3 directly running on top of IP
■ Flooding
■ The discovery and maintenance of neighbor relationships, and the selection and establishment of adjacencies
■ The link types, namely point-to-point, broadcast, nonbroadcast multiaccess (NBMA), Point-to-MultiPoint, and virtual links
■ The interface and neighbor state machine
■ Designated router (DR) election
■ Area support
■ Shortest Path First (SPF) calculations
■ Area ID, router ID, and link-state ID as 32-bit fields
■ Functionality of Hello, Database Description, Link-State Request, Link-State Update, and Link-State Acknowledgment packets
You can still use OSPFv3 in conjunction with OSPFv2. They run independently of each other. You can also run multiple instances of OSPFv3 on a single link.
Example 9-5 shows the basic configuration for OSPFv3. Example 9-5 Basic Configuration for OSPFv3
|
ipv6 unicast-routing ipv6 cef ! |
||
|
interface Loopback0 ip address 10.200.254.3 ! |
255.255 |
255.255 |
|
interface Serial4/0 ipv6 ipv6 enable ipv6 ospf 1 area 0 ! |
address |
2001:DB8:4::1/64 |
|
ipv6 router ospf 1 log-adj acency-changes maximum-paths 2 ! |
As you can see, OSPFv3 is directly enabled on the interface, as it is done with all the IPv6 unicast routing protocols. The general OSPFv3 parameters can be configured under the ipv6 router ospf section. Example 9-6 shows how to verify the OSPFv3 neighbors.
Example 9-6 Verifying OSPFv3 Neighbors new-york#show ipv6 ospf 1 neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
10.200.254.4 1 FULL/ - 00:00:35 10 Serial4/0
new-york#show ipv6 ospf 1 neighbor detail
Neighbor 10.200.254.4
In the area 0 via interface Serial4/0
Neighbor: interface-id 10, link-local address FE80::204:C0FF:FEF1:8820
Neighbor priority is 1, State is FULL, 6 state changes
Options is 0x635791D9
Dead timer due in 00:00:39
Neighbor is up for 00:11:49
Index 1/1/1, retransmission queue length 0, number of retransmission 1 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 0 msec
The OSPFv3 database is shown in Example 9-7. Notice the two new LSAs in the OSPFv3 database: Link LSA and Intra-Area LSA.
Example 9-7 OSPFv3 Database
|
new-york#show ipv6 ospf 1 database |
|||||
|
OSPFv3 Router with ID (10.200.254.3) (Process ID 1) |
|||||
|
Router Link States (Area 0) |
|||||
|
Age Seq# |
Fragment ID Link count |
Bits |
|||
|
10.200.254 |
3 |
725 0x80000002 |
0 1 |
None |
|
|
10.200.254 |
4 |
722 0x80000002 |
0 1 |
None |
|
|
Link (Type-8) Link States (Area 0) |
|||||
|
ADV Router |
Age Seq# |
Link ID Interface |
|||
|
10.200.254 |
3 |
735 0x80000001 |
7 Se4/0 |
||
|
10.200.254 |
4 |
182 0x80000003 |
10 Se4/0 |
||
|
Intra Area Prefix Link |
States (Area 0) |
||||
|
ADV Router |
Age Seq# |
Link ID Ref-lstype |
Ref-LSID |
||
|
10.200.254 |
3 |
735 0x80000001 |
0 0x2001 |
0 |
|
|
10.200.254 |
4 |
182 0x80000004 |
0 0x2001 |
0 |
|
Example 9-8 OSPFv3 Link LSA
new-york#show ipv6 ospf 1 database link
OSPFv3 Router with ID (10.200.254.3) (Process ID 1)
Link (Type-8) Link States (Area 0)
LS age: 910
Options: (V6-Bit E-Bit R-bit DC-Bit) LS Type: Link-LSA (Interface: Serial4/0) Link State ID: 7 (Interface ID) Advertising Router: 10.200.254.3 LS Seq Number: 80000001 Checksum: 0xCA4 Length: 56 Router Priority: 1
Link Local Address: FE80::203:6CFF:FEC8:9800 Number of Prefixes: 1 Prefix Address: 2001:DB8:4:: Prefix Length: 64, Options: None
Example 9-9 shows the OSPFv3 Intra-Area LSA in more detail.
Example 9-9 OSPFv3 Intra-Area LSA
new-york#show ipv6 ospf 1 database prefix
OSPFv3 Router with ID (10.200.254.3) (Process ID 1)
Intra Area Prefix Link States (Area 0)
Routing Bit Set on this LSA LS age: 962
LS Type: Intra-Area-Prefix-LSA Link State ID: 0
Advertising Router: 10.200.254.3 LS Seq Number: 80000001 Checksum: 0x7879 Length: 44
Referenced LSA Type: 2001
Referenced Link State ID: 0
Referenced Advertising Router: 10.200.254.3
Number of Prefixes: 1
Prefix Address: 2001:DB8:4::
Prefix Length: 64, Options: None, Metric: 64
Most OSPFv2 commands have the equivalent command in OSPFv3. Table 9-1 is an overview of the OSPFv3 commands versus the OSPFv2 commands.
|
OSPFv3 Command |
OSPFv2 Command |
|
show ipv6 ospf |
show ip ospf |
|
clear ipv6 ospf |
|
|
debug ipv6 ospf |
IS-IS for IPv6
ISO 10589 originally specified IS-IS, which specified the routing for Connectionless Network Service (CLNS). The IETF specified RFC 1195 and made IS-IS perform routing for IP.
If IS-IS runs both CLNS and IP routing, it is called dual routing. The TLV (an easy means of encoding in a Type-Length-Value fashion) encoding used throughout IS-IS ensured that the protocol was extendible from the start. Recent work is underway in the form of a draft: draft-ietf-isis-ipv6 (Routing IPv6 with IS-IS) to extend IS-IS so that it can do routing for IPv6. In essence, what is needed is the addition of a few TLVs so that IS-IS can take care of the routing for IPv6. The draft specifies the addition of two new TLVs: IPv6 Reachability and IPv6 Interface Address. The first one is the equivalent of the IP Internal Reachability Information and IP External Reachability Information TLVs, and the second is the equivalent of the IP Interface Address TLV. All of them are used for IPv4 encoding.
To configure IS-IS IPv6, you must configure the following:
■ Generic IS-IS interface attributes
■ IS-IS IPv6 on the interface
■ Generic IS-IS router-mode attributes
■ IS-IS IPv6-specific attributes under the IPv6 address-family submode of the IS-IS router mode
The generic IS-IS attributes can be the circuit type, priority, and so on configured on the interface. To configure IS-IS IPv6 on the interface, configure the command ipv6 router isis [tag]. You must enable the interface for IPv6 by having an IPv6 address on it or by having the command ipv6 enable on it. You can then configure any of the IPv6-specific attributes under the IPv6 address family of IS-IS. Examples are summary-prefix ipv6-prefix/prefix-length {level-1 I level-1-2 I
level-2} and redistribute source-protocol [process-id] [include-connected] [target-protocol-options] [source-protocol-options]. These attributes are applied only to the IPv6 routing table.
IS-IS is a link-state routing protocol. As such, it builds a database of the network topology. This database is present on all the routers. Each router must then take the IS-IS database and run a SPF calculation (or Dijkstra, after the inventor) on it. The result of this SPF calculation is the shortest path of all possible paths to all destinations or, in short, a routing table. However, when combining CLNS routing with IPv4 routing, only one SPF is performed on the IS-IS database in Cisco IOS. This means that the topologies of CLNS and IPv4 have to be the same. For a dual routing network, each interface with IS-IS routing for CLNS configured on it also has to have IS-IS routing for IPv4 configured on it. Otherwise, the topology of CLNS differs from the IPv4 topology, and routing fails in certain parts of the network.
Now that IPv6 is added as another protocol to be routed by IS-IS, the same problem can occur if the IPv4 and IPv6 topologies differ from each other. The result might be that IPv6 traffic is routed toward a non-IPv6-capable router and is thus discarded. You must take care in networks that are running IS-IS for both IPv4 and IPv6—which might still be the case for quite some time to come—that the topologies for both IP protocols are the same. Having the same topology for IPv4 and IPv6 might not always be wanted, though. They are, after all, different protocols. Cisco IOS lets you do Multi-Topology IS-IS, which allows IS-IS to run two separate SPF calculations: one for the IPv4 links, and one for the IPv6 links. This is described in the draft draft-ietf-isis-wg-multi-topology with the title "M-ISIS: Multi Topology (MT) Routing in IS-IS." This draft explains how the multi-topology IS-IS routing works and introduces the following four new TLVs for IS-IS:
■ Multi-Topology TLV
■ MT Intermediate Systems TLV
■ Multi-Topology Reachable IPv4 Prefixes TLV
■ Multi-Topology Reachable IPv6 Prefixes TLV
In Cisco IOS, you enable Multi-Topology routing in IS-IS by configuring multi-topology [transition] under the IPv6 address family of router IS-IS. If you do not configure this command, the default applies, which is to run one SPF for both IPv4 and IPv6, meaning that IPv4 and IPv6 topologies must be the same. The optional keyword transition allows the router to send and accept both Multi-Topology TLVs and the old-style IS-IS IPv6 TLVs. The network can then transition from the existing IS-IS IPv6 single SPF mode to the Multi-Topology IS-IS IPv6 mode.
NOTE Wide metric is required to run Multi-Topology IS-IS IPv6.
Example 9-10 Basic IS-IS Configuration for IPv6
ipv6 unicast-routing ipv6 cef
interface Serial4/0 ipv6 address 2001:DB8:4::1/64 ipv6 enable ipv6 router isis
router isis net 49.0001.0001.0000.0000.0002.00
address-family ipv6 redistribute static exit-address-family
Example 9-11 shows some commands to verify the correct functioning of IS-IS for IPv6.
Example 9-11 Verifying IS-IS for IPv6
new-york#show isis neighbors detail
System Id Type Interface IP Address State Holdtime Circuit Id sydney L1L2 Se4/0 10.200.202.2 UP 22 00
Area Address(es): 49.0001.0001 SNPA: *HDLC*
IPv6 Address(es): FE80::204:C0FF:FEF1:8820 State Changed: 00:02:17 Format: Phase V
new-york#show isis ipv6 topology
IS-IS IPv6 paths to level-1 routers
System Id Metric Next-Hop Interface SNPA
sydney 10 sydney Se4/0 *HDLC*
IS-IS IPv6 paths to level-2 routers
System Id Metric Next-Hop Interface SNPA
sydney 10 sydney Se4/0 *HDLC*
new-york#show isis ipv6 rib
IS-IS IPv6 process "", local RIB 2001:DB8:4::/64
via FE80::204:C0FF:FEF1:8820/Serial4/0, type L1
via FE80::204:C0FF:FEF1:8820/Serial4/0, type L2 * 2001:DB8:10::/64
via FE80::204:C0FF:FEF1:8820/Serial4/0, type L1
via FE80::204:C0FF:FEF1:8820/Serial4/0, type L2
new-york#show clns interface serial 4/0
Serial4/0 is up, line protocol is up
Checksums enabled, MTU 1500, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec. CLNS fast switching enabled CLNS SSE switching disabled
DEC compatibility mode OFF for this interface Next ESH/ISH in 21 seconds Routing Protocol: IS-IS Circuit Type: level-1-2
Interface number 0x0, local circuit ID 0x100 Neighbor System-ID: sydney Level-1 Metric: 10, Priority: 64, Circuit ID: new-york.00 Level-1 IPv6 Metric: 10 Number of active level-1 adjacencies: 1
Level-2 Metric: 10, Priority: 64, Circuit ID: new-york.00
Level-2 IPv6 Metric: 10
Number of active level-2 adjacencies: 1
Next IS-IS Hello in 4 seconds if state UP
EIGRP for IPv6
Enhanced Interior Gateway Routing Protocol (EIGRP) is the Cisco proprietary distance vector routing protocol. It is the successor to the Interior Gateway Routing Protocol (IGRP), which was a huge success in the early days of routing. EIGRP became successful, too, especially in enterprise networks. These are the advances of EIGRP compared to IGRP:
■ No periodic updates
■ Classless routing
■ A more efficient way in operating (for example, a more efficient use of bandwidth)
■ Faster convergence
■ The use of its own topology table
■ Tracking of neighbors
■ Guaranteed loop-free routing
■ Internetwork Packet Exchange (IPX) and AppleTalk routing metric 20 LSP [3/4]
metric 20 LSP [4/4]
metric 20 LSP [3/4]
metric 20 LSP [4/4]
The IPv4, IPX, and Appletalk routing in EIGRP are not tied together like IPv4, IPv6, and CLNS are when using IS-IS as the routing protocol. When you are adding IPv6 routing for EIGRP, it is just another addition, which is completely separate from EIGRP for IPv4. There is no linkage between EIGRP for IPv4 and EIGRP for IPv6; they are separately configured and managed.
To configure EIGRP for IPv6, you must enable IPv6 on the interface, configure ipv6 eigrp as-number on the interface, and configure ipv6 router eigrp as-number. The router ID for the EIGRP for IPv6 process is still a 32-bit field. You can find it in the same manner that you would for the EIGRP for IPv4 process. However, the router-id ip-address command can overwrite the router ID. If the router is running only IPv6 and not IPv4, make sure to configure at least one IPv4 address to serve as a router ID for EIGRP for IPv6. The main difference between EIGRP for IPv4 and EIGRP for IPv6 is that you enable EIGRP for IPv4 on an interface by having the network command cover the IPv4 address of the interface. In contrast, you enable EIGRP for IPv6 on an interface directly by configuring the command ipv6 eigrp as-number on the interface.
Example 9-12 shows a basic EIGRP for IPv6 configuration.
Example 9-12 Basic Configuration of EIGRP for IPv6
ipv6 unicast-routing ipv6 cef
interface Loopback0 ip address 10.200.254.3 255.255.255.255
interface Serial4/0 ipv6 address 2001:DB8:4::1/64 ipv6 enable ipv6 nd prefix default ipv6 eigrp 1
ipv6 router eigrp 1 router-id 10.200.254.3
redistribute static metric 64 2000 255 1 1500
The usual EIGRP router commands are also available for EIGRP for IPv6, as you can see in Example 9-13.
Example 9-13 EIGRP for IPv6 Router Commands sydney(config)#ipv6 router eigrp 1
sydney(config-rtr)#?
default Set a command to its defaults default-information Distribution of default information default-metric Set metric of redistributed routes distance distribute-list exit log-neighbor-changes log-neighbor-warnings maximum-paths no passive-interface redistribute router-id shutdown stub timers variance
Administrative distance
Filter networks in routing updates
Exit from IPv6 routing protocol configuration mode
Enable/Disable IPv6-EIGRP neighbor logging
Enable/Disable IPv6-EIGRP neighbor warnings
Forward packets over multiple paths
Negate a command or set its defaults
Suppress routing updates on an interface
Redistribute IPv6 prefixes from another routing protocol router-id for this EIGRP process
Shutdown protocol
Set IPv6-EIGRP as stubbed router
Adjust routing timers
Control load balancing variance
Example 9-14 shows how to verify whether EIGRP for IPv6 is forming neighborships.
Example 9-14 Verifying EIGRP for IPv6 Neighbors
|
new-york#show ipv6 eigrp 1 neighbors |
||||
|
IPv6-EIGRP neighbors for process 1 |
||||
|
H Address Interface |
Hold |
Uptime SRTT |
RTO |
Q Seq |
|
(sec |
(ms) |
Cnt Num |
||
|
0 FE80::204:C0FF:FEF1:882 Se4/0 |
13 |
00:23:25 1 |
3000 |
0 1 |
Example 9-15 shows how to verify the EIGRP for IPv6 topology table. Example 9-15 Verifying EIGRP for IPv6 Topology Table
|
new-york#show ipv6 eigrp 1 topology |
|
|
IPv6-EIGRP Topology Table for AS(1)/ID(10.200.254.3) |
|
|
Codes: P - Passive, A - Active, U - Update, Q - Query, |
R - Reply, |
|
r - reply Status, s - sia Status |
|
|
P 2001:DB8:100::/64, 1 successors, FD is 2297856 |
|
|
via FE80::204:C0FF:FEF1:8820 (2297856/128256), |
Serial4/0 |
|
P 2001:DB8:4::/64, 1 successors, FD is 2169856 |
|
|
via Connected, Serial4/0 |
Example 9-16 shows how to check whether the EIGRP for IPv6 routes made it into the IPv6 routing table.
Example 9-16 Verifying EIGRP for IPv6 Routes in the IPv6 Routing Table new-york#show ipv6 route eigrp
IPv6 Routing Table - 5 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external D 2001:DB8:100::/64 [90/2297856]
via FE80::204:C0FF:FEF1:8820, Serial4/0
EIGRP for IPv6 transmits Hello packets with the link-local address of the transmitting interface as source address. The address of the EIGRP for IPv6 neighbor in the EIGRP neighbor table is the IPv6 link-local address. If you want to ping this link-local address, you do have to specify the output interface, because link-local addresses are only unique per interface. Multicast Hello packets have a destination address of FF02::A (the EIGRP for IPv6 multicast address). Packets sent to specific peers contain the unicast address of the peer. To test whether the EIGRP for IPv4 neighbors are listening, you can ping the EIGRP for IPv4 multicast address (224.0.0.10). For EIGRP for IPv6, ping the EIGRP for IPv6 multicast address (FF02::A) to verify which neighboring routers run EIGRP for IPv6. Look at Example 9-17 to learn how to perform this ping.
Example 9-17 Pinging the EIGRP for IPv6 Multicast Address new-york#ping ipv6 ff02::a
Output Interface: serial4/0 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::A, timeout is 2 seconds: Packet sent with a source address of FE80::203:6CFF:FEC8:9800
Reply to request 0 received from FE80::204:C0FF:FEF1:8820, 4 ms
Reply to request 1 received from FE80::204:C0FF:FEF1:8820, 0 ms
Reply to request 2 received from FE80::204:C0FF:FEF1:8820, 0 ms
Reply to request 3 received from FE80::204:C0FF:FEF1:8820, 0 ms
Reply to request 4 received from FE80::204:C0FF:FEF1:8820, 0 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms 5 multicast replies and 0 errors.
Multiprotocol BGP Extensions for IPv6
Multiprotocol BGP (MP-BGP) is defined in RFC 2283. This RFC also defines two new attributes: Multiprotocol Reachable NLRI (MP_REACH_NLRI) and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) carries the set of reachable destinations with the next-hop information to be used for forwarding to these destinations. The second one (MP_UNREACH_NLRI) carries the set of unreachable destinations. The first two fields in the two attributes contain the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The first one identifies the network layer protocol for the network address advertised by BGP. The second one identifies additional information about the type of Network Layer Reachability Information (NLRI) carried by the attribute. Table 9-2 lists the AFI values and their meanings.
|
AFI |
Meaning |
|
1 |
IPv4 |
|
2 |
IPv6 |
NOTE The address family numbers are listed at http://www.iana.org/numbers.html. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols.
|
SAFI |
Meaning |
|
1 |
Unicast |
|
2 |
Multicast |
|
3 |
|
|
4 |
MPLS Label |
|
128 |
MPLS-labeled VPN |
If BGP is carrying IPv6 traffic, AFI equals 2, SAFI equals 1 for Unicast, and SAFI equals 2 for multicast. When BGP peers set up their session between them, they send an OPEN message containing optional parameters. One optional parameter is capabilities. Possible capabilities are Multiprotocol extensions, route refresh, outbound route filtering (ORF), and so on. When the BGP peers exchange the Multiprotocol extension capability, they exchange AFI and SAFI numbers and thus identify what the other BGP speaker is capable of. When running BGP for unicast IPv6, BGP speakers exchange AFI/SAFI 2/1. In the case of 6PE, the BGP speakers exchange AFI/SAFI 2/4, indicating that they are capable of IPv6 and labels or IPv6 + label. In the case of 6VPE, the BGP speakers exchange AFI/SAFI 2/128, indicating that they are capable of VPNs for IPv6.
NOTE Both 6PE and 6VPE are schemes to carry IPv6 over MPLS. See the sections "Carrying IPv6 over an MPLS Backbone (6PE)" and "Carrying IPv6 in VPNs Across an MPLS Backbone (6VPE)" later in this chapter for more details.
Example 9-18 shows a BGP session being established between two BGP speakers that are capable of 6PE and 6VPE. In this example, the two speakers are also capable of Unicast IPv4 and IPv6 and MPLS VPN for IPv4, as indicated by the AFI/SAFI numbers.
Example 9-18 BGP Exchanging AFI/SAFI
|
!output has been removed for brevity |
|||||||
|
sydney#debug bgp all |
|||||||
|
BGP debugging |
is on for all address families |
||||||
|
*May 18 11:51 |
51.192 |
BGP |
10.200 |
254 |
1 |
went |
from Idle to Active |
|
*May 18 11:51 |
57.352 |
BGP |
10.200 |
254 |
1 |
went |
from Active to OpenSent |
|
*May 18 11:51 |
57.352 |
BGP |
10.200 |
254 |
1 |
sending OPEN, version 4, my as: 1, holdtime 180 |
|
|
seconds |
|||||||
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcv OPEN, version 4, holdtime 180 seconds |
|
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcv OPEN w/ OPTION parameter len: 48 |
|
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcvd |
OPEN w/ optional parameter type 2 |
|
(Capability) |
len 6 |
||||||
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has CAPABILITY code: 1, length 4 |
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has MP_EXT CAP for afi/safi: 1/1 |
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcvd |
OPEN w/ optional parameter type 2 |
|
(Capability) |
len 6 |
||||||
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has MP_EXT CAP for afi/safi: 2/1 |
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcvd |
OPEN w/ optional parameter type 2 |
|
(Capability) |
len 6 |
||||||
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has MP_EXT CAP for afi/safi: 2/4 |
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcvd |
OPEN w/ optional parameter type 2 |
|
(Capability) |
len 6 |
||||||
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has MP_EXT CAP for afi/safi: 1/128 |
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcvd |
OPEN w/ optional parameter type 2 |
|
(Capability) |
len 6 |
||||||
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has MP_EXT CAP for afi/safi: 2/128 |
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
rcvd |
OPEN w/ optional parameter type 2 |
|
(Capability) |
len 2 |
||||||
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has CAPABILITY code: 2, length 0 |
|
*May 18 11:51 |
57.356 |
BGP |
10.200 |
254 |
1 |
OPEN |
has ROUTE-REFRESH capability(new) |
|
for all address-families |
|||||||
|
BGP: 10.200.254.1 rcvd OPEN w/ remote |
AS 1 |
||||||
|
*May 18 11:51 |
57.360 |
BGP |
10.200 |
254 |
1 |
went |
from OpenSent to OpenConfirm |
|
*May 18 11:51 |
57.360 |
BGP |
10.200 |
254 |
1 |
went |
from OpenConfirm to Established |
|
*May 18 11:51 |
57.360 |
neighbor 10.200.254.1 Up |
|||||
Continue reading here: Carrying IPv6 over an MPLS Backbone
Was this article helpful?