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?
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/
