cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3121
Views
5
Helpful
9
Replies

Cisco Catalyst 3750 - GRE tunnel keepalive retry count cannot be set

vderobertis
Level 1
Level 1

Hi everybody,

in my production environment I have several Catalyst 3750-48PS stacks running IOS c3750-ipservicesk9-mz.122-55.SE9.bin (latest version as of today).

IP Routing is enabled on these switches and several point-to-point GRE tunnels are configured. The problem I have on all these switches is that I cannot set the GRE tunnel keepalive retry count to a value other than 3, which is the default.

 

Example:

GRE Tunnel configuration:

interface Tunnel0
 ip address 172.17.18.1 255.255.255.254
 [other commands]

 keepalive 5
 tunnel source Loopback0
 tunnel destination 172.17.1.0
end

with this configuration I expect tunnel keepalive period to be 5 seconds and retry count to be 3 times (default value). A "sh int t0" returns:

Tunnel0 is up, line protocol is up

.......

Keepalive set (5 sec), retries 3

........

 

If I change the tunnel configuration and set "keepalive 5 6" in tunnel interface configuration mode I expect the running configuration to reflect the change and the sh int t0 to show 6 as number of retries, instead I get:

sh run int t0

interface Tunnel0
 ip address 172.17.18.1 255.255.255.254
 [other commands]

 keepalive 5
 tunnel source Loopback0
 tunnel destination 172.17.1.0
end

and

sh int t0

Tunnel0 is up, line protocol is up

.......

Keepalive set (5 sec), retries 3

........

 

Nothing has changed compared to the previous configuration.

It seems that the keepalive period can be correctly set to a value other than 10 seconds, which is the default, while the retry count cannot.

 

This seems to be a bug in IOS, has anyone else experienced the same issue?

 

Thank you very much in advance.

2 Accepted Solutions

Accepted Solutions

"Supported" is not the same thing as "usually works".  It's clearly documented that the command to create the GRE tunnel is not supported by TAC and I would therfore never want to rely on this in production.

Last time I tried this in a lab, all packets that were sent via the GRE tunnel were process switched with a corresponding hit to CPU utilisation as the traffic was punted out of hardware.  Are you able to confirm if this is the case or if the packets are indeed being forwarded by hardware?

View solution in original post

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I can add, during my brief test, just pinging across the GRE tunnel appeared to cause a 10% CPU increase.  I.e. it would appear to me GRE was being done in software.

View solution in original post

9 Replies 9

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I recall tunnels (endpoints) are not supported on 3750s.

Hi,

thanks for your answer.

I can confirm that GRE tunnels are 100% supported on 3750s with IP Services IOS installed. I have many of them (with both endpoints being 3750 switches and also with an endpoint being a 3750 and the other being a Cisco router) configured on several 3750 stacks in production environment and they work flawlessly with routing protocols running on top of them.

The only issue I have is with the keepalive retry count that cannot be set to values different than the default.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

An interesting observation.  I tried it myself, and it does appear to work (at least pinging across the tunnel), but what do you make of this:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_55_se/configuration/guide/scg3750/swuncli.html#wp1021363

Hi,

that is definitely weird. Not only the interface tunnel global configuration command is supported but also other commands that are listed as not supported in the guide you posted actually are supported. For example the ip prefix-list global configuration command, the set tag route-map configuration command and the ip mtu interface configuration command which I use with no problem in my production environment.

May I ask you if you tried to use the keepalive [period] [retry count] command in tunnel interface configuration mode and verified if the problem I have with setting the retry count can be replicated in your environment too?

Thank you very much for your help.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Dang, I should have tried it while I had the tunnel configured (although my 3750s are running 55SE7).

I'm in class all this week, so I won't have time to try it again soon but if you send me a personal note the following week, I'll see if I can try it then.

PS:

Oh, I did try the keepalive command itself, set as keepalive 1, which also took the tunnel down when the far side couldn't be reached (i.e. it appeared to work fine too), but I didn't try changing the retry count.

Thank you Joseph.

Yes, the keepalive command does what it should do when configured, I can confirm that too. The only issue is with the retry count which is always 3.

I had the same issue also with IOS 55SE6, so I think it should be present on 55SE7 as well.

I will send you a note the next week as you asked, thanks again for your help.

Bye.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I can add, during my brief test, just pinging across the GRE tunnel appeared to cause a 10% CPU increase.  I.e. it would appear to me GRE was being done in software.

"Supported" is not the same thing as "usually works".  It's clearly documented that the command to create the GRE tunnel is not supported by TAC and I would therfore never want to rely on this in production.

Last time I tried this in a lab, all packets that were sent via the GRE tunnel were process switched with a corresponding hit to CPU utilisation as the traffic was punted out of hardware.  Are you able to confirm if this is the case or if the packets are indeed being forwarded by hardware?

Thanks Reuben.

You are right, and Joseph is too. I haven't noticed that the Unsupported Commands section in the Software Configuration Guide for IOS 12.2(55)SE states that:

"This appendix lists some of the command-line interface (CLI) commands that appear when you enter the question mark (?) at the Catalyst 3750 switch prompt but are not supported in this release, either because they are not tested or because of switch hardware limitations."

It seems that GRE tunnels work if configured but are not officially supported due to hardware limitations of the 3750. I can confirm that the packets are process switched but this is not a problem for me since the 3750s where GRE tunnels are configured are used in very small production environments with low traffic and not in central sites (and so CPU utilization is not a problem here). I will evaluate if keeping the tunnels on these switches and disable the keepalive feature or move them elsewhere.

I will mark this question as answered both by you and Joseph.

Thanks again for your kind assistance. Bye.

Review Cisco Networking products for a $25 gift card