12-19-2011 09:13 AM
Hello,
I have a frame-relay hub and spoke environment.
One head office ( hub) and around seven remote branch office.
I am trying to encrypt all data between hub and spoke using point to point gre tunnels from hub to spokes.
I did the necessary configure on all routers and using SDM and all the tunnels showed up.
The problem when I tried to redirect all traffic for the respective subnet thru the tunnel s assigned
nothing is happen.
I decided to do some troubleshooting using a one spoke and testing connection to the hub.
Pinging from head office to endpoint of the tunnel
Router01#ping ppp.168.140.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to ppp.168.140.14, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Pinging from Spoke to endpoint of the tunnel
router04#ping ppp.168.140.4
Sending 5, 100-byte ICMP Echos to ppp.168.140.4, timeout is 2 seconds:
.....
Show neighbor networks learned by Spoke as a result of eigrp process
router04#sh ip eigrp ne
IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.x.x.1 Se0/0/0.1 14 2d21h 40 2280 0 2493678
Show neighbor networks learned by Hub as a result of eigrp process
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
8 ppp.168.160.16 Tu2 31 00:00:26 1 5000 1 0
7 ppp.168.150.15 Tu1 13 00:00:47 1 5000 1 0
3 ppp.168.170.17 Tu3 14 00:00:59 1 5000 1 0
2 ppp.192.168.190.19 Tu4 13 00:01:05 1 5000 1 0
0 ppp.168.140.14 Tu0 31 00:01:18 1 5000 1 0
11 10.x.0.6 Se0/0/0.4 12 02:40:20 53 318 0 399684
1 10.x.x.9 Se0/0/0.7 11 02:41:20 1380 5000 0 377427
9 10.x.x.5 Se0/0/0.3 11 02:44:28 47 1426 0 370651
4 10.x.x.7 Se0/0/0.5 12 1d23h 51 306 0 363006
5 10.x.x.8 Se0/0/0.1 12 2d06h 77 462 0 1210492
12 10.x.x.11 Se0/0/0.8 11 2d21h 51 306 0 395295
6 10.x.x.4 Se0/0/0.2 14 2d21h 53 318 0 284379
Router01#
I have a enclosed the configurations of the hub and one of the spoke ( the problem as outline above is happening for all the spoke ) .
Also it should be mention the pre-share keys were strip off and the ip address edited for security reasons.
Regards
Jomo
Solved! Go to Solution.
12-22-2011 06:53 AM
12-19-2011 11:47 AM
Remove the encryption from ALL tunnel interfaces.
12-19-2011 12:56 PM
Hello Prince.
Can I just remove encryption on the spoke and the corresponding tunnel on the Hub?.
Also will
no crypto map SDM_CMAP_1
be suffice to remove the encryption if not can you provide a command to remove same.
Regards
12-19-2011 03:08 PM
Yes to both questions - that is the best way to remove the encrption on the tunnel - without actually removing the encryption settings.
12-20-2011 06:15 AM
hello Andrew,
I remove the encryption as per direction what is the next step.
I tried ping the the interface as outline in previous post and the same response.
Regards
12-20-2011 06:29 AM
OK - can you ping the tunnel source and destination IP addresses? Post the output of "show ip interface brief" & "show frame-relay lmi" & "show frame-relay pvc" & "show frame-relay map"
12-20-2011 07:15 AM
12-20-2011 06:54 AM
I have read the whole config of Hub and Spoke and you have a fundimental desgin issue. You cannot have multiple serial point-to-point interfaces and use ip unnumbered. For this type of topology a specific interface is required @ the hub. You need to reconfigure it to a "multipoint" interface, if you wish to keep the same IP subnetting. You also need to statically define frame-relay ip maps to set remote IP to DLCI. Then it will work for you.
12-20-2011 08:05 AM
I am in a bit of jam.
To reconfigure hub in production will need downtime this we cannot afford.
Is there a remote possibility that you can come up with a work around.
I mean we can ping the tunnel source and destination IP addressesbut just the traffic for the respected subnet
refuse to go thru the tunnel.
We are currently phasing out frame-relay and there is another hub router and 8 spoke using ip dsl and dmvpn for tunnel
creation and encryption, soon all the spokes on the frame-relay platform will be integrated into the existing ip dsl enivorment.
For short term we would like to encryption the frame-relay traffic and would be grateful if you can suggest a work around
using the current frame-relay config.
Regards
12-20-2011 08:41 AM
I am confused - if you say no traffic will go thru the tunnel, then the tunnels/Frame relay are not working??
12-20-2011 09:27 AM
hello Andrew,
That is correct the tunnels are showing up, but the greater task is the tunnels.frame-relay combination and this clearly
not working due the flaw design ,yes the tunnels/Frame relay are not working.
But is there anything we can do with the current confiog to make the tunnels/frame-relay working?
Regards
12-20-2011 09:49 AM
I would do the below
1) change the IP subnets for the sub-interfaces at the hub and spokes (See below for IP subnets)
2) re-configure the the tunnels to reflect the new tunnel source/destinations
3) Confirm tunnels are up
4) Re-configure the dynamic routing protocol to confirm neighbours and remote subnets available via the hub
5) Configure the tunnel encryption
The most difficult taks would be 1 - as you need remote access to the spokes via another IP connection, does this exist?
HUB 10.x.x.1 > Spoke 1 10.x.x.2 /30
HUB 10.x.x.5 > Spoke 2 10.x.x.6 /30
HUB 10.x.x.9 > Spoke 3 10.x.x.10 /30
HUB 10.x.x.13 > Spoke 4 10.x.x.14 /30
HUB 10.x.x.17 > Spoke 5 10.x.x.18 /30
etc.
12-20-2011 12:13 PM
As per my previous post - my configs would be
***** HUB *****
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key c15c0 address 10.0.0.2
crypto isakmp key c15c0 address 10.0.0.6
!
!
crypto ipsec transform-set FR-ENCRYPTION esp-aes esp-sha-hmac
!
crypto ipsec profile ENCRYPT-GRE
set transform-set FR-ENCRYPTION
!
interface Tunnel1
ip address 10.0.1.1 255.255.255.252
tunnel source Serial1/0.1
tunnel destination 10.0.0.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile ENCRYPT-GRE
!
interface Tunnel2
ip address 10.0.1.5 255.255.255.252
tunnel source Serial1/0.2
tunnel destination 10.0.0.6
tunnel mode ipsec ipv4
tunnel protection ipsec profile ENCRYPT-GRE
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial1/0.1 point-to-point
ip address 10.0.0.1 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 16
!
interface Serial1/0.2 point-to-point
ip address 10.0.0.5 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 17
!
router eigrp 1
passive-interface default
no passive-interface Tunnel1
no passive-interface Tunnel2
network 10.0.0.0
no auto-summary
***** Spoke 1 *****
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key c15c0 address 10.0.0.1
!
crypto ipsec transform-set FR-ENCRYPTION esp-aes esp-sha-hmac
!
crypto ipsec profile ENCRYPT-GRE
set transform-set FR-ENCRYPTION
!
interface Tunnel1
ip address 10.0.1.2 255.255.255.252
tunnel source Serial1/0.1
tunnel destination 10.0.0.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile ENCRYPT-GRE
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial1/0.1 point-to-point
ip address 10.0.0.2 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 16
!
router eigrp 1
passive-interface default
no passive-interface Tunnel1
network 10.0.0.0
no auto-summary
!
***** Spoke 2 *****
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key c15c0 address 10.0.0.5
!
crypto ipsec transform-set FR-ENCRYPTION esp-aes esp-sha-hmac
!
crypto ipsec profile ENCRYPT-GRE
set transform-set FR-ENCRYPTION
!
interface Tunnel1
ip address 10.0.1.6 255.255.255.252
tunnel source Serial1/0.1
tunnel destination 10.0.0.5
tunnel mode ipsec ipv4
tunnel protection ipsec profile ENCRYPT-GRE
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial1/0.1 point-to-point
ip address 10.0.0.6 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 17
!
router eigrp 1
passive-interface default
no passive-interface Tunnel1
network 10.0.0.0
no auto-summary
!
HTH>
12-22-2011 05:37 AM
Hi Andrew,
I tried you suggestion in lab and it work fine, but after discussion with my supervisor, Management do not want to risk
disrupting the production enviroment and hence we will settle for the phase out of frame-relay and integration of same in to IP dsl.
Thanks for your time and suggestion and it was informative and learning expirence for me.
Best of wishes and may you enjoy the festive season to the max.
Regards
12-22-2011 06:53 AM
Sure no problem.
Have a good holiday.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide