Virtual Links
Virtual Links
Virtual links repair a broken backbone or connect a remote area to area 0 through a transit area. They are configuration-light but concept-heavy, and they are a favourite exam trap.
Core rules
- A virtual link is configured on the two ABRs that share a transit area, and it is logically part of area 0.
- The transit area must have a normal area type (not stub or NSSA) and must already have a full adjacency between the two ABRs.
- On SR OS the link is configured under the backbone:
area 0.0.0.0 virtual-link <remote-router-id> transit-area <area-id>. - Hellos on the virtual link are sent as unicast to the remote router ID, using the outgoing interface of the transit area. Timers and authentication must match on both ends.
- The virtual link gives the remote area a path to the backbone; it does not make the transit area itself backbone.
Worked example
Area 2 attaches to Area 1, and Area 1 has no direct link to Area 0 because the backbone link failed. Configure a virtual link between the two Area 1 ABRs through Area 1. Area 2's type 3 LSAs then reach area 0. If Area 1 were configured as a stub, the virtual link would not come up.
Traps that cost marks
- Configuring a virtual link through a stub or NSSA transit area.
- Using the transit area's interface address instead of the remote router ID.
- Mismatched hello/dead or authentication on the virtual link, which leaves it down while the transit adjacency is Full.
- Expecting the virtual link to fix a missing physical adjacency in the transit area; it cannot.