03-10-2013 12:29 PM - edited 03-04-2019 07:14 PM
Hi,
I am doing some tests using tunnel interfaces.
My tunnels are working fine, but when I tried to configure keepalive parameters on both sides, tunnels go down !!
I tried to configure ´´keepalive 5 3´´, and also ´´keepalive 10 3´´...both options send my interface tunnel to down
If I go back to ´´no keepalive´´, both tunnels go back to up and everything works fine.
SITEA(config-if)#int tun 10
SITEA(config-if)#keep 5 3
%SYS-5-CONFIG_I: Configured from console by console
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, changed state to down
SITEB(config-if)#int tun 10
SITEB(config-if)#keep 5 3
%SYS-5-CONFIG_I: Configured from console by console
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, changed state to down
Is keepalive supported on tunnel interfaces or do I need to add extra config under my tunnel interfaces?
SITE A:
interface Tunnel10
ip vrf forwarding test
ip address 100.100.100.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Loopback6
tunnel destination 6.1.1.2
sh int tun 10
Tunnel10 is up, line protocol is up
Hardware is Tunnel
Internet address is 100.100.100.1/24
MTU 17916 bytes, BW 100 Kbit, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 6.1.1.1 (Loopback6), destination 6.1.1.2
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:30:29, output 00:30:29, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1572 packets input, 176188 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1541 packets output, 175460 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
SITE B:
!
interface Tunnel10
ip vrf forwarding test
ip address 100.100.100.2 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Loopback6
tunnel destination 6.1.1.1
sh int tun 10
Tunnel10 is up, line protocol is up
Hardware is Tunnel
Internet address is 100.100.100.2/24
MTU 17916 bytes, BW 100 Kbit, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 6.1.1.2 (Loopback6), destination 6.1.1.1
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:31:22, output 00:31:22, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1521 packets input, 172980 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1572 packets output, 176188 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Please help....!
Thanks,
Regards
guruiz
03-10-2013 02:12 PM
Hi Guruiz,
I think you need to use tunnel vrf...
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml
interface Tunnel0 ip vrf forwarding green ip address 200.200.200.3 255.255.255.0 tunnel source Ethernet0/0 tunnel destination 10.10.10.1 tunnel vrf blue!--- Tunnel 0 is part of VRF GREEN; but it uses the tunnel !--- destination and source addresses from the routing !--- table of VRF BLUE, because of this tunnel vrf blue!--- command. |
Are the source and destination IPs in the same VRF, different VRF, or global routing table?
Also, does it work OK without the keepalive command?
Thanks!
Nick
03-10-2013 08:54 PM
Hi Nick,
Thank you for your answer !
Source and Destination IPs (6.1.1.1 and 6.1.1.2) are in the global routing table.
Only Tunnel 10 in both sides are in the vrf test. Here are the routes:
SITEA:
!
interface Loopback6
ip address 6.1.1.1 255.255.255.255
!
!
SITEA#sh ip route
6.0.0.0/32 is subnetted, 2 subnets
C 6.1.1.1 is directly connected, Loopback6
O E2 6.1.1.2 [110/20] via 180.176.134.110, 00:39:31, GigabitEthernet1/0
!
!
SITEA#sh ip route vrf test
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 100.100.100.0/24 is directly connected, Tunnel10
L 100.100.100.1/32 is directly connected, Tunnel10
--------------------------------------------------------------------------
SITEB:
!
interface Loopback6
ip address 6.1.1.2 255.255.255.255
!
!
SITEB#sh ip route
6.0.0.0/32 is subnetted, 2 subnets
O E2 6.1.1.1 [110/20] via 180.176.134.109, 00:42:04, GigabitEthernet1/0
C 6.1.1.2 is directly connected, Loopback6
!
!
SITEB#sh ip route vrf test
100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 100.100.100.0/24 is directly connected, Tunnel10
L 100.100.100.2/32 is directly connected, Tunnel10
I want to configure keepalives to adjust period and retries timers with shorter timers.
Following your config recommendation, I have configured "tunnel vrf test" under tunnel10 on both sites, but tunnel interface go down again....:(
SITEA(config)#int tun 10
SITEA(config-if)#tunnel vrf test
: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, changed state to down
!
interface Tunnel10
description TO SITEB
ip vrf forwarding test
ip address 100.100.100.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Loopback6
tunnel destination 6.1.1.2
tunnel vrf test
end
------------------------------------------------------------------
SITEB(config)#int tun 10
SITEB(config-if)#tunnel vrf test
: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, changed state to down
!
interface Tunnel10
description TO SITEA
ip vrf forwarding test
ip address 100.100.100.2 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Loopback6
tunnel destination 6.1.1.1
tunnel vrf test
end
Any ideas?
Thanks.
guruiz
03-10-2013 09:33 PM
guruiz
I would like some verification that the tunnels are really working. Would you post the output of traceroute 100.100.100.2 from siteA? and perhaps also the output of traceroute 100.100.100.1 from siteB?
HTH
Rick
03-10-2013 10:30 PM
Hi Richard,
To do the test, I have removed the "tunnel vrf test" config line first.
Here are the inputs:
SITEA#ping vrf test 100.100.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/33/44 ms
SITEA#trace vrf test 100.100.100.2
Type escape sequence to abort.
Tracing the route to 100.100.100.2
1 100.100.100.2 56 msec * 36 msec
--------------------------------------------------------
SITEB#ping vrf test 100.100.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/34/48 ms
SITEB#trace vrf test 100.100.100.1
Type escape sequence to abort.
Tracing the route to 100.100.100.1
1 100.100.100.1 60 msec * 60 msec
And here is the show run of each:
SITEA#sh run
Building configuration...
Current configuration : 1220 bytes
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SITEA
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
ip source-route
ip vrf test
!
!
!
!
!
ip cef
no ip domain lookup
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
interface Tunnel10
description TO SITEB
ip vrf forwarding test
ip address 100.100.100.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Loopback6
tunnel destination 6.1.1.2
!
interface Loopback6
ip address 6.1.1.1 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface GigabitEthernet1/0
description OSPF
dampening
ip address 10.1.1.1 255.255.255.252
no ip redirects
no ip proxy-arp
ip ospf network point-to-point
ip ospf cost 5
ip ospf hello-interval 2
ip ospf dead-interval 6
carrier-delay msec 0
negotiation auto
!
router ospf 1
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.1.1.0 0.0.0.3 area 0
!
ip classless
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end
-------------------------------------------------------
SITEB#sh run
Building configuration...
Current configuration : 1220 bytes
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SITEB
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
ip source-route
ip vrf test
!
!
!
!
!
ip cef
no ip domain lookup
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
interface Tunnel10
description TO SITEA
ip vrf forwarding test
ip address 100.100.100.2 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Loopback6
tunnel destination 6.1.1.1
!
interface Loopback6
ip address 6.1.1.2 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface GigabitEthernet1/0
description OSPF
dampening
ip address 10.1.1.2 255.255.255.252
no ip redirects
no ip proxy-arp
ip ospf network point-to-point
ip ospf cost 5
ip ospf hello-interval 2
ip ospf dead-interval 6
carrier-delay msec 0
negotiation auto
!
router ospf 1
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.1.1.0 0.0.0.3 area 0
!
ip classless
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end
Any help is very appreciated !!
guruiz
03-11-2013 02:05 AM
Hi Guruiz,
Source and Destination IPs (6.1.1.1 and 6.1.1.2) are in the global routing table.
Only Tunnel 10 in both sides are in the vrf test.
The GRE keepalive mechanism generates IP Packets with the router's own tunnel source IP as destination, encapsulates that packet and sends it across the GRE-tunnel. The destination removes the GRE header and forwards the original packet according to it's routing-table. If the source-router receives it's originated packet back, the tunnel is considered bidirectional.
An example:
Site A sends:
IP source: 6.1.1.1
IP destination: 6.1.1.2
GRE-Payload
IP source: 6.1.1.2
IP destination: 6.1.1.1
So if your tunnel interface is assigned to a VRF, you have to make sure that routing to the tunnel-destination for that VRF works:
SiteA# ping vrf test 6.1.1.2 source loopback6
Hope that helps
Rolf
03-11-2013 06:25 AM
Hello guruiz,
I think this will be the problem ->
GRE tunnel keepalive is not supported in cases where virtual route forwarding (VRF) is applied to a GRE tunnel.
http://www.cisco.com/en/US/docs/ios/12_4/interface/configuration/guide/inb_tun.html#wp1083034
Best Regards
Please rate all helpful posts and close solved questions
03-11-2013 07:32 AM
This seems a very good identification of the problem. +5 for this.
HTH
Rick
03-11-2013 07:35 AM
Agreed, great job blau grana!
Nick Bonifacio
CCIE #38473
03-11-2013 08:33 AM
Blau Grana,
Fantastic answer! That explains this behavior.
All,
Thank you much for sharing your knowledge.
Best regrads,
guruiz
03-11-2013 08:45 AM
Right, that's what the documentation says.
Unfortunately it doesn't say why.
Anyway, I tried this setup with gns3, assigned all the relevant interfaces and routes to the VRF and it worked perfectly.
Curious if it would work (reliably) in the real world too - even if unsupported.
interface Loopback6
ip vrf forwarding TEST
ip address 6.1.1.1 255.255.255.255
!
interface Tunnel10
ip vrf forwarding TEST
ip address 100.100.100.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
keepalive 10 3
tunnel source Loopback6
tunnel destination 6.1.1.2
! without the tunnel vrf command tu10 doesn't come up
tunnel vrf TEST
!
interface FastEthernet0/0
ip vrf forwarding TEST
ip address 172.16.12.1 255.255.255.252
!
ip route vrf TEST 6.1.1.2 255.255.255.255 172.16.12.2 name Tunnel-10-Destination
R1#ping vrf TEST 100.100.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/64 ms
R1#debug tunnel keepalive
Tunnel keepalive debugging is on
*Mar 1 00:57:21.815: Tunnel10: sending keepalive, 6.1.1.2->6.1.1.1 (len=24 ttl=255), counter=1
*Mar 1 00:57:21.843: Tunnel10: keepalive received, 6.1.1.2->6.1.1.1 (len=24 ttl=252),resetting counter
R1#show interfaces tunnel 10
Tunnel10 is up, line protocol is up
(...)
03-11-2013 09:42 AM
Hello Rolf,
Problem with your test is, that tunnel source and destination IPs have to be in global routing table.
I also tried this scenario in GNS ->
R1 [f0/0] <---> [f0/0] R2
R1
ip vrf test
rd 1:1
int f0/0
ip add 10.0.0.1 255.255.255.0
int tun 0
ip vrf forward test
ip add 100.0.0.1 255.255.255.0
tunnel source f0/0
tunnel dest 10.0.0.2
R2
ip vrf test
rd 2:2
int f0/0
ip add 10.0.0.2 255.255.255.0
int tun 0
ip vrf forward test
ip add 100.0.0.2 255.255.255.0
tunnel source f0/0
tunnel dest 10.0.0.1
Until now tunnel is working, but after configuring keepalives tunnels go down.
R1(config-if)#do ping vrf test 100.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
R1(config-if)#int t0
R1(config-if)#keep 3 10
R1(config-if)#do deb tun keep
Tunnel keepalive debugging is on
R1(config-if)#
*Mar 1 00:05:04.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=2
R1(config-if)#
*Mar 1 00:05:07.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=3
R1(config-if)#
*Mar 1 00:05:10.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=4
R1(config-if)#
*Mar 1 00:05:13.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=5
R1(config-if)#
*Mar 1 00:05:16.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=6
R1(config-if)#
*Mar 1 00:05:19.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=7
R1(config-if)#
*Mar 1 00:05:22.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=8
R1(config-if)#
*Mar 1 00:05:25.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=9
R1(config-if)#
*Mar 1 00:05:28.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=10
R1(config-if)#
*Mar 1 00:05:31.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=11
*Mar 1 00:05:32.859: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R1(config-if)#
*Mar 1 00:05:34.859: Tunnel0: sending keepalive, 10.0.0.2->10.0.0.1 (len=24 ttl=255), counter=12
wireshark file attached
Best Regards
Please rate all helpful posts and close solved questions
03-11-2013 10:44 AM
Hi Blau Grana,
thanks for the response.
Of course your're right - again.
In the original setup with tunnel-interface and tunnel source/dest in different routing instances it won't work.
I just wanted to show what I meaned in my former post regarding the GRE keepalive mechanism.
Because that's the reason why it can't work like this.
And the result that it seems to work with all relevant interfaces and routes in the VRF plus the use of the "tunnel vrf
Regards
Rolf
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: