IPv6: Mikrotik: OSPFv2 vs OSPFv3

From OnnoWiki
Revision as of 17:15, 11 January 2019 by Onnowpurbo (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

sumber: http://packetlife.net/blog/2010/mar/2/ospfv2-versus-ospfv3/




OSPFv3 is to IPv6 what OSPFv2 is to IPv4. The two versions of OSPF naturally have much in common, however there are several important differences in the way the two protocols operate. This article seeks to highlight some of the more noteworthy deviations. (For a more thorough discussion, see section 2 of RFC 5340.) For illustration, both OSPFv2 and OSPFv3 have been configured on the example topology below.

OSPFv2-OSPFv3.png

For some IOS OSPFv3 configuration fundamentals, see IPv6 and OSPFv3. New LSA Types

OSPFv3 carries over the seven basic LSA types we're familiar with from OSPFv2. However, the type 1 and 2 LSAs have been re-purposed, as will be discussed in a bit. OSPFv3 also introduces two new LSA types: Link and Intra-area Prefix.

OSPFv3	OSPFv2
0x2001	Router LSA	1	Router LSA
0x2002	Network LSA	2	Network LSA
0x2003	Inter-area Prefix LSA	3	Network Summary LSA
0x2004	Inter-area Router LSA	4	ASBR Summary LSA
0x4005	AS-External LSA	5	AS-External LSA
0x2006	Group Membership LSA	6	Group Membership LSA
0x2007	Type-7 LSA	7	NSSA External LSA
0x0008	Link LSA	
0x2009	Intra-area Prefix LSA	

Separation of Addressing from the SPF Tree

One of the biggest advantages of OSPFv3 over its predecessor is the separation of IP addressing from the calculation of the SPF tree. One of OSPFv3's new LSAs, the Intra-area Prefix LSA (type 9), handles intra-area network information that was previously included in OSPFv2 type 2 LSAs. Because IP addressing is communicated independent of the LSAs used for SPF tree calculation, adding or modifying IP subnets within the OSPF domain will not affect the integrity of the SPF tree (which is concerned only with nodes and the links between them) and avoid forcing an SPF recalculation.

For illustration, following are the two OSPF databases from R2 in our example topology:

R2# show ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)  

        Router Link States (Area 0) 

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1697        0x80000001 0x00264B 2
4.4.4.4         4.4.4.4         1693        0x80000002 0x005216 2

        Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.123.0      2.2.2.2         1683        0x80000002 0x00DEC5

        Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1656        0x80000003 0x00BB55 1
2.2.2.2         2.2.2.2         1655        0x80000003 0x008086 1
3.3.3.3         3.3.3.3         1656        0x80000003 0x003FBF 1

        Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.123.3      3.3.3.3         1656        0x80000001 0x007B0E

        Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.0.0        2.2.2.2         1694        0x80000001 0x003BB2


R2# show ipv6 ospf database

            OSPFv3 Router with ID (2.2.2.2) (Process ID 1)

        Router Link States (Area 0)

ADV Router      Age         Seq#        Fragment ID  Link count  Bits
2.2.2.2         1694        0x80000002  0            1           B
4.4.4.4         1695        0x80000002  0            1           None

        Inter Area Prefix Link States (Area 0)

ADV Router      Age         Seq#        Prefix
2.2.2.2         1692        0x80000001  2001:DB8:0:123::/64

        Link (Type-8) Link States (Area 0)

ADV Router      Age         Seq#        Link ID    Interface
2.2.2.2         1696        0x80000002  6          Se1/0
4.4.4.4         1699        0x80000002  6          Se1/0

        Intra Area Prefix Link States (Area 0) 

ADV Router      Age         Seq#        Link ID    Ref-lstype  Ref-LSID
2.2.2.2         1696        0x80000001  0          0x2001      0
4.4.4.4         1699        0x80000001  0          0x2001      0

        Router Link States (Area 1) 

ADV Router      Age         Seq#        Fragment ID  Link count  Bits
1.1.1.1         1652        0x80000005  0            1           None
2.2.2.2         1652        0x80000005  0            1           B
3.3.3.3         1649        0x80000005  0            1           None

        Net Link States (Area 1)

ADV Router      Age         Seq#        Link ID    Rtr count
3.3.3.3         1661        0x80000001  4          3

        Inter Area Prefix Link States (Area 1) 

ADV Router      Age         Seq#        Prefix
2.2.2.2         1693        0x80000001  2001:DB8::/64

        Link (Type-8) Link States (Area 1) 

ADV Router      Age         Seq#        Link ID    Interface
1.1.1.1         1697        0x80000002  4          Fa0/0
2.2.2.2         1698        0x80000002  4          Fa0/0
3.3.3.3         1696        0x80000002  4          Fa0/0

        Intra Area Prefix Link States (Area 1) 

ADV Router      Age         Seq#        Link ID    Ref-lstype  Ref-LSID
3.3.3.3         1662        0x80000001  4096       0x2002      4

Note that the OSPFv3 database appears larger, because network addressing is now stored separately in the new Link and Intra-area LSAs. LSA Flooding Scope

Looking again at the above table of LSA types, one might note that OSPFv3 LSA numbers begin with differing numbers (for example, 0x2001 versus 0x4005). The second and third most-significant bits in an LSA number (referenced as bits S2 and S1, respectively) indicate its flooding scope:

S2	S1	Flooding Scope
0	0	Link-local
0	1	Area
1	0	AS (OSPF domain)
1	1	Reserved

Most LSAs begin with 0x2, indicating that they are flooded within an area. Two LSAs of note are the AS-External LSA (which advertises external routes) with a domain-wide scope, and the Link LSA with a scope appropriately restricted to the local link.

Link-local Addressing

An OSPFv2 router forms adjacencies using its configured IPv4 interface address:

R1# show ip ospf neighbor detail
 Neighbor 2.2.2.2, interface address 10.0.123.2
    In the area 1 via interface FastEthernet0/0
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 10.0.123.3 BDR is 10.0.123.2
    Options is 0x52
    LLS Options is 0x1 (LR)
    Dead timer due in 00:00:37
    Neighbor is up for 00:15:32
    Index 2/2, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
...

OSPFv3, however, makes use of IPv6's link-local address scope (FE80::/10). All OSPFv3 adjacencies are formed using link-local addresses:

R1# show ipv6 ospf neighbor detail
 Neighbor 3.3.3.3
    In the area 1 via interface FastEthernet0/0 
    Neighbor: interface-id 4, link-local address FE80::C003:7DFF:FE07:0
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 3.3.3.3 BDR is 2.2.2.2
    Options is 0x6670B96D
    Dead timer due in 00:00:32
    Neighbor is up for 00:16:48
    Index 1/1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Also note in the second output that neighboring routers are referred to not by IP address, but by OSPF ID, demonstrating OSPFv3's fundamental separation of the SPF tree and IP addressing. It is worth pointing out that OSPFv3 router IDs are not IPv4 addresses; they are merely unique 32-bit identifiers expressed in the familiar dotted-decimal notation. Support for Multiple Instances Per Link

OSPFv3 includes support for multiple instances of OSPF running in parallel across a common link. This is especially handy for shared network segments such as those found in Internet exchange points. On Cisco IOS, OSPFv3 instances are configured by appending the instance argument to the ipv6 ospf statement:

Router(config-if)# ipv6 ospf 100 area 0 instance 1

Removal of OSPF-specific Authentication

OSPFv2 authentication is achieved by implementing a shared secret and MD5 HMAC supported as part of the OSPFv2 protocol. OSPFv3 does away its own support for authentication entirely, instead relying on the more flexible IPsec framework offered by IPv6. For more detail on how OSPFv3 authentication is configured, see OSPFv3 authentication. Improved Handling of Unknown LSA Types

OSPFv2 routers simple discard LSAs of an unknown type. OSPFv3 LSAs may be discarded, or optionally stored and flooded as though they were understood. Which action is taken is determined by the most-significant bit (the U bit) in the LSA type number. This option allows for the introduction of new LSA types across OSPF networks where only some routers support the new types. Cisco IOS Configuration Differences

Cisco notes some differences in the way OSPFv2 and OSPFv3 are configured here. A brief summary:

  • Enabling OSPF on an IPv6 interface automatically enables OSPFv3; an explicit OSPFv3 routing process does not need to be administratively created (though it likely still will be for other purposes).
  • OSPFv3 interfaces must be designated under interface configuration; there is no option to designate interfaces using the network command under router configuration.
  • NBMA neighbors must be identified by link-local IPv6 address.
  • Like OSPFv2, OSPFv3 will take its router ID from the highest-numbered IPv4 loopback interface; however, as this IPv4 address is likely irrelevant your IPv6 network, it is recommended to manually specify a router ID with the router-id command under OSPFv3 router configuration.



Referensi


Pranala Menarik