OSPFv3 for IPv4 and IPv6
OSPFv3 for IPv4 and IPv6
Cisco IOS support for OSPFv3 for multiple address families
Many enterprises use OSPF version 2 for their internal IPv4 routing protocol. OSPF has gone through changes over the years and the protocol has been adapted to work with IPv6. As organizations start to contemplate how they will deploy IPv6 at their Internet perimeters and within their enterprise networks they should be aware of OSPF version 3 and how it differs from what they are familiar with. This article reviews the differences between OSPF version 2 and OSPF version 3 and how they can be configured to work with IPv4, IPv6 and both protocols.
Brief History of OSPF
The Open Shortest Path First (OSPF) routing protocol was first conceived in the late 1980s. This was a time when the IETF was just starting to mature into an international networking standards organization. The IETF needed to develop a robust IP routing protocol suitable for larger networks. OSPF was first documented as a standard by John Moy in RFC 1131. Improvements were made in OSPF version 2, which was originally documented in RFC 1247 but later updated by RFC 2178 and then again in RFC 2328.
OSPF was then extensively modified to support IPv6. The IETF developed a new version OSPF that was specifically developed for IPv6 and was introduced in RFC 2740. Many network equipment vendors implemented OSPF for IPv6 as they developed their IPv6 products. OSPF for IPv6 (OSPF version 3) was then updated with RFC 5340. Fundamental OSPF mechanisms and algorithms unchanged but the packet and LSA formats are different in OSPFv3 because of the larger 128-bit IPv6 addresses. However, there were other subtle differences between OSPFv2 and OSPFv3 that network engineers should be aware of.
OSPFv2 and OSPFv3 Compared
Many aspects of the OSPF routing protocol remain the same between OSPFv2 and OSPFv3; such as the LSA flooding rules, the LSA aging mechanisms, and the interface types (broadcast, point-to-point, point-to-multipoint, among others). OSPFv3 Packet and LSA formats differ from OSPFv2. Specifically, OSPFv3 adds two new LSA types for Link (0x0008, tells neighbors about link-local addresses and IPv6 prefixes on link) and Intra-Area-Prefix (0x2009, IPv6 prefixes connected to a router). OSPFv2 has two flooding scope, AS wide and area wide but now OSPFv3 has three flooding scopes (noted with the S1 and S2 bits).
Here is a list of the similarities between OSPFv2 and OSPFv3:
Both are link-state Interior Gateway Protocol (IGP) routing protocols
Both use a 2-level hierarchy with Area 0.0.0.0 at the core
Both use Area Border Routers (ABRs) and Autonomous System Boundary Routers (ASBRs)
Both use the Shortest Path First (SPF) calculation within each area utilizing Edsger Dijkstra's SPF algorithm
Both use metrics that are based on interface bandwidth (or manual configuration)
Both have 5 common protocol packet types: Hello, Database description (DBD), Link-state request (LSR), Link-state update (LSU), Link-state acknowledgment (LSA)
They use similar interface types: Broadcast, P2P, P2MP, NBMA, and Virtual-Links
They have the same LSA flooding and aging timers
Here is a list of the differences between OSPFv2 and OSPFv3:
They use different address families (OSPFv2 is for IPv4-only, OSPFv3 can be used for IPv6-only or both protocols (more on this following))
OSPFv3 introduces new LSA types
OSPFv3 has different packet format
OSPFv3 uses different flooding scope bits (U/S2/S1)
OSPFv3 adjacencies are formed over link-local IPv6 communications
OSPFv3 runs per-link rather than per-subnet
OSPFv3 supports multiple instances on a single link, Interfaces can have multiple IPv6 addresses
OSPFv3 uses multicast addresses FF02::5 (all OSPF routers), FF02::6 (all OSPF DRs)
OSPFv3 Neighbor Authentication done with IPsec (AH)
OSPFv2 Router ID (RID) must be manually configured, still a 32-bit number
OSPFv3 Configuration Example
There are some differences between configuring OSPF on a Cisco IOS router for IPv6 and configuring OSPF for IPv4. For starters, OSPFv3 has more commands that are configured under the interface and a few commands configured under the routing protocol configuration block. Under each interface you configure the type of interface and the area. Technically, all you have to do is configure OSPFv3 on the IPv6-enabled interfaces and you do not need to explicitly create the IPv6 routing process configuration; it will be created automatically. You also configure OSPFv3 static neighbors in the case of NBMA links and IPsec AH authentication on the interface. You can also configure OSPFv3 to work with Virtual Routing Forwarding (VRF) instances and you can even enable multiple OSPFv3 instances on the same link. Following is a simple example of OSPFv3 configuration on a Cisco IOS 12.4T router.
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet 0/0
description Area 0.0.0.0 backbone interface
ipv6 address 2001:DB8:100:1::1/64
ipv6 ospf network broadcast
ipv6 ospf 100 area 0.0.0.0
!
interface GigabitEthernet 0/1
description Area 0.0.0.1 area interface
ipv6 address 2001:DB8:200:2::1/64
ipv6 ospf network broadcast
ipv6 ospf 100 area 0.0.0.1
!
ipv6 router ospf 100
router-id 10.1.1.1
log-adjacency-changes
passive-interface default
no passive-interface GigabitEthernet 0/0
no passive-interface GigabitEthernet 0/1
area 0.0.0.0 range 2001:DB8:100::/48
area 0.0.0.1 range 2001:DB8:200::/48
redistribute connected metric-type 1
If you are familiar with Cisco IOS show commands for OSPF, you will be ready to use these same commands for IPv6. In most cases you simply just replace the "ip" keyword with "ipv6. Here is a list of useful OSPFv3 commands.
show ipv6 route [ospf]
show ipv6 ospf
show ipv6 ospf neighbor [detail]
show ipv6 ospf database
show ipv6 ospf [process-id] [area-id] interface [interface-name]
show ipv6 ospf [process-id] [area-id] neighbor
show ipv6 ospf [process-id] [area-id] database [link | prefix | database-summary]
You can also clear out the OSPFv3 routes and reset the process with the following command.
clear ipv6 ospf [process-id] {process | force-spf | redistribution | counters [neighbor [neighbor-interface]]}
There are also many useful OSPFv3 debug command options.
debug ipv6 ospf [ adj | hello | spf | flooding | events | lsa-generation | database-timer | packets | retransmission | tree ]
OSPFv3 for Both Address Families
If an organization wanted to use OSPF for both their IPv4 and IPv6 routing protocol, then they would likely use OSPFv2 for their IPv4 routing and OSPFv3 for their IPv6 routing. This would give the organization dual control planes for dual forwarding protocols. In this configuration, if there was a problem with either routing domain then it would not affect the other IP version. The same separation could also be achieved by running two completely different routing protocols. For instance, an organization could use OSPFv2 for IPv4 and IS-IS in single-protocol single-topology mode for IPv6. Having this type of control plane and data plane separation may be exactly what some organizations are looking for.
The IETF has continued to develop OSPFv3 so that it is now capable of working with multiple address families. In much the same way as MultiProtocol Border Gateway Protocol (MP-BGP) can function as an IPv4 and IPv6 routing protocol. The new OSPFv3 RFC 5838 is titled "Support of Address Families in OSPFv3" (Later updated by RFC 6969).
Once again, Cisco changed the IOS configuration commands required for OSPFv3 configuration. The new OSPFv3 configuration uses the "ospfv3" keyword instead of the earlier "ipv6 router ospf" routing process command and "ipv6 ospf" interface commands. OSPFv3 is still configured on the interfaces similarly to how the previous OSPFv3 commands were used. However, the biggest change is in the configuration of the routing process. This new syntax is more like multi-AF configuration of BGP and you have both an IPv4 and an IPv6 address family configuration section under "router ospfv3 ". Following is how the new OSPFv3 syntax is used to configure a dual-protocol interface and for multi-address-family configuration under the OSPFv3 routing process.
ipv6 unicast-routing
ipv6 cef
!
interface GigabitEthernet 0/0
description Area 0.0.0.0 backbone interface
ip address 192.168.100.1 255.255.255.0
ipv6 address 2001:DB8:100:1::1/64
ospfv3 100 area 0 ipv4
ipv6 ospf 100 area 0
ospfv3 100 area 0 ipv6
!
interface GigabitEthernet 0/1
description Area 0.0.0.1 area interface
ip address 192.168.200.1 255.255.255.0
ipv6 address 2001:DB8:200:2::1/64
ospfv3 100 area 1 ipv4
ipv6 ospf 100 area 1
ospfv3 100 area 1 ipv6
!
router ospfv3 100
router-id 10.1.1.1
auto-cost reference-bandwidth 1000
bfd all-interfaces
log-adjacency-changes
passive-interface default
address-family ipv6 unicast
area 0 range 2001:db8:100:1::/48
area 1 range 2001:db8:200:2::/48
redistribute static
default-information originate always metric 100 metric-type 2
address-family ipv4 unicast
area 0 range 192.168.100.0 255.255.255.0
area 1 range 192.168.200.0 255.255.255.0
default-information originate always metric 100 metric-type 2
Yet again, the Cisco IOS show commands are different for this new edition of OSPFv3 configuration syntax.
show ospfv3 [process-id] [address-family] border-routers
show ospfv3 [process-id] [area-id]] [address-family] database [database-summary | internal | external [ipv6-prefix ] [link-state-id] | grace | inter-area prefix [ipv6-prefix | link-state-id] | inter-area router [destination-router-id | link-state-id] | link [interface interface-name | link-state-id] | network [link-state-id] | nssa-external [ipv6-prefix] [link-state-id] | prefix [ref-lsa {router | network} | link-state-id] | promiscuous | router [link-state-id] | unknown [{area | as | link} [link-state-id]] [adv-router router-id] [self-originate]
show ospfv3 [process-id] [address-family] events [generic | interface | lsa | neighbor | reverse | rib | spf]
show ospfv3 [process-id] [area-id] [address-family] flood-list interface-type interface-number
show ospfv3 [process-id] [address-family] graceful-restart
show ospfv3 [process-id] [area-id] [address-family] interface [type number] [brief]
show ospfv3 [process-id] [area-id] [address-family] neighbor [interface-type interface-number] [neighbor-id] [detail]
show ospfv3 [process-id] [area-id] [address-family] request-list[neighbor] [interface] [interface-neighbor]
show ospfv3 [process-id] [area-id] [address-family] retransmission-list [neighbor] [interface] [interface-neighbor]
show ospfv3 [process-id] [address-family] statistic [detail]
show ospfv3 [process-id] [address-family] summary-prefix
show ospfv3 [process-id] [address-family] timers rate-limit
show ospfv3 [process-id] [address-family] traffic[interface-type interface-number]
show ospfv3 [process-id] [address-family] virtual-links
You can force an OSPFv3 SPF calculation using the following command
clear ospfv3 [force-spf | process | redistribution ]
Summary
OSPF has had a long history as a premier IP routing protocol. OSPF has continued to stay relevant by adapting to IPv6 and is now evolved into a fully dual-protocol multi-AF routing protocol. Organizations now have multiple options for deploying OSPF. Organizations can stick with OSPFv2 for IPv4, and then use OSPFv3 for IPv6-only for a configuration that separates the control planes and the forwarding planes. Organizations can now combine the configuration of IPv4 and IPv6 into a single OSPFv3 process that can work equally well for both IP protocols.
OSPF routers create a routing table showing the shortest-path routes through the network. When a component fails, the routers automatically reroute around it. Routers build these tables based on their link state database, which they populate based on link state advertisements (LSAs) from other routers in the network. LSAs are the means by which the network maintains its current knowledge about routing traffic.
There are 11 types of LSA:
Type # | LSA Name | Description |
1 | Router | A router sends this to describe neighbors and its own interfaces. |
2 | Network | For broadcast networks only; the designated router for the broadcast segment uses this to list all the routers connected to the segment directly. |
3 | Summary | A router touching multiple areas of the network uses this to summarize information about one of those areas to update the other areas. |
4 | ASBR-summary | Sent by a border router that has sent a Type 5 LSA to describe how to get to that border router via the internal network. |
5 | AS-external | Sent by a border router to describe external routes through itself. Can be used to advertise "this is the way to (all or part of) the Internet." |
6 | Group membership | Used in a now obsolete multicast version of Multicast Open Shortest Path First (MOSPF). Most routers no longer support MOSPF; this LSA may be reassigned in the future. |
7 | NSSA External | OSPF stub areas are those without a direct path to the outside; they do not allow Type 5 LSAs in, and all externally bound traffic is just routed out through the stub area’s boundary router. A “not so stubby area” (NSSA) has some limited external routes available; they are advertised within the NSSA using Type 7 LSAs. The NSSA’s boundary routers translated Type 7 LSAs into Type 5 LSAs to flood into adjacent areas. |
8 | External Attributes | In OSPFv2, this was used to convey BGP link attributes into an OSPF network, but it was rarely implemented. In OSPFv3, it has been repurposed to send information about all of the IPv6 address information associated with the local link. |
9 | Intra-Area-Prefix (was Link-local Opaque) | Communicates prefixes for stub areas and for transit networks, in OSPFv3. (In OSPFv2, it was a link-local “opaque” field, conveying information passed on by OSPF routers but not used for OSPF routing.) |
10 | Area-Local Opaque | Flooded to area routers even if the router doesn’t understand the information within. Used by applications to extend OSPF functionality, e.g. for MPLS traffic engineering. |
11 | AS Opaque | Like a Type 10, is not flooded into stubs, as with Type 5 LSAs. |
0 Response to "OSPFv3 for IPv4 and IPv6"
Post a Comment