[c-nsp] GRE and NHRP; avoiding routing through the hub
Bob Tinkelman
bob at tink.com
Mon Apr 14 17:04:10 EDT 2008
This is a cry for some design advice.
I have an existing configuration using multipoint GRE
tunnels and NHRP to implement backup connections from
customer sites through dsl and cable-modem networks.
It's straightforward and has been fullfilling its purpose.
There is no encryption or IPsec involved. There is almost
no spoke-to-spoke traffic.
I have a new requirement that I'm trying to figure out how
to implement. My first two tries failed, and so I decided
to ask for advice.
I have a customer with two sites, each with (among other
things) a LAN with private ip addresses, and we'd like to
route between these nets "behind the firewalls", and without
any NAT-ing.
A standard solution for this type of configuration seems to
be to use IPsec, as in:
http://www.cisco.com/warp/public/471/dcmvpn.html
This is almost what I want. Traffic from spoke to spoke
will go over a dynamic tunnel set up between the spokes,
when the hub recognizes the need.
That's great. But it depends on the hub's knowing where to
route these packets, which it does by having a copy of the
routing table being used by the spokes. In the referenced
example it participates in the ospf routing. That's a non-
starter; my hub router shouldn't get involved in customer-
private routing.
I thought of having a separate multi-point tunnel for each
customer, possibly each in its own routing VRF-lite routing
table, but that seems like a lot of work, and I'd still
prefer to keep the customer private routes off my router,
even if they're segregated in separate tables.
In a lab environment, I connected two 2651XM routers to DSL/
Cable-modem services and configured a multipoint tunnel
using a central server elsewhere on our net.
Spoke 151
| interface Tunnel202
| description Dynamic multi-point tunnel
| ip address 69.48.189.151 255.255.255.0
| ip nhrp map 69.48.189.1 165.254.97.2
| ip nhrp authentication xxxxxxxxxxxxxxxx
| ip nhrp map multicast 165.254.97.2
| ip nhrp map multicast 165.254.147.2
| ip nhrp map 69.48.189.1 165.254.97.2
| ip nhrp map 69.48.189.2 165.254.147.2
| ip nhrp network-id xxxxxxxxxxxxxxxxx
| ip nhrp holdtime 300
| ip nhrp nhs 69.48.189.1
| ip nhrp nhs 69.48.189.2
| ip nhrp server-only
| ip virtual-reassembly
| no ip route-cache cef
| no ip route-cache
| no ip mroute-cache
| delay 1000
| tunnel source FastEthernet0/1
| tunnel mode gre multipoint
| tunnel key xxxxxxxxxxxxxxxxxxx
...
| ip route 165.254.97.2 255.255.255.255 FastEthernet0/1 dhcp
| ip route 165.254.147.2 255.255.255.255 FastEthernet0/1 dhcp
Spoke 152
| interface Tunnel202
| description Dynamic multi-point tunnel
| ip address 69.48.189.152 255.255.255.0
.... the rest is almost the same ...
The above tunnel works. I can ping from 69.48.189.151 to .152.
Then I added LANs for testing
Spoke 151:
| interface FastEthernet0/0.151
| description Test LAN - 10.151.0.0/24
| encapsulation dot1Q 151
| ip address 10.151.0.1 255.255.255.0
Spoke 152:
| interface FastEthernet0/0.152
| description Test LAN - 10.152.0.0/24
| encapsulation dot1Q 152
| ip address 10.152.0.1 255.255.255.0
Note that traceroute from one spoke to the other actually
goes though the hub:
| test-151-westel#tr 69.48.189.152
|
| Type escape sequence to abort.
| Tracing the route to test-152.tink.com (69.48.189.152)
|
| 1 tu-202.gw1.nycmnycz.ispnetinc.net (69.48.189.1) 32 msec 32 msec 32 msec
| 2 test-152.tink.com (69.48.189.152) 48 msec * 48 msec
| test-151-westel#
So, the idea of using static routes of the form
ip route 10.152.0.0 255.255.255.0 Tunnel202 69.48.189.152
won't work, as packets destined for the 10-networks would go
to the hub which wouldn't know what to do with them.
I tried to solve the problem by encapsulating this traffic
in packets which the hub would know how to handle. I
figured I could use either IPsec or GRE, running over the
existing GRE tunnel.
There's my (failed) attempt using gre.
I defined a new tunnel to run inside the existing tunnel:
Spoke 151:
| interface Tunnel303
| description Point-to-Point tunnel between Sites
| ip address 10.255.255.1 255.255.255.252
| tunnel source Tunnel202
| tunnel destination 68.49.189.152
| ip route 10.152.0.0 255.255.255.0 Tunnel303 10.255.255.2
Spoke 152:
| interface Tunnel303
| description Point-to-Point tunnel between Sites
| ip address 10.255.255.2 255.255.255.252
| tunnel source Tunnel202
| tunnel destination 68.49.189.151
| ip route 10.151.0.0 255.255.255.0 Tunnel303 10.255.255.1
And right there I was stymied. The above doesn't work.
The tunnel looks OK,
| test-151-westel#sho int t303
| Tunnel303 is up, line protocol is up
| Hardware is Tunnel
| Description: Point-to-Point tunnel between Sites
| Internet address is 10.255.255.1/30
| MTU 1514 bytes, BW 100 Kbit, DLY 500000 usec,
| reliability 255/255, txload 1/255, rxload 1/255
| Encapsulation TUNNEL, loopback not set
| Keepalive not set
| Tunnel source 69.48.189.151 (Tunnel202), destination 68.49.189.152
| Tunnel protocol/transport GRE/IP
| Key disabled, sequencing disabled
| Checksumming of packets disabled
| Tunnel TTL 255
| Fast tunneling enabled
but, I can't even ping from one end to the other, let alone
betwen the 10.*.0.0 nets.
Ping my end
| test-151-westel#ping 10.255.255.1
|
| Type escape sequence to abort.
| Sending 5, 100-byte ICMP Echos to 10.255.255.1, timeout is 2 seconds:
| !!!!!
| Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Ping the other end
| test-151-westel#ping 10.255.255.2
|
| Type escape sequence to abort.
| Sending 5, 100-byte ICMP Echos to 10.255.255.2, timeout is 2 seconds:
| .....
| Success rate is 0 percent (0/5)
So, the usual questions:
o Did I just make some stupid mistake in detail ?
o Am I going about this in some totally flawed way ?
(e.g., tunnel-in-tunnel)
o Am I totally off the wall ? :-)
o What's the right way to do this? And, is there a
published example :-) ?
--
Bob Tinkelman <bob at tink.com>
ISPnet, Inc. http://www.ispnetinc.net
+1 (718) 464-4747 office
+1 (800) 806-NETS toll free
+1 (718) 217-9407 fax
More information about the cisco-nsp
mailing list