cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
219
Views
0
Helpful
1
Replies

ispec and mss

brewerts
Level 1
Level 1

hi

I have an ipsec setup between site a, a cisco 2600 with ios 12.2x, and site b, a netscreen 10 with netscreen os 5.x

the ipsec tunnel seems to be working, as both side can ping each others private networks ok. but there seems to be a mismatch in the size of packets/frames on each side

site a pinging site b can send a ping of max 1472bytes

site b pinging site a can send a ping of max 1414 bytes, anything larger fails !

now there is no formal 'interface tunel' in the cisco config, and I can't alter the ip mss value on an interface !

should I be looking to create a formal GRE tunnel with the netscreen, and then ipsec'ing the ends of it ? that would allow me to alter the mss value

if this is not the right idea, could anyone suggest a better/more correct way of achieving this ?

thanks

_scott

1 Reply 1

s-doyle
Level 3
Level 3

It is a good idea to alter the mss value as suggested by you. It should work fine I think.

You could refer to the following doc for adjusting the mss values.

http://www.cisco.com/en/US/tech/tk472/tk473/technologies_tech_note09186a008011a218.shtml

This is a good doc on mtu tuning concepts.

http://www.cisco.com/en/US/tech/tk801/tk703/technologies_tech_note09186a0080094c4f.shtml

However, there's another option called Path MTU discovery. PMTUD is an optimization whereby a TCP connection attempts to send the longest packets that will not be fragmented along the path from source to destination. It does this by using a flag, DontFragment, in the IP packet. This flag is supposed to alter the behavior of an intermediate router that cannot send the packet across a link because it is too long. Normally the flag is off and the router should fragment the packet and send the fragments. But if the DontFragment flag is on, the router should discard the packet and return an error packet explaining the difficulty to the source of the original packet. PMTUD is a good idea in principle, but fragile in practice. With poor or badly configured TCP implementations and poorly-implemented routers or badly-configured firewalls, it can devolve to a persistent state in which each end of a TCP connection is waiting for the other end to say something.

The IntraPort line of products support Path MTU Discovery. This can be turned on by configuring the following Keyword=value pairs in the General section: PreTunnelFragmentation=true, and MTUDiscoveryTimeout=10 .