cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9495
Views
10
Helpful
12
Replies

tunnels go down when I configure keepalives

guillermo.ruiz
Level 1
Level 1

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

12 Replies 12

nickbonifacio
Level 1
Level 1

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

Nick Bonifacio CCIE #38473

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

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

HTH

Rick

guillermo.ruiz
Level 1
Level 1

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

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

Hello guruiz,

I think this will be the problem ->

Restrictions

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

Best Regards Please rate all helpful posts and close solved questions

This seems a very good identification of the problem. +5 for this.

HTH

Rick

HTH

Rick

Agreed, great job blau grana!

Nick Bonifacio
CCIE #38473

Nick Bonifacio CCIE #38473

Blau Grana,

Fantastic answer! That explains this behavior.

All,

Thank you much for sharing your knowledge.

Best regrads,

guruiz

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

(...)

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

Best Regards Please rate all helpful posts and close solved questions

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 " command I found pretty interesting.

Regards

Rolf

Getting Started

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: