"ip tcp adjust-mss " command

Hello Everyone,
I wonder "ip tcp adjust-mss " command useage. Basicaly, should i apply this command on routers that are communicating point-to-point ? or there is not must to apply this command on both end ?
I have a IPsec configured router and i can not be sure if i should apply this command on LAN interface or WAN interface ? and Do i have to apply this command on other end ?

Hi,
You can use following configuration instead of former command:
#interface tunnel 0
-if)#mtu 1600
-if)#ip access-group DLP in
-if)#ip address <><>
#ip access-list extended DLP
-acl)#statistics per-entry
-acl)#deny ip any any packet-length gt <adjust value>
-acl)#permit ip any any
I think, it may helps you.
Houtan

Similar Messages

IP TCP Adjust MSS

Hi
We have a network setup where the customers comes via internet to 7600 and from there we for ward this to mpls-vpn cloud
CE -----Internet cloud -------Internet Access router --- 7600-----IP VPN cloud
we use ipsec tunnel from ce to 7600 .Sometimes customer complains of email/other Application not working etc.
Most of the issue are resolved when we put the ip tcp adjust mss command on lan from a higher value to lower value like from 1452 to 1350 etc.
Can somebody clarify abt the working of ip tcp adjust mss and its effect.
Thanks in Advance
Tarun

When a host initiates a TCP session with a server, it negotiates the IP segment size by using the MSS option field in the TCP SYN packet. The value of the MSS field is determined by the maximum transmission unit (MTU) configuration on the host. The default MSS value for a PC is 1500 bytes
Links for Reference:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t4/ft_admss.htm
http://cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml
http://cisco.com/en/US/products/hw/routers/ps4081/products_tech_note09186a0080094268.shtml
But the actual MSS between two end points is derived as below.
MSS = MinPathMTU - MinTCLHeadrLen - MinIP HeadrLen = 20 - 20 = MTU - 40.
Now for GRE = GRE header + GRE IP HEader = 4 + 20 = 24
IPSEC = 60 to 72 approx depedning on the encryption used.
Since your internet routers wont be supporting more than 1500 bytes as an MTU, effectively the MSS available for
you host to server session is the actual MTU on the path minus the overhead mentioned above.
which is MinPathMTU - MinTCLHeadrLen - MinIP HeadrLen - (GRE header + GRE IP HEader) - IPSEC overhead
1500 - (40+24+60~72) = 1376~1364.
So a TCP MSS value of 1360 would be safe for your end-to-end TCP sessions over a GRE-IPSEC Tunnel.
If you were not doing a GRE-IPSEC till the 7600 and had a leased circuit to the 7600 then a MSS value of 1460 fits well.
1500-40.
HTH-Cheers,
Swaroop

Ip tcp adjust-mss on LAN and BVI

hi all,
just a quick question, we got routers configured with LAN interface and bridged to a BVI interface.
i want to set the ip tcp adjust-mss 1420 but which port will take precedence?
my question, which port do i configure this command?
interface FastEthernet0/0.2
description ### Corp LAN ###
encapsulation dot1Q 2
no ip redirects
ip accounting output-packets
ip nbar protocol-discovery
ip tcp adjust-mss 1420 <<<
interface BVI2
description ### Corp VLAN ###
ip address 192.168.231.1 255.255.255.0
ip flow ingress

Since this command works at the IP layer, you will need to apply it to the routed interface. That will be BVI2 in this case.
Regards,
Mike

Ip tcp adjust-mss unidirection or bidirectional?

If i configure this command on my cisco CPE with a value of 1440, why do i still have packets who has a mss of 1460, while i clearly see the TCP three-way handshake? I'm no wireshark expert, but maybe you guys can tell me what i am doing wrong? I have made a capture between two hosts who are communicating with each other.
Here is the direct link for a more clearer picture http://s16.postimg.org/4vyeqpg91/syn_bit.png

Hi there,
Correct me if i m wrong, is the capture taken from a PC connected to Cisco?
The default MSS is 1460 which MTU 1500 - 40 Header = 1460 which is announced by the PC in syn and as you can see from the second packet which is syn ack received on the PC through the router the MSS is set to 1440, which means the MSS was modified / adjusted by the router.
Please refer below link for more information and testing MSS.
http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/12_2sba/feature/guide/sb_admss.pdf
HTH
Hitesh

L2L tunnel up, not passing traffic...all of a sudden

I've had a tunnel in place on a 5505 to a remote network i don't control...so my troubleshooting there is limited. But the tunnel has been in place for over a year without issue. Suddenly it doesn't appear to be passing traffic. But it is in at least one direction.
Remote network:192.168.191.0/24
Local ASA side: 10.220.78.0/24
I had a constant ping started from 192.168.191.10 > 10.220.78.23
Which is a Windows server pinging a Windows workstation.
When i debug icmp on the ASA i get:
ICMP echo request from outside:192.168.191.10 to inside:10.220.78.23 ID=1 seq=2866 len=32
ICMP echo reply from inside:10.220.78.23 to outside:192.168.191.10 ID=1 seq=2866 len=32
Which confirms to me that the remote network is in fact traversing the tunnel and hitting the 10.220.78.23 device, which is in fact responding, and the reply is being sent out the ASA.
The tunnel negotiates and comes up any time I reset it, by all accounts it looks correct.
The problem is not limited to ICMP as I'm unable to net use or map drives, nor can 192.168.191.10 print to the printer at 10.220.78.20.
But once i saw the icmp trace output I pretty much figured it has to be on the remote end...so....
My question, can I absolutely infer from this that the issue resides on the remote end?

Some additional info. Aside from the ping they have running from the remote network, which is shown in the above icmp trace, if i run packet tracer from the local network to the remote, tunnel's up/traffic is allowed. Not a big surprise since the tunnel does negotiate and stay up.
I captured packets from the ASA and I can see the local 10.220.78.23 device sending the reply to 192.168.191.10. Matching up with the icmp trace.
I had them run a packet capture on their firewall and confirmed, the ICMP requests from 192.168.191.10 are being encapsulated and sent on the tunnel. Again confirmed in my mind since i see the requests on the ASA. But they don't ever see the response.
There's no tcp adjust mss command on the ASA but there's this in the config:
ASA# sh run all sys
no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
sysopt connection permit-vpn
sysopt connection reclassify-vpn
no sysopt connection preserve-vpn-flows
no sysopt nodnsalias inbound
no sysopt nodnsalias outbound
no sysopt radius ignore-secret
no sysopt noproxyarp inside
no sysopt noproxyarp outside
Any other ideas?

WAN MTU change: impact on applications?

Has anyone made an in-production MTU change to their WAN? If so, how have the applications been impacted?
Our DMVPN (enterprise site-to-site) MTU is currently set to 1400 bytes, and we're looking at dropping it by a few more. I know that new connections established after the change will figure out the new MTU size using the usual MSS/PMTUD methods. I'm being asked to estimate the impact on live communications though. I know that some apps send max-MTU packets with the DF bit set. Once we change the MTU, I expect the router to drop those packets and send an ICMP error back. The X factor is how the individual apps will handle that in mid-stream: will they adapt on the fly? Reset the connection and try again? Or just sit down and cry until rebooted by a sysadmin? I recognize that some apps may be different, I'm just looking to get an overall picture.

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
My understanding is, if the source gets the ICMP fragmentation message it will reduce the size of all newly sent packets for that flow. As far as I know, once packet size is reduced, that flow will never increase the size.
I also recall older fragmentation left the sender to try various sized packets until fragmentation no longer needed. I think newer ICMP implementations will also include what the size needs to be reduced to. If this is correct, the former would cause more of a performance hit until the correct MTU was found.
From personal experience, I've noticed TCP flows that start up with a too large MTU take a noticable performance hit, at least initially, than starting with a non-fragmenting size (such as can be provided by the ip tcp adjust-mss command). NB: this observation is from several years ago, although the adjust command is still very, very useful for TCP start up where you expect a MTU size drop (and you can allow for that).
Flows should adapt. Have had the situation where primary path across dedicated WAN link, normal MTU supported, but fail over was via VPN tunnel, with reduced MTU.
PS:
What does cause problems is when source doesn't receive ICMP message. This is espeically annoying when the MTU only differs by a few bytes, like PPoE or incorrect allowance for MPLS tags. Most packets get through, some don't.
Another option is to allow intermediate system to fragment packets, but that can overload the device doing the fragmentation and actually uses extra bandwidth as packet headers are replicated during fragmentation.

DMVPN connection problems

I am having a very strange DMVPN connection problem.
I'm in the initial stages of moving from an IPSEC Site-to-Site vpn to a full DMVPN cloud. I currently have only one spoke converted from Site-to-Site to DMVPN.
Site to Hub connection looks like this
1841 -> Internet -> 2821 -> Core switch
From the spoke I can reach most resources off the core switch. However I'm unable to open internet browser connections to internal resources. Previously this site had been a Site-to-Site vpn using the same addressing and connecting through the same equipment. As a Site-to-Site vpn I can connect to all the proper internal network resources, as I can at all the other Site-to-Site vpn locations.
AS soon as I moved to DMVPN I started having connection problems to certain resources.
Once packets from the spoke reach the internal network is their any difference in their content between a DMVPN and a Site-to-Site vpn?

You can read more about it here:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00804247fc.html
I realize the settings I gave you aren't what is recommended in the document. I got those settings from TAC and they work for me. I haven't had a chance to play around with them to try different combinations as it typically breaks things.
The df-bit clear would remove the 'do not fragement' flag from the packet, enabling the router to fragment these packets into smaller sizes so they can get under the max MTU size. You shouldn't need the df-bit clear with the ip tcp adjust-mss command in place.
Transport mode may also help you here. It will reduce header overhead on the packets that are traversing your tunnel.

VPN Client - Pings of 1500 bytes fail?

I have a VPN client setup into a 1700 router. My customer is complaining that they can ping devices on the office LAN however, as they increase the ping size it starts to fail.
Any thoughts?

Andrew
For TCP based traffic I have found a very effective solution with the ip tcp adjust-mss command which is configured on the LAN interface(s) of the router. This command will cause the end stations to negotiate a mss that is small enough that fragmentation will not be needed. It may take some experimentation to find the optimum value to set to eliminate fragmentation. (The amound of overhead will vary depending on some options within IPSec and whether you are doing GRE with IPSec or IPSec without GRE. I frequently use 1375 in environments using both GRE and IPSec and find that works for us.)
For non-TCP traffic I have seen a solution which uses a route map to identify the IPSec traffic and to turn off the DF bit. This allows the packet to be fragmented as it passes through the IPSec tunnel. I have not used this solution so I can not speak to details of how it works.
HTH
Rick

Problem to disable IPV6 Router Advertisements suppress command

Hello:
I Have a Cisco 877 with IOS:
Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(24)T6, RELEASE SOFTWARE (fc2)
I am implementing Hurricane Electric Tunnel Broker, but actually to do this test I have disconnected the Wan Interface , and It only has a Windows 7 host connected to port FastEthernet 0, through vlan1:
FONTENLAS#show ip interface brief Interface                  IP-Address      OK? Method Status                ProtocolATM0                       unassigned      YES NVRAM administratively down down ATM0.1                     unassigned      YES unset administratively down down    Dialer0                    unassigned      YES NVRAM up                    up      FastEthernet0              unassigned      YES unset up                    up      FastEthernet1              unassigned      YES unset up                    down    FastEthernet2              unassigned      YES unset up                    down    FastEthernet3              unassigned      YES unset up                    down    NVI0                       unassigned      YES unset administratively down down    Tunnel0                    unassigned      YES NVRAM up                    down    Vlan1                      172.16.1.1      YES NVRAM up                    up      FONTENLAS#pingFONTENLAS#ping 172.16.1.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:.!!!!Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 msFONTENLAS#
I have configured an IPV6 address on Interface Vlan1, but I don't want that the prefix to be distributed through Autoconfiguration, so I have configured on interface Vlan1 the command: nd ra suppress as I show you
FONTENLAS#show run interface vlan 1Building configuration...Current configuration : 187 bytes!interface Vlan1 ip address 172.16.1.1 255.255.255.0 ip nat inside ip virtual-reassembly ip tcp adjust-mss 1412 ipv6 address 2001:470:1F15:EE2::/64 eui-64 ipv6 nd ra suppressendFONTENLAS#
As result, the router doesn't send its periodical Router Advertisements , but when the host is restarted, it sends a Router Solicitation message and the Router answers with Router Advertisement (that is making me crazy, because I understand it musn't send RA messages with suppres command configured)
That's what happens when I restart the connected Host:
FE80::219:AAFF:FEC2:30BC -> Router Link Local Address
FE80::7004:6BEB:4C26:79ED -> Host Link Local Address
FONTENLAS#show ipv6 interface brief ATM0                       [administratively down/down]    unassignedATM0.1                     [administratively down/down]    unassignedDialer0                    [up/up]    unassignedFastEthernet0              [up/up]    unassignedFastEthernet1              [up/down]    unassignedFastEthernet2              [up/down]    unassignedFastEthernet3              [up/down]    unassignedNVI0                       [administratively down/down]    unassignedTunnel0                    [up/down]    FE80::219:AAFF:FEC2:30BC    2001:470:1F14:EE2::2Vlan1                      [up/up]    FE80::219:AAFF:FEC2:30BC    2001:470:1F15:EE2:219:AAFF:FEC2:30BCFONTENLAS#show run interface vlan 1Building configuration...Current configuration : 187 bytes!interface Vlan1 ip address 172.16.1.1 255.255.255.0 ip nat inside ip virtual-reassembly ip tcp adjust-mss 1412 ipv6 address 2001:470:1F15:EE2::/64 eui-64 ipv6 nd ra suppressendFONTENLAS#*Mar 2 11:09:51.945: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to down*Mar 2 11:09:51.945: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down*Mar 2 11:09:51.945: ICMPv6-ND: L3 down on Vlan1*Mar 2 11:09:51.949: IPv6-Address: Address 2001:470:1F15:EE2:219:AAFF:FEC2:30BC/64 is down on Vlan1*Mar 2 11:09:51.949: ICMPv6-ND: Linklocal FE80::219:AAFF:FEC2:30BC on Vlan1, Down*Mar 2 11:09:51.949: IPv6-Address: Address FE80::219:AAFF:FEC2:30BC/10 is down on Vlan1*Mar 2 11:09:52.949: %LINK-3-UPDOWN: Interface FastEthernet0, changed state to down*Mar 2 11:09:54.497: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up*Mar 2 11:09:54.501: ICMPv6-ND: L2 came up on Vlan1*Mar 2 11:09:54.501: IPv6-Addrmgr-ND: DAD request for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:09:54.501: ICMPv6-ND: Sending NS for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:09:54.505: ICMPv6: Sent N-Solicit, Src=::, Dst=FF02::1:FFC2:30BC*Mar 2 11:09:55.489: %LINK-3-UPDOWN: Interface FastEthernet0, changed state to up*Mar 2 11:09:55.501: IPv6-Addrmgr-ND: DAD: FE80::219:AAFF:FEC2:30BC is unique.*Mar 2 11:09:55.501: ICMPv6-ND: Sending NA for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:09:55.501: ICMPv6-ND: L3 came up on Vlan1*Mar 2 11:09:55.501: IPv6-Addrmgr-ND: DAD request for 2001:470:1F15:EE2:219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:09:55.501: ICMPv6-ND: Sending NS for 2001:470:1F15:EE2:219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:09:55.501: ICMPv6-ND: Linklocal FE80::219:AAFF:FEC2:30BC on Vlan1, Up*Mar 2 11:09:55.501: ICMPv6: Sent N-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FF02::1*Mar 2 11:09:55.501: ICMPv6: Sent N-Solicit, Src=::, Dst=FF02::1:FFC2:30BC*Mar 2 11:09:55.501: IPv6-Address: Address FE80::219:AAFF:FEC2:30BC/10 is up on Vlan1*Mar 2 11:09:56.490: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to up*Mar 2 11:09:56.502: IPv6-Addrmgr-ND: DAD: 2001:470:1F15:EE2:219:AAFF:FEC2:30BC is unique.*Mar 2 11:09:56.502: ICMPv6-ND: Sending NA for 2001:470:1F15:EE2:219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:09:56.502: IPv6-Address: Address 2001:470:1F15:EE2:219:AAFF:FEC2:30BC/64 is up on Vlan1*Mar 2 11:09:56.506: ICMPv6: Sent N-Advert, Src=2001:470:1F15:EE2:219:AAFF:FEC2:30BC, Dst=FF02::1*Mar 2 11:10:22.596: ICMPv6: Received R-Solicit, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::2*Mar 2 11:10:22.596: ICMPv6-ND: Received RS on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:22.596: ICMPv6-ND: Sending solicited RA on Vlan1*Mar 2 11:10:22.596: ICMPv6-ND: Sending RA from FE80::219:AAFF:FEC2:30BC to FE80::7004:6BEB:4C26:79ED on Vlan1*Mar 2 11:10:22.600: ICMPv6-ND:     MTU = 1500*Mar 2 11:10:22.600: ICMPv6-ND:     prefix = 2001:470:1F15:EE2::/64 onlink autoconfig*Mar 2 11:10:22.600: ICMPv6-ND:             2592000/604800 (valid/preferred)*Mar 2 11:10:22.600: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:22.604: ICMPv6-ND: STALE -> DELAY: FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:22.604: ICMPv6: Sent R-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:22.604: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:23.096: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:25.452: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:25.452: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:25.456: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:25.592: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:25.764: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:25.768: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:26.096: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:27.605: ICMPv6-ND: DELAY -> PROBE: FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:27.605: ICMPv6-ND: Sending NS for FE80::7004:6BEB:4C26:79ED on Vlan1*Mar 2 11:10:27.609: ICMPv6: Sent N-Solicit, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:27.609: ICMPv6: Received N-Advert, Src=FE80::7004:6BEB:4C26:79ED, Dst=FE80::219:AAFF:FEC2:30BC*Mar 2 11:10:27.609: ICMPv6-ND: Received NA for FE80::7004:6BEB:4C26:79ED on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:27.609: ICMPv6-ND: PROBE -> REACH: FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:28.753: ICMPv6: Received N-Solicit, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::1:FFC2:30BC*Mar 2 11:10:28.753: ICMPv6-ND: Received NS for FE80::219:AAFF:FEC2:30BC on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:28.757: ICMPv6-ND: Sending NA for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:10:28.761: ICMPv6: Sent N-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:38.219: ICMPv6: Received N-Solicit, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::1:FFC2:30BC*Mar 2 11:10:38.219: ICMPv6-ND: Received NS for FE80::219:AAFF:FEC2:30BC on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:38.219: ICMPv6-ND: Sending NA for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:10:38.223: ICMPv6: Sent N-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:10:39.619: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:10:40.095: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:11:10.114: ICMPv6-ND: REACH -> STALE: FE80::7004:6BEB:4C26:79EDFONTENLAS#
So the result is that the Host obtains again the prefix through Autoconfiguration from RA router message.
I haved looked for new cli commands on the router to prevent this but I haven't found any other. The more I had got is to configure the commands (specially the first one):
ipv6 nd prefix default no-advertise
ipv6 nd managed-config-flag
so now, the router doesn't send the Prefix on RA messages, but it continues answering to RS Host Messages with its RA message. And I don't want that, because although It doesn't send the prefix with "nd prefix default no-advertise" command, it sends the MTU and the Default Gateway to the router
and I don't want that because later I want to deploy a Windows Server in the same LAN to do that function (Dhcp server, DNS server...)
That's what happens (Router sends again RA)
FONTENLAS#show run interface vlan 1Building configuration...Current configuration : 253 bytes!interface Vlan1 ip address 172.16.1.1 255.255.255.0 ip nat inside ip virtual-reassembly ip tcp adjust-mss 1412 ipv6 address 2001:470:1F15:EE2::/64 eui-64 ipv6 nd prefix default no-advertise ipv6 nd managed-config-flag ipv6 nd ra suppressendFONTENLAS#*Mar 2 11:26:15.067: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to down*Mar 2 11:26:15.067: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down*Mar 2 11:26:15.067: ICMPv6-ND: L3 down on Vlan1*Mar 2 11:26:15.071: IPv6-Address: Address 2001:470:1F15:EE2:219:AAFF:FEC2:30BC/64 is down on Vlan1*Mar 2 11:26:15.071: ICMPv6-ND: Linklocal FE80::219:AAFF:FEC2:30BC on Vlan1, Down*Mar 2 11:26:15.071: IPv6-Address: Address FE80::219:AAFF:FEC2:30BC/10 is down on Vlan1*Mar 2 11:26:16.068: %LINK-3-UPDOWN: Interface FastEthernet0, changed state to down*Mar 2 11:26:17.700: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up*Mar 2 11:26:17.704: ICMPv6-ND: L2 came up on Vlan1*Mar 2 11:26:17.704: IPv6-Addrmgr-ND: DAD request for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:26:17.704: ICMPv6-ND: Sending NS for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:26:17.708: ICMPv6: Sent N-Solicit, Src=::, Dst=FF02::1:FFC2:30BC*Mar 2 11:26:18.692: %LINK-3-UPDOWN: Interface FastEthernet0, changed state to up*Mar 2 11:26:18.704: IPv6-Addrmgr-ND: DAD: FE80::219:AAFF:FEC2:30BC is unique.*Mar 2 11:26:18.704: ICMPv6-ND: Sending NA for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:26:18.704: ICMPv6-ND: L3 came up on Vlan1*Mar 2 11:26:18.704: IPv6-Addrmgr-ND: DAD request for 2001:470:1F15:EE2:219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:26:18.704: ICMPv6-ND: Sending NS for 2001:470:1F15:EE2:219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:26:18.704: ICMPv6-ND: Linklocal FE80::219:AAFF:FEC2:30BC on Vlan1, Up*Mar 2 11:26:18.704: ICMPv6: Sent N-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FF02::1*Mar 2 11:26:18.704: ICMPv6: Sent N-Solicit, Src=::, Dst=FF02::1:FFC2:30BC*Mar 2 11:26:18.704: IPv6-Address: Address FE80::219:AAFF:FEC2:30BC/10 is up on Vlan1*Mar 2 11:26:19.692: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to up*Mar 2 11:26:19.704: IPv6-Addrmgr-ND: DAD: 2001:470:1F15:EE2:219:AAFF:FEC2:30BC is unique.*Mar 2 11:26:19.704: ICMPv6-ND: Sending NA for 2001:470:1F15:EE2:219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:26:19.704: IPv6-Address: Address 2001:470:1F15:EE2:219:AAFF:FEC2:30BC/64 is up on Vlan1*Mar 2 11:26:19.708: ICMPv6: Sent N-Advert, Src=2001:470:1F15:EE2:219:AAFF:FEC2:30BC, Dst=FF02::1*Mar 2 11:26:44.958: ICMPv6: Received R-Solicit, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::2*Mar 2 11:26:44.958: ICMPv6-ND: Received RS on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:44.958: ICMPv6-ND: Sending solicited RA on Vlan1*Mar 2 11:26:44.958: ICMPv6-ND: Sending RA from FE80::219:AAFF:FEC2:30BC to FE80::7004:6BEB:4C26:79ED on Vlan1*Mar 2 11:26:44.962: ICMPv6-ND:     Managed address configuration*Mar 2 11:26:44.962: ICMPv6-ND:     MTU = 1500*Mar 2 11:26:44.962: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:44.966: ICMPv6-ND: STALE -> DELAY: FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:44.966: ICMPv6: Sent R-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:45.458: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:47.879: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:47.879: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:47.883: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:47.955: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:48.187: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:48.191: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:48.459: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:26:49.967: ICMPv6-ND: DELAY -> PROBE: FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:49.967: ICMPv6-ND: Sending NS for FE80::7004:6BEB:4C26:79ED on Vlan1*Mar 2 11:26:49.971: ICMPv6: Sent N-Solicit, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:49.971: ICMPv6: Received N-Advert, Src=FE80::7004:6BEB:4C26:79ED, Dst=FE80::219:AAFF:FEC2:30BC*Mar 2 11:26:49.971: ICMPv6-ND: Received NA for FE80::7004:6BEB:4C26:79ED on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:49.971: ICMPv6-ND: PROBE -> REACH: FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:51.620: ICMPv6: Received N-Solicit, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::1:FFC2:30BC*Mar 2 11:26:51.620: ICMPv6-ND: Received NS for FE80::219:AAFF:FEC2:30BC on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:26:51.624: ICMPv6-ND: Sending NA for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:26:51.628: ICMPv6: Sent N-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:27:02.606: ICMPv6: Received N-Solicit, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::1:FFC2:30BC*Mar 2 11:27:02.606: ICMPv6-ND: Received NS for FE80::219:AAFF:FEC2:30BC on Vlan1 from FE80::7004:6BEB:4C26:79ED*Mar 2 11:27:02.606: ICMPv6-ND: Sending NA for FE80::219:AAFF:FEC2:30BC on Vlan1*Mar 2 11:27:02.610: ICMPv6: Sent N-Advert, Src=FE80::219:AAFF:FEC2:30BC, Dst=FE80::7004:6BEB:4C26:79ED*Mar 2 11:27:03.486: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:27:03.954: ICMPv6: Received type 143, Src=FE80::7004:6BEB:4C26:79ED, Dst=FF02::16*Mar 2 11:27:32.477: ICMPv6-ND: REACH -> STALE: FE80::7004:6BEB:4C26:79EDFONTENLAS#
So I would like to know If I making some mistake or some missconfiguration with this?
Maybe I haven't the correct knowless about how Slacc Autoconfiguration should work (Isn't right that with suppress comand configured the router shouldn't send any RA message ?), or maybe it's a problem with this IOS version. I'm gettin crazy with this.
This router has 24 Mb Flash, so If it's a problem with IOS version, I don't know which one to put on it because I think 15.X versions exceed 24Mb
Thanks for reading this large post and for helping
Kind regards
Pablo JC

Hi Harold:
Thanks so much for your answer.
Unfortunately, this Router has 128/24 Dram, but IOS 15.1(3)T3 requires 193/32.
Related to your answer I have found this link
Where it is explained:
CSCth90147
Symptoms: Router will respond to an RS with an RA.
Conditions: The symptom is observed when you configure the ipv6 nd ra suppress command. This command is only intended to suppress periodic mcast RAs. The router will still respond to unicast RS (that is intended behavior).
Workaround: Use an ACL to block the reception of RS packets.
I have read in another web that other possible solution is to use configuren the nd ra lifetime messages as 0.
I have combined several commands in this way:
interface Vlan1
ip address 172.16.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1412
ipv6 address 2001:470:1F15:EE2::/64 eui-64
ipv6 nd prefix default no-advertise
ipv6 nd managed-config-flag
ipv6 nd ra suppress
ipv6 nd ra lifetime 0
end
With:
ipv6 nd ra suppress -> The router won't send periodical RA messages
ipv6 nd prefix default no-advertise -> The router won't publish the prefix in message RA that it send answering host RS
ipv6 nd ra lifetime 0 -> Does this prevent that the rest of the configuration send by RA could stay in hosts
ipv6 nd managed-config-flag
What do you thing about this configuration? I know it's a bit dirtier than using an ACL to block the reception of RS packet, but could it done the same function?
Kind regards
Thanks for reading

Ip nhrp command not available?

Hi everyone,
I'm setting up an 871 and I've configured my tunnel0 interface, however I cannot type in any commands for ip nhrp.
I currently have:
interface Tunnel0
bandwidth 1000
ip address 10.10.10.20 255.255.255.0
ip access-group 101 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1400
ip virtual-reassembly
ip route-cache flow
ip tcp adjust-mss 1360
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet4
tunnel mode gre multipoint
tunnel key 10000
tunnel protection ipsec profile SDM_Profile1
end
When I type in ip nhrp ? I get an unrecognized command error.
Is there anything I have to enable prior to having this command available?
Thanks,
Ali

That was pretty much it... after digging around that day, I noticed the IOS on that baby was advsecurity. Upgraded to Advanced IP services and worked like a charm.
I'm not at all familiar with DMVPNs so that one was a trick to find out.
Thanks Andrew.

Optimize mtu and mss

Dear all,
It is about a IPSEC/GRE over WAN...
Would you please confirm or comment the following in terms of MTU:
1. On GRE tunnel interfaces "ip mtu" and "ip tcp adjust-mss" is mandatory. "tunnel path-mtu-discovery" is good to have and will allow DF bit to be set in the outer header. If "tunnel path-mtu-discovery" is to be applied, ICMP should not be blocked between routers.
2. On inside router interfaces "ip tcp adjust-mss" is mandatory and will be the same value as on the tunnel interfaces. This will make sure TCP traffic from inside hosts is OK.
3. It is mandatory that ICMP messages are not blocked between inside hosts and WAN routers in order for PMTUD for hosts to be working.
Thanks in advance,
Mladen

No you have not mis-read the document - maybe just been lead down a path a little, my answers are based on experiance.
I have found that tunnel path-mtu-discovery/PMTUD/BlackHole MTUD do not work in 99.999% of the cases where I have had mtu issues - Windows OS has been where the issues lie. I have never encounted a time where the Windows OS has actually taken any notice of the ICMP fragmentation needed message has been recevied.
Some Cisco platforms cannot use the tcp mss adjust command on transient packets, only packets sourced from the deivce are effected.
Cisco firewalls, have default configuration in regards to fragementation - the packets will be fragemented prior to encrypting the packet and they copy the DF bit = the packet will be dropped due to being oversized.
What I do when dealing with GRE/IPSEC tunnels is either:-
1) Change the MTU of the workstations/servers - works in small enviroments, does not scale.
2) You do not have to worry about MTU/MSS sizes on internet sites generally, as the remote servers wil 99% negotiate a small MSS.
3) Use where possible tcp mss adjust on routers and firewalls (this is a great place, especially when you are not using GRE tunnels)
4) Perform packet captures to determine if an application will send ALL packets with the DF bit set, or as normal just the TCP handshake.
Below is a good example:-
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008081e621.shtml
HTH>

Getting huge number tcp-retransmissions 7& TCP Dup ACK packets.

Hi,
I was working with a issue, in which we were observing that the citrix application page is freezing intermittently for 5-10secs and again working without any discosnnections.
On troubleshooting I did nt observe any abnormal latency or packet loss on the GRE tunnel from source vlan till server destiantions.
The citrix traffic flows via a GRE tunnel to remote location then via plain internet flows to a internet facing citrix server behind a firewall.
On analyzing the traffic using Ethereal I have observed huge number of duplicate ACK packets and TCP retransmissions, hence i derived it has some thing to do with packet fragmentations.Hence I modified that TCP MSS size to 1400 from 1412.
Hence I modified the GRE tunnel configs as below
Router#sh run int tu 691
interface Tunnel691
description XXXX
ip address X.X.X.41 255.255.255.252
ip mtu 1500
ip tcp adjust-mss 1400
tunnel source Loopback69
tunnel destination X.X.X.X
end
Still there is intermittent issue.Can you pls help me to find out where excatly the issue can lie.

We had a similar issue and issued the following commands and everything is working well.
ip mtu 1476
ip tcp adjust-mss 1436

MTU MSS DF Bit and Fragmentation

I am running an encrypted link and want to check for and if necessary, remedy fragmentation.
I'm using two connected 6500's with VPN modules.
Using the NAM I sniffed the outbound physical interface and I see packets of various sizes but the biggest is 128bytes even during a massive file transfer. I'm assuming fragmentation but need to be sure.
Using ping I see the biggest packet allowed without fragmentation is 1472.
My primary intent is to first determine if there is a fragmentation issue. If there is I'll probably follow up with questions on which command to use and where to put it. I assume that I would use either the physical outgoing interface(currently MTU=1500) or the inside crypto interface(current MTU=4500)
1. How do I determine if there is a fragmentation issue
2. Which command to use and where?
Any help would be appreciated.

Issue with large packets that have the don't fragment bit set that become too large with the additional overhead of ipsec.
use command "ip tcp adjust-mss ",TCP MSS (Maximum segment size) sufficiently low enough that the packet isn't fragmented.
you may need to clear the df-bit entirely (it's a less efficient method, but it works). For the router, you can do so via "crypto ipsec df-bit clear".
Try these links for more info:
http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00804247fc.html
http://www.cisco.com/warp/public/105/pmtud_ipfrag.html
http://www.cisco.com/warp/public/105/38.shtml

Advice required on optimal MTU and MSS settings for GRE and IPSEC connections

Hi,
We have 2 remote sites (Site A and Site B) which connect to our datacentres (DC) over IPSEC VPN and connect to each other over GRE tunnels.
We had some issues recently which we believe were MTU/MSS related (browsing web servers at one location not appearing correctly etc)
We got some advice from our Cisco partner and tweaked some settings but I'm still not convinced we have the optimal configuration - and we still have some problems I suspect may be MTU related. For example, from our DC (connected to Site A by IPSEC), we CANNOT browse to the webpage of the phone system hosted at Site A. Yet, we CAN browse to the webpage of the Site A phone system from Site B (connected over GRE)
Site A and Site B have two WAN internet circuits each - and each provider presents their circuit to us as ethernet.
Here are the relevant interface settings showing the currently configured MTU and MSS (both routers are configured the same way)
Can someone advise on what the optimal settings should be for our MTU and MSS values on the various interfaces or how we might best determine the values?
interface Tunnel1
description *** GRE Tunnel 1 to SiteB***
ip address [removed]
ip mtu 1400
ip tcp adjust-mss 1360
keepalive 30 3
tunnel source [removed]
tunnel destination [removed]
interface Tunnel2
description *** GRE Tunnel2 to SiteB***
ip address [removed]
ip mtu 1400
ip tcp adjust-mss 1360
keepalive 30 3
tunnel source [removed]
tunnel destination [removed]
interface GigabitEthernet0/0
description "WAN Connection to Provider1"
ip address [removed]
ip access-group firewall in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect cbac out
ip virtual-reassembly in
crypto map cryptomap
interface GigabitEthernet0/1
description "Connection to LAN"
no ip address
ip flow ingress
ip flow egress
duplex auto
speed auto
interface GigabitEthernet0/1.1
description DATA VLAN
encapsulation dot1Q 20
ip address [removed]
ip access-group 100 in
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1320
interface GigabitEthernet0/1.2
description VOICE VLAN
encapsulation dot1Q 25
ip address [removed]
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1320
interface GigabitEthernet0/2
description "Connection to Provider2"
ip address [removed]
ip access-group firewall in
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip inspect cbac out
ip virtual-reassembly in
duplex auto
speed auto
crypto map grecrypto
Thanks.

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
http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

MTU vs MSS

I have been reading up on DMVPN and noticed the tunnel configuration had the following:
iinterface Tunnel0
ip mtu 1408
ip tcp adjust-mss 574
Would someone be able to explain to me why the mss is so much lower than the MTU.
I thought the MSS was 28 less than the MTU.

From same doc, I think this is valid
"The goal is to select an optimum value for ip tcp adjust-mss that minimizes both the IPSec padding and
ATM adaption layer (AAL) 5 padding."
Is that your objective in live network?
For the rest it's pretty self explanatory.
IP MTU of transport network > IP MTU overlay network > TCP MSS set on overlay

"ip tcp adjust-mss " command

Similar Messages

Maybe you are looking for