cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
437
Views
15
Helpful
29
Replies
VIP Mentor

Re: GRE Tunnel issue

Hello,

 

since both public IP addresses are not in the same subnet, the only thing left I can think of is that some intermediate device blocks the multicast traffic for EIGRP...

 

Try the 'neighbor' command under the EIGRP processes on both routers (which effectively creates a unicast neighborship)...

 

Router1:

 

interface Tunnel100
ip address 172.25.100.1 255.255.255.252
ip mtu 1300
ip tcp adjust-mss 1260
tunnel source 148.244.229.68
tunnel destination 96.85.125.162

!

router eigrp 1
distribute-list prefix filter_eigrp out
neighbor 172.25.100.2 Tunnel100
network 10.84.0.0 0.0.255.255
network 172.25.100.0 0.0.0.3
redistribute static route-map static2EIGRP
passive-interface Loopback0

 

Router2:

 

interface Tunnel100
ip address 172.25.100.2 255.255.255.252
ip mtu 1300
ip tcp adjust-mss 1260
tunnel source 96.85.125.162
tunnel destination 148.244.229.68

!

router eigrp 1
distribute-list prefix filter_eigrp out
neighbor 172.25.100.1 Tunnel100
network 10.86.0.0 0.0.255.255
network 172.25.100.0 0.0.0.3
redistribute static route-map static2EIGRP
passive-interface Loopback0

Highlighted
Participant

Re: GRE Tunnel issue

First, I would not worry about EIGRP for now.  Point-to-point tunneled IP connectivity is a prerequisite for end-to-end EIGRP connectivity, so let's resolve that first.  Do a "show ip route {remote tunnel IP}" from each router.  Let's make sure that it shows as directly connected to interface Tunnel100 on both ends.  Next, let's see if an old bug is in play; change the tunnel source from the IP address of the routers' local interfaces to the interface name that it will be egressing to arrive at the remote destination.  Next, do a "show ip route {remote tunnel destination IP}" on each router, to validate both ends are actually egressing the predicted interface to arrive at the remote destination public IP.  

 

 

Re: GRE Tunnel issue

ur tunel has mtu size 1300, BUT for eigrp_gre tunnel  mtu size must be higher than the EIGRP header + whatever TLVs will be attached to this. Try to set the MTU to 5x32 (EIGRP header) +20 (IP header) and watch what is happening with the adjacency

Then go lower and check again. Use debug EIGRP to see it in action. I assume ur egrp messages get dropped.

Enthusiast

Re: GRE Tunnel issue

Hi,

I have a issue with one of the spoke...

 

show cry isa sa is showing : QM_IDLE but i cant see tunnel in the eigrp neighbour list.

Here is the output:

 

JIRCVPN2#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
221.123.160.154 218.104.50.122 QM_IDLE 1575 ACTIVE

 

 

what could be the reason!!!

Thanks

 

VIP Mentor

Re: GRE Tunnel issue

Hello,

 

post the current configurations...

Enthusiast

Re: GRE Tunnel issue

Here are the spoke and hub tunnel config:

 

Spoke:

interface Tunnel156
bandwidth 4000
ip address 172.25.156.58 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication BJ56DVPN
ip nhrp map 172.25.156.56 221.123.160.154
ip nhrp map multicast 221.123.160.154
ip nhrp map 172.25.156.50 211.95.31.106
ip nhrp map multicast 211.95.31.106
ip nhrp network-id 2
ip nhrp holdtime 300
ip nhrp nhs 172.25.156.56 priority 1 cluster 6
ip nhrp nhs 172.25.156.50 priority 2 cluster 6
ip nhrp nhs cluster 6 max-connections 2
ip nhrp nhs fallback 5
ip nhrp shortcut
ip tcp adjust-mss 1360
delay 3001
tunnel source GigabitEthernet0/2
tunnel mode gre multipoint
tunnel key 2
tunnel path-mtu-discovery
tunnel vrf ISP2


HUB1:

interface Tunnel156
bandwidth 4000
ip address 172.25.156.56 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1
ip nhrp authentication BJ56DVPN
ip nhrp map multicast dynamic
ip nhrp network-id 2
ip nhrp holdtime 300
ip nhrp redirect
ip tcp adjust-mss 1360
delay 1500
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 2
tunnel path-mtu-discovery
tunnel vrf ISP2

 

Thanks

 

VIP Mentor

Re: GRE Tunnel issue

Hello,

 

what is the output of 'show ip cef' from the spoke ? Can you ping another spoke from the spoke of which you posted the config ?

Enthusiast

Re: GRE Tunnel issue

 

Ping from HUB:

HUB1#ping vrf ISP2 123.138.200.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 123.138.200.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms

 

Ping from SPOKE:

SPOKE1#ping vrf ISP2 221.123.160.154
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 221.123.160.154, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Thanks

 

 

 

Rising star

Re: GRE Tunnel issue

there is no tunnel protection...
Enthusiast

Re: GRE Tunnel issue

Its there......I skip it on CSC forum.

Rising star

Re: GRE Tunnel issue

debug crypto ipsec
Enthusiast

Re: GRE Tunnel issue

here are the logs:

 

-------------------

SPOKE1#sh logging
Syslog logging: enabled (0 messages dropped, 4 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)

No Active Message Discriminator.

 

No Inactive Message Discriminator.


Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 211 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled

No active filter modules.

Trap logging: level informational, 86 message lines logged
Logging to 10.18.2.18 (udp port 514, audit disabled,
link up),
85 message lines logged,
0 message lines rate-limited,
0 message lines dropped-by-MD,
xml disabled, sequence number disabled
filtering disabled
Logging Source-Interface: VRF Name:
Loopback0

Log Buffer (16386 bytes):

Nov 19 15:00:51 MET: %SYS-5-CONFIG_I: Configured from console by gcmaint on vty0 (10.18.19.7)
Nov 19 14:15:44.312: IPSEC:(SESSION ID = 285) (cleanup_tun_decap_oce) unlock and null out profile-shared Tunnel156 lookup_oce 3EC78440 from ident 3F74EF30
Nov 19 14:15:44.312: insert of map into mapdb AVL failed, map + ace pair already exists on the mapdb
Nov 19 14:15:44.316: IPSEC: Expand action denied, discard or forward packet.
Nov 19 14:15:44.316: IPSEC: Expand action denied, notify RP
Nov 19 14:15:44.316: IPSEC: Expand action denied, discard or forward packet.
Nov 19 14:15:44.316: IPSEC: Expand action denied, discard or forward packet.
Nov 19 14:15:44.316: IPSEC:(SESSION ID = 285) (recalculate_mtu) reset sadb_root 22ABC398 mtu to 1500
Nov 19 14:15:44.316: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 123.138.200.2:500, remote= 221.123.160.154:500,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Transport),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
Nov 19 14:15:44.344: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Nov 19 14:15:44.344: IDB is NULL : in crypto_ipsec_key_engine_delete_sas (), 5410
Nov 19 14:15:44.344: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
Nov 19 14:15:44.344: IPSEC: still in use sa: 0x0
Nov 19 14:15:44.344: IPSEC: sa null
Nov 19 14:15:51.340: IPSEC(validate_proposal_request): proposal part #1
Nov 19 14:15:51.340: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Transport),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
Nov 19 14:15:51.340: Crypto mapdb : proxy_match
src addr : 123.138.200.2
dst addr : 221.123.160.154
protocol : 47
src port : 0
dst port : 0
Nov 19 14:15:51.340: (ipsec_process_proposal)Map Accepted: vpn_profile_hasel_aes-head-1, 65538
Nov 19 14:15:51.340: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Nov 19 14:15:51.340: Crypto mapdb : proxy_match
src addr : 123.138.200.2
dst addr : 221.123.160.154
protocol : 47
src port : 0
dst port : 0
Nov 19 14:15:51.340: IPSEC(crypto_ipsec_create_ipsec_sas): Map found vpn_profile_hasel_aes-head-1, 65538
Nov 19 14:15:51.340: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 221.123.160.154
Nov 19 14:15:51.340: IPSEC(crypto_ipsec_update_ident_tunnel_decap_oce): updating profile-shared Tunnel156 ident 3F74EF30 with lookup_oce 3EC78440
Nov 19 14:15:51.340: IPSEC(get_old_outbound_sa_for_peer): No outbound SA found for peer 3F20FD6C
Nov 19 14:15:51.340: IPSEC(create_sa): sa created,
(sa) sa_dest= 123.138.200.2, sa_proto= 50,
sa_spi= 0x4DACC233(1303167539),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2581
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:15:51.340: IPSEC(create_sa): sa created,
(sa) sa_dest= 221.123.160.154, sa_proto= 50,
sa_spi= 0x95652419(2506433561),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2582
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:15:51.372: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Nov 19 14:15:51.372: IDB is NULL : in crypto_ipsec_key_engine_delete_sas (), 5410
Nov 19 14:15:51.372: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
Nov 19 14:15:51.372: IPSEC: delete incomplete sa: 0x3F77829C
Nov 19 14:15:51.372: IPSEC(key_engine_delete_sas): delete SA with spi 0x95652419 proto 50 for 221.123.160.154
Nov 19 14:15:51.372: IPSEC(update_current_outbound_sa): updated peer 221.123.160.154 current outbound sa to SPI 0
Nov 19 14:15:51.372: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 123.138.200.2, sa_proto= 50,
sa_spi= 0x4DACC233(1303167539),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2581
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:15:51.372: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 221.123.160.154, sa_proto= 50,
sa_spi= 0x95652419(2506433561),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2582
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:15:51.372: IPSEC(send_delete_notify_kmi): not sending KEY_ENGINE_DELETE_SAS
Nov 19 14:15:51.376: IPSEC(ident_delete_notify_kmi): Failed to send KEY_ENG_DELETE_SAS
Nov 19 14:15:51.376: IPSEC(ident_update_final_flow_stats): Collect Final Stats and update MIB
IPSEC get IKMP peer index from peer 0x3F20FD6C ikmp handle 0x800000E8
IPSEC IKMP peer index 0
[ident_update_final_flow_stats] : Flow delete complete event received for flow id 0x34000245,peer index 0

Nov 19 14:15:53.484: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 123.138.200.2:500, remote= 221.123.160.154:500,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Transport),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
Nov 19 14:15:53.512: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Nov 19 14:15:53.512: IDB is NULL : in crypto_ipsec_key_engine_delete_sas (), 5410
Nov 19 14:15:53.512: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
Nov 19 14:15:53.512: IPSEC: still in use sa: 0x0
Nov 19 14:15:53.512: IPSEC: sa null
Nov 19 14:16:21.340: IPSEC(validate_proposal_request): proposal part #1
Nov 19 14:16:21.340: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Transport),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
Nov 19 14:16:21.340: Crypto mapdb : proxy_match
src addr : 123.138.200.2
dst addr : 221.123.160.154
protocol : 47
src port : 0
dst port : 0
Nov 19 14:16:21.340: (ipsec_process_proposal)Map Accepted: vpn_profile_hasel_aes-head-1, 65538
Nov 19 14:16:21.340: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Nov 19 14:16:21.340: Crypto mapdb : proxy_match
src addr : 123.138.200.2
dst addr : 221.123.160.154
protocol : 47
src port : 0
dst port : 0
Nov 19 14:16:21.340: IPSEC(crypto_ipsec_create_ipsec_sas): Map found vpn_profile_hasel_aes-head-1, 65538
Nov 19 14:16:21.340: IPSEC(get_old_outbound_sa_for_peer): No outbound SA found for peer 3F20FD6C
Nov 19 14:16:21.340: IPSEC(create_sa): sa created,
(sa) sa_dest= 123.138.200.2, sa_proto= 50,
sa_spi= 0x11C9E84A(298444874),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2583
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:16:21.340: IPSEC(create_sa): sa created,
(sa) sa_dest= 221.123.160.154, sa_proto= 50,
sa_spi= 0xCC8FCF6F(3431976815),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2584
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:16:21.372: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Nov 19 14:16:21.372: IDB is NULL : in crypto_ipsec_key_engine_delete_sas (), 5410
Nov 19 14:16:21.372: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
Nov 19 14:16:21.372: IPSEC: delete incomplete sa: 0x3F778208
Nov 19 14:16:21.372: IPSEC(key_engine_delete_sas): delete SA with spi 0xCC8FCF6F proto 50 for 221.123.160.154
Nov 19 14:16:21.376: IPSEC(update_current_outbound_sa): updated peer 221.123.160.154 current outbound sa to SPI 0
Nov 19 14:16:21.376: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 123.138.200.2, sa_proto= 50,
sa_spi= 0x11C9E84A(298444874),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2583
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:16:21.376: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 221.123.160.154, sa_proto= 50,
sa_spi= 0xCC8FCF6F(3431976815),
sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2584
sa_lifetime(k/sec)= (4608000/3600),
(identity) local= 123.138.200.2:0, remote= 221.123.160.154:0,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0
Nov 19 14:16:21.376: IPSEC(send_delete_notify_kmi): not sending KEY_ENGINE_DELETE_SAS
Nov 19 14:16:21.376: IPSEC(ident_delete_notify_kmi): Failed to send KEY_ENG_DELETE_SAS
Nov 19 14:16:21.376: IPSEC(ident_update_final_flow_stats): Collect Final Stats and update MIB
IPSEC get IKMP peer index from peer 0x3F20FD6C ikmp handle 0x800000E8
IPSEC IKMP peer index 0
[ident_update_final_flow_stats] : Flow delete complete event received for flow id 0x34000247,peer index 0

Nov 19 14:16:25.380: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 123.138.200.2:500, remote= 221.123.160.154:500,
local_proxy= 123.138.200.2/255.255.255.255/47/0,
remote_proxy= 221.123.160.154/255.255.255.255/47/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Transport),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
Nov 19 14:16:25.408: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Nov 19 14:16:25.408: IDB is NULL : in crypto_ipsec_key_engine_delete_sas (), 5410
Nov 19 14:16:25.408: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
Nov 19 14:16:25.408: IPSEC: still in use sa: 0x0
Nov 19 14:16:25.408: IPSEC: sa null
Nov 19 14:16:25.916: IPSEC(key_engine): got a queue event with 1 KMI message(s)

 

-------------------

 

Thanks

Rising star

Re: GRE Tunnel issue

probably it's a bad design problem.
do you have two isp on the hub? do you have vrf's on the hub? or all of them in GRT?

Enthusiast

Re: GRE Tunnel issue

yes i have two hub with each having 2 isp and every spoke have 2 isps.

 

HUB and spoke are using VRFs,

 

Thanks

Beginner

Re: GRE Tunnel issue

Hi

 

What do these route-map static2EIGRP and the filter list do?

 

Did you try to bring up the neigborship with a plain configuration, a mean with no route-map or filter list?

 

router eigrp 1
network 10.86.0.0 0.0.255.255
network 172.25.100.0 0.0.0.3
passive-interface Loopback0

 

 

 

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards