CCDTT

6.2.3.7 Packet Tracer – Configuring Multiarea OSPFv3.pka

Download Lab Here

 

The OSPFv3 Multiarea Adjacency feature allows you to configure a link that multiple Open Shortest Path First version 3 (OSPFv3) areas can share to enable optimized routing. You can add more than one area to an existing OSPFv3 primary interface.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Prerequisites for OSPFv3 Multiarea Adjacency

  • Ensure that Open Shortest Path First version 3 (OSPFv3) is configured on the primary interface.
  • Ensure that the primary interface type is point-to-point.

Restrictions for OSPFv3 Multiarea Adjacency

  • A multiarea interface operates only if OSPFv3 is configured on the primary interface and the OSPFv3 network type of the primary interface is point-to-point.
  • A multiarea interface exists as a logical construct over a primary interface for OSPFv3; however, the neighbor state on the primary interface is independent of the multiarea interface.
  • A multiarea interface establishes a neighbor relationship with the corresponding multiarea interface on the neighboring device. A mixture of multiarea and primary interfaces is not supported.
  • A multiarea interface advertises a point-to-point connection to another device in the device link-state advertisement (LSA) for the corresponding area when the neighbor state is full.
  • A multiarea interface inherits all the OSPFv3 parameters (such as, authentication) from the primary interface. You cannot configure the parameters on a multiarea interface; however, you can configure the parameters on the primary interface.
Information About OSPFv3 Multiarea Adjacency

OSPFv3 Multiarea Adjacency Overview

Open Shortest Path First version 3 (OSPFv3) allows a single physical link to be shared by multiple areas. This creates an intra-area path in each of the corresponding areas sharing the same link. All areas have an interface on which you can configure OSPFv3. One of these interfaces is designated as the primary interface and others as secondary interfaces.The OSPFv3 Multiarea Adjacency feature allows you to configure a link on the primary interface to enable optimized routing in multiple areas. Each multiarea interface is announced as a point-to-point unnumbered link. The multiarea interface exists as a logical construct over an existing primary interface. The neighbor state on the primary interface is independent of the neighbor state of the multiarea interface. The multiarea interface establishes a neighbor relationship with the corresponding multiarea interface on the neighboring device. You can only configure multiarea adjacency on an interface that has two OSPFv3 speakers.Use the ospfv3 multi-area command to configure multiarea adjacency on the primary OSPFv3 interface.

For example, picture a global company with 3,000 locations throughout the world. Some sites are large, with a few thousand end users and redundant, high-quality internet connections. However, some sites are small and located in remote locations where the best internet connection available is a flaky T1. This isn’t at all hypothetical. This is common among large organizations with sites located in emerging countries.In this design, all DMVPN spokes register with the DMVPN hub locations — for example, one in New York and one in London. Additionally, spokes have dynamically created on-demand spoke-to-spoke connectivity. With 3,000 locations around the world and likely tens of thousands of routes, the topology changes often, even if the changes are relatively minor. If the organization chooses to run OSPF over DMVPN using default OSPF settings, whenever one of these changes occurs, all 3,000 routers would have to rerun SPF.  And this is why it’s advisable to run stub or NSSA areas.Though OSPF over DMVPN phase 3 can be configured and fine-tuned to function over a DMVPN topology, a better option is to run EIGRP and configure spokes as stubs. This eliminates configuration complexity and the risk for high CPU utilization from running SPF due to route churn. If CPU utilization is consistently high enough, it can bring down a network. OSPF is extremely popular, especially since it’s an open standard. An exterior gateway protocol, such as the Border Gateway Protocol, is also a good option for very large deployments, but when choosing an IGP for use over a DMVPN infrastructure, using a vector protocol such as EIGRP is best practice.

Share the Post:

Related Posts

Help Us By Donating