Thursday, February 6, 2014

NTS: OSPFv2/OSPFv3

OSPFv2/OSPFv3




OSPFv2 (Open Shortest Path First v2) is defined in RFC 2328.
OSPFv3 is defined in RFC 5340.
OSPFv2 as PE/CE protocol is defined in RFC 4577.



OSPF is protocol 89.

Sends updates to multicast 224.0.0.5 (all OSPF routers) and 224.0.0.6 (all DR routers)



Adjacencies

Adjacency can be formed between different networks if "ip unnumbered" is used on both sides.

If multiple "network" commands are used, the most specific wins.

The following must match for adjacency to be successful:
  • area
  • hello/dead timers
  • mtu
  • network type
  • stub
  • authentication

DR election per network type
  • DR/BDR
    • broadcast (default on ethernet, multicast hellos)
    • non-broadcast (default on frame-relay, unicast hellos)
  • no DR/BDR
    • point-to-point (default on serial/pos, multicast hellos)
    • point-to-multipoint (multicast hellos)
    • point-to-multipoint non-broadcast (unicast hellos)

Use the "neighbor" command to send unicast hellos.

You can use the commands "ip ospf hello-interval" and "ip ospf dead-interval" in order to tune the convergence time. Fast hellos (1 sec) are also possible using the "minimal" keyword.



By default the loopback interface is advertised as a /32 (stub). Use network-type point-to-point under the loopback interface to advertise it with the original subnet mask.



Path Selection

  • "bandwidth" under the interface (not applicable to IOS-XR)
  • "ip ospf cost" under the interface
  • "auto-cost reference-bandwidth" under the ospf process
  • "neighbor x.x.x.x cost" under the ospf process



OSPF Route Preference

O - OSPF (intra-area)
IA - OSPF inter area
E1 - OSPF external type 1
E2 - OSPF external type 2
N1 - OSPF NSSA external type 1
N2 - OSPF NSSA external type 2
      
Distance and metric are evaluated as a second step, between routes of same type.



LSAs

LSA types carried in IPv6 Stub areas:
  • Router-LSAs
  • Network-LSAs
  • Inter-Area-Prefix-LSAs
  • Link-LSAs
  • Intra-Area-Prefix-LSAs

LSA types carried in IPv6 NSSA areas:
  • Router-LSAs
  • Network-LSAs
  • Inter-Area-Prefix-LSAs
  • Link-LSAs
  • Intra-Area-Prefix-LSAs
  • NSSA-LSAs

LSA types carried in IPv4 Stub areas:
  • Router-LSAs
  • Network-LSAs
  • Summary-LSAs

LSA types carried in IPv4 NSSA areas:
  • Router-LSAs
  • Network-LSAs
  • Summary-LSAs
  • NSSA-LSAs




NSSA

The NSSA ASBR redistributes routes into OSPF and originates the Type-7 LSAs.

Type-7 LSAs are only flooded within the originating NSSA area.

Type-7 LSAs have a propagate (P) bit that, when set, tells an NSSA ABR to translate a Type-7 LSA into a Type-5 LSA.

The NSSA ABR translates Type-7 LSAs into Type-5 LSAs and floods them into area 0.

If there are multiple NSSA ABRs, the router with the highest Router ID is elected as the translator.

The NSSA ASBR and the NSSA ABR can be the same router.

Preference between two Type-7 LSAs is determined by the following tie breaker rules:
  • An LSA with the P-bit set is preferred over one with the P-bit clear
  • If the P-bit settings are the same, the LSA with the higher router ID is preferred

Links



LSDB optimization

You can decrease the LSA DB size by doing one or more of the following:
  • configure interfaces as unnumbered
  • remove network LSAs (caused by DRs) by using point-to-point as network type on interfaces
  • remove transit prefixes by activating prefix-suppression 

Prefixes that will be removed by prefix-suppression can be found under "Link connected to: a Stub Network" in Router LSAs (loopbacks, secondary IPs and passive interfaces are excluded).



LSA flood-reduction

OSPF requires every LSA to be refreshed by default every 1800 seconds (30 mins) or else the LSA will expire when it reaches 3600 seconds (1 hour).

When flood-reduction is enabled on a router (towards a neighbor), then this router will flood its self-originated LSAs with the DoNotAge (DNA) bit set, so they do not have to be re-flooded every 30 mins. Of course any change in the contents of the LSA will cause the new LSA to be re-flooded (again with the DoNotAge bit set).

IOS
interface X
 ip ospf flood-reduction
 ipv6 ospf flood-reduction


IOS-XR
router ospf X
 flood-reduction enable
 area 0
  flood-reduction enable
  interface X
   flood-reduction enable



In IOS-XR, flood-reduction can be configured under the ospf process, under a specific area and under a specific interface.

Prefer to enable it on stable topologies.

The demand-circuit offers the same functionality plus the suppression of periodic hello packets.

Links



Route Filtering

  • distribute-list
    • in: filter the routes from entering the RIB
    • out: filter the redistributed routes (E1/E2) entering OSPF on an ASBR
  • stub area
    • stub (filter LSA-5)
    • totally stub (filter LSA-3/4/5)
    • nssa (filter LSA-5, allow LSA-7)
    • totally nssa (filter LSA-3/4/5, allow LSA-7)
  • LSA-3 prefix filter
    • "area x filter-list prefix x"



LSA Searching

Depending on what type of LSAs you're searching for, you can use the following commands to do so:

IOS
sh ip ospf database router | i Link State ID  
  Link State ID: x.x.x.x
 

sh ip ospf database network | i Link State ID
  Link State ID: x.x.x.x (address of Designated Router) 

sh ip ospf database summary | i Link State ID
  Link State ID: x.x.x.x (Summary Network Number)
 
sh ip ospf database asbr-summary | i Link State ID
  Link State ID: x.x.x.x (AS Boundary Router address)

sh ip ospf database external | i Link State ID
  Link State ID: x.x.x.x (External Network Number)
 


IOS-XR
sh ospf database router | i Link State ID
  Link State ID: x.x.x.x
 

sh ospf database network | i Link State ID
  Link State ID: x.x.x.x (address of Designated Router)

sh ospf database summary | i Link State ID
  Link State ID: x.x.x.x (Summary Network Number)
 

sh ospf database asbr-summary | i Link State ID
  Link State ID: x.x.x.x (AS Boundary Router address)

sh ospf database external | i Link State ID
  Link State ID: x.x.x.x (External Network Number)


Searching for IPv6 is a little bit different, because the IPv6 prefix information is stored in another attribute.




Summarization

  • Type-3 summary
    • at ABR
    • area x range 10.10.10.0 255.255.255.0 (IOS)
    • area 1 range 10.10.10.0/24 (IOS-XR)
  • Type-5 summary
    • at ASBR
    • summary-address 20.20.20.0 255.255.255.0 (IOS)
    • summary-prefix 20.20.20.0/24 (IOS-XR)

Both types of summarization can also accept "not-advertise" as parameter.

Sub-routes must pre-exist in order for the summaries to be advertised.



OSPFv3

Multicast addresses have become FF02::x from 224.0.0.x (where x=5 for all OSPF routers, or x=6 for all DR routers).

If there is no IPv4 address assigned to any interface, then you must manually configure an IPv4-formatted router-id under the OSPFv3 process.

OSPFv3 runs per-link instead of per-subnet.

You cannot automatically detect OSPFv3 neighbors when using NBMA interfaces. You must manually configure your router to detect neighbors when using an NBMA interface.

All manually configured neighbors in OSPFv3 must be identified by their link-local IPv6 address.

On all OSPFv3 interfaces except virtual links, OSPFv3 packets are sent using the interface's associated link-local unicast address as the source address.

On virtual links, a global scope IPv6 address must be used as the source address for OSPFv3 packets.

Router-LSAs (Type-1) and Network-LSAs (Type-2) no longer contain network addresses, but simply express topology information.

Link-LSAs (Type-8) include the prefixes which are configured on links and are flooded only on local-link scope. Link-local addresses appear only in Link-LSAs.

For Stub areas, the Inter-area Prefix LSA can only be a default route.
For NSSA areas, the AS-External LSA can also be a default route.


IOS
ipv6 router ospf 1
 router-id 2.2.0.2 
!
interface Ethernet1/0
 ipv6 ospf 1 area 0



IOS-XR
router ospfv3 1
 router-id 2.2.0.8
 address-family ipv6 unicast
 area 0
  interface Loopback0
   passive
  !
  interface GigabitEthernet0/2/1/1



A use for running multiple OSPFv3 instances is to have a single link belong to two or more OSPFv3 areas.
Also on a LAN you can have multiple adjacencies between different routers, each one on a separate OSPFv3 process/instance.



OSPFv2 Authentication

  • Null (Type 0)  - default
  • Plain-text (Type 1)
  • MD5 (Type 2)

In IOS, you can configure the authentication type under the ospf process or under the interface.

IOS
router ospf 1
 area 0 authentication
!
interface X
 ip ospf authentication
 ip ospf authentication-key xxx


IOS
router ospf 1
 area 0 authentication message-digest
!

interface X
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 xxx


In IOS-XR, you can configure the authentication type/key under the ospf process, under the area or under the interface.

IOS-XR
router ospf 1
 authentication-key xxx
 authentication
 area 0
  authentication-key xxx
  authentication
  interface X
   authentication-key xxx
   authentication



IOS-XR
router ospf 1
 authentication message-digest
 message-digest-key 1 md5 xxx

  area 0
  authentication message-digest
  message-digest-key 2 md5 xxx

  interface X   authentication message-digest
   message-digest-key 3 md5 xxx



You can always use various combination of enabling authentication for a specific area (under the ospf process) or for a specific adjacency (under the interface).

More specific configurations override the less specific ones.



OSPFv3 Authentication

You can configure an authentication (AH) or encryption (ESP) policy, either on an interface or for an OSPFv3 area/process.

IPSec AH
  • Authentication
    • MD5
    • SHA1

IPSec ESP
  • Encryption
    • 3DES
    • AES (128,192,256 bits)
    • DES
    • NULL
  • Authentication
    • MD5
    • SHA1

To use the IPsec AH (for authentication), you must use commands with the "authentication" keyword.

To use the IPsec ESP (for authentication & confidentiality), you must use commands with the "encryption" keyword.

ESP may use encryption and authentication or only authentication (when encryption=null), but is not recommended.


IOS
ipv6 router ospf 1
 area 0 authentication ipsec spi 256 md5 yyy

 area 0 encryption ipsec spi 256 esp 3des md5 yyy
!
interface X
 ipv6 ospf authentication ipsec spi 256 md5 zzz
 ipv6 ospf encryption ipsec spi 256 esp 3des md5 zzz

 
IOS > 12.3(4)T is required for OSPFv3 IPsec authentication.


IOS-XR
router ospfv3 1
 authentication ipsec spi 256 md5 password xxx
 encryption ipsec spi 256 esp 3des password xxx

!
 area 0

  authentication ipsec spi 256 md5 password yyy
  encryption ipsec spi 256 esp 3des password yyy

!
  interface GigabitEthernet0/2/1/1.78
   authentication ipsec spi 256 md5 password zzz
   encryption ipsec spi 256 esp 3des password zzz



More specific configurations override the less specific ones.

Links



Options Bits

Hello/DBD/LSA Options Bits
  • V6 bit: It should be set, unless the router will not participate in IPv6 topology calculation and IPv6 transit routing. If this bit is clear, the router/link should be excluded from any IPv6 routing calculations.
  • R bit: It should be set, unless the router will not participate in any transit routing. It allows the router to participate in the unicast topology, but does not allow transit traffic.
  • E bit: It should be set if the interface attaches to a regular area (i.e., not a stub or NSSA area).
  • N bit: It should be set if the interface attaches to an NSSA area.
  • DC bit: This bit describes the router's handling of demand circuits. It should be set in Hellos/DBDs if the router wishes to suppress the sending of future Hellos over the interface. It should be set in LSAs, if the router can correctly process the DoNotAge bit when it appears in the LS age field of LSAs.

IPv6 Prefix Options Bits
  • NU bit: The "No Unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations. If not set, it should be included.
  • LA bit: The "Local Address" capability bit. If set, the prefix is actually an IPv6 interface address of the Advertising Router.
  • P bit: The "Propagate" bit. Set on NSSA area prefixes that should be readvertised by the translating NSSA area border.
  • DN bit: The "Down" bit. This bit controls an inter-area-prefix-LSAs or AS-external-LSAs re-advertisement in a VPN environment. It is used for loop prevention in PE=>CE=>PE advertisements and should not be checked in CE multi-vrf (vrf-lite) scenarios.



Special multi-hop adjacencies
  • virtual-link
    • connects two areas 0 or extends area 0 across a transit area
    • uses a transit area in order to connect areas 0 or extend area 0
    • used in normal environments with multiple areas 0 or area 0 extension
    • configured betweens two ABRs under the OSPF process
  • sham-link
    • connects two areas X (including 0)
    • uses the MPLS core in order to connect the areas
    • used in MPLS VPN environments with backdoor links
    • configured betweens two PEs/ABRs under the OSPF vrf process

Virtual-Link

All areas in an OSPF autonomous system must be connected to area 0. When this is not possible in terms of direct connectivity, then a virtual-link can be used in order to connect the non-backbone areas to area 0, as long as there is a common area between them.

  • connect two areas 0
    • R1 <=(area 0)=> R2 <=(area 1)=> R3 <=(area 0)=> R4
    • a virtual link can be configured between ABRs R2,R3 that connect to area 0 from different sides and have a common area between them
  • extend area 0 
    • R1 <=(area 0)=> R2 <=(area 1)=>R3 <=(area 2)=> R4
    • a virtual link can be configured between ABRs R2,R3 that connect to a common area, with only one ABR directly connected to area 0.
    • area 0 is extended to R3, in order to serve area 2
If a common area does not exist between the ABRs, then an additional area can be created to become the transit area.

The transit area through which the virtual link is configured, must have full routing information, so it cannot be any type of stub area. If this is the case, a GRE tunnel can be used to connect the two areas 0.


For virtual-links in OSPFv3 you have to use the remote neighbor's router-id (IPv4 format).

ABR #1

IOS
router ospf 1
 area 1 virtual-link 2.2.2.2

IOS-XR
router ospf 1
 area 1

  virtual-link 2.2.2.2


ABR #2

IOS
router ospf 1
 area 1 virtual-link 3.3.3.3

IOS-XR
router ospf 1
 area 1

  virtual-link 3.3.3.3


Sham-Link

To make a route through an MPLS backbone appear to be an intra-area route, it is necessary to make it appear as if there is an intra-area link connecting the two PE routers. A sham link can be thought of as a indirect relation between two VRFs.  If two VRFs are to be connected by a sham link, each VRF must be associated with a "Sham Link Endpoint Address", a 32-bit IPv4 address that is treated as an address of the PE router containing that VRF.

The Sham Link Endpoint Address is an address in the VPN's address space, not the SP's address space.  It must not be advertised inside customer's OSPF, because when there is no BGP VPNv4 route to the Sham Link Endpoint Address, that address must become unreachable, so that the sham link comes down.

The sham link is an unnumbered point-to-point intra-area link and is advertised as a type 1 LSA.

Sham links are treated as OSPF Demand Circuits. This means that LSAs will be flooded over them, but periodic refresh traffic will be avoided. Normal flooding is done over the backdoor link, but if that fails, flooding will occur over the sham-link (because LSA synchronization between sites must continue).

Configuration Steps
  • Create a /32 loopback that belongs to the relevant VRF on both PEs
  • Advertise the above /32 into BGP VPNv4 on both PEs
  • Don't advertise the above /32 into the OSPF vrf process on both PEs
  • Create a sham-link between the above /32 of the PEs under the OSPF vrf process

PE1

IOS
interface Loopback1
 vrf forwarding VPN
 ip address 1.1.1.1 255.255.255.255
!

router ospf 100 vrf VPN
 area 0 sham-link 1.1.1.1 2.2.2.2


IOS-XR
interface Loopback1
 vrf VPN

 ipv4 address 1.1.1.1/32
!
router ospf 100
 vrf VPN
  area 0
   sham-link 1.1.1.1 2.2.2.2



PE2

IOS
interface Loopback1
 vrf forwarding VPN
 ip address 2.2.2.2 255.255.255.255

!
router ospf 100 vrf VPN
 area 0 sham-link 2.2.2.2 2.1.1.1


IOS-XR
interface Loopback1
 vrf VPN

 ipv4 address 2.2.2.2/32
!

router ospf 100
 vrf VPN
  area 0
   sham-link 2.2.2.2 1.1.1.1



Verification

IOS
R1#sh ip ospf sham-links
Sham Link OSPF_SL0 to address 2.2.2.2 is up
Area 0 source address 1.1.1.1
  Run as demand circuit
  DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40,
    Hello due in 00:00:04
    Adjacency State FULL (Hello suppressed)
    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



R1#sh ip ospf interface | b _SL
OSPF_SL0 is up, line protocol is up
  Internet Address 0.0.0.0/0, Area 0
  Process ID 100, Router ID 10.10.10.1, Network Type SHAM_LINK, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Configured as demand circuit.
  Run as demand circuit.
  DoNotAge LSA allowed.
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:06
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 10.10.10.2  (Hello suppressed)
  Suppress hello for 1 neighbor(s)



R1#sh ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
...
10.10.10.2        0   FULL/  -           -        2.2.2.2
         OSPF_SL0
...


R1#sh ip ospf neighbor detail | b 2.2.2.2
 Neighbor 10.10.10.2, interface address 2.2.2.2
    In the area 0 via interface OSPF_SL0
    Neighbor priority is 0, State is FULL, 6 state changes
    DR is 0.0.0.0 BDR is 0.0.0.0
    Options is 0x32 in Hello (E-bit, L-bit, DC-bit)
    Options is 0x72 in DBD (E-bit, L-bit, DC-bit, O-bit)
    LLS Options is 0x1 (LR)
    Neighbor is up for 00:12:16
    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



IOS-XR
GSR#sh ospf vrf VPN sham-links

Sham Links for OSPF 2, VRF VPN

Sham Link OSPF_SL0 to address 2.2.2.2 is up
Area 0, source address 1.1.1.1
IfIndex = 2
  Run as demand circuit
  DoNotAge LSA allowed., Cost of using 1
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:08
    Adjacency State FULL (Hello suppressed)
    Number of DBD retrans during last exchange 0
    Index 2/2, retransmission queue length 0, number of retransmission 0
    First 0(0)/0(0) Next 0(0)/0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec



Both sham-links and virtual-links can have most of their "interface" attributes (hellos, cost, authentication, etc.) configured (IOS-XR gives more options).

The OSPF Sham Link endpoint address must not be used as the endpoint address of an OSPF Virtual Link.



OSPF Multi-Area

Applicable to OSPFv2 and OSPFv3.

It allows a link to be configured in more than one area, so that the link could be considered as an intra-area link in all those areas and get preference over inter-area links.

It exists as a logical construct over an existing primary interface for OSPF; however, the neighbor state on the primary interface is independent of the multi-area interface.

Only point-to-point adjacencies are supported.

IOS
interface Ethernet 0/0
 ip ospf 1 area 0
 ip ospf multi-area 1


IOS-XR
router ospf 1
 area 0
  interface GigabitEthernet0/2/1/2
 area 1
  multi-area-interface GigabitEthernet0/2/1/2
 area 2
  multi-area-interface GigabitEthernet0/2/1/2


The multi-area interface inherits the interface characteristics from its primary interface, but some interface characteristics can be configured under the multi-area interface configuration.

It also inherits the BFD characteristics from its primary interface.




OSPF Multiple-instance

Both IOS and IOS-XR allows you to run multiple OSPFv3 instances. Peer routers need to use the same instance-id for ospfv3 communication to happen.

Also, OSPFv3 can support multiple address-families using a different instance per address-family.

Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.



Although the relevant RFC defines the mechanism to differentiate packets for different instances sent and received on the same interface, Cisco's current IOS implementation allows you to have multiple OSPFv2 processes (not instances) using only different interfaces. Some of these processes can be VRF ones.


Links




No comments:

Post a Comment