Posts Tagged ‘multipoint’


DMVPN stands for Dynamic Multipoint VPN and it is an effective solution for dynamic secure overlay networks. In short, DMVPN is combination of the following technologies:

1) Multipoint GRE (mGRE)
2) Next-Hop Resolution Protocol (NHRP)
4) Dynamic Routing Protocol (EIGRP, RIP, OSPF, BGP)
3) Dynamic IPsec encryption
5) Cisco Express Forwarding (CEF)

Assuming that reader has a general understanding of what DMVPN is and a solid understanding of IPsec/CEF, we are going to describe the role and function of each component in details. In this post we are going to illustrate two major phases of DMVPN evolution:

1) Phase 1 – Hub and Spoke (mGRE hub, p2p GRE spokes)
2) Phase 2 – Hub and Spoke with Spoke-to-Spoke tunnels (mGRE everywhere)

As for DMVPN Phase 3 – “Scalable Infrastructure”, a separate post is required to cover the subject. This is due to the significant changes made to NHRP resolution logic (NHRP redirects and shortcuts), which are better being illustrated when a reader has good understanding of first two phases. However, some hints about Phase 3 will be also provided in this post.

Note: Before we start, I would like to thank my friend Alexander Kitaev, for taking time to review the post and providing me with useful feedback.

Continue Reading

Tags: , , , , , , , ,


A common question that I get from students in class is what are the options to resolve spoke to spoke reachability in a Frame-Relay network. Below are your “standard” choices in order of preference:

1) Use point-to-point subinterfaces on the spokes.  This option is preferred as all IP addresses on the subnet will automatically be mapped to the DLCI that is bound to the subinterface.
2) Multipoint interfaces (physical or multipoint subinterfaces) on the spokes with Frame-Relay mappings pointing to the hub’s DLCI to reach the other spokes.
3) Multipoint interfaces on the spokes along with using the OSPF point-to-multipoint network type on all routers on the subnet. Each end point will advertise out a /32 and this advertisement will be relayed to the other spokes by the hub. This is exactly what the OSPF point-to-multipoint network type was designed for (full layer 3 reachability in a network that doesn’t have full layer 2 connectivity.
4) Use PPP over Frame-Relay (PPPoFR). By using PPPoFR IP will now be running over PPP and not directly over Frame-Relay. This means that IP sees everything as point-to-point links and no layer 3 to layer 2 mappings are needed.
5) Static /32 routes on the spokes point to the hub to reach the other spokes. Not a pretty solution but it will resolve the reachability issue.

Tags: , , ,



Why does the point-to-multipoint OSPF network type generate the /32 routes and how can I stop them from being advertised?

The behavior of point-to-multipoint is to advertise each end-point out as a /32 and suppress the advertisement of the network itself. Point-to-multipoint advertises the end points to overcome possible reachability issues between devices that are on the same logical subnet but do not have direct communication (i.e. spoke to spoke communication in a hub and spoke environment). The OSPF point-to-multipoint and loopback network types do not advertise the network itself but advertise a host route for each end-point. This is as per the RFC.

If you want to suppress the /32s and advertise only the network, you would need to use an OSPF network type other than point-to-multipoint or configure the network to be in its own OSPF area. After the network is put in its own OSPF area, use the area range command to summarize the /32s so other routers only see the summarized route.

Tags: , ,


By adjusting the hello/dead timers you can make non-compatible OSPF network types appear as neighbors via the “show ip ospf neighbor” but they won’t become “adjacent” with each other.  OSPF network types that use a DR (broadcast and non-broadcast) can neighbor with each other and function properly.  Likewise OSPF network types (point-to-point and point-to-multipoint) that do not use a DR can neighbor with each other and function properly.  But if you mix DR types with non-DR types they will not function properly (i.e. not fully adjacent).  You should see in the OSPF database “Adv Router is not-reachable” messages when you’ve mixed DR and non-DR types.

Here is what will work:

Broadcast to Broadcast
Non-Broadcast to Non-Broadcast
Point-to-Point to Point-to-Point
Point-to-Multipoint to Point-to-Multipoint
Broadcast to Non-Broadcast (adjust hello/dead timers)
Point-to-Point to Point-to-Multipoint (adjust hello/dead timers)

Tags: , , , ,


CCIE Bloggers