First off, lets take a look at the topology I will be using for this example:
Everything works, and we the math is right, we should see an NHRP shortcut being created for the Spoke to Spoke tunnel:
and on Spoke-02:
And the RIB on both routers should reflect this as well:
The “H” routes are from NHRP
And just to verify that our crypto is working, heres a capture from wireshark on the internet “Cloud” when pinging from Spoke-01 to Spoke-02:
Now lets turn our attention to the Quality of Service aspect of our solution.
We have 3 facts to deal with.
-
The Hub router has a line-rate Gigabit Ethernet circuit to the Internet.
-
The Spoke-01 site has a Gigabit Ethernet circuit, but its a subrate to 10Mbit access-rate.
-
The Spoke-02 site has a Gigabit Ethernet circuit, but its a subrate to 30Mbit access-rate.
We somehow want to signal to the Hub site to “respect” these access-rates. This is where the “Per-Tunnel QoS” feature comes into play.
If you remember the Hub tunnel100 configuration, which looks like this:
Also the NAT configuration itself:
We are only NAT’ing the two loopbacks from the spokes on our network.
Lets verify the NAT state table on the hub:
All good!.