02-11-2010 10:07 AM - edited 03-04-2019 07:28 AM
Greetings, we currently have a small hub and spoke deployement consisting of a single hub and four spoke sites, all running 12.4 Advanced Security on 877 ISR's, we would like to be able to communicate between spokes within establishing a fully meshed topology or by using GRE and dynamic routing as the routers dont have the feature set necessary to support it.
Hub - 192.168.10.0/24
Spoke A - 192.168.20.0/24
Spoke B- 192.168.30.0/24
Spoke C - 192.168.40.0/24
Spoke D - 192.168.50.0/24
L2L Tunnels have already been formed and all is working fine, i have also enabled reverse route on all connections which i thought would take care of the routing without having to add statics on all sites.
Any suggestions would be much appreciated.
Regards
Relevant Hub Config:
crypto isakmp key 85m4EhiH address 1.1.1.1 no-xauth
crypto isakmp key upXJ3R3j address 2.2.2.2 no-xauth
crypto isakmp key dZmpt9cp address 3.3.3.3 no-xauth
crypto isakmp key SGYXHKwa address 4.4.4.4 no-xauth
!
crypto ipsec transform-set 3DesL2L esp-3des
!
crypto map hqmap 1 ipsec-isakmp
description ****** Link to SpokeA ******
set peer 1.1.1.1
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 101
reverse-route
crypto map hqmap 2 ipsec-isakmp
description ****** Link to SpokeB ******
set peer 2.2.2.2
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 102
reverse-route
crypto map hqmap 3 ipsec-isakmp
description ****** Link to SpokeC ******
set peer 3.3.3.3
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 103
reverse-route
crypto map hqmap 4 ipsec-isakmp
description ****** Link to SpokeD ******
set peer 4.4.4.4
set security-association lifetime seconds 86400
set transform-set 3DesL2L
set pfs group2
match address 104
reverse-route
crypto map hqmap 65535 ipsec-isakmp dynamic clientmap
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source route-map nonat interface Dialer1 overload
!
access-list 100 remark ****** NAT ACL ******
access-list 100 deny ip 192.168.10.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 100 permit ip 192.168.10.0 0.0.0.255 any
!
access-list 101 remark ****** Link to SpokeA******
access-list 101 permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
access-list 102 remark ****** Link to SpokeB ******
access-list 102 permit ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255
access-list 103 remark ****** Link to SpokeC ******
access-list 103 permit ip 192.168.10.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 104 remark ****** Link to SpokeD ******
access-list 104 permit ip 192.168.10.0 0.0.0.255 192.168.50.0 0.0.0.255
!
Show IP Route on Hub
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
81.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 81.112.49.0/24 is directly connected, Dialer1
C 81.113.20.1/32 is directly connected, Dialer1
C 192.168.10.0/24 is directly connected, Vlan1
S 192.168.20.0/24 [1/0] via 1.1.1.1
S 192.168.30.0/24 [1/0] via 2.2.2.2
S 192.168.40.0/24 [1/0] via 3.3.3.3
S 192.168.50.0/24 [1/0] via 4.4.4.4
S* 0.0.0.0/0 is directly connected, Dialer1
Show IP Route on Spoke
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
81.0.0.0/32 is subnetted, 1 subnets
C 81.10.88.1 is directly connected, Dialer1
C 212.6.112.0/24 is directly connected, Dialer1
C 192.168.20.0/24 is directly connected, Vlan1
S* 0.0.0.0/0 is directly connected, Dialer1
S 192.168.0.0/16 [1/0] via ***HUB IP ADDRESS**
02-11-2010 10:36 AM
The routers that you have are perfectly fine,Multipoint GRE (DMVPN) is really the best solution even if only static routes, as once done you have full connectivity.
02-11-2010 10:40 AM
These are 877 ISR's running Advanced Security, i did consider DMVPN but for simplicity sake and the fact that i dont have access to EIGRP/OSPF in the feature set i had hoped i could make do with just IPSEC, we are only talking about nominal ammounts of spoke to spoke traffic.
Regards
02-11-2010 12:06 PM
Routing protocol is not mandatory. You can use static or RIPv2 that also works well.
What makes the difference, is the multipoint GRE will avoid a lot of convolute configuration, virtual interfaces, etc.
02-11-2010 12:34 PM
Edit: Scratch that idea i think ill go with the following for simplicity sake, as i would have to reconfigure all the routers to get DMVPN working whilst if i just configure GRE tunnels on the existing L2L Tunnels i can achieve what i want to do.
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008009438e.shtml
Regards
02-11-2010 02:01 PM
This is the configuration i have so far, with this i can ping each spoke on both the LAN IP and Tunnel IP Address, i can also ping the Tunnel IP Address from a Spoke router.
However the spoke router cant ping another Spoke on the LAN IP Address or Tunnel Interface other than the one adjacent to it.
Hub Config
interface Tunnel0
ip address 10.255.255.1 255.255.255.252
tunnel source Dialer1
tunnel destination 1.1.1.1
ip mtu 1420
tunnel path-mtu-discovery
crypto map hqmap
!
interface Tunnel2
ip address 10.255.255.5 255.255.255.252
tunnel source Dialer1
tunnel destination 2.2.2.2
crypto map hqmap
ip mtu 1420
tunnel path-mtu-discovery
!
interface Tunnel3
ip address 10.255.255.9 255.255.255.252
tunnel source Dialer1
tunnel destination 3.3.3.3
crypto map hqmap
ip mtu 1420
tunnel path-mtu-discovery
!
interface Tunnel4
ip address 10.255.255.13 255.255.255.252
tunnel source Dialer1
tunnel destination 4.4.4.4
crypto map hqmap
ip mtu 1420
tunnel path-mtu-discovery
!
ip route 192.168.20.0 255.255.255.0 10.255.255.2
ip route 192.168.30.0 255.255.255.0 10.255.255.6
ip route 192.168.40.0 255.255.255.0 10.255.255.10
ip route 192.168.50.0 255.255.255.0 10.255.255.14
!
Spoke Config
interface Tunnel0
ip address 10.255.255.2 255.255.255.252
tunnel source Dialer1
tunnel destination ***HUB External IP Address***
ip mtu 1420
tunnel path-mtu-discovery
crypto map tiptmap
!
ip route 192.168.0.0 255.255.0.0 10.255.255.1
02-11-2010 02:18 PM
Seems correct, one would need an hand-on session to find some inaccuracy that may have slipped in.
The purporse of the multipoint tunnel is exactly to reduce all the bunch of addresses that lead to errors, and of course allow spoke-to'spoke traffic to not bounce off to hub.
02-11-2010 02:24 PM
Got it working now, had the network statements for RIP wrong on the spokes. Thank you for your comments
Hub
interface Tunnel0
ip address 10.255.255.1 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 1.1.1.1
tunnel path-mtu-discovery
crypto map hqmap
!
interface Tunnel2
ip address 10.255.255.5 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 2.2.2.2
tunnel path-mtu-discovery
crypto map hqmap
!
interface Tunnel3
ip address 10.255.255.9 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 3.3.3.3
tunnel path-mtu-discovery
crypto map hqmap
!
interface Tunnel4
ip address 10.255.255.13 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 4.4.4.4
tunnel path-mtu-discovery
crypto map hqmap
!
router rip
version 2
network 10.0.0.0
network 192.168.0.0
no auto-summary
Spoke
interface Tunnel0
ip address 10.255.255.2 255.255.255.252
ip mtu 1420
tunnel source Dialer1
tunnel destination 10.10.10.10
tunnel path-mtu-discovery
crypto map tiptmap
!
router rip
version 2
network 10.0.0.0
network 192.168.20.0
no auto-summary
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: