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

OSPFV3.PNG

 

Basic configuration of all routers:

 

R1:

interface Loopback0

 ip address 1.1.1.1 255.255.255.0

 ip ospf network point-to-point

 ip ospf 1 area 1

!

interface FastEthernet0/1

 ip address 123.0.0.1 255.255.255.0

 ip ospf 1 area 123

 ip ospf cost 10

 no shut

!

routerospf 1

 router-id 0.0.0.1

 

R2:

interface FastEthernet0/0

 ip address 24.0.0.2 255.255.255.0

 ip ospf 1 area 0

 ip ospf cost 10

 no shut

!

interface FastEthernet0/1

 ip address 123.0.0.2 255.255.255.0

 ipospf 1 area 123

 ip ospf cost 10

 no shut

!

routerospf 1

 router-id 0.0.0.2

 

R3:

interface FastEthernet0/0

 ip address 34.0.0.3 255.255.255.0

 ip ospf 1 area 0

 ip ospf cost 10

 no shut

!

interface FastEthernet0/1

 ip address 123.0.0.3 255.255.255.0

 ip ospf 1 area 123

 ip ospf cost 10

 no shut

!

routerospf 1

 router-id 0.0.0.3

 

R4:

interface Loopback0

 ip address 4.4.4.4 255.255.255.0

 ip ospf network point-to-point

 ip ospf 1 area 0

!

interface FastEthernet0/0

 ip address 34.0.0.4 255.255.255.0

 ip ospf 1 area 0

 i pospf cost 10

 no shut

!

interface FastEthernet0/1

 ip address 24.0.0.4 255.255.255.0

 ip ospf 1 area 0

 ip ospf cost 10

 no shut

!

routerospf 1

router-id 0.0.0.4

 

Verify the routing table of R1 and ensure it has learned all routes, the routes are installed as inter-area:

 

R1#show ip route ospf | beg Gate

Gateway of last resort is not set

 

      4.0.0.0/24 is subnetted, 1 subnets

O IA     4.4.4.0 [110/21] via 123.0.0.3, 00:00:31, FastEthernet0/1

                 [110/21] via 123.0.0.2, 00:00:31, FastEthernet0/1

      24.0.0.0/24 is subnetted, 1 subnets

O IA     24.0.0.0 [110/20] via 123.0.0.2, 00:00:31, FastEthernet0/1

      34.0.0.0/24 is subnetted, 1 subnets

O IA     34.0.0.0 [110/20] via 123.0.0.3, 00:00:31, FastEthernet0/1

R1#

 

Verify the routing table of R4, notice that the route to 1.1.1.0/24 is missing, this is because the area 1 is not connected directly to the backbone area 0:

 

R4#show ip route ospf | beg Gate

Gateway of last resort is not set

 

      123.0.0.0/24 is subnetted, 1 subnets

O IA     123.0.0.0 [110/20] via 34.0.0.3, 00:17:36, FastEthernet0/0

                   [110/20] via 24.0.0.2, 00:17:36, FastEthernet0/1

R4#

 

To allow R4 to learn the route to 1.1.1.0/24, configure a virtual link between R1 and R2 allowing area 1 connection to the backbone area, the area 123should be the transit area:

 

R2(config)#router osp 1

R2(config-router)#area 123 virtual-link 0.0.0.1

 

R1(config)#router osp 1

R1(config-router)#area 123 virtual-link 0.0.0.2

 

Verify that the virtual link is working using the show ipospnei command on R1 and R2, you should see a neighbor relationship built through the virtual link:

 

R1#show iposnei

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

0.0.0.2           0   FULL/  -           -        123.0.0.2       OSPF_VL0

0.0.0.2           1   FULL/BDR        00:00:32    123.0.0.2       FastEthernet0/1

0.0.0.3           1   FULL/DROTHER    00:00:35    123.0.0.3       FastEthernet0/1

R1#

 

R2#show iposnei

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

0.0.0.1           0   FULL/  -           -        123.0.0.1       OSPF_VL0

0.0.0.4           1   FULL/BDR        00:00:36    24.0.0.4        FastEthernet0/0

0.0.0.1           1   FULL/DR         00:00:37    123.0.0.1       FastEthernet0/1

0.0.0.3           1   FULL/DROTHER    00:00:39    123.0.0.3       FastEthernet0/1

R2#

 

Now let's take a look at the routing table of R1, all inter-area routes seen before the virtual link are now installed as intra-area routes:

 

R1#show ip route os | beg Gate

Gateway of last resort is not set

 

      4.0.0.0/24 is subnetted, 1 subnets

O        4.4.4.0 [110/21] via 123.0.0.3, 00:00:12, FastEthernet0/1

                 [110/21] via 123.0.0.2, 00:00:12, FastEthernet0/1

      24.0.0.0/24 is subnetted, 1 subnets

O        24.0.0.0 [110/20] via 123.0.0.2, 00:00:12, FastEthernet0/1

      34.0.0.0/24 is subnetted, 1 subnets

O        34.0.0.0 [110/20] via 123.0.0.3, 00:00:12, FastEthernet0/1

R1#

 

This is because R1 is an ABR since it has a direct connection to the backbone area:

 

R1# show iposintbr

Interface    PID   Area            IP Address/Mask    Cost  StateNbrs F/C

VL0          1     0               123.0.0.1/24       10    P2P   1/1

Lo0          1     1               1.1.1.1/24         1     P2P   0/0

Fa0/1        1     123             123.0.0.1/24       10    DROTH 2/2

R1#

 

R1#show ipospf | i border

It is an area border router

R1#

 

Since R1 has a direct connection to Area 0, it creates its own Type-1 LSA for Area 0, this LSA is special, since it carries the information about the LinkType 4 to which R1 is connected ( Link connected to: a Virtual Link ), the Type-1 LSA created for area 123 has a new information carried to indicate to all routers located in the transit area 123 that it is an end point of a virtual link, this information is carried with V-bit, the V-bit informs the routers that do not participate in virtual link operation like R3 to know the existence of a virtual link:

 

R1#show ipos data router sel

 

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

 

                Router Link States (Area 0)

 

  LS age: 370

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 0.0.0.1

  Advertising Router: 0.0.0.1

  LS Seq Number: 80000002

  Checksum: 0xE97

  Length: 36

  Area Border Router

  Number of Links: 1

 

  Link connected to: a Virtual Link

     (Link ID) Neighboring Router ID: 0.0.0.2

     (Link Data) Router Interface address: 123.0.0.1

      Number of MTID metrics: 0

       TOS 0 Metrics: 10

 

 

 

                Router Link States (Area 1)

 

  LS age: 375

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 0.0.0.1

  Advertising Router: 0.0.0.1

  LS Seq Number: 80000002

  Checksum: 0x427

  Length: 36

  Area Border Router

  Number of Links: 1

 

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 1.1.1.0

     (Link Data) Network Mask: 255.255.255.0

      Number of MTID metrics: 0

       TOS 0 Metrics: 1

 

 

 

                  Router Link States (Area 123)

 

  LS age: 203

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 0.0.0.1

  Advertising Router: 0.0.0.1

  LS Seq Number: 80000004

  Checksum: 0x62C2

  Length: 36

  Area Border Router

  Virtual Link Endpoint

  Number of Links: 1

 

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 123.0.0.3

     (Link Data) Router Interface address: 123.0.0.1

      Number of MTID metrics: 0

       TOS 0 Metrics: 10

 

 

R1#

 

The show iposp borders-routers shown that the ABRs R2 and R3 are now reachable through the transit area 123 and the backbone area 0 (in other words the virtual link), this means that R1 has two paths to reach each ABR, a physical link and a virtual link:

 

R1#show iposbor

 

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

 

 

                Base Topology (MTID 0)

 

Internal Router Routing Table

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

 

i0.0.0.2 [10] via 123.0.0.2, FastEthernet0/1, ABR, Area 0, SPF 17

i0.0.0.2 [10] via 123.0.0.2, FastEthernet0/1, ABR, Area 123, SPF 19

i0.0.0.3 [30] via 123.0.0.2, FastEthernet0/1, ABR, Area 0, SPF 17

i0.0.0.3 [10] via 123.0.0.3, FastEthernet0/1, ABR, Area 123, SPF 19

R1#

 

The traceroute shown that the packets to 4.4.4.4 go through R2 and R3 since we have seen previously that R1 installed a load balancing in its routing table:

 

R1#tra 4.4.4.4 sou 1.1.1.1

Type escape sequence to abort.

Tracing the route to 4.4.4.4

VRF info: (vrf in name/id, vrf out name/id)

  1 123.0.0.2 84 msec

    123.0.0.3 96 msec

    123.0.0.2 76 msec

  2 34.0.0.4 100 msec

    24.0.0.4 108 msec

    34.0.0.4 120 msec

R1#

 

Influence the path so that R1 chooses R3 towards 4.4.4.0/24 by modifying a cost:

 

The simplest way to do this is to increase the cost from R2's perspective toward R4, this way forces R2 to advertise higher metric than R3:

 

Note: we can modify the cost from R1's perspective toward R2 but you should configure the fastethernet 0/1 interfaces of R1, R2 and R3 as point-to-multipoint network type.

 

R2(config)#int fa0/0

R2(config-if)#ip ospf cost 11

 

Verify tha routing table of R1, now only the path through R3 is installed, Transit Capability flag turned on:

 

R1#show ip route os | beg Gate

Gateway of last resort is not set

 

      4.0.0.0/24 is subnetted, 1 subnets

O        4.4.4.0 [110/21] via 123.0.0.3, 00:00:06, FastEthernet0/1

      24.0.0.0/24 is subnetted, 1 subnets

O        24.0.0.0 [110/21] via 123.0.0.2, 00:00:06, FastEthernet0/1

      34.0.0.0/24 is subnetted, 1 subnets

O        34.0.0.0 [110/20] via 123.0.0.3, 00:05:04, FastEthernet0/1

R1#

 

Let's do a traceroute to see where the packets will go, through R3 (23.0.0.3):

 

R1#tra 4.4.4.4 sou 1.1.1.1

Type escape sequence to abort.

Tracing the route to 4.4.4.4

VRF info: (vrf in name/id, vrf out name/id)

  1 123.0.0.3 240 msec 4 msec 300 msec

  2 34.0.0.4 232 msec 280 msec 264 msec

R1#

 

R1 chooses R3 as the next-hop to reach 4.4.4.0/24, even if it has a direct path through the virtual link (area 0 connection) with R2. R1 chooses transitarea 123. This is due to the Transit Capability turned on by default. So instead of using the virtual link (area 0), R4 uses the path through the transit area 123 since R3 is advertising a better metric.

 

Configure OSPF so that R1 chooses R2 as the next-hop without changing the cost or bandwidth parameters:

 

To do this challenge we should disable the capability transit, whent setting up a virtual link the capability transit is enabled by default.

 

To verify use the show ip os command, and notice the transit area 123 has the transit capability enabled:

 

R1#show ipos | beg Area 123

     Area 123

        Number of interfaces in this area is 1

        This area has transit capability: Virtual Link Endpoint

        Area has no authentication

        SPF algorithm last executed 00:11:02.852 ago

        SPF algorithm executed 8 times

        Area ranges are

        Number of LSA 9. Checksum Sum 0x056D85

        Number of opaque link LSA 0. Checksum Sum 0x000000

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

 

R1#

 

Before disabling the capabality transit feature, let's verify one important point, the shipos data su 4.4.4.0 self command tell us that R1 created oneType-3 LSA for area 1 only, it is logic, imagine we have an internal router in area 1 connected to R1, it needs the information about the subnet 4.4.4.0/24located inanother area (area 0), this is why R1 anticipates to create a Type-3 LSA:

 

R1#show ipos data summ 4.4.4.0 self-originate

 

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

 

                Summary Net Link States (Area 1)

 

  LS age: 124

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 4.4.4.0 (summary Network Number)

  Advertising Router: 0.0.0.1

  LS Seq Number: 80000006

  Checksum: 0xBB5A

  Length: 28

  Network Mask: /24

        MTID: 0         Metric: 21

 

R1#

 

The shipos da su 4.4.4.0 | s Area 123|0.2|0.3 command shown that R1 is receiving in area 123: two Type-3 LSAs for 4.4.4.0/24 from R2 (0.0.0.2) and R3 (0.0.0.3):

 

R1#sh ipos da su4.4.4.0 | s Area 123|0.2|0.3

  LS Seq Number: 80000002

                Summary Net Link States (Area 123)

  Advertising Router: 0.0.0.2

  LS Seq Number: 80000002

  Advertising Router: 0.0.0.3

  LS Seq Number: 80000002

R1#

 

But the question that we should ask, why R1 didn't create a Type-3 LSA for 4.4.4.0/24 in area 123 ?

 

Let's execute debug iposplsa-generation, debugging is a good method to how OSPF works, i recommend highly to use debugging:

 

R1#debug ipospflsa-generation

OSPF LSA generation debugging is on

R1#

 

From the debug output, we can see that because the split-horizon, R1 didn't generate a Summary LSA (Type-3) for the subnet 4.4.4.0/24, in order to avoid aloop, R1 knows that R3 and R4 are ABRs, the Split-Horizon rule tells to the ABR R1: do not generate a Type-3 LSA for 4.4.4.0/24 in area 123, it receivedalready two Type-3 LSAs from R2 and R3 in area 123, no need to create a new one in the same area 123:

 

*Sep  6 06:25:13.943: OSPF-1 LSGEN: Build sum 4.4.4.0, mask 255.255.255.0, type 3, age 0, seq 0x80000008 to area 1

*Sep  6 06:25:13.943: OSPF-1 LSGEN: MTID      Metric      Origin          Topology Name

*Sep  6 06:25:13.947: OSPF-1 LSGEN: 0         21          intra-area      Base

*Sep  6 06:25:13.951: OSPF-1 LSGEN: split-horizon. Do not generate summary LSAfrom intra-area prefix, id 4.4.4.0 type 0, into area 123

*Sep  6 06:25:13.951: OSPF-1 LSGEN: Build sum 34.0.0.0, mask 255.255.255.0, type 3, age 0, seq 0x80000006 to area 1

*Sep  6 06:25:13.955: OSPF-1 LSGEN: MTID      Metric      Origin          Topology Name

*Sep  6 06:25:13.955: OSPF-1 LSGEN: 0         20          intra-area      Base

*Sep  6 06:25:13.959: OSPF-1 LSGEN: split-horizon. Do not generate summary LSA from intra-area prefix, id 34.0.0.0 type 2, into area 123

 

Let's disable capability transit feature on R1:

 

R1(config)#router osp 1

R1(config-router)#no capability transit

 

Let's verify the routing table of R1, now the path through R2 is installed even though R3 advertises a lower metric toward 4.4.4.0/24:

 

R1#show ip route os | beg Gate

Gateway of last resort is not set

 

      4.0.0.0/24 is subnetted, 1 subnets

O        4.4.4.0 [110/22] via 123.0.0.2, 00:00:52, FastEthernet0/1

      24.0.0.0/24 is subnetted, 1 subnets

O        24.0.0.0 [110/21] via 123.0.0.2, 00:00:53, FastEthernet0/1

      34.0.0.0/24 is subnetted, 1 subnets

O        34.0.0.0 [110/31] via 123.0.0.2, 00:00:52, FastEthernet0/1

R1#

 

Let's execute the traceroute to confirm the result:

 

R1#tra 4.4.4.4 sou 1.1.1.1

Type escape sequence to abort.

Tracing the route to 4.4.4.4

VRF info: (vrf in name/id, vrf out name/id)

  1 123.0.0.2 72 msec 28 msec 4 msec

  2 24.0.0.4 168 msec 108 msec 96 msec

R1#

 

In OSPFv2, Capability Transit is enabled by default, this features allows the ABR to select a better route through the transit area rather than the virtual link. In some case you need the ABR to go through the virtual link directly connected to the backbone area 0, therefore you can disable capability transit using the no capability transit command.

 

RFC 2328 defines the transit-capability for stub area in the following section:

 

  TransitCapability

        This parameter indicates whether the area can carry data traffic

        that neither originates nor terminates in the area itself. This

        parameter is calculated when the area's shortest-path tree is

        built (see Section 16.1, where TransitCapability is set to TRUE

        if and only if there are one or more fully adjacent virtual

        links using the area as Transit area), and is used as an input

        to a subsequent step of the routing table build process (see

        Section 16.3). When an area's TransitCapability is set to TRUE,

        the area is said to be a "transit area".

 

RFC 1583 which is the default RFC implemented by Cisco routers defines the transit-capability for stub area in the following section:

 

TransitCapability

        Set to TRUE if and only if there are one or more active virtual

        links using the area as a Transit area. Equivalently, this

        parameter indicates whether the area can carry data traffic that

        neither originates nor terminates in the area itself. This

        parameter is calculated when the area's shortest-path tree is

        built (see Section 16.1, and is used as an input to a subsequent

        step of the routing table build process (see Section 16.3).

 

Verify that the capability transit is disabled:

 

R1#show ipos | beg Area 123

     Area 123

        Number of interfaces in this area is 1

        Area has no authentication

        SPF algorithm last executed 00:01:56.280 ago

        SPF algorithm executed 21 times

        Area ranges are

        Number of LSA 13. Checksum Sum 0x0538A8

        Number of opaque link LSA 0. Checksum Sum 0x000000

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

 

R1#

 

Finally let's verify the LSDB of R1, now we can see that R1 generated a Type-3 LSA for Area 123, and the debug output shows that R1 built a Summary LSA for

the subnet 4.4.4.0/24, you should take care when disabling capability transit, because it break the split-horizon rule and can cause routing loop:

 

R1#show ipos data summa 4.4.4.0 self

 

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

 

                Summary Net Link States (Area 1)

 

  LS age: 122

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 4.4.4.0 (summary Network Number)

  Advertising Router: 0.0.0.1

  LS Seq Number: 80000007

  Checksum: 0xC350

  Length: 28

  Network Mask: /24

        MTID: 0         Metric: 22

 

 

               Summary Net Link States (Area 123)

 

  LS age: 122

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 4.4.4.0 (summary Network Number)

  Advertising Router: 0.0.0.1

  LS Seq Number: 80000001

  Checksum: 0xCF4A

  Length: 28

  Network Mask: /24

        MTID: 0         Metric: 22

 

R1#

 

R1#      Base

*Sep  6 06:21:22.139: OSPF-1 LSGEN: Build sum 4.4.4.0, mask 255.255.255.0, type 3, age 0, seq 0x80000007 to area 1

*Sep  6 06:21:22.143: OSPF-1 LSGEN: MTID      Metric      Origin          Topology Name

*Sep  6 06:21:22.143: OSPF-1 LSGEN: 0         22          intra-area      Base

*Sep  6 06:21:22.147: OSPF-1 LSGEN: Build sum 4.4.4.0, mask 255.255.255.0, type 3, age 0, seq 0x80000001 to area 123

*Sep  6 06:21:22.151: OSPF-1 LSGEN: MTID      Metric      Origin          Topology Name

*Sep  6 06:21:22.151: OSPF-1 LSGEN: 0         22          intra-area      Base

*Sep  6 06:21:22.155: OSPF-1 LSGEN: Build sum 34.0.0.0, mask 255.255.255.0, type 3, age 0, seq 0x80000005 to area 1

*Sep  6 06:21:22.159: OSPF-1 LSGEN: MTID      Metric      Origin          Topology Name

*Sep  6 06:21:22.159: OSPF-1 LSGEN: 0         31          intra-area      Base

*Sep  6 06:21:22.163: OSPF-1 LSGEN: Build sum 34.0.0.0, mask 255.255.255.0, type 3, age 0, seq 0x80000001 to area 123

1 Comment
Sam-CCNP
Level 1
Level 1

I'm confused by this statement and the output that comes after:

Now let's take a look at the routing table of R1, all inter-area routes seen before the virtual link are now installed as intra-area routes:

R1#show ip route os | beg Gate

Gateway of last resort is not set

 

      4.0.0.0/24 is subnetted, 1 subnets

O        4.4.4.0 [110/21] via 123.0.0.3, 00:00:12, FastEthernet0/1

                 [110/21] via 123.0.0.2, 00:00:12, FastEthernet0/1

      24.0.0.0/24 is subnetted, 1 subnets

Because the transit link to R2 should be the only intra-area route to R4's loopback. But according to your output, both ABR routers are intra-area, which can only happen if the virtual link was also setup between R1-R2. Because whilst R1 is still learning 4.4.4.0 from R3, it is should be inter-area (IA O, Type-3) route, and intra-area will always preferred over inter-area.

And although transit capability means ABRs will use Type-3 LSA not learnt from the backbone in their SPF calculation, the routing table should only show a route to 4.4.4.4 via R2 and not R2 and R3.

That's my understanding, at least. Please correct me if I am wrong.

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: