cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1940
Views
0
Helpful
0
Comments
Meddane
VIP
VIP

OSPF TOPO.PNG

 

Basic configuration of all routers:

 

R1:

ipv uni

!

Interface Ethernet0/0

 ipv6 address 21::1/64

 ipv6 ospf 1 area 12

!

interface Serial 1/0

 ipv6 address 12::1/64

 ipv6 ospf 1 area 0

!

ipv6 router ospf 1

 router-id 0.0.0.1

 

R2:

ipv uni

!

Interface Ethernet0/0

 ipv6 address 21::2/64

 ipv6 ospf 1 area 12

!

interface Serial 1/0

 ipv6 address 12::2/64

 ipv6 ospf 1 area 0

!

ipv6 router ospf 1

 router-id 0.0.0.1

!

Interface Ethernet0/1

 ipv6 address 23::2/64

 ipv6 ospf 1 area 1

 no shut

!

interface Ethernet0/2

 ipv6 address 32::2/64

 ipv6 ospf 1 area 2

 no shut

!

ipv6 router ospf 1

 router-id 0.0.0.2

 

R3:

ipv uni

!

Interface Ethernet0/1

 ipv6 address 23::3/64

 ipv6 ospf 1 area 1

 no shut

!

interface Ethernet0/2

 ipv6 address 32::3/64

 ipv6 ospf 1 area 2

 no shut

!

ipv6 router ospf 1

 router-id 0.0.0.3

 redistribute connected route-map TEST

!

route-map TEST permit 10

 match interface Loopback0

 

R3 redistributes the external prefix 3::/64 into OSPF.

 

Let’s verify the LSDB of R1, we can see that it is receiving one Type-5 LSA from R3 0.0.0.3.

 

R1#sh ipv os data ex

 

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

 

          Type-5 AS External Link States

 

  LS age: 182

  LS Type: AS External Link

  Link State ID: 0

  Advertising Router: 0.0.0.3

  LS Seq Number: 80000001

  Checksum: 0x12A4

  Length: 36

  Prefix Address: 3::

  Prefix Length: 64, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

 

R1#

 

Since the Forward Address is not set in the Type-5 LSA, R1 lookup how to reach the ASBR and it needs a Type-4 LSA because R3 is located in another area, the ABR R2 will give this information, remember that Type-4 LSA has an area flooding scope, in this topology R2 is connected to R1 through two different areas, therefore R2 creates two Type-4 LSAs for areas 0 and 12 as shown below, because the loop-prevention mechanism of inter-area routes, the ABR R1 ignores the Type-4 LSA learned through area 12 the non-backbone area, ABR expects summary and ASB-summary LSAs from Area 0 only. This means there should be at least one adjacency in FULL state built over Area 0 interface. In case if ABR has such adjacency, it will ignore summary-LSAs received over non-backbone areas. These LSAs will be installed in the database, but not used for SPF calculations. This why you see the line “LSA ignored in SPF calculation” in the Type-4 LSA learned through area 12 as shown below.

 

R1#sh ipv os data inter router adv 0.0.0.2

 

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

 

          Inter Area Router Link States (Area 0)

 

  Routing Bit Set on this LSA

  LS age: 249

  Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)

  LS Type: Inter Area Router Links

  Link State ID: 3

  Advertising Router: 0.0.0.2

  LS Seq Number: 80000001

  Checksum: 0x39BB

  Length: 32

  Metric: 10

  Destination Router ID: 0.0.0.3

 

 

          Inter Area Router Link States (Area 12)

 

  LSA ignored in SPF calculation

  LS age: 249

  Options: (V6-Bit, E-Bit, R-Bit, DC-Bit)

  LS Type: Inter Area Router Links

  Link State ID: 3

  Advertising Router: 0.0.0.2

  LS Seq Number: 80000001

  Checksum: 0x39BB

  Length: 32

  Metric: 10

  Destination Router ID: 0.0.0.3

 

R1#

 

The total and best cost to reach the ASBR R3 can be displayed with the sh ipv os bord command, we can see that R1 considers the path through s1/0 as the best path to reach the ASBR R3 with a metric of 74.

 

R1#sh ipv os bor

 

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

 

Codes: i - Intra-area route, I - Inter-area route

 

I 0.0.0.3 [74] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ASBR, Area 0, SPF 5

i 0.0.0.2 [10] via FE80::A8BB:CCFF:FE00:2000, Ethernet0/0, ABR, Area 12, SPF 2

i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ABR, Area 0, SPF 5

R1#

 

Verify the routing table, R1 installs the path through s1/0, this suboptimal routing is caused by the loop prevention mechanism of inter-area route.

 

R1#sh ipv route 3::

Routing entry for 3::/64

  Known via "ospf 1", distance 110, metric 20, type extern 2

  Route count is 1/1, share count 0

  Routing paths:

    FE80::A8BB:CCFF:FE00:2000, Serial1/0

      Last updated 00:05:24 ago

 

R1#

 

The traceroute command confirms the result:

 

R1#tracer 3::3

Type escape sequence to abort.

Tracing the route to 3::3

 

  1 12::2 9 msec 9 msec 8 msec

  2 23::3 9 msec 8 msec 10 msec

R1#

 

This is what we call, the split-horizon mechanism. When an ABR learns a Type-3 LSA or Type-4 LSA through a non-backbone area, it ignores this LSA to prevent loop.

 

RFC 3509 explains OSPF ABR Behavior and split-horizon mechanism in the following section:

 

1.2 Motivation

 

   In OSPF domains the area topology is restricted so that there must be

   a backbone area (area 0) and all other areas must have either

   physical or virtual connections to the backbone.  The reason for this

   star-like topology is that OSPF inter-area routing uses the

   distance-vector approach and a strict area hierarchy permits

   avoidance of the "counting to infinity" problem.  OSPF prevents

   inter-area routing loops by implementing a split-horizon mechanism,

   allowing ABRs to inject into the backbone only Summary-LSAs derived

   from the

   intra-area routes, and limiting ABRs' SPF calculation to consider

   only Summary-LSAs in the backbone area's link-state database.

 

   The last restriction leads to a problem when an ABR has no backbone

   connection (in OSPF, an ABR does not need to be attached to the

   backbone).

 

To prevent the suboptimal routing and override the split-horizon rule, we need to block the Type-4 LSA so that the ABR R2 will not generate it for both area 12 and area 0, to do this configure areas 1 and 2 as NSSA:

 

R2(config)#ipv router os 1

R2(config-rtr)#area 1 nssa

R2(config-rtr)#area 2 nssa

 

R3(config)#ipv router os 1

R3(config-rtr)#area 1 nssa

R3(config-rtr)#area 2 nssa

 

Since areas 1 and 2 are configured as NSSA, R3 generates two Type-7 LSAs for areas 1 and 2 with the Forward Address 23::3 and 32::3 respectively, from the ABR R2’s perspective, to decide which Type-7 LSA, it uses the area id as the tie breaker, the largest area id will win, in this case the Type-7 LSA learned through area 2 is chosen to be translated rather than the Type-7 LSA learned through area 1, this rule is described in RFC 3101.

 

On R1 verify that it is receiving the Type-5 LSA with the Forward Address 32::3 from the NSSA translator R2.

 

R1#sh ipv os data ex

 

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

 

          Type-5 AS External Link States

 

  LS age: 174

  LS Type: AS External Link

  Link State ID: 0

  Advertising Router: 0.0.0.2

  LS Seq Number: 80000001

  Checksum: 0x90DF

  Length: 52

  Prefix Address: 3::

  Prefix Length: 64, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

  Forward Address: 32::3

 

R1#

 

Verify the routing table of R1 for the prefix 3::/64, we can see that R1 is still using the slower path through the serial link to reach the external prefix.

 

R1#sh ipv route 3::

Routing entry for 3::/64

  Known via "ospf 1", distance 110, metric 20, type extern 2

  Route count is 1/1, share count 0

  Routing paths:

    FE80::A8BB:CCFF:FE00:2000, Serial1/0

      Last updated 00:00:05 ago

 

R1#

 

The reason is the same one mentioned previously, R1 when it want to select the best path to reach the external prefix 3::/64, it will lookup the best inter-area route to reach the Forward Address 32::/64 listed in the Type-5 LSA, the routing table below shown that the inter-area route through the serial link is the best path to reach the Forward Address 32::3/64, because the inter-area loop prevention mechanism, the ABR R1 ignores the Type-3 LSA learned from the ABR R2 through area 12, a Type-3 LSA learned by an ABR through a non-backbone area is not considered in SPF calculation.

 

R1#sh ipv route os | beg App

       lr - LISP site-registrations, ld - LISP dyn-eid, a - Application

OE2 3::/64 [110/20]

     via FE80::A8BB:CCFF:FE00:2000, Serial1/0

OI  23::/64 [110/74]

     via FE80::A8BB:CCFF:FE00:2000, Serial1/0

OI  32::/64 [110/74]

     via FE80::A8BB:CCFF:FE00:2000, Serial1/0

R1#

 

To override this rule once again we should suppress the Forward Address, this causes the ABR NSSA R2 to translate Type-7 LSAs to Type-5 LSAs, but use the address 0.0.0.0 for the forwarding address instead of that specified in the Type-7 LSA. This causes R2 that are configured not to advertise forwarding addresses into area 0 and area 12 to direct forwarded traffic to the translating NSSA ABR R2:

 

R2(config-rtr)#ipv router os 1                           

R2(config-rtr)#area 2 nssa translate type7 suppress-fa

 

Verify the Type-5 LSA on R1, the Forward Address now is not set.

 

R1#sh ipv os data ex

 

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

 

          Type-5 AS External Link States

 

  LS age: 6

  LS Type: AS External Link

  Link State ID: 0

  Advertising Router: 0.0.0.2

  LS Seq Number: 80000008

  Checksum: 0xAA6

  Length: 36

  Prefix Address: 3::

  Prefix Length: 64, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

 

R1#

 

Since the FA is suppressed, R1 looks the best path to reach the NSSA ABR R2 which is also an ASBR.

 

There are two host intra-area routing entries for the same router-id "0.0.0.2" and with the cost 10 through area 12 and a cost 64 through area 0. the intra-area route through area 12 is better.

 

R1#sh ipv os bor

 

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

 

Codes: i - Intra-area route, I - Inter-area route

 

i 0.0.0.2 [10] via FE80::A8BB:CCFF:FE00:2000, Ethernet0/0, ABR/ASBR, Area 12, SPF 3

i 0.0.0.2 [64] via FE80::A8BB:CCFF:FE00:2000, Serial1/0, ABR/ASBR, Area 0, SPF 6

R1#

 

Verify the routing table of R1, we can see that now it installs the path through area 12.

 

R1#sh ipv route 3::

Routing entry for 3::/64

  Known via "ospf 1", distance 110, metric 20, type extern 2

  Route count is 1/1, share count 0

  Routing paths:

    FE80::A8BB:CCFF:FE00:2000, Ethernet0/0

      Last updated 00:01:21 ago

 

R1#

 

The trace route confirms the result.

 

R1#tracer 3::3    

Type escape sequence to abort.

Tracing the route to 3::3

 

  1 21::2 4 msec 1 msec 1 msec

  2 32::3 1 msec 1 msec 1 msec

R1#

 

Verify the connectivity.

 

R1#ping 3::3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms

R1#

 

Remove the area 2 nssa translate type7 suppress-fa command and use another solution to resolve the suboptimal routing issue.

 

The second method to suppress the Forward Address is to aggregate the Type-7 LSA prefixes on the NSSA ABR R2 using the summary-prefix command, keep in mind that this command should be executed on the ASBR, and R2 is a pseudo ASBR since it is originating a Type-5 LSA, this causes R2 to generate a Type-5 LSA for the summary prefix 3::/64 without the Forward Address.

 

Per RFC 3101, the sections Type-7 LSAs and Translating Type-7 LSAs into Type-5 LSAs explain that the FA is set to zero in the translated Type-5 LSA when performing summarization on the NSSA ABR for the Type-7 LSAs.

 

Section: 2.3  Type-7 LSAs

 

Type-5 LSAs that are translations of Type-7 LSAs copy the Type-7

   LSAs' non-zero forwarding addresses.  Only those Type-5 LSAs that are

   aggregations of Type-7 LSAs may have 0.0.0.0 as a forwarding address.

   (See Section 3.2 for details.)

 

Section: 3.2 Translating Type-7 LSAs into Type-5 LSAs

 

The newly generated Type-5 LSA will have a link-state ID equal

          to the Type-7 address range's address (in the case of multiple

          originations of Type-5 LSAs with the same network address but

          different mask, the link-state ID can also have one or more of

          the range's "host" bits set).  The advertising router field

          will be the router ID of this area border router.  The network

          mask and the external route tag are set to the range's

          configured values.  The forwarding address is set to 0.0.0.0.

          The path type and metric are set to the range's path type and

          metric as defined and computed above.

 

So remove the area 2 nssa translate type7 suppress-fa command and configure the summary-prefix 3::/64 command.

 

R2(config-rtr)#no area 2 nssa translate type7 suppress-fa

R2(config-rtr)#summary-prefix 3::/64 

 

Let’s verify the Type-5 LSA, the Forward Address is not set.

 

R1#sh ipv os data ex

 

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

 

          Type-5 AS External Link States

 

  LS age: 6

  LS Type: AS External Link

  Link State ID: 0

  Advertising Router: 0.0.0.2

  LS Seq Number: 80000012

  Checksum: 0xF5B0

  Length: 36

  Prefix Address: 3::

  Prefix Length: 64, Options: None

  Metric Type: 2 (Larger than any link state path)

  Metric: 20

 

R1#

 

Let's verify the routing table of R1, now the external route to 3::/64 through area 12 is installed successfully, R1 looks the best path to reach the NSSA ABR translator, the traffic should be forwarded to the advertising OSPF router, in this case, the translating NSSA ABR R2 through the best intra-area route.

 

R1#sh ipv route 3::

Routing entry for 3::/64

  Known via "ospf 1", distance 110, metric 20, type extern 2

  Route count is 1/1, share count 0

  Routing paths:

    FE80::A8BB:CCFF:FE00:2000, Ethernet0/0

      Last updated 00:00:07 ago

 

R1#

 

Let’s verify the connectivity to 3::/64, the ping from R1 fails.

 

R1#ping 3::3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds:

XXXXX       

Success rate is 0 percent (0/5)

R1#

 

It seems that the issue is the router R2, let’s verify the routing table of R2, WAW, R2 has no longer an NSSA external routes to 3::/64 in its routing tables, instead, it has a intra-area route via null0. And according to the OSPF path selection described by RFC 1583, an intra-area route is always preferred than an external route.

 

RFC 1583 section:    

 

11.1.  Routing table lookup

 

Reduce the set of matching entries to those having the most

            preferential path-type (see Section 11). OSPF has a four

            level hierarchy of paths. Intra-area paths are the most

            preferred, followed in order by inter-area, type 1 external

            and type 2 external paths.

 

R2#sh ipv rou osp | be App

       lr - LISP site-registrations, ld - LISP dyn-eid, a - Application

O   3::/64 [254/20]

     via Null0, directly connected

R2#

 

With OSPF External and internal discard-route entries pointed to the null0 interface are installed in routing tables by default when configuring route summarization, routing loops may occur when packet is sent to a prefix which is a part of the summary but this prefix is no longer reachable, and a router that is performing summarization has a default route advertised by another router. To prevent the routing loop, a discard route is installed in the routing table of the ABR or ASBR.

 

If you do not want to use the external for ASBR or internal for ABR discard route, you can remove the discard route using the no discard-route command with the external or internal keyword for ABR and ASBR respectively.

 

Since we are using the summary-prefix command on an ASBR, remove the discard route using the external keyword.

 

R2(config)#ipv router os 1

R2(config-rtr)#disc

R2(config-rtr)#discard-route ex

R2(config-rtr)#no discard-route external

 

Verify the routing table of R2, the discard route is no longer present.

 

R2#sh ipv rou osp | be App

       lr - LISP site-registrations, ld - LISP dyn-eid, a - Application

ON2 3::/64 [110/20]

     via 32::3, Ethernet0/2

     via 23::3, Ethernet0/1

R2#

 

The ping from R1 is now successful.

 

R1#ping 3::3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

R1#

 

R1#trace 3::3

Type escape sequence to abort.

Tracing the route to 3::3

 

  1 21::2 4 msec 1 msec 0 msec

  2 32::3 1 msec 0 msec 0 msec

R1#

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: