> Why not nail up a separate GRE tunnel between the two spokes and let the > spoke routers handle the routing, completely separate of your MP GRE?
Sorry, I should have mentioned this. Unlike my lab environment, The real-life spokes will have dynamic ip addresses. I need a way for them to find each other. That's why I was using the multipoint tunnel with NHRP to a hub with a fixed ip address. - Bob > Bob Tinkelman wrote: > > 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 <[EMAIL PROTECTED]> > > ISPnet, Inc. http://www.ispnetinc.net > > > > +1 (718) 464-4747 office > > +1 (800) 806-NETS toll free > > +1 (718) 217-9407 fax > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
