RE: RIB and FIB Interaction [7:123656] posted 07/18/2007
- Subject: RE: RIB and FIB Interaction [7:123656]
- From: "scott vermillion" <nobody@xxxxxxxxxxxxxx>
- Date: Wed, 18 Jul 2007 17:18:42 -0400
> My first question is why? If
> the tunnels are virtual why can't they be nailed up?
In short, they could be! But, depending on your topology, do you always
want a full-mesh of tunnels between all of your spokes? What if you have a
few hundred of them? A thousand or more? Of course not. In that case, the
obvious choice (putting DMVPN aside for the moment) would be a traditional
hub-and-spoke topology, with all spoke-to-spoke traffic transiting the hub.
For some, that = YUCK. Think dual encryption/decryption (once to the hub
and once from). Also, every time you add a spoke, you need to add
additional config at the hub as well as at the spoke.
In reality, there is actually a variety of scenarios that DMVPN answers. So
as to stay within the bounds of my knowledge, I'll give you my common, very
I have a "deployable" network which might be set up by, say, first
responders on a disaster scene. The network is fronted by a single
deployable router (usually out of the Cisco MAR series (3200), but
occasionally a lower-end ISR). This router, some switching stuff, maybe
some celluar data stuff, etc, is all packaged in a single chassis that is
plopped down in a hotel room w/ either WiFi or wireline Ethernet. The hotel
obviously does dynamic addressing from RFC 1918 and PAT at the front door.
First two challenges arise at this point:
--I need a L4 header so that PAT works. This is handled by NAT-T, which
isn't really DMVPN at all, but the two are typically coupled together, at
least in my experience.
--I have a dynamic address, which from the perspective of the Head End is
actually the hotel's public IP. I couldn't have nailed this tunnel up, as I
couldn't have known in advance what to tell the HE what the spoke IP would
be. This is one area where NHRP comes into play. A dynamic entry is placed
at the HE that says "tunnel end-point so-and-so presently can be reached at
public IP so-and-so."
For my application, this is usually enough â?? end of story. Of course, I
also do IPSec and all of that on the multipoint tunnels and I run EIGRP or
OSPF. But back to spoke-to-spoke, which is where I believe most DMVPN
applicability lies for most organizations...
The need for multipoint at the HE is obvious; lots of spokes. But the
spokes can also be multipoint. Since they dynamically register themselves
with the hub via NHRP, when a spoke has traffic for another spoke, it can
initially begin sending that traffic via the hub while NHRP dynamically
informs the originating spoke how to reach the destination spoke and
dynamically establish a direct tunnel for however long its required. The
spoke is relieved of needing to know this in advance, which is an especially
big deal when other spokes are picking up dynamic (read: potentially
changing) public IPs.
This greatly simplifies everything. If I want to add a spoke, I just set it
up to become a new NHRP client (and all of the attending config) and off it
goes; nothing specific is required at the head end in terms of config
(depending on how you do authentication, there may be steps to be taken at
the HE location, but you do not need to modify the tunnel config, as NHRP
will dynamically register the spoke). Also, I don't need a /30 or /31
subnet for every hub-spoke tunnel; in DMVPN w/ mGRE, the hub and all the
spokes are in a single subnet. On and on. Itâ??s just a better solution
overall if you have dynamic addressing at the spokes and/or if you stand to
benefit from spoke-to-spoke flows vs. spoke-to-hub-to-spoke flows.
No doubt others here have come up with novel implementations of DMVPN. In
my case, I actually wound up turning to DMVPN/NHRP in order to avoid the use
of Mobile IP, which lacks significantly in High Availability functionality.
With DMVPN, you can easily build redundancy at the HE and also easily build
redundant HEs. Much cleaner and much more functional that Mobile IP.
OK, back to a thorough review of OSPFâ?¦
Message Posted at:
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html