Network Enhancers - "Delivering Beyond Boundaries" Headline Animator

Showing posts with label OSPF. Show all posts
Showing posts with label OSPF. Show all posts

Tuesday, April 30, 2013

Things to Remember in OSPF


DR and BDR

DR - Designated Router and BDR backup designated Router are Routers on a Broadcast segment. For example Ethernet a DR and optionally an BDR is chosen. The election is based on
  • The highest priority on the interface
    • Default priority is 1. Can be set in the range 0 - 255
    • If priority is set to 0 the router can not be a DR
    • The priority is set on a per-link basis.
  • The highest RID - Router ID
interface fastethernet 0/0
 ip ospf priority 255

RID: Router ID

The RID is the IP address which the Router is known as.
  1. Set manually
  2. Highest Loopback IP address
  3. Highest IP address if no Loopbacks defined
interface Loopback 0
 ip address 10.10.10.1
!
interface Loopback 1
 ip address 192.168.10.1
!
router ospf 1
  router-id 10.10.10.1

Stub Areas

OSPF RFC's describe Stub and Not-So-Stubby-Area. Totally Stub Area is a Cisco proprietary standard.

What is Stub Areas

Stub Areas are part of a network which don't need to have a copy of the total Link-State database. It reduces the memory requirements and CPU overhead of the router. Often stub areas only have a default gateway.

Stub Area

  • Stub Areas blocks Type 5 LSA's. (External Routes)
    • Routing to the outside world is based on a default route.
    • A Stub Area will accept Summary Routes from other Areas.

Totally Stub Area

  • totally Stub Areas blocks Type 3,4 and 5 LSA's. Only a default gateway.
    • Has a default route out of the Area,

NSSA: Not So Stubby Area

  • A NSSA imports a limited number of External Routes. The number of Routes is limited to those Routes required to provide connectivity between Areas.

Example

Example

Stub Area example


Example

Totally Stub Area example


Example

NSSA: Not So Stubby Areas


Example

Example

Example

Example

Virtual links


Example

Example

Example

Single Area configuration

Example 1


Example network 1



hostname R1
!
interface fastethernet 0/0
  ip address 192.168.0.1 255.255.255.0
!
interface fastethernet 0/1
  ip address 10.0.1.1 255.255.255.0
!
router ospf 88
  network 192.168.0.0 0.0.0.255 area 0
  network 10.0.1.0 0.0.0.255 area 0
hostname R2
!
interface fastethernet 0/0
  ip address 192.168.0.2 255.255.255.0
!
interface fastethernet 0/1
  ip address 10.0.2.1 255.255.255.0
!
router ospf 77
  network 192.168.0.0 0.0.0.255 area 0
  network 10.0.2.0 0.0.0.255 area 0
hostname R3
!
interface fastethernet 0/0
  ip address 192.168.0.3 255.255.255.0
!
interface fastethernet 0/1
  ip address 10.0.3.1 255.255.255.0
!
interface serial 0/0
  ip address 172.16.0.1 255.255.255.252
!
router ospf 66
  network 192.168.0.0 0.0.0.255 area 0
  network 10.0.3.0 0.0.0.255 area 0
  network 172.16.0.0 0.0.0.3 area 0
hostname R4
!
interface fastethernet 0/1
  ip address 10.0.4.1 255.255.255.0
!
interface serial 0/0
  ip address 172.16.0.2 255.255.255.252
router ospf 66
  network 172.16.0.0 0.0.0.3 area 0
  network 10.0.4.0 0.0.0.255 area 0

Default administrative Distance

 

Cisco implementation


Default Administrative Distance (metric)
Route SourceDistance
Connected Interface0
Static Route out an Interface0
Static Route to a next hop1
EIGRP summary route5
External BGP20
Internal EIGRP90
IGRP100
OSPF110
IS-IS115
RIP (Version 1 og 2)120
EGP140
ODR (On Denmand Routing)160
External EIGRP170
Internal BGP200
Ukendt source255

 

LSA Types

 

LSA Types
Type ABR Sent to Meaning
1 O 224.0.0.5 Router Link: Indeholder alle Routerens Links. Floodes til Area
2 O 224.0.0.6 Network Link: Floodes fra DR til Area. Indeholder alle Naboer på MA-medie
3 O IA Summary Link: Sendes fra Area til Area gennem ABR. Indeholder IA Summaries.
4 O IA ASBR summary Link: Sendes fra ASBR’s. Indeholder externe router.
5 O E1/2 Externe Router fra ASBR. E1 intern + extern cost. E2 kun extern cost.
7 O E1/2 Externe Routes fra ASBR i NSSA
8 OSPF and BGP internetworking
9,10,11 Opaque LSA used by Cisco for MPLS

 

The following are descriptions of each type of LSA.

 

Type 1


Every router generates router link advertisements for each area to which it belongs. A type 1 LSA describes the collective states of the directly connected links (interfaces) of the router. These LSAs are flooded only within the area in which they are originated.

 

  Type 2


A type 2 LSA is generated for every transit broadcast and NBMA network within an area. A transit network has at least two directly attached OSPF routers. Ethernet is an example of a transit network.
The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, as well as the subnet mask used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.

Type 3


The ABR sends type 3 summary LSAs. Type 3 LSAs advertise any networks owned by an area to the rest of the areas in the OSPF autonomous system, as shown in Figure .
The link-state ID is set to the network number; the mask is also advertised.

By default, OSPF does not automatically summarize groups of contiguous subnets or summarize a network to its classful boundary. The network operator uses configuration commands to specify how the summarization occurs. By default, a type 3 LSA is advertised into the backbone area for every subnet defined in the originating area, which can cause significant flooding problems. Consequently, you should always consider using manual route summarization at the ABR.

Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.

Note By default, summary LSAs do not contain summarized routes.

Type 4

A type 4 summary LSA is generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR router ID. All traffic destined to an external autonomous system requires routing table knowledge of the ASBR that originated the external routes.

In Figure , the ASBR sends a type 1 router LSA with an external bit (e bit) that is set to identify itself as an ASBR. When the ABR, which is identified with a border bit (b bit) in the router LSA, receives the type 1 LSA, it builds a type 4 LSA and floods it to the backbone (area 0). Subsequent ABRs regenerate a type 4 LSA to flood into their areas.

Type 5

Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.

The link-state ID is the external network number. Because of the flooding scope, and depending on the number of external networks, the default lack of route summarization can be a major issue with external LSAs. Therefore, you should summarize blocks of external network numbers at the ASBR to reduce flooding problems.

Type 6

Type 6 LSAs are specialized LSAs that are used in multicast OSPF applications.

Type 7

Type 7 is an LSA type that is used in not-so-stubby areas (NSSAs). They are originated by ASBRs within NSSAs and are flooded only within the NSSA in which they originated.

Type 8

Type 8 is a specialized LSA that is used in internetworking OSPF and Border Gateway Protocol (BGP).

Types 9, 10, and 11

The opaque LSAs, types 9, 10, and 11, are designated for future upgrades to OSPF for application-specific purposes. For example, Cisco Systems uses opaque LSAs for Multiprotocol Label Switching (MPLS) with OSPF. Opaque LSAs are distributed using standard LSDB flooding mechanisms. Each type has a different flooding scope.

Notes

  • loopback interfaces advitces as /32 unless ip ospf network point-to-point command is run on the Interface. 
 

Saturday, November 24, 2012

OSPF Basics


What Is OSPF?
• Open Shortest Path First
• Link State Protocol using the Shortest Path First algorithm (Dijkstra) to calculate loop-free routes
• Used purely within the TCP/IP environment
• Designed to respond quickly to topology changes but using minimal protocol traffic
• Used in both Enterprise and Service Provider Environment
• Uses IP protocol 89
• Metric is cost, based on interface bandwidth by default (10^8 / BW in bps)
• Sends partial route updates only when there are changes
• Send hello packets every 10 sec with dead timer of 40 sec over Point to Point & Broadcast networks
• Send hello packets every 30 sec with dead timer of 120 sec over NBMA networks
• Uses multicast address 224.0.0.5 (ALL SPF Routers)
• Uses multicast address 224.0.0.6 (ALL DR Routers)

Different Types of OSFP LSAs1. Router Link State Advertisement (Type 1 LSA)
2. Network Link State Advertisement (Type 2 LSA)
3. Summary Link State Advertisement (Type 3 and Type 4 LSA)
4. External Link State Advertisement (Type 5 LSA)

Different types of OSPF Packet
1. Hello
2. Database description
3. Link State Request
4. Link State Update
5. Link State Acknowledgement

Different Types of OSPF Areas
Regular Area: ABRs forward all LSAs from backbone
• Summary LSA (summarized/non-summarized) from other areas injected
• External links injected

Stub Area: A stub area is an area with single exit point (if you need multiple exit points then configure it as NSSA) into which External LSA are not flooded
• Summary LSAs from other areas injected
• LSA type 5 not injected
• Default LSA injected into area as Summary LSA
• Define all routers in area as stub
• External link flaps will not be injected
Consolidates specific external links— default 0.0.0.0
Used in networks with a lot of LSA Type 5

Totally Stubby Area
A Totally Stubby Area Forwards Default Link 0.0.0.0
The ABR will block not only the AS External LSAs bit also all Summary LSAs, except a single Type 3 LSA to advertise the default route.

Not So Stubby Areas (NSSA)
Benefits of stub area, but ASBR is allowed

New type external LSA (type 7)
• Type 7 LSAs flooded throughout the area
• No type 5 external LSAs in the area
• Type 7 LSAs will be converted into type 5 LSAs when flooded into area 0 by ABRs
Filtering and summaries allowed at ABRs

Areas are used to make OSPF Scale
• OSPF uses a 2 level hierarchical model
• One SPF per area, flooding done per area
• Regular, Stub, Totally Stubby and NSSA Area Types
• A router has a separate LS database for each area to which it belongs
• All routers belonging to the same area should have identical databases
• SPF calculation is performed independently for each area
• LSA flooding is bounded by area
• If any link flaps in the area it takes nlogn calculations where n is the number of the links in the area


 

Friday, November 23, 2012

OSPF High Availability with SSO,NSF and NSR


Nonstop Forwarding with Stateful Switchover (NSF/SSO) are redundancy mechanisms for intra-chassis route processor failover.

SSO synchronizes Layer 2 protocol state, hardware L2/L3 tables (MAC, FIB, adjacency table), configuration, ACL and QoS tables.

NSF gracefully restarts routing protocol neighbor relationships after an SSO fail-over

1. Newly active redundant route processor continues forwarding traffic using synchronized HW forwarding tables.
2. NSF capable routing protocol (eg: OSPF) requests graceful neighbor restart.Routing neighbors reform with no traffic loss.
3. Cisco and RFC3623 as per standard.
4. Graceful Restart capability must always be enabled for all protocols. This is only necessary on routers with dual processors that will be performing switch overs.
5. Graceful Restart awareness is on by default for non-TCP based interior routing protocols (OSPF,ISIS and EIGRP). These protocols will start operating in GR mode as soon as one side is configured.
6. TCP based protocols (BGP) must enable GR on both sides of the session and the session must be reset to enable GR. The information enabling GR is sent in the Open message for these protocols.

Nonstop Routing (NSR) is a stateful redundancy mechanism for intra chassis route processor (RP) failover.

NSR , unlike NSF with SSO, 1. Allows routing process on active RP to synchronize all necessary data and states with routing protocol process on standy RP.
2. When switchover occurs, routing process on newly active RP has all necessary data and states to continue running without requiring any help from its neighbor(s).
3. When switchover occurs, routing process on newly active RP has all necessary data and states to continue running without requiring any help from its neighbor(s).
4. Standards are not necessary as NSR does NOT require additional communication with protocol peers
5. NSR is desirable in cases where routing protocol peer doesn’t support Cisco or IETF standards to support Graceful Restart capabilities exchange.
6. NSR uses more system resources due to information transfer to standby processor.

Deployment Considerations for SSO/NSF and NSR

1. From a high level, you need to protect the interfaces (SSO), the forwarding plane (NSF) and the control plane (GR or NSR).
2. Enabling SSO also enables NSF.
3. Each routing protocol peer needs to be examined to ensure that both its capability has been enabled and that its peer has awareness enabled.
4. While configuring OSPF with NSF, make sure all the peer devices that participate in OSPF must be made OSPF NSF-aware.
5. While configuring OSPF with Non Stop Routing (NSR), it doesn’t require peer devices be NSR capable. It only requires more system resources. Both NSF and NSR could be active at same time but NSF is used as fallback.


Configuration:-
OSPF with Nonstop Forwarding
redundancy
mode sso
!
router ospf 1
nsf [cisco | ietf]


OSPF with Nonstop Routing
nsr process-failures switchover
!
router ospf 1
nsr
<!–google_ad_section_end–>
 

Monday, May 9, 2011

Understanding OSPF External Route Path Selection


Courtesy - INE

What is the major difference in using an E1 route over an E2 route in OSPF?

This is actually a very common area of confusion and misunderstanding in OSPF. Part of the problem is that the vast majority of CCNA and CCNP texts teach the theory that for OSPF path selection of E1 vs E2 routes, E1 routes use the redistributed cost plus the cost to the ASBR, while with E2 routes only use the redistributed cost. When I just checked the most recent CCNP ROUTE text from Cisco Press, it specifically says that “[w]hen flooded, OSPF has little work to do to calculate the metric for an E2 route, because by definition, the E2 route’s metric is simply the metric listed in the Type 5 LSA. In other words, the OSPF routers do not add any internal OSPF cost to the metric for an E2 route.” While technically true, this statement is an oversimplification. For CCNP level, this might be fine, but for CCIE level it is not.

The key point that I’ll demonstrate in this post is that while it is true that “OSPF routers do not add any internal OSPF cost to the metric for an E2 route”, both the intra-area and inter-area cost is still considered in the OSPF path selection state machine for these routes.


First, let’s review the order of the OSPF path selection process. Regardless of a route’s metric or administrative distance, OSPF will choose routes in the following order:

Intra-Area (O)
Inter-Area (O IA)
External Type 1 (E1)
External Type 2 (E2)
NSSA Type 1 (N1)
NSSA Type 2 (N2)

To demonstrate this, take the following topology:



R1 connects to R2 and R3 via area 0. R2 and R3 connect to R4 and R5 via area 1 respectively. R4 and R5 connect to R6 via another routing domain, which is EIGRP in this case. R6 advertises the prefix 10.1.6.0/24 into EIGRP. R4 and R5 perform mutual redistribution between EIGRP and OSPF with the default parameters, as follows:

follows:
R4:
router eigrp 10
 redistribute ospf 1 metric 100000 100 255 1 1500
!
router ospf 1
 redistribute eigrp 10 subnets

R5:
router eigrp 10
 redistribute ospf 1 metric 100000 100 255 1 1500
!
router ospf 1
 redistribute eigrp 10 subnets

The result of this is that R1 learns the prefix 10.1.6.0/24 as an OSPF E2 route via both R2 and R3, with a default cost of 20. This can be seen in the routing table output below. The other OSPF learned routes are the transit links between the routers in question.

R1#sh ip route ospf
     10.0.0.0/24 is subnetted, 8 subnets
O E2    10.1.6.0 [110/20] via 10.1.13.3, 00:09:43, FastEthernet0/0.13
                 [110/20] via 10.1.12.2, 00:09:43, FastEthernet0/0.12
O IA    10.1.24.0 [110/2] via 10.1.12.2, 00:56:44, FastEthernet0/0.12
O E2    10.1.46.0 [110/20] via 10.1.13.3, 00:09:43, FastEthernet0/0.13
                  [110/20] via 10.1.12.2, 00:09:43, FastEthernet0/0.12
O IA    10.1.35.0 [110/2] via 10.1.13.3, 00:56:44, FastEthernet0/0.13
O E2    10.1.56.0 [110/20] via 10.1.13.3, 00:09:43, FastEthernet0/0.13
                  [110/20] via 10.1.12.2, 00:09:43, FastEthernet0/0.12

Note that all the routes redistributed from EIGRP appear on R1 with a default metric of 20. Now let’s examine the details of the route 10.1.6.0/24 on R1.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.1.13.3 on FastEthernet0/0.13, 00:12:03 ago
  Routing Descriptor Blocks:
    10.1.13.3, from 10.1.5.5, 00:12:03 ago, via FastEthernet0/0.13
      Route metric is 20, traffic share count is 1
  * 10.1.12.2, from 10.1.4.4, 00:12:03 ago, via FastEthernet0/0.12
      Route metric is 20, traffic share count is 1

As expected, the metric of both paths via R2 and R3 have a metric of 20. However, there is an additional field in the route’s output called the “forward metric”. This field denotes the cost to the ASBR(s). In this case, the ASBRs are R4 and R5 for the routes via R2 and R3 respectively. Since all interfaces are FastEthernet, with a default OSPF cost of 1, the cost to both R4 and R5 is 2, or essentially 2 hops.

The reason that multiple routes are installed in R1’s routing table is that the route type (E2), the metric (20), and the forward metric (2) are all a tie. If any of these fields were to change, the path selection would change.

To demonstrate this, let’s change the route type to E1 under R4’s OSPF process. This can be accomplished as follows:

R4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1
R4(config-router)#end
R4#

The result of this change is that R1 now only installs a single route to 10.1.6.0/24, the E1 route learned via R2.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 22, type extern 1
  Last update from 10.1.12.2 on FastEthernet0/0.12, 00:00:35 ago
  Routing Descriptor Blocks:
  * 10.1.12.2, from 10.1.4.4, 00:00:35 ago, via FastEthernet0/0.12
      Route metric is 22, traffic share count is 1

Note that the metric and the forward metric seen in the previous E2 route is now collapsed into the single “metric” field of the E1 route. Although the value is technically the same, a cost of 2 to the ASBR, and the cost of 20 the ASBR reports in, the E1 route is preferred over the E2 route due to the OSPF path selection state machine preference. Even if we were to raise the metric of the E1 route so that the cost is higher than the E2 route, the E1 route would be preferred:

R4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 100
R4(config-router)#end
R4#

R1 still installs the E1 route, even though the E1 metric of 102 is higher than the E2 metric of 20 plus a forward metric of 2.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 102, type extern 1
  Last update from 10.1.12.2 on FastEthernet0/0.12, 00:00:15 ago
  Routing Descriptor Blocks:
  * 10.1.12.2, from 10.1.4.4, 00:00:15 ago, via FastEthernet0/0.12
      Route metric is 102, traffic share count is 1

R1 still knows about both the E1 and the E2 route in the Link-State Database, but the E1 route must always be preferred:

R1#show ip ospf database external 10.1.6.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 64
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.4.4
  LS Seq Number: 80000003
  Checksum: 0x1C8E
  Length: 36
  Network Mask: /24
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 100
        Forward Address: 0.0.0.0
        External Route Tag: 0

  LS age: 1388
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.5.5
  LS Seq Number: 80000001
  Checksum: 0x7307
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

This is the behavior we would expect, because E1 routes must always be preferred over E2 routes. Now let’s look at some of the commonly misunderstood cases, where the E2 routes use both the metric and the forward metric for their path selection.

First, R4’s redistribution is modified to return the metric-type to E2, but to use a higher metric of 100 than the default of 20:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 100
R4(config-router)#end
R4#

The result on R1 is that the route via R4 is less preferred, since it now has a metric of 100 (and still a forward metric of 2) vs the metric of 20 (and the forward metric of 2) via R5.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.1.13.3 on FastEthernet0/0.13, 00:00:30 ago
  Routing Descriptor Blocks:
  * 10.1.13.3, from 10.1.5.5, 00:00:30 ago, via FastEthernet0/0.13
      Route metric is 20, traffic share count is 1

The alternate route via R4 can still be seen in the database.

R1#show ip ospf database external 10.1.6.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 34
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.4.4
  LS Seq Number: 80000004
  Checksum: 0x9D8B
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 100
        Forward Address: 0.0.0.0
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 1653
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.5.5
  LS Seq Number: 80000001
  Checksum: 0x7307
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

This is the path selection that we would ideally want, because the total cost of the path via R4 is 102 (metric of 100 plus a forward metric of 2), while the cost of the path via R5 is 22 (metric of 20 plus a forward metric of 2). The result of this path selection would be the same if we were to change both routes to E1, as seen below.

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 100
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 1
R5(config-router)#end
R5#

R1 still chooses the route via R5, since this has a cost of 22 vs R4’s cost of 102.

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 22, type extern 1
  Last update from 10.1.13.3 on FastEthernet0/0.13, 00:00:41 ago
  Routing Descriptor Blocks:
  * 10.1.13.3, from 10.1.5.5, 00:00:41 ago, via FastEthernet0/0.13
      Route metric is 22, traffic share count is 1

R1#show ip ospf database external 10.1.6.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 56
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.4.4
  LS Seq Number: 80000005
  Checksum: 0x1890
  Length: 36
  Network Mask: /24
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 100
        Forward Address: 0.0.0.0
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 45
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.5.5
  LS Seq Number: 80000003
  Checksum: 0xEB0D
  Length: 36
  Network Mask: /24
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

R1#

Note that the E1 route itself in the database does not include the cost to the ASBR. This must be calculated separately either based on the Type-1 LSA or Type-4 LSA, depending on whether the route to the ASBR is Intra-Area or Inter-Area respectively.

So now this begs the question, why does it matter if we use E1 vs E2? Of course as we saw E1 is always preferred over E2, due to the OSPF path selection order, but what is the difference between having *all* E1 routes vs having *all* E2 routes? Now let’s at a case where it *does* matter if you’re using E1 vs E2.
R1’s OSPF cost on the link to R2 is increased as follows:

R1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#interface Fa0/0.12
R1(config-subif)#ip ospf cost 100
R1(config-subif)#end
R1#

R4 and R5’s redistribution is modified as follows:

R4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 99
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 1 metric 198
R5(config-router)#end
R5#

Now R1’s routes to the prefix 10.1.6.0/24 are as follows: Path 1 via the link to R2 with a cost of 100, plus the link to R4 with a cost of 1, plus the redistributed metric of 99, making this total path a cost of 200. Next, Path 2 is available via the link to R3 with a cost of 1, plus the link to R5 with a cost of 1, plus the redistributed metric of 198, masking this total path a cost of 200 as well. The result is that R1 installs both paths equally:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 200, type extern 1
  Last update from 10.1.12.2 on FastEthernet0/0.12, 00:02:54 ago
  Routing Descriptor Blocks:
  * 10.1.13.3, from 10.1.5.5, 00:02:54 ago, via FastEthernet0/0.13
      Route metric is 200, traffic share count is 1
    10.1.12.2, from 10.1.4.4, 00:02:54 ago, via FastEthernet0/0.12
      Route metric is 200, traffic share count is 1

Note that the database lists the costs of the Type-5 External LSAs as different though:

R1#show ip ospf database external 10.1.6.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 291
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.4.4
  LS Seq Number: 80000006
  Checksum: 0xC9C
  Length: 36
  Network Mask: /24
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 99
        Forward Address: 0.0.0.0
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 207
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.5.5
  LS Seq Number: 80000004
  Checksum: 0xE460
  Length: 36
  Network Mask: /24
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 198
        Forward Address: 0.0.0.0
        External Route Tag: 0

What happens if we were to change the metric-type to 2 on both R4 and R5 now? Let’s see:

R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 99
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 198
R5(config-router)#end
R5#

Even though the end-to-end costs are still the same, R1 should now prefer the path with the lower redistributed metric via R4:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 99, type extern 2, forward metric 101
  Last update from 10.1.12.2 on FastEthernet0/0.12, 00:01:09 ago
  Routing Descriptor Blocks:
  * 10.1.12.2, from 10.1.4.4, 00:01:09 ago, via FastEthernet0/0.12
      Route metric is 99, traffic share count is 1

The forward metric of this route means that the total cost is still 200 (the metric of 99 plus the forward metric of 101). In this case, even though both paths are technically equal, only the path with the lower redistribution metric is installed. Now let’s see what happens if we do set the redistribution metric the same.

R4#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 1
R4(config-router)#end
R4#

R5#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router ospf 1
R5(config-router)#redistribute eigrp 10 subnets metric-type 2 metric 1
R5(config-router)#end
R5#

Both routes now have the same metric of 1, so both should be installed in R1’s routing table, right? Let’s check:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 1, type extern 2, forward metric 2
  Last update from 10.1.13.3 on FastEthernet0/0.13, 00:00:42 ago
  Routing Descriptor Blocks:
  * 10.1.13.3, from 10.1.5.5, 00:00:42 ago, via FastEthernet0/0.13
      Route metric is 1, traffic share count is 1

This is the result we may not expect. Only the path via R5 is installed, not the path via R4. Let’s look at the database and see why:

R1#show ip ospf database external 10.1.6.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 56
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.4.4
  LS Seq Number: 80000008
  Checksum: 0xB3D4
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 47
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.1.6.0 (External Network Number )
  Advertising Router: 10.1.5.5
  LS Seq Number: 80000006
  Checksum: 0xAADD
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 0

Both of these routes show the same cost, as denoted by the “Metric: 1”, so why is one being chosen over the other? The reason is that in reality, OSPF External Type-2 (E2) routes *do* take the cost to the ASBR into account during route calculation. The problem though is that by looking at just the External LSA’s information, we can’t see why we’re choosing one over the other.

Now let’s go through the entire recursion process in the database to figure out why R1 is choosing the path via R5 over the path to R4.

First, as we saw above, R1 finds both routes to the prefix with a metric of 1. Since this is a tie, the next thing R1 does is determine if the route to the ASBR is via an Intra-Area path. This is done by looking up the Type-1 Router LSA for the Advertising Router field found in the Type-5 External LSA.

R1#show ip ospf database router 10.1.4.4

            OSPF Router with ID (10.1.1.1) (Process ID 1)
R1#show ip ospf database router 10.1.5.5

            OSPF Router with ID (10.1.1.1) (Process ID 1)
R1#

This output on R1 means that it does not have an Intra-Area path to either of the ASBRs advertising these routes. The next step is to check if there is an Inter-Area path. This is done by examining the Type-4 ASBR Summary LSA.

R1#show ip ospf database asbr-summary 10.1.4.4

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

                Summary ASB Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1889
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 10.1.4.4 (AS Boundary Router address)
  Advertising Router: 10.1.2.2
  LS Seq Number: 80000002
  Checksum: 0x24F3
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 1 

R1#show ip ospf database asbr-summary 10.1.5.5

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

                Summary ASB Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1871
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(AS Boundary Router)
  Link State ID: 10.1.5.5 (AS Boundary Router address)
  Advertising Router: 10.1.3.3
  LS Seq Number: 80000002
  Checksum: 0x212
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 1

This output indicates that R1 does have Inter-Area routes to the ASBRs R4 and R5. The Inter-Area metric to reach them is 1 via ABRs R2 (10.1.2.2) and R3 (10.1.3.3) respectively. Now R1 needs to know which ABR is closer, R2 or R3? This is accomplished by looking up the Type-1 Router LSA to the ABRs that are originating the Type-4 ASBR Summary LSAs.

R1#show ip ospf database router 10.1.2.2

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 724
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.1.2.2
  Advertising Router: 10.1.2.2
  LS Seq Number: 8000000D
  Checksum: 0xA332
  Length: 36
  Area Border Router
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.12.2
     (Link Data) Router Interface address: 10.1.12.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

R1#show ip ospf database router 10.1.3.3

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1217
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.1.3.3
  Advertising Router: 10.1.3.3
  LS Seq Number: 80000010
  Checksum: 0x9537
  Length: 36
  Area Border Router
  Number of Links: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.1.13.1
     (Link Data) Router Interface address: 10.1.13.3
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

This output indicates that R2 and R3 are adjacent with the Designated Routers 10.1.12.2 and 10.1.13.3 respectively. Since R1 is also adjacent with these DRs, the cost from R1 to the DR is now added to the path.

R1#show ip ospf database router 10.1.1.1

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

Router Link States (Area 0)

LS age: 948
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.1.1.1
Advertising Router: 10.1.1.1
LS Seq Number: 8000000F
Checksum: 0x6FA6
Length: 60
Number of Links: 3

Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.13.1
(Link Data) Router Interface address: 10.1.13.1
Number of TOS metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.12.2
(Link Data) Router Interface address: 10.1.12.1
Number of TOS metrics: 0
TOS 0 Metrics: 100

R1 now knows that its cost to the DR 10.1.12.2 is 100, who is adjacent with R2, whose cost to R4 is 1, whose redistributed metric is 1. R1 also now knows that its cost to the DR 10.1.13.3 is 1, who is adjacent with R3, whose cost to R5 is 1, whose redistributed metric is 1. This means that the total cost to go to 10.1.6.0 via the R1 -> R2 -> R4 path is 102, while the total cost to go to 10.1.6.0 via the R1 -> R3 -> R5 path is 3.

The final result of this is that R1 chooses the shorter path to the ASBR, which is the R1 -> R3 -> R5 path. Although the other route to the prefix is via an E2 route with the same external cost, one is preferred over another due to the shorter ASBR path.

Based on this we can see that both E1 and E2 routes take both the redistributed cost and the cost to the ASBR into account when making their path selection. The key difference is that E1 is always preferred over E2, followed by the E2 route with the lower redistribution metric. If multiple E2 routes exist with the same redistribution metric, the path with the lower forward metric (metric to the ASBR) is preferred. If there are multiple E2 routes with both the same redistribution metric and forward metric, they can both be installed in the routing table. Why does OSPF do this though? Originally this stems from the design concepts of “hot potato” and “cold potato” routing.

Think of a routing domain learning external routes. Typically those prefixes have some “external” metric associated with them – for example, E2 external metric or the BGP MED attribute value. If the routers in the local domain select the exit point based on the external metric they are said to perform “cold potato” routing. This means that the exit point is selected based on the external metric preference, e.g. distances to the prefix in the bordering routing system. This optimizes link utilization in the external system but may lead to suboptimal path selection in the local domain. Conversely, “hot potato” routing is the model where the exit point selection is performed based on the local metric to the exit point associated with the prefix. In other words, “hot potato” model tries to push packets out of the local system as quick as possible, optimizing internal link utilization.

Now within the scope of OSPF, think of the E2 route selection process: OSPF chooses the best exit point based on the external metric and uses the internal cost to ASBR as a tie breaker. In other words, OSPF performs “cold potato” routing with respect to E2 prefixes. It is easy to turn this process into “hot potato” by ensuring that every exit point uses the same E2 metric value. It is also possible to perform other sorts of traffic engineering by selectively manipulating the external metric associated with the E2 route, allowing for full flexibility of exit point selection.

Finally, we approach E1. This type of routing is a hybrid of hot and cold routing models – external metrics are directly added to the internal metrics. This implicitly assumes that external metrics are “comparable” to the internal metrics. In turn, this means E1 is meant to be used with another OSPF domain that uses a similar metric system. This is commonly found in split/merge scenarios where you have multiple routing processes within the same autonomous system, and want to achieve optimum path selection accounting for both metrics in both systems. This is similar to the way EIGRP performs metric computation for external prefixes.

So there we have it. While it is technically true that “OSPF routers do not add any internal OSPF cost to the metric for an E2 route”, both the intra-area and inter-area cost can still be considered in the OSPF path selection regardless of whether the route is E1 or E2.

My Blog List

Networking Domain Jobs