How to configure OSPF Virtual Link

(William V) #42

Hi Andrew hope you are well just wondering if you saw my last update or if you are content that you have covered off in your last update ? Thanks Will V - I was just after some final clarification if that is possible many thanks indeed

0 Likes

(Andrew P) #43

Hi William,
Sorry for the delay. I wanted to lab up some scenarios to ensure I gave you a proper answer, and that takes time–something I have in scarce quantities these days!

It is the job of the ABR to advertise a summary to its Area regardless of where that summary might originate (for this discussion, let’s just ignore the complexities that different stub areas can introduce).

I have attached a network diagram that shows a simple network. Here’s a walk through of the scenario:

Area 2 has the network 20.0.0.0/24 - 20.0.3.0/24 which R2 is summarizing to 20.0.0.0/22. Before the summary, all routers in all areas knew about the individual /24 networks. When R2 creates the summary, it sends out two distinct LSAs:

  1. The Summary-LSA (LSA Type 3) which says “I know about Link State ID 20.0.0.0 with netmask 255.255.252.0” (Link State ID is just the field that really means network subnet). R2 sets its own Router-ID (2.2.2.2) as the advertising router.

  2. “Poison” Type-3 LSA. This LSA tells all of Area 0, “You know those networks, 20.0.0.0/24 - 20.0.3.0/24? Change the metric of those to 16,777,215” What this means is that R2 is telling everyone in Area 0 that the individual /24 networks that are part of the /22 summary now have an infinite metric. This causes all the routers in Area 0 to flush out the /24 networks in favor of the just the /22 summary. This poison LSA has 2.2.2.2 (R2) as the originating router

Ok, so now what about R4 which is one Area over (Area 3)? The exact same thing happens, except this time it is the job of R3 (which is the ABR for Area 3) to make the announcement instead of R2. The same two LSAs are sent to Area 3, but this time the originating router is 3.3.3.3 (R3).

Lastly, as far as the backbone Area 0 having a special purpose in handling summaries–it really doesn’t. The reason that an Area 0 is special is because it plays an important role in preventing routing loops. This is why OSPF requires that “legal” design has all areas directly connected to Area 0–its loop prevention strategy.

0 Likes

(Anuradha K) #44

Hi Rene,

Is a virtual link always between ABR’s? To be more specific, what I want to know is, in case Area 0 has a DR and BDR, if a virtual link has to be made, is it made to the DR/BDR or still to the ABR?

Thanks,
Anu

0 Likes

(Shantel - Networklessons.com) split this topic #45

19 posts were merged into an existing topic: How to configure OSPF Virtual Link

0 Likes

(Stuart G) #46

Hi Rene,
I am tying to understand some of the mechanics of the virtual links.
I am assuming that the virtual link LSAs are unicast directly but that data packets traverse the transit area normally.

when we have area 0 - 1 - 2 arrangement. The ABR between areas 1 and 2 has a virtual link to area 0.
Does the area 2 ABR send type 3 LSAs into area 1? and are the area 1 routers happy to send packets direct to area 2 ?

where we have a 0 - 1 - 0 setup and we bridge the two area 0’s
From area 1’s perspective does each ABR to area 0 send different set of type 3 LSA ?

Area 1 routers must not assume area 0 is continuous.
So the ABRs must not send LSAs learnt over the virtual link into the transit area ?

Stuart.

0 Likes

(Lazaros Agapides) #47

Hello Stuart.

Here is the diagram that Rene has in his lesson:

A virtual link has been created between the L0 interface of R1 and the Fa1/0 interface of R2.

The OSPF packets between the two ends of the virtual link are not multicast packets. (Note the two ends of the virtual link are the L0 interface of R1 and the Fa1/0 interface of R2). LSAs that are sent over the virtual link are actually tunnelled packets between 192.168.23.2 and 1.1.1.1, based on the network diagram in the lesson. However, the LSA packets as they continue their journey from R2 to R3, the ARE multicast packets just like any ordinary OSPF LSAs.

Secondly, yes, data packets traverse the whole network normally independent of any virtual links.

Concerning your second question: [quote=“stuart.w.gall, post:46, topic:942”]
when we have area 0 - 1 - 2 arrangement. The ABR between areas 1 and 2 has a virtual link to area 0.Does the area 2 ABR send type 3 LSAs into area 1? and are the area 1 routers happy to send packets direct to area 2 ?
[/quote]

According to Cisco, an ABR is a router with at least ONE interface in area 0 and at least ONE interface in another area. In other words, there is no such thing as an ABR between area 1 and 2. One of the areas has to be area 0.

Practially, an OSPF router configured as an ABR, without a connection to area 0, will route traffic within and even between its connected areas. However, it won’t share one area’s routing information with another area’s OSPF neighbors without an area 0.

Your third question,

From the point of view of the routers, this is the same as having two ABRs link between area 0 and area 1 without a virtual link. In this case type 3 LSAs will be injected into area 1 from both R1 and R2, however, the LSAs will be different based on the destinations that exist in each of the two “parts” of area 0.

Area 1 routers must not assume area 0 is continuous.
So the ABRs must not send LSAs learnt over the virtual link into the transit area ?

Area 1 routers don’t care if area 0 is contiguous or not. They are not aware of how the areas interconnect, weather they connect via virtual link or not. ABRs in area 1 will advertise the type 3 LSAs that the receive from each discontiguous part of the area 0 thus informing the routers in area 1 of the correct route to the destinations within each “part” of area 0.

I hope this has been helpful!

Laz

1 Like

(JAMES H) #48

Hi @ReneMolenaar

In the discontinuous backbone area config, why is the virtual link config on R1 pointing to 192.168.23.3, and not 3.3.3.3?
Why specify the 1.1.1.1 address on the ‘return’, and not 192.168.12.1?

Many thanks.

0 Likes

(Lazaros Agapides) #49

Hello James

When implementing the area 1 virtual-link command, we don’t indicate the router on the other end of the virtual link with an IP address of an interface, but with the router ID. Notice that before the virtual link commands are implemented, the following show commands were used to determine the router IDs:

image

It is these two router IDs that are being used in the subsequent virtual-link commands. Note that initially, the virtual link is down because the router with ID 1.1.1.1 does not know how to reach the router with ID 192.168.23.3 (the other end of the virtual link). All of the link-state advertisements (LSAs) in Area 1 need to be flooded, and the shortest path first (SPF) algorithm must be run within Area 1 by both routers so that the two routers will know how to reach each other through area 1. The actual IP addresses used to communicate and to create the virtual link will be 192.168.12.1 and 192.168.23.3.

I hope this has been helpful!

Laz

0 Likes

(Mohammad Hasanuz Zaman) #50

Hi Rene,
Hope you are doing well :slight_smile:
I have a question , why Virtual link is not allowed on STUB/Special Area . Need clear concept on it in your way .

br//zaman

0 Likes

(Lazaros Agapides) #51

Hello Mohammad

The purpose of a virtual link is to connect a discontiguous network to the backbone area 0. If you have a stub network, then you are by default automatically connected to the area 0.

A stub network is a network with only one point of exit. If you create a virtual link on a stub network, then you are creating a second link to area 0 which would make the stub network no longer a stub network. You would be receiving both summary LSAs and type 5 LSAs making the network NOT a stub.

I hope this has been helpful!

Laz

0 Likes

(Mohammad Hasanuz Zaman) #52

Hi Laz,
I think you can’t catch my question…
Visualize a topology like …

area0>> Area-1 stub/nssa >> Area-2
so upon on above scenario the Area-2 have to connect to Area-0 using Virtual link to make the area functioning. Technically Virtual link not possible over the Stub/nssa area why ?? Thx

br//zaman

0 Likes

(Lazaros Agapides) #53

Hello Mohammad

OK, using your topology:

Area 0—Area 1—Area 2

where Area 1 is a Stub/NSSA

It IS possible to create a virtual link to make Area 0 connect to Area 2. However, if you do this, then Area 1 will no longer be a stub network because it can now reach Area 0 from two points: the connection to Area 0 and the connection to Area 2.

I hope this has been helpful!

Laz

0 Likes

(Zeko a) #54

i created a virtual link it’s working fine but then i tried to configure authentication for virtual links i did plaintext authentication in one side of the virtual link and on the otherside i didn’t the neighborship is still up didin go down. weird

0 Likes

(Rene Molenaar) #55

Hi Zeko,

If you enable authentication for virtual links, you have to enable it globally for area 0 and set the password on the virtual link command. Here’s an example:

R1#show run | begin ospf
router ospf 1
 area 0 authentication
 area 1 virtual-link 2.2.2.2 authentication-key NWL

Authentication is enabled for area 0, the virtual link goes through area 1 and has the password. You can see it works with this command:

R1#show ip ospf virtual-links 
Virtual Link OSPF_VL0 to router 192.168.23.2 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 1, via interface GigabitEthernet0/1
 Topology-MTID    Cost    Disabled     Shutdown      Topology Name
        0           1         no          no            Base
  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:04
    Adjacency State FULL (Hello suppressed)
    Index 1/1/2, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
  Simple password authentication enabled

Note the last line that says simple password authentication enabled.

Hope this helps!

Rene

1 Like

(Heng S) #56

Hello
what about if i have to go through more then one area ? what should i do ?
Please help
Sovandara

0 Likes

(Rene Molenaar) #57

Hello Sovandara,

You can create more than one virtual link if needed. For example, let’s say you have a topology like this:

(area 0) R1 (area 1) R2 (area 2) R3 (area 3)

You can configure a virtual link between R1-R2 to get area 2 connected to area 0. The virtual link is like a tunnel that gives R2 access to area 0.

You can then configure a virtual link between R2 and R3 to connect area 3 to area 0.

Hope this helps!

Rene

1 Like

(Heng S) #58

Hello Rene
It works now. so in this case if i want to enable authentication on virtual link that connect from area 0 to are 1 and from area 0 to area 3, do i have do enable authentication on all the area ?
Thank
Sovandara

0 Likes

(Lazaros Agapides) #59

Hello Heng

If you enable authentication on the virtual link you will only have to enable it for the specific area that you are linking. For example, if you have a discontiguous Area 0, you just have to activate it on Area 0 and not on the areas that you are traversing.

For more information about authentication and OSPF Virtual Links, take a look at this lesson.

I hope this has been helpful!

Laz

0 Likes

(Rick D) #60

The notion of virtual links makes sense. However, how is this actually working under the hood. What is the virtual link actually doing? Is this tunneling the LSA’s ?

0 Likes

(Lazaros Agapides) #61

Hello Rick

LSAs that traverse a virtual link is not actually tunneled. It is routed via the available routing tables in the intervening routers just like any other packet. Virtual links can be described as an internal hack to the OSPF database to make the backbone area APPEAR continuous and to make all non-backbone areas APPEAR to be directly connected. This way two VIRTUALLY directly connected OSPF routers can sync their databases in a targeted OSPF adjacency session. The transit area (i.e. the area over which the virtual link is built) will contain routing information about all areas and external routes, and will therefore be capable of routing packets natively.

According to RFC 2328 which defines OSPFv2:

    Just as the virtual link's cost and viability are determined by
    the routing table build process (through construction of the
    routing table entry for the other endpoint), so are the IP
    interface address for the virtual interface and the virtual
    neighbor's IP address.  These are used when sending OSPF
    protocol packets over the virtual link.

So packets are actually routed normally over the transit area using the routing tables of the intervening routers. It is the information found within the LSAs themselves that inform the OSPF routers of how to handle and interpret the information found therein as that received from a virtual link.

I hope this has been helpful!

Laz

0 Likes