JNCIS-SP: OSPFv3 Lab.

The JNCI-SP OSPFv3 lab looks as follows:

scenario



The lab setup.

This OSPF lab will cover OSPFv3, Virtual Router Redundancy protocol (VRRP) and Bidirectional Forwarding Detection (BFD). The lab is not very extensive, but the course JNCIS-SP isn't all too extensive on OSPFv3 either.

The lab is comprised of four routers. R6 and R7 are backbone routers and they are connected to a remote location.
On the remote location, R2 and R3 will be in an NSSA area. R3 will act as a failover to R2. The gateway to all other devices will be a VRRP VIP and all devices on the location will be connected via two switches.

What I'll do is the following:

    • setup basic OSPFv3 between R6 and R7 with BFD
    • create the NSSA area and the necessary configuration on R2 and R3
    • configure VRRP between R2 and R3



Basic OSPFv3 and BFD.

Let's start out with the basic configuration on R6. The most basic configuration for OSPFv3 is the following:



scenario


This is very similar to OSPFv2 for IPv6. First I configured the IP addresses, then I activated OSPFv3 on the interfaces.
OSPFv3 uses a 32-bit router-id, just like OSPFv2. If none would have been configured, the IPv4 loopback of the router would have been used since we have one configured.
After activating the configuration (and configuring R7 in the exact same way), the neighbor relationship came up and the loopbacks were advertised:



scenario


Here we can observer the following:

    • the shocking similarities between not only the configuration but also the OSPFv3 commands
    • we neglected to configure the OSPFv3 interface as link-type p2p, so a DR and BDR are elected
    • the neighbor router-id is R7's loopback and the neighbor-address is the connected links IPv6 link local address
    • this is the same next-hop that is installed in the forwarding table
    • we have connectivity between the loopback IP's of R6 and R7

In OSPF, across a broadcast medium, on router is chosen and elected DR. This election is amongst all OSPF interfaces to represent the segment to the rest of the network. Besides the DR, all routers agree on a BDR (DR's backup) as well, the rest are DRother.

The main idea is to reduce OSPF protocol traffic across the segment. This election can take tens of seconds and does not offer us any advantage. In fact, for every broadcast segment with a DR/BDR, there is an additional Type 2 LSA describing the multi-access segment.

Since it offers Since this does not benefit us in anyway, let's get rid of it and activate BFD as well;



scenario


The interface type p2p will make sure that if the neighbor relationship can be build a little bit faster between R6 and R7.
BFD is added to the configuration to decrease the detection time that is needed to remove the OSPFv3 neighbor adjacency with R7. Normally, OSPFv2 and v3 routers exchange hellos between each others. These hellos are exchanged, by default, every 10 seconds. When a router misses 4 hellos, the neighbor is declared dead. The dead time is shown with 'show ospf3 neighbor extensive'.

To decrease the dead time of a neighbor, you could increase the rate of hellos. This increased rate of hellos would put additional stress on the router though. Instead of speeding up OSPF, it is better to rely on a more lightweight protocol, like BFD.

BFD is configured under the protocol you want to enhance, so in our case it is configured under OSPFv3. BFD is supported on far more protocols though. BFD can be configured on IS-IS. RSVP, BGP and static routes as well for instance.

When BFD is active, you can even think about increasing the normal protocol timers to reduce the strain of certain protocols on some of your busy routers.

Back to the output, after configuring it, I displayed the BFD session. This shows the state of the session, which is currently up, and the detect time in milliseconds. The detect time is the configured minimum interval * multiplier. I configured a 1.000, but you can easily go to several hundreds of ms and a multiplier of 3, which leads to a far better detection time than the default OSPF values.



The NSSA area.

The NSSA area 0.0.1.1 will be activated on all routers. R2 and R3 will only have interfaces in this NSSA area. They will only learn a default route from the routers in Area 0.0.0.0
In order to advertise a default route, one has to be present in the routing table. In this scenario, we will create a static default route on R6 and redistribute that into OSPFv3.
The most basic configuration could be as follows:



scenario


After the default route is present in the routing table, we can move on to configuring the NSSA. On R6 and R2.
Let's take care of R6 first;



scenario


The keywords 'nssa' and 'no-summaries' make sure that R2 will only receive a default route from R6. Observe the following configuration of R2:



scenario


After configuring R2, we can see that a neighbor relationship was created. In the NSSA area, there is an ASBR, which is R6 due to the redistribution of the static default route.
We can also see that the OSPFv3 routes do not include the loopbacks of R6 and R7, nor do they include the network segment between those routers.
Let's perform the same configuration on R7 and R3, and ad an OSPF neighbor relationship between R3 and R2. We will end up with the following;



scenario


R2 and R3 will receive a default from the backbone area. Whenever the neighbor relationship between R2 and R6 fails, R2 will be able to use the default route learned via R3 and vice versa.
When everything is normal, the situation is as follows;



scenario


Now, let's assume the link between R2 and R6 is broken. After this, we would observe the following:



scenario


There would be connectivity via R3's default route (the interface numbering might be confusing, but the lab is on 1 physical box).
R2 and R3 can now offer a redundant uplink to the backbone area, but devices on the remote location needing connectivity will probably not understand OSPFv3. The easiest thing to do, is to give them a virtual gateway using VRRP.
After configuring R2, let's setup R3 as the backup router:



scenario


And verify this on R3;



scenario


R2 will be the owner of the virtual gateway;



scenario


Additionally, you can run BFD between all routers to speed up the process of detecting link-failures. With VRRP however, you also have the option to track the status of an interface or the presence of a route. Through this tracking mechanism, you can decide to lower the router's priority if an interface goes down or a route goes missing, example;



scenario


This should cover most of VRRP, BFD and OSPFv3 for JNCIS-SP.
16-8-2014.