OSPF Virtual Links
By stretch | Monday, April 4, 2011 at 1:30 a.m. UTC
Virtual links can be considered as duct tape for OSPF: They can fix things in a pinch, but aren't intended to be a permanent solution and should never comprise your original design. This article looks at how a virtual link may be used and how one is configured. The scenario presented in this article concerns an IPv6 and OSPFv3 network, but the same concepts apply to IPv4 and OSPFv2.
The OSPF network shown above is broken. The two sides of what should be a single backbone area are isolated from one another. Intra-area LSAs from the left side area 0 won't make it to the right side, and vice versa. Examining the OSPF database on R3, we see that it has received an LSA from R2 for R1's 2001:db8:0:1::/64 prefix.
R3# show ipv6 ospf database inter-area prefix Inter Area Prefix Link States (Area 1) LS age: 1314 LS Type: Inter Area Prefix Links Link State ID: 3 Advertising Router: 192.168.0.2 LS Seq Number: 80000001 Checksum: 0xFE8D Length: 36 Metric: 20 Prefix Address: 2001:DB8:0:1:: Prefix Length: 64, Options: None ...
However, R3 does not create an IPv6 route from this LSA, because it is an ABR and the inter-area LSA was received over a non-backbone area:
R3# show ipv6 route 2001:db8:0:1:: % Route not found
This results in a unidirectional discontinuity in the routing topology: R1 can reach R3 (via a perfectly valid inter-area LSA generated by R2) but R3 cannot reach R1. This effect is reflected against the opposite side of the topology as well; R4 can reach R2 but R2 can't reach R4.
This behavior is inherent to the design of OSPF, which, although it is a link-state protocol, acts as a distance vector protocol when routing among areas. OSPF routers in one area have no visibility into the link state tree of another area and must rely on summary LSAs. While the requirement that the backbone area be contiguous may be interpreted as a drawback, it is necessary to guard against routing loops within a multi-area network.
To resolve the issue with our topology, we must find a way to reunite the two parts of the backbone area. Ideally, this would be accomplished by creating a simple routed link between R1 and R4. But then we wouldn't get to look at how to configure virtual links, which sadly are sometimes necessary in the real world.
Virtual Link Configuration
First, we must decide where to establish a virtual link. On such a simple network, the decision is obvious: between R2 and R3. Keep in mind that this is typically a far more complex design consideration when applied to a real-world network. At least one end of a virtual link must be terminated on a backbone (area 0) router.
Virtual links are created under the OSPF process configuration by referencing the peer router's RID, not an IP address.
R2(config)# ipv6 router ospf 1 R2(config-rtr)# area 1 virtual-link ? A.B.C.D RouterID associated with virtual link neighbor R2(config-rtr)# area 1 virtual-link 192.168.0.3
And the complementary command on R3:
R3(config)# ipv6 router ospf 1 R3(config-rtr)# area 1 virtual-link 192.168.0.2 R3(config-rtr)# %OSPFv3-5-ADJCHG: Process 1, Nbr 192.168.0.2 on OSPFv3_VL0 from LOADING to FULL, Loading Done
A new adjacency is created over the virtual link interface, called OSPFv3_VL1.
R3# show ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface ID Interface 192.168.0.2 1 FULL/ - - 11 OSPFv3_VL1 192.168.0.4 1 FULL/DR 00:00:31 4 FastEthernet0/0 192.168.0.2 1 FULL/DR 00:00:38 5 FastEthernet0/1
This is considered an adjacency through area 0, which allows for the exchange of backbone LSAs as it would occur over a regular routed link. All routers now have a complete routing table.
R1# show ipv6 route IPv6 Routing Table - 10 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external C 2001:DB8:0:1::/64 [0/0] via ::, FastEthernet0/1 L 2001:DB8:0:1::1/128 [0/0] via ::, FastEthernet0/1 O 2001:DB8:0:4::/64 [110/40] via FE80::C002:45FF:FE8D:0, FastEthernet0/0 C 2001:DB8:0:12::/64 [0/0] via ::, FastEthernet0/0 L 2001:DB8:0:12::1/128 [0/0] via ::, FastEthernet0/0 OI 2001:DB8:0:12::2/128 [110/10] via FE80::C002:45FF:FE8D:0, FastEthernet0/0 OI 2001:DB8:0:23::/64 [110/20] via FE80::C002:45FF:FE8D:0, FastEthernet0/0 O 2001:DB8:0:34::/64 [110/30] via FE80::C002:45FF:FE8D:0, FastEthernet0/0 OI 2001:DB8:0:34::3/128 [110/20] via FE80::C002:45FF:FE8D:0, FastEthernet0/0 L FF00::/8 [0/0] via ::, Null0
Posted in Routing
Comments
April 4, 2011 at 4:34 a.m. UTC
Good post, it's nice that you've started using IPv6 for your examples. If I can give you a tip for the Visio drawings it would be to put the names in the Device icon itself, like INE etc does. That gives more space for drawing links and putting interface names.
Virtual links is a bit of a hack but they can also be used to provide redundancy, so I guess they do have a valid usage.
April 4, 2011 at 4:50 a.m. UTC
thanks your writing , it improve my understanding for OSPF virtual link, and can you tell me the name that you draw net topology‘s software ?
April 4, 2011 at 4:56 a.m. UTC
@Daniel: Since switching to the new icon set from VSDfx I only place the device labels on the icons when necessary. Some icons, like the multilayer switch icon, look dumb with a label on the shape itself.
@Candy: The drawings are made in Microsoft Visio.
April 4, 2011 at 5:09 a.m. UTC
thank you , i like packetlife, i hope you run it forever 。 can you give me your email-address and i can contact you by email in time,because i'm in china, so there are many factor will stop me visiting your net。
January 25, 2012 at 11:54 a.m. UTC
Hi Stretch.
Thanks so much for explaining.
How much can you say virtual links are relevant in real world production network ?
I mean i never use virtual link and so i don't know in what situation in the real world can you use this or is it really practical ?
Can you point me to a real world eg ?
Thanks.