"keepalive" not allowed on sub interface?

[Mark_Matthias]

When I try to put a keepalive on a frame-relay subinterface, (S2.2) I get a reply of "Unrecognized Command".

Why is this command not allowed at a sub interface?

If you are wondering why I am wanting to use it there, I have been having problems setting up an encryption session across frame-relay. When encryption is up, I can keep my telnet session and ping. Sometimes I can bring up a new telnet session. Other than that, I can't do much of anything else. FTP sessions across the link connect, then eventually time out before one can log in.

So the second part of my question might be: Is increasing the "keepalive" a possible solution for a timing out encryption session?

Thanks,

Mark

[smif101]

Can you enter your the config for you routers, I assume their is something wrong with your IPSEC config. The keepalive command only monitors if the connection is up or not, so if it doesn't recieve a keepalive it will bring the interface down.

Jason Smith

www.smif101.com

[Mark_Matthias]

I'm not using any IPSEC. I'd prefer not to post the config. Any more ideas? Could it be RIP?

Mark

[Richard Burts]

Your original question referred to an encryption session accross frame relay. If it is not IPSec, then what is it?

I suspect the command that you attempted to use was "keepalive" and this command operates at the level of the physical interface not at a subinterface level. There is a specific frame relay end to end keepalive in recent versions of IOS. Is this what you had in mind?

I doubt very much that RIP is the cause of your problem. When some applications do work and other applications do not work to that destination, one thing that I would look for would be access lists that do permit one application and do not permit the other. (be careful to look for access lists on both ends - it is not necessarily your end that has a problem.)

If you are actually doing some encryption over the link one other thing that might be a problem would be MTU problems. You might try setting a smaller ip mtu on the subinterface.

[Mark_Matthias]

I'm just using crypto maps. DES 64-cfb.

I'll review the access lists closely. I tend to think that is not what is going on.

Here's why: It seems like the more lines in my crypto access-list the more jammed up the link gets.

I used to have 4 lines in the access list I used for my crypto map. Results were much worse if you see my previous posts. A minimal amount of traffic would go through, then the crypto session would shut down on one end. The other end thought it was still up. It seems like the more lines in my crypto access-list the more jammed up the link gets.

With just the one line, it seems the encryption stays up indefinitely but I can't do more than ping.

The one line I am using is close to the following (I'm not at the router)..

access-list 129 permit tcp 10.0.0.0 0.255.255.255 10.0.0.0 00.255.255.255

Basically any tcp traffic on the 10.0.0.0 segment gets filtered.

I think the MTU setting has possibilities. How would I go about doing that? I understand that the standard Message transfer Unit is something like 1500 bites.

Thanks! Mark

[Richard Burts]

I am still puzzled what encryption you are doing with crypto maps that is not IPSec. And I am puzzled about what effect the length of the crypto access list would have.

But to answer your question about MTU, there are at least two things you can do to adjust it. The easy and straightforward is "ip mtu nnnn" (where nnnn is the value you want the interface to use) which is applied to the interface carrying the traffic (in your case probably the serial subinterface). This command has been part of IOS for a long time. The other approach is "ip tcp adjust-mss nnnn". This command is in recent IOS so you may need to be careful to ascertain whether your version has it. I used it with good success on some routers that were having problems establishing sessions and that were running IPSec. I applied it to the inbound interface where traffic entered the router (Ethernet) rather than the outbound interface.

[Mark_Matthias]

My router configs are similar to the ones on Cisco's troubleshooting page entitiled....

Configuring and Troubleshooting Cisco Network-Layer Encryption: Background - Part 1

It's at

http://www.cisco.com/warp/public/707/16.html#intro

I want to see things working at that level before moving on to part 2, which talks about IPSec and ISAKMP.

I'll have the routers in about an hour and will post after ettempting a few things. Namely:

Use the 'keepalive' in the interface because it won't go on the sub interface. I'm going to up it to 20 from the default 10 on both sides of the interface.

Crank down the packet size using " ip mtu 1400 " on the sub interfaces of both routers.

If those don't work, I'll look at the other access lists very closely.

I might also look at the command "frame-relay keepalive".

Then I'll check back here in hopes you can think of something else.

My longer Encryption Acces-list permitted TCP and UDP and denied telent to/from either direction. When in place, the encryption session would last at the most 20 min. When I reduced the access list to permit (filter) tcp traffic in one direction, the session would stay up indefinitely, but only limitted traffic send to go through.

Thanks,

Mark

[Richard Burts]

Mark

I will be interested in your results.

This response does clarify the encryption aspect: Cisco Network Layer Encryption was an early effort by Cisco to support encryption and does have some proprietary aspects. Cisco pretty quickly shifted its emphasis to standards based IPSec. While I can understand that you might want to start with Network Layer Encryption as a learning experience, I would suggest that you shift your efforts to IPSec (partly because with Network Layer Encryption and older versions of IOS the potential for bugs may be problematic).

I think experimenting with setting ip mtu may help (I have found that MTU problems are fairly common when doing encryption). I think you are welcom to try the keepalive change on the physical interface or the frame-relay keepalive, but frankly your description of the problems does not sound to me like keepalive issues.

Could you be more specific about some of the configuration, especially the access lists and crypto maps (privately if you would feel better about it).

[Mark_Matthias]

Results so far:

I set keepalive to 20 on both routers.

I generated new keys, exchanged them

Applied map to both interfaces.

4500 thinks the crypto connection is up and active.

flag: was timing out

2500 doesn't see a crypto, flag is: XCHANGE Keys

MTU is next. I'll post results when completed

[Mark_Matthias]

I put "ip mtu 1400" on both router's frame-relay sub-interfaces.

We use a Proxy program to remote out to PCs.

As soon as I pressed enter-key after adding the the crypto map to the 4500's sub interface, we lost our proxy test app. It was immediate.

[Mark_Matthias]

So we were unable establish any encryption session at this point. The 4500 thought it was up but the 2500 kept negotiating, showing negative numbers.

After each of the above or below change, we cleared the crypto interfaces on both sides. Some times we removed the Crypto map from the sub interface.

I reviewed a previous configuration that worked on these routers (albeit slow) many years ago. The immediate difference we noticed was that the previous configuration was using 40 bit Encryption and we were using 64 bit.

We made that change. Still 4500 thought it was up, 2500 didn't

We had it running a few days ago we decided to go into debug mode. That (debugging) brought both sides of the encryption up.

Entering debug mode brought up the product was the most telling item of the entire evening.

We returned the MTU to the default, the crypto went back to: 4500 okay, 2500 negotiating. We put it back to 1400 and encryption worked again.

Changing MTU size did help. Thanks!

We ran it for along time, FTPing, remote access, email. Everything we threw at it worked except Funk software's "Proxy".

We were pleased. We spent a good hour tesing. We were about to let it run for a day or two, then, it rolled into it's preferred modus-operandi : 4500 Okay and 2500 negotiating. Only "ping" and existing telnet worked. Existing telnet failed.

We brought it up a time or two after that in debug mode and captured the debug log when it failed.

Too tired to study it tonight. I'll post that tomorrow if you'd like.

Thanks for your interest and assistance.