Don't Fragment bit ?

Hi all !
Doing some TCP captures, I noticed that all packets originating from the Ironport's have the "Don't Fragment" Bit set...
Is this normal / wanted ? Can this be disabled ? (I suspect this is causing problems in some situations...)
Could these two topics also be affected by the DF bit :
- https://www.ironportnation.com/forums/viewtopic.php?t=1009&highlight=tcp+settings
- https://www.ironportnation.com/forums/viewtopic.php?t=898&highlight=tcp+settings
Thanks and regards,
Fred

Welcome to the world of MTU Path Discovery.
By setting the DF bit the IronPort - like most modern OSes (ie, anything beyond about 1995!) - will attempt to determine the optimum MTU (Maximum Transfer Unit - basically the maximum packet size) allowed for the complete path between the sending and receiving hosts.
Determining the MTU is a good thing, and means that packets don't need to be fragmented by an intermediary host, which in turn gives the best possible performance.
The problem with MTU Path Discovery is that some admins get over zealous about security, and do silly things. The most common "silly thing" that admins do in this respect is that they drop all ICMP traffic, on the basis that all ICMP traffic is bad.
In fact this couldn't be further from the truth. ICMP is critical to the correct operation of TCP (and other protocols), and by blocking certain ICMP packets admins often end up breaking other protocols, such as TCP.
Whilst there may be valid reasons to block certain type of ICMP messages (eg, ping packets, redirects, etc) there are some types of ICMP which should never be blocked. The most obvious of these is ICMP Type 3, code 4 which is "Fragmentation required but DF bit set", which is the one that breaks MTU Path Discovery if it's turned off. Most of the rest of Type 3 are also good to allow.

Similar Messages

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

PMTU-D Black Hole Detection Missing? Cause of some conn hangs.

In looking through the kernel source, it appears that Apple has left out one of the most important parts of Path MTU Discovery (RFC1191) as suggested in RFC2923. Since Path MTU Discovery is enabled by default, this may cause some of you to have 15 minute hangs and ultimate termination of connections when large packets are sent to specific hosts.
Other than DNS and Wireless network drops, MTU settings appear to be one of the single most problematic things going on with OS X right now.
For those who are not familiar with MTU, here's a brief rundown.
10/100 Ethernet networks support a base MTU of around 1514 bytes. This is the max number of bytes that a packet is able to be in order to get put on an Ethernet network (and be within spec). Gigabit Ethernet allows for larger, but we won't go into that.
You're probably more used to hearing 1500, however, that is the MTU for IP (or the Ethernet payload) as the Ethernet header itself is 14 bytes.
In that 1500 bytes, you have to fit your IP header, ICMP/TCP/UDP header, and any higher layer protocols and data, each layering on top of the next.
|<--Ethernet (14 Bytes)--><--IP (20 Bytes)--><--TCP (20 Bytes)--><--Data (1460 Bytes)-->|
So that is how things look on a local area network.
Once the WAN comes into play, the Ethernet header is stripped off leaving only the IP packet and another header put in its place to get it over the next link. This process goes on and on and on until the packet finally reaches its destination.
But here's the problem - what if there is ANOTHER layer between the Ethernet and IP stack?
This is actually quite common and you're probably using it now. The protocol PPP over Ethernet (PPPoE) fits between the Ethernet header and the IP header and adds another 8 bytes to this packet size.
So now we end up with:
|<--Ethernet (14 Bytes)--><--PPPoE (8 Bytes)--><--IP (20 Bytes)--><--TCP (20 Bytes)--><--Data (1452 Bytes)-->|
Notice that we now can't put as much data in this packet or we'll end up with a packet that is too big to fit on the Ethernet network.
The PPPoE header will ultimately get taken off once the packet gets where it needs to go at your ISP, but there may be other 'tunnels' between you and your ultimate destination and continue to strip off space of how much data you can put into a packet.
So how do you know how much data you can put into a packet when you don't own or know anything about the network between you and the destination?
That's where Path MTU Discovery comes into play.
It used to be that IP packets would be fragmented (split up) if a packet was too big to get put on the next network. This process of fragmentation causes overhead for both the router having to split up the packets and the receiving device that has to put them all back together again (and make sure they go in the right order).
So in order to reduce this overhead and also ensure that you are always sending the largest packets possible from end to end, IP stacks started setting the 'Don't Fragment' bit in the IP header. This instructs routers to throw away the packet if it is too big when it gets there.
When the packet gets thrown away due to it being too large, the router that throws it away also sends an ICMP packet (an IP diagnostics message) back to the sender telling it what the MTU is of the interface that couldn't take the packet. The sender can then re-calculate things based on that value and resend.
This works great EXCEPT when there are firewalls in the way (or broken routers, which is less likely these days). Many firewalls will not allow these ICMP messages to go back to the sender. Therefore, your host never receives the message that it is supposed to reduce the size of the packet and keeps trying and trying for about 15 minutes until it finally dies.
This is one reason why you may be seeing long hangs that ultimately end in termination of your connection.
RFC2923 goes into some options to work past this issue.
One way that this can be done, Windows Vista for instance does this, is for the system to keep an eye on how many max sized packets get retransmitted. After a certain number (lets say 5), the system assumes that it is not getting this ICMP notification and cuts the size of that packet in half so it can now get the data through - assuming that smaller packets are better than no packets getting sent.
It may also (and does with Vista) temporarily disable the setting of the 'Don't Fragment' bit and allow the routers to just take care of things. So in Vista, you'll see the page stutter for a second, and then continue to load, where an OS X system will sit there and hang for 15 minutes.
This is where OS X goes wrong. This behavior is called PMTU-D Black Hole Detection and does not appear to be in the IP stack for Leopard (and probably not previous releases).
So what can you do.
You have a few options, some of which I've already provided to a few folks (although without the mathematics so it's just a rough guess value).
First, you can just disable PMTU-D. The command to do this is:
sudo sysctl -w net.inet.tcp.pathmtudiscovery=0
This is a 'quick fix' but does eliminate the benefits that PMTU-D provides.
Second, you can calculate out what size MTU seems to work for you by working backwards and configure that on something within your control.
If your home router supports it, that's a good place to reduce the MTU since it only comes into play when you're using your Internet connection and not when hosts within the same network talk to each other. So if you place the MTU of 1472 on your router and your host sends it a 1500 byte packet, it will send back the ICMP message telling you to reduce it down to 1472.
If your router doesn't support it, you can reduce the MTU on your macs physical interface. This isn't always the best solution since you really should then reduce the MTU on each of your local systems or you could run into issues locally.
The command to do this is:
sudo ifconfig en1 mtu 1472
To make this permanent for Ethernet, set it in the Network settings. For Airport, search the forums. I provided an update you can make to one of the preferences files manually to do this (don't remember what file right now).
I have found a couple of sites (Washington Mutual's website for instance) that appear to have configuration issues internal to their network in which a device behind a firewall (possibly the web server, load balancer, or IPSec added) that may have an MTU less than 1500 set on it AND a firewall blocking ICMP packets from coming back. These sites will throw off your math since you can no longer assume a max size of 1500 for IP packets. In this specific case, you have to assume 1480.
Third, you can adjust the MSS setting (Max Segment Size) in the kernel to a value that is 20 bytes smaller than what you would otherwise set the MTU to. This ensures that the TCP stack doesn't put more than that amount of data in any single packet (therefore, eliminating the MTU issue), however, this will not work for UDP.
Finally, you can submit a bug report to let Apple know that PMTU-D Black Hole detection is something that we need.
So what kind of impact does this have on performance?
This will depend on what solution you choose, what the performance of your home router is, and the load on the various servers that have to potentially re-assemble the packets.
That said, knocking things all the way down to 1400 bytes, I am able to still get at least 15 Mbps up and down stream over the Internet.
If you have any questions on this post, please post and i'll do my best to respond. Hopefully this will help one more person resolve their performance issues with Leopard.

Hi Karsten and thanks for the suggestion!
I have exempted internal networks and can connect them via the VPN connection. I also got connectivity to the outside world with nat (outside,outside) and 'same-security-traffic permit intra-interface'.
A question remains though. At the moment, all traffic gets out of the network through the 'outside' interface IP (.22). I'd rather use a dedicated address from the /29 on GigabitEthernet0/0. Is this possible to achieve that? To put it differently, I'd like to NAT the VPN range onto an address that is not the 'outside' interface, like I did in this statement, for instance:
nat (v200,outside) source dynamic v200_private v200_public
My other question is, whether the single NAT statement [nat (outside,outside) dynamic interface] is sufficient for VPN traffic and whether the original statement can be removed [nat (vpn,outside) source dynamic vpn_pool vpn_public].
Thanks once again for the tips!
R.

EAP-TLS authentication failure

We've been struggling with this problem for weeks without a solution yet. Maybe someone can help us.
Note: some information below has been redacted and the IP addresses are not the original ones. They have been changed to fictional IP addresses but they have been adjusted to reflect an equivalent situation.
This situation is as follows:
WLAN infrastructure with:
1 x
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
AIR-WLC2112-K9 (IP address = 10.10.10.10)
8 x
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
AIR-LAP1142N-E-K9
Data for the WLC:
Product Version.................................. 6.0.199.4
RTOS Version..................................... 6.0.199.4
Bootloader Version.............................. 4.0.191.0
Emergency Image Version................... 6.0.199.4
The WLC is connected to a switch, Cisco Catalyst model WS-C3750X-24, sw version 12.2(53)SE2.
The idea is to have the clients/supplicants (Windows XP), who have a valid certificate, authenticate against a RADIUS server. The authentication is configured as 802.1x over EAP-TLS.
The RADIUS server is a Windows 2003 Server with IAS (IP address = 15.15.15.15). This server is accessed via a WAN link. We don't manage this server.
The problem: no wireless client (Windows XP) is able to go past the initial authentication.
I should add that the WLC and the APs were working perfectly and clients were connecting correctly to them. However this setup was moved to a new building and, since then, nothing has worked. I must add that the configuration on the WLC and APs has not changed, since the network configuration (IP subnets, etc) was migrated from the previous building to this new one. But something has changed: the WAN router (connected to the Internet and with a VPN established to the corporate network) and the LAN equipment (switches), which are all brand new.
On the RADIUS side we find these error messages:
Fully-Qualified-User-Name = XXXXXXXXXXXX/XXXX/XXXXX/XXXX/XXXXX (it shows the correct information)
NAS-IP-Address = 10.10.10.10
NAS-Identifier = XX-002_WLAN
Called-Station-Identifier = f0-25-72-70-65-xx:WLAN-XX
Calling-Station-Identifier = 00-1c-bf-7b-08-xx
Client-Friendly-Name = xxxxxxx_10.10.10.10
Client-IP-Address = 10.10.10.10
NAS-Port-Type = Wireless - IEEE 802.11
NAS-Port = 2
Proxy-Policy-Name = Use Windows authentication for all users
Authentication-Provider = Windows
Authentication-Server = <undetermined>
Policy-Name = Wireless LAN Access
Authentication-Type = EAP
EAP-Type = <undetermined>
Reason-Code = 22
Reason = The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.
On the WLC side, the error messages are:
TRAP log:
RADIUS server 15.15.15.15:1812 failed to respond to request (ID 42) for client 00:27:10:a3:1b:xx / user 'unknown'
SYSLOG:
Jan 06 10:16:35 10.10.10.10 XX-002_WLAN: *Jan 06 10:16:32.709: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx
Jan 06 10:17:05 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:02.960: %DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447 Authentication aborted for client 00:19:d2:02:76:xx
Jan 06 10:17:05 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:02.961: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx
Jan 06 10:17:36 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:34.110: %DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447 Authentication aborted for client 00:19:d2:02:76:xx
Jan 06 10:17:36 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:34.110: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx
WLC Debug:
*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Station 58:94:6b:15:f5:d0 setting dot1x reauth timeout = 1800
*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Connecting state
*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Sending EAP-Request/Identity to mobile 58:94:6b:15:f5:d0 (EAP Id 1)
*Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Received EAPOL START from mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.709: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Connecting state
*Jan 07 19:31:42.709: 58:94:6b:15:f5:d0 Sending EAP-Request/Identity to mobile 58:94:6b:15:f5:d0 (EAP Id 2)
*Jan 07 19:31:42.710: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.710: 58:94:6b:15:f5:d0 Received EAP Response packet with mismatching id (currentid=2, eapid=1) from mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Received Identity Response (count=2) from mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 EAP State update from Connecting to Authenticating for mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Authenticating state
*Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Entering Backend Auth Response state for mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.711: AuthenticationRequest: 0xd1bc104
*Jan 07 19:31:42.711:     Callback.....................................0x87e1870
*Jan 07 19:31:42.712:     protocolType.................................0x00140001
*Jan 07 19:31:42.712:     proxyState...................................58:94:6B:15:F5:D0-9B:00
*Jan 07 19:31:42.712:     Packet contains 12 AVPs (not shown)
*Jan 07 19:31:42.712: apfVapRadiusInfoGet: WLAN(1) dynamic int attributes srcAddr:0x0, gw:0x0, mask:0x0, vlan:0, dpPort:0, srcPort:0
*Jan 07 19:31:42.712: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 231) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Access-Challenge received from RADIUS server 15.15.15.15 for mobile 58:94:6b:15:f5:d0 receiveId = 155
*Jan 07 19:31:42.788: AuthorizationResponse: 0xa345700
*Jan 07 19:31:42.788:     structureSize................................145
*Jan 07 19:31:42.788:     resultCode...................................255
*Jan 07 19:31:42.788:     protocolUsed.................................0x00000001
*Jan 07 19:31:42.788:     proxyState...................................58:94:6B:15:F5:D0-9B:00
*Jan 07 19:31:42.788:     Packet contains 4 AVPs (not shown)
*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Processing Access-Challenge for mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Entering Backend Auth Req state (id=3) for mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Sending EAP Request from AAA to mobile 58:94:6b:15:f5:d0 (EAP Id 3)
*Jan 07 19:31:42.805: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.805: 58:94:6b:15:f5:d0 Received EAP Response from mobile 58:94:6b:15:f5:d0 (EAP Id 3, EAP Type 13)
*Jan 07 19:31:42.806: 58:94:6b:15:f5:d0 Entering Backend Auth Response state for mobile 58:94:6b:15:f5:d0
*Jan 07 19:31:42.806: AuthenticationRequest: 0xd1bc104
*Jan 07 19:31:42.806:     Callback.....................................0x87e1870
*Jan 07 19:31:42.806:     protocolType.................................0x00140001
*Jan 07 19:31:42.807:     proxyState...................................58:94:6B:15:F5:D0-9B:01
*Jan 07 19:31:42.807:     Packet contains 13 AVPs (not shown)
*Jan 07 19:31:42.807: apfVapRadiusInfoGet: WLAN(1) dynamic int attributes srcAddr:0x0, gw:0x0, mask:0x0, vlan:0, dpPort:0, srcPort:0
*Jan 07 19:31:42.807: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
*Jan 07 19:31:52.531: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 228) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00                               ..
*Jan 07 19:31:52.808: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
*Jan 07 19:32:02.531: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 228) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
*Jan 07 19:32:02.808: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
*Jan 07 19:32:12.532: 58:94:6b:15:f5:d0 Max retransmission of Access-Request (id 228) to 15.15.15.15 reached for mobile 58:94:6b:15:f5:d0
*Jan 07 19:32:12.532: 58:94:6b:15:f5:d0 [Error] Client requested no retries for mobile 58:94:6B:15:F5:D0
*Jan 07 19:32:12.533: 58:94:6b:15:f5:d0 Returning AAA Error 'Timeout' (-5) for mobile 58:94:6b:15:f5:d0
*Jan 07 19:32:12.533: AuthorizationResponse: 0xb99ff864
Finally, we've also done some packet sniffing, using Wireshark and Commview. These appear to suggest that something is wrong with one of the packets and this leads to the authentication process to fail and restart again and again:
******************** WIRESHARK CAPTURE ********************
No.     Time        Source                Destination           Protocol Info
      1 0.000000    10.10.10.10        15.15.15.15           RADIUS   Access-Request(1) (id=125, l=280)
Frame 1: 322 bytes on wire (2576 bits), 322 bytes captured (2576 bits)
Ethernet II, Src: Cisco_62:63:00 (f8:66:f2:62:63:00), Dst: Cisco_55:20:41 (1c:df:0f:55:20:41)
Internet Protocol, Src: 10.10.10.10 (10.10.10.10), Dst: 15.15.15.15 (15.15.15.15)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 308
    Identification: 0x501f (20511)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x4aee [correct]
    Source: 10.10.10.10 (10.10.10.10)
    Destination: 15.15.15.15 (15.15.15.15)
User Datagram Protocol, Src Port: filenet-rpc (32769), Dst Port: radius (1812)
    Source port: filenet-rpc (32769)
    Destination port: radius (1812)
    Length: 288
    Checksum: 0xe8e0 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Radius Protocol
    Code: Access-Request (1)
    Packet identifier: 0x7d (125)
    Length: 280
    Authenticator: 79b2f31c7e67d6fdaa7e15f362ecb025
    Attribute Value Pairs
        AVP: l=27 t=User-Name(1): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (username is correct!!!)
        AVP: l=19 t=Calling-Station-Id(31): 00-21-6a-29-80-xx
        AVP: l=27 t=Called-Station-Id(30): f0-25-72-70-65-c0:WLAN-XX
        AVP: l=6 t=NAS-Port(5): 2
        AVP: l=6 t=NAS-IP-Address(4): 10.10.10.10
        AVP: l=13 t=NAS-Identifier(32): XX-002_WLAN
        AVP: l=12 t=Vendor-Specific(26) v=Airespace(14179)
        AVP: l=6 t=Service-Type(6): Framed(2)
        AVP: l=6 t=Framed-MTU(12): 1300
        AVP: l=6 t=NAS-Port-Type(61): Wireless-802.11(19)
        AVP: l=89 t=EAP-Message(79) Last Segment[1]
            EAP fragment
            Extensible Authentication Protocol
                Code: Response (2)
                Id: 3
                Length: 87
                Type: EAP-TLS [RFC5216] [Aboba] (13)
                Flags(0x80): Length
                Length: 77
                Secure Socket Layer
        AVP: l=25 t=State(24): 1d68036a000001370001828b38990000000318a3088c00
        AVP: l=18 t=Message-Authenticator(80): 9fe1bfac02df3293ae2f8efc95de2d5d
No.     Time        Source                Destination           Protocol Info
      2 0.060373    15.15.15.15        10.10.10.10          IP       Fragmented IP protocol (proto=UDP 0x11, off=0, ID=2935) [Reassembled in #3]
Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Cisco_55:20:41 (1c:df:0f:55:20:41), Dst: Cisco_62:63:00 (f8:66:f2:62:63:00)
Internet Protocol, Src: 15.15.15.15 (15.15.15.15), Dst: 10.10.10.10 (10.10.10.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 44
    Identification: 0x2935 (10549)
    Flags: 0x01 (More Fragments)
    Fragment offset: 0
    Time to live: 122
    Protocol: UDP (17)
    Header checksum: 0x58e0 [correct]
    Source: 15.15.15.15 (15.15.15.15)
    Destination: 10.10.10.10 (10.10.10.10)
    Reassembled IP in frame: 3
Data (24 bytes)
0000 07 14 80 01 05 69 e8 f5 0b 7d 05 61 6c 83 00 ae   .....i...}.al...
0010 d0 75 05 c3 56 29 a7 b1                           .u..V)..
No.     Time        Source                Destination           Protocol Info
      3 0.060671    15.15.15.15        10.10.10.10          RADIUS   Access-challenge(11) (id=125, l=1377)
Frame 3: 1395 bytes on wire (11160 bits), 1395 bytes captured (11160 bits)
Ethernet II, Src: Cisco_55:20:41 (1c:df:0f:55:20:41), Dst: Cisco_62:63:00 (f8:66:f2:62:63:00)
Internet Protocol, Src: 15.15.15.15 (15.15.15.15), Dst: 10.10.10.10 (10.10.10.10)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 1381
    Identification: 0x2935 (10549)
    Flags: 0x00
    Fragment offset: 24
    Time to live: 122
    Protocol: UDP (17)
    Header checksum: 0x73a4 [correct]
    Source: 15.15.15.15 (15.15.15.15)
    Destination: 10.10.10.10 (10.10.10.10)
    [IP Fragments (1385 bytes): #2(24), #3(1361)]
User Datagram Protocol, Src Port: radius (1812), Dst Port: filenet-rpc (32769)
    Source port: radius (1812)
    Destination port: filenet-rpc (32769)
    Length: 1385
    Checksum: 0xe8f5 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Radius Protocol
    Code: Access-challenge (11)
    Packet identifier: 0x7d (125)
    Length: 1377
    Authenticator: 6c8300aed07505c35629a7b14de483be
    Attribute Value Pairs
        AVP: l=6 t=Session-Timeout(27): 30
            Session-Timeout: 30
        AVP: l=255 t=EAP-Message(79) Segment[1]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[2]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[3]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[4]
            EAP fragment
        AVP: l=255 t=EAP-Message(79) Segment[5]
            EAP fragment
        AVP: l=33 t=EAP-Message(79) Last Segment[6]
            EAP fragment
            Extensible Authentication Protocol
                Code: Request (1)
                Id: 4
                Length: 1296
                Type: EAP-TLS [RFC5216] [Aboba] (13)
                Flags(0xC0): Length More
                Length: 8184
                Secure Socket Layer
[Malformed Packet: SSL]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Message: Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]
******************** COMMVIEW CAPTURE ******************
Packet #6, Direction: Pass-through, Time:11:27:35,251292, Size: 323
Ethernet II
    Destination MAC: 1C:DF:0F:55:20:xx
    Source MAC: F8:66:F2:62:63:xx
    Ethertype: 0x0800 (2048) - IP
IP
    IP version: 0x04 (4)
    Header length: 0x05 (5) - 20 bytes
    Differentiated Services Field: 0x00 (0)
        Differentiated Services Code Point: 000000 - Default
        ECN-ECT: 0
        ECN-CE: 0
    Total length: 0x0135 (309)
    ID: 0x2B26 (11046)
    Flags
        Don't fragment bit: 1 - Don't fragment
        More fragments bit: 0 - Last fragment
    Fragment offset: 0x0000 (0)
    Time to live: 0x40 (64)
    Protocol: 0x11 (17) - UDP
    Checksum: 0x6FE6 (28646) - correct
    Source IP: 161.86.66.49
    Destination IP: 15.15.15.15
    IP Options: None
UDP
    Source port: 32769
    Destination port: 1812
    Length: 0x0121 (289)
    Checksum: 0x5824 (22564) - correct
Radius
    Code: 0x01 (1) - Access-Request
    Identifier: 0x8D (141)
    Packet Length: 0x0119 (281)
    Authenticator: 60 4E A6 58 A8 88 A2 33 4E 56 D0 E9 3B E0 62 18
    Attributes
        Attribute
            Type: 0x01 (1) - User-Name
            Length: 0x1A (26)
            Username: XXXXXXXXXXXXXXXXXXXXXXX (username is correct!!!)
        Attribute
            Type: 0x1F (31) - Calling-Station-Id
            Length: 0x11 (17)
            Calling id: 58-94-6b-15-5f-xx
        Attribute
            Type: 0x1E (30) - Called-Station-Id
            Length: 0x19 (25)
            Called id: f0-25-72-70-65-c0:WLAN-XX
        Attribute
            Type: 0x05 (5) - NAS-Port
            Length: 0x04 (4)
            Port: 0x00000002 (2)
        Attribute
            Type: 0x04 (4) - NAS-IP-Address
            Length: 0x04 (4)
            Address: 10.10.10.10
        Attribute
            Type: 0x20 (32) - NAS-Identifier
            Length: 0x0B (11)
            NAS identifier: XX-002_WLAN
        Attribute
            Type: 0x1A (26) - Vendor-Specific
            Length: 0x0A (10)
            Vendor id: 0x00003763 (14179)
            Vendor specific:
        Attribute
            Type: 0x06 (6) - Service-Type
            Length: 0x04 (4)
            Service type: 0x00000002 (2) - Framed
        Attribute
            Type: 0x0C (12) - Framed-MTU
            Length: 0x04 (4)
            Framed MTU: 0x00000514 (1300)
        Attribute
            Type: 0x3D (61) - NAS-Port-Type
            Length: 0x04 (4)
            NAS port type: 0x00000013 (19) - Wireless - IEEE 802.11
        Attribute
            Type: 0x4F (79) - EAP-Message
            Length: 0x57 (87)
            EAP-Message
        Attribute
            Type: 0x18 (24) - State
            Length: 0x17 (23)
            State: 1F 38 04 12 00 00 01 37 00 01 82 8B 38 99 00 00 00 03 18 A6 82 B7 00
        Attribute
            Type: 0x50 (80) - Message-Authenticator
            Length: 0x10 (16)
            Message-Authenticator: 4F 13 92 9C 10 29 C5 3A B9 AE 92 CA 74 11 6C B5
Packet #28, Direction: Pass-through, Time:11:27:36,523743, Size: 62
Ethernet II
    Destination MAC: F8:66:F2:62:63:xx
    Source MAC: 1C:DF:0F:55:20:xx
    Ethertype: 0x0800 (2048) - IP
IP
    IP version: 0x04 (4)
    Header length: 0x05 (5) - 20 bytes
    Differentiated Services Field: 0x00 (0)
        Differentiated Services Code Point: 000000 - Default
        ECN-ECT: 0
        ECN-CE: 0
    Total length: 0x002C (44)
    ID: 0x4896 (18582)
    Flags
        Don't fragment bit: 0 - May fragment
        More fragments bit: 1 - More fragments
    Fragment offset: 0x0000 (0)
    Time to live: 0x7A (122)
    Protocol: 0x11 (17) - UDP
    Checksum: 0x397F (14719) - correct
    Source IP: 15.15.15.15
    Destination IP: 10.10.10.10
    IP Options: None
UDP
    Source port: 1812
    Destination port: 32769
    Length: 0x0569 (1385)
    Checksum: 0x2FE4 (12260) - incorrect

Hi,
We spent many hours trying to solve this problem.
Our setup:
Cisco wireless setup, using windows NPS for 802.1x authentication.
Certificate base auth, with an internal PKI sending out client machine certs, and also the server cert.
Auth was failing with "reason code 22, The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server."
It turned out to be a GPO setting on the server, that was enforcing key protection.
There is this note on the below technet article:
Requiring the use of strong private key protection and user prompting on all new and imported keys will disable some applications, such as Encrypting File System (EFS) and wireless (802.1X) authentication that cannot display UI. For more information, see article 320828 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115037).
http://technet.microsoft.com/en-us/library/cc725621(v=WS.10).aspx
Hopefully this helps someone out, if you have the same annoying error.

Cannot download from Intranet sites

Hi,
We have VPN setup through a Cisco 877w router. Everything works fine, we can share files, browse the Intranet pages but we cannot download files (.doc, .xls) from the page. The browser says folder or files not found. Those files can be accessed via the file server.
Could someone let me know what could prevent it please?
Triet

Go to cisco.com and search for ip tcp mss-adjust. This explains how to manipulate the maximum segment size on your office lan. Your server probably starts sending your requested file with an mtu of 1500. Since it traverses a tunnel that has a smaller mtu and the don't fragment bit is set on your server the router just drops the packets returning an icmp message "df set but fragmentation needed". You problably woud be able to see that on your server using a packet capture program. Just try to lower your server's MTU size of program the "ip tcp mss-adjust" command on your router. Start with a value of 1300 and gradually go up.
Regards,
Florent Conings

Setting WAN port MTU?

I mentioned in another thread that I had been having some problems with NAT on the AEBS. I think I narrowed it down to something going on between my DSL router and the AEBS.
I believe the DSL router needs to have an MTU of 1460 or fewer bytes per packet. Probably becuase it encapsulates TCP/IP before sending over its DSL ATM link.
I was able to get similar broken behavior when I replaced the AEBS with a similarly configured Linksys WRT54GS and forced the MTU to 1500 in the WRT's web managment tool.
It looks like MTU set to "auto" or 1460 or fewer bytes per packet makes the WRT54GS behave nicely with the DSL modem. Presumably, that would make the AEBS happy too... if I could find a place to set the WAN port's MTU. Anybody know how to do it?
The DSL router is about a five year old Siemens Speedsteam connected by ATM to the telco's DSLAM. Perhaps newer DSL routers do something a little smarter with packet encapsulation, fragmentation and reassembly. Not mine, by the looks of it.
Thanks,
Bill

I just waned to add, the Speedstream is taking care of the PPPOE itself. The model I have is the 5861, which is a full-blown IP router. I am getting a /27 block of IPs routed to me by my ISP.
If not the MTU size, perhaps the AEBS is setting the DF bit (Don't Fragment) bit in the IP header, so if the Speedstream needs to fragment a big packet because it is slapping on additional encapsulation for PPPOE, it has to drop the packet from the AEBS because the packet is over 1500 bytes when encapsulated.
The issue is only a problem when certain ports (say, 473 for instance) are NATted. Port 80 seems to be no problem. Unfortunately, there is more than basic HTML in this world.
Bill

Problems with QoS between 2950 and 3550 with use of Native VLAN

Hi!
I try to set up QoS between a C2950 and a C3550, I have provided a drawing that might help understanding the setup.
As I understand it, since I only have the SMI image on the C2950 I have to run a 802.1Q trunk over the leased 2Mb line to get QoS to work. And I DO get it to work, or at least it seems so to me.
What I'm trying to setup QoS on is between a Nortel Succession Media Server and a Nortel i2004 IP Phone.
And when I sniff the port that the Succession Media Server is connected to, I get this output:
*BEGIN*
*** TO IP Phone ***
IP version: 0x04 (4)
Header length: 0x05 (5) - 20 bytes
Type of service: 0xB8 (184)
Precedence: 101 - CRITIC/ECP
Delay: 1 - Low delay
Throughput: 1 - High throughput
Reliability: 0 - Normal reliability
Total length: 0x00C8 (200)
ID: 0x5FE1 (24545)
Flags
Don't fragment bit: 0 - May fragment
More fragments bit: 0 - Last fragment
Fragment offset: 0x0000 (0)
Time to live: 0x40 (64)
Protocol: 0x11 (17) - UDP
Checksum: 0x69EC (27116) - correct
Source IP: 10.40.2.10
Destination IP: 10.10.153.100
IP Options: None
UDP
Source port: 5216
Destination port: 5200
Length: 0x00B4 (180)
Checksum: 0x5C02 (23554) - correct
*** FROM IP Phone ***
IP version: 0x04 (4)
Header length: 0x05 (5) - 20 bytes
Type of service: 0xB8 (184)
Precedence: 101 - CRITIC/ECP
Delay: 1 - Low delay
Throughput: 1 - High throughput
Reliability: 0 - Normal reliability
Total length: 0x00C8 (200)
ID: 0x8285 (33413)
Flags
Don't fragment bit: 0 - May fragment
More fragments bit: 0 - Last fragment
Fragment offset: 0x0000 (0)
Time to live: 0x7F (127)
Protocol: 0x11 (17) - UDP
Checksum: 0x0848 (2120) - correct
Source IP: 10.10.153.100
Destination IP: 10.40.2.10
IP Options: None
UDP
Source port: 5200
Destination port: 5216
Length: 0x00B4 (180)
Checksum: 0x5631 (22065) - correct
*END*
But, then to the problem:
Since the modems I use have ip adresses in them I want to monitor them and be able to change settings in them.
But to connect to units within the trunk, I have to set the native vlan to VLAN 144, which provides the ip adresses I use for the modems, in both ends of the trunk.
But if I do that the tagging of the packets from the IP Phone disappears!
Here's an output after native VLAN is applied:
*BEGIN*
*** TO IP Phone ***
IP version: 0x04 (4)
Header length: 0x05 (5) - 20 bytes
Type of service: 0xB8 (184)
Precedence: 101 - CRITIC/ECP
Delay: 1 - Low delay
Throughput: 1 - High throughput
Reliability: 0 - Normal reliability
Total length: 0x00C8 (200)
ID: 0xDEF8 (57080)
Flags
Don't fragment bit: 0 - May fragment
More fragments bit: 0 - Last fragment
Fragment offset: 0x0000 (0)
Time to live: 0x40 (64)
Protocol: 0x11 (17) - UDP
Checksum: 0xEAD4 (60116) - correct
Source IP: 10.40.2.10
Destination IP: 10.10.153.100
IP Options: None
UDP
Source port: 5240
Destination port: 5200
Length: 0x00B4 (180)
*** FROM IP Phone ***
IP version: 0x04 (4)
Header length: 0x05 (5) - 20 bytes
Type of service: 0x00 (0)
Precedence: 000 - Routine
Delay: 0 - Normal delay
Throughput: 0 - Normal throughput
Reliability: 0 - Normal reliability
Total length: 0x00C8 (200)
ID: 0x89E4 (35300)
Flags
Don't fragment bit: 0 - May fragment
More fragments bit: 0 - Last fragment
Fragment offset: 0x0000 (0)
Time to live: 0x7F (127)
Protocol: 0x11 (17) - UDP
Checksum: 0x01A1 (417) - correct
Source IP: 10.10.153.100
Destination IP: 10.40.2.10
IP Options: None
UDP
Source port: 5200
Destination port: 5240
Length: 0x00B4 (180)
Checksum: 0x31CA (12746) - correct
*END*
See, there is noe QoS tagging from the IP Phone anymore.
If I set no switchport trunk native vlan 144 in both ends the tagging is back.
Any ideas? Is this a bug, or just some command I don't know about?
Please take a look at the picture to get a more understandable view of the setup.
Thanks!

Well, native VLANs are by definition untagged so there´s nothing wrong with that as far as you are getting the expected results. By the other way I think you should include VLAN 402 on your allowed vlan range on Catalyst 3550's FastEth0/45 trunk port, otherwise this VLAN will be completly isolated from the rest of the network.

MTU setting on FastEthernet

HI
Is it possibel to set MTU on Fastethernet ?
I was trying to change MTU on 7206 and i got this error
config-if)#ip mtu ?
<68-1500> MTU (bytes)
config-if)#mtu 1510
% Interface FastEthernet0/0 does not support user settable mtu.

Thank you . The RFC was so useful
And know i want to aks you
1. MPLS MTU command , should be on the Edge-LSR interface connected to MPLS clou or on the interface connected to CE ?
2.On section 3.4 of the RFC it says that :
4. If the IP datagram has the "Don't Fragment" bit set in its IP
header:
a. the datagram MUST NOT be forwarded
b. Create an ICMP Destination Unreachable Message:
i. set its Code field [3] to "Fragmentation Required and DF
Set",
ii. set its Next-Hop MTU field [4] to the difference between
the Effective Maximum Frame Payload Size and the value
of N
c. If possible, transmit the ICMP Destination Unreachable
Message to the source of the of the discarded datagram.
How can i do this
If the source who set DF is client , it will be easy , but what if a webserver is setting DF ? and also do not support path Mtu discover ?
regards

Data package/container size

We are using MI and I have a little question about data packages sizes and container sizes.
If I use data packaging and the size very small, I read at help.sap.com that MI is sending 20 containers.
But how much data is sent by MI. What is the size of 1 container?
I ask this question because we have a little problem with the sizes of the data packages/containers.
So the major question is: What is the size of a container which is sent from MI to the Middleware (SAP WAS)?
How can I see the data I sent from MI to the middleware (SAP WAS) and how can I see if the packages are full ore not.
I hope someone can help me. Thanks in advance.
Kind regards,
Bart Elshout

Hi Thomas,
Do you know anything about a "Fragment Bit" which is set with sending data from SAP MI client to SAP WAS (middleware)?
The data is sent with a "Don't fragment bit" and one of our switches/routers or something in the network has to fragment our data, but the bit is set. So the MI client receives an error message (Unexpected end of file from server).
We want to set something in the SAP MI client which sais this datapacket may be fragmented so it can pass the network switches/routers/etc.
Can someone help us with this problem?
Thanks in advance and kind regards,
Bart Elshout

Airport Extreme upload speed never goes past 18 KB/s

That's always been the case, and it's very frustrating when I want to upload, say, an MP3 from GarageBand or attach it to an email. Is there any way to speed it up? I'm comfortable with UNIX, if the solution requires Terminal.

I looked with a packet sniffer at the actual packets from the router to the LAN Mac.
The MacBook finder connection is usually IP6 but is sometimes IP4. Packets are no larger than 1500 and in IP4 the don't-fragment bit is set.
When it is moving a file to the LAN Mac I see this pattern on the TCP connection that is repeated:
The MacBook sends a full packet of bytes three times (sometimes with one segment missing) and they are acked. The LAN Mac acks a couple more times and then things stop for a second and a half. The MacBook resends a segment and this is repeated.
Earlier I saw a problem with large packets that become fragmented, but here things seem to fail on the 3rd or 4th of four Ethernet sized packets.
Transmitter failing after a burst of data?
Bug in OS X /n driver?
Router dropping wireless packets?
I would think that if there is interference that the communication between the wireless router and the MacBook would cause an immediate resend.
If I knew this was a problem with the SMS Baracuda then I could get an Airport and be done with it, but I suspect my MacBook is broken.

Future raw socket capability in Java?

Is there raw socket capability with Java now? As I recall, Java only supports TCP and UDP sockets, right? I hope Java will include support for raw sockets, especially since Windows XP will support it as a standard.

I agree; I wouldn't mind some restrictions (to prevent IP spoofing) but developers should definitely have access to the don't fragment bit, the protocol field and the entire payload. Sometimes neither TCP nor UDP will get the job done...

Do I need 'crypto ipsec df-bit clear'?

I have a VPN tunnel between an 871 and 877, the tunnel seems to be fine, but checking the tunnel using SDM shows an error.
Checking the tunnel status... Up
Encapsulation :330231
Decapsulation :393226
Send Error :7939
Received Error :0
A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not Fragmet' packets.
1)Contact your ISP/Administrator to resolve this issue. 2)Issue the command 'crypto ipsec df-bit clear' under the VPN interface to avoid packets drop due to fragmentation.
Are the send errors anything to worry about?
Do I need to issue the 'crypto ipsec df-bit clear' on the routers?
Any info would be much appreciated.
Thanks
Gareth

Hi Rick
I've got a list of icmp types from typing 'permit icmp any any ?' in IOS... theres quite a list, 57!!
How should I decide which ones to allow and which ones to block, I don't even know what they mean :-) Do Cisco publish any recommendations?
bim7dsl(config-ext-nacl)#permit icmp any any ?
<0-255> ICMP message type
administratively-prohibited Administratively prohibited
alternate-address Alternate address
conversion-error Datagram conversion
dod-host-prohibited Host prohibited
dod-net-prohibited Net prohibited
echo Echo (ping)
echo-reply Echo reply
fragments Check non-initial fragments
general-parameter-problem Parameter problem
host-isolated Host isolated
host-precedence-unreachable Host unreachable for precedence
host-redirect Host redirect
host-tos-redirect Host redirect for TOS
host-tos-unreachable Host unreachable for TOS
host-unknown Host unknown
host-unreachable Host unreachable
information-reply Information replies
information-request Information requests
log Log matches against this entry
log-input Log matches against this entry, including input
interface
mask-reply Mask replies
mask-request Mask requests
mobile-redirect Mobile host redirect
net-redirect Network redirect
net-tos-redirect Net redirect for TOS
net-tos-unreachable Network unreachable for TOS
net-unreachable Net unreachable
network-unknown Network unknown
no-room-for-option Parameter required but no room
option Match packets with given IP Options value
option-missing Parameter required but not present
packet-too-big Fragmentation needed and DF set
parameter-problem All parameter problems
port-unreachable Port unreachable
precedence Match packets with given precedence value
precedence-unreachable Precedence cutoff
protocol-unreachable Protocol unreachable
reassembly-timeout Reassembly timeout
redirect All redirects
reflect Create reflexive access list entry
router-advertisement Router discovery advertisements
router-solicitation Router discovery solicitations
source-quench Source quenches
source-route-failed Source route failed
time-exceeded All time exceededs
time-range Specify a time-range
timestamp-reply Timestamp replies
timestamp-request Timestamp requests
tos Match packets with given TOS value
traceroute Traceroute
ttl-exceeded TTL exceeded
unreachable All unreachables
Would it be better to permit all icmp where the source is the other end of my VPN, a known fixed IP? And then deny icmp from elsewhere?
Thanks for all your help on this.
Gareth

MPLS , DF bit set

Hi everybody
According to my book, if an LSR can not fragment the labelled packet because of DF bit, following will occur:
Only if the IP header has the Don’t Fragment (DF) bit set does the LSR not fragment the IP packet, but it drops the packet and returns an ICMP error message “Fragmentation needed and do not fragment bit set” (ICMP type 3, code 4) to the originator of the IP packet. As with the ICMP message “time exceeded” (type 11, code 0), which is sent when the TTL expires of a labeled packet, the “Fragmentation needed and do not fragment bit set” ICMP message is sent, using a label stack that is the outgoing label stack for the packet that caused the ICMP message to be created. This means that the ICMP message travels further down the LSP until it reaches the egress LSR of that LSP. Then it is returned to the originator of the packet with the DF bit set.
However, when i put this claim to test, i do not see that behavior.
R5---R1 f0/1-----R2----R3---R4
Above R1 f0/1 mpls mtu 1400
On R5, i generated a ping of 1500 , DF bit set. R1 should send ICMP error towards R4 which then send it to R5.
R5#debug ip icmp
ICMP packet debugging is on
R5#ping
Protocol [ip]:
Target IP address: 4.4.4.4
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with the DF bit set
Success rate is 0 percent (0/5)
I do not see such ICMP errors message being received. Wireshark capture between R1--R2, does not show that any ICMP error message from R1 either.
I suspect the packets with DF bit are silently discarded by LSR ( R1). If this is true, then my book is pretty wrong.
thanks

Thanks Nagendra
R4#show version
Cisco IOS Software, 2600 Software (C2691-ADVIPSERVICESK9-M), Version 12.4(15)T6, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Mon 07-Jul-08 04:30 by prod_rel_team
ROM: ROMMON Emulation Microcode
ROM: 2600 Software (C2691-ADVIPSERVICESK9-M), Version 12.4(15)T6, RELEASE SOFTWARE (fc2)
R4 uptime is 46 minutes
System returned to ROM by unknown reload cause - suspect boot_data[BOOT_COUNT] 0x0, BOOT_COUNT 0, BOOTDATA 19
System image file is "tftp://255.255.255.255/unknown"

16 bit editing in PSE 8 as compared to PSE 6 (Mac)

In deciding whether to upgrade to PSE 8 from PSE 6 for Mac, I am wondering if PSE 8 allows more 16 bit file editing capability than in PSE 6, which was very limited? If so, what editing features can now be done on 16 bit files? Thanks.

Actually, I can't remember if PSE 6 allowed you to use the built-in color curves command on a 16 bit image (I don't think so), but PSE 8 does allow that.

Bit of a Newbie Question

I have been running a Mirror Door G4 for about a year now and have done a fair bit of work with it. however reading around it seems that the model I have should have dual 1.25Ghz processors, however in the hardware overview it indicates that there is only one CPU installed.
Am I missing something? i.e. does the hardware overview always report in this way, or is there a firmware patch I am missing (currently at 4.4.8f2) , or a hardware/software switch that needs to be set.
Or does it mean that one of the CPU's has died? Or simply that the device I have only cam with one processor (I can't see that there was ever an option to specify a single CPU version).
All help gratefully recived

I concur with japamac's assesment that yours is the later-introduced "education only" single-processor G4/1.25.
Its main claim to fame was that it was a fast machine that schools could buy new that would allow booting OS 9 (after all other models would no longer boot OS 9) as well as X, when the schools were ready to move up.
Its faster motherboard should allow the installation of a dual processor 1.25, if you want to buy one. But get the heatsink with the CPU, as there are several slightly different ones that do not quite interchange.
Dual CPU is somewhat over-rated, as the graphics card has a lot of impact on Web movie playing as well. \[Apple thinks so little of dual CPU that you get no extra credit for dual CPU in installing 10.5 Leopard. You MUST have at least 867 MHz (NOT dual 800) to qualify.]

Don't Fragment bit ?

Similar Messages

Maybe you are looking for