Significance of loopback MTU

So the default MTU for the loopback interface is 16 KB. And apparently this is in fact changeable, or at least ifconfig acts as though it is.
Is there any situation where changing the MTU of the loopback interface might be useful? e.g. could tuning it up or down affect the performance of a local proxy? I'm just kind of curious about why this setting exists.

You piqued my interest, but this is all I could find on a quick Google... Seems to be since the loopback interface doesn't connect to an ethernet network, there are no packets or fragmentation limits, in which case I guess it depends on the available buffers or whatever the kernel uses internally to transfer the "packets" as to what the optimum size would be.
(Warning: I don't know enough about the kernel to stand by anything I've said in the above paragraph )
http://forums.fedoraforum.org/showthread.php?t=252717 wrote:
From linux-2.6-stable/drivers/net/loopback.c
* The loopback device is special. There is only one instance
* per network namespace.
static void loopback_setup(struct net_device *dev)
dev->mtu = (16 * 1024) + 20 + 20 + 12;
dev->hard_header_len = ETH_HLEN; /* 14 */
dev->addr_len = ETH_ALEN; /* 6 */
dev->tx_queue_len = 0;
dev->type = ARPHRD_LOOPBACK; /* 0x0001*/
dev->flags = IFF_LOOPBACK;
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
dev->features = NETIF_F_SG | NETIF_F_FRAGLIST
| NETIF_F_TSO
| NETIF_F_NO_CSUM
| NETIF_F_HIGHDMA
| NETIF_F_LLTX
| NETIF_F_NETNS_LOCAL;
dev->ethtool_ops = &loopback_ethtool_ops;
dev->header_ops = &eth_header_ops;
dev->netdev_ops = &loopback_ops;
dev->destructor = loopback_dev_free;
16436 = = (16 * 1024) + 20 + 20 + 12
Remember that the lo device is not an 802 media - so there is no MAC address and encapsulation. The flags above indicate there is no checksum. I suppose the extra 52 bytes are sufficient to create the IP header with a 16KiB paymoad.
Also:
http://www.chesterproductions.net.nz/blogs/it/sysadmin/size-matters-the-quest-for-the-ideal-mtu/36/ wrote:In the example above the loopback device has had its MTU set to 16436 from 16430. If we echo 1 to ‘/proc/sys/net/ipv4/ip_no_pmtu_disc’ then MTU dynamic shaping will be turned off and the machine will not send data packets less than the maximum if it has data to fill it. This is some times useful when trying to simulate devices on a network that do not have dynamic MTU built in or disabled.

Similar Messages

  • Loopback problems, cups

    I believe I have a problem getting to the cups configuration page at http://localhost:631 because my loopback interface isn't up.  After following all the steps in the CUPS Howto on the Wiki, I point Firefox to that address, but nothing comes up and firefox eventually times out.
    I am on dialup, using wvdial.
    Here's what "ifconfig" reveals:
    ppp0 Link encap:Point-to-Point Protocol
    inet addr:204.39.208.213 P-t-P:204.39.208.6 Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
    RX packets:1732 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1736 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:3
    RX bytes:1497715 (1.4 Mb) TX bytes:188942 (184.5 Kb)
    Here's what "ifconfig lo" reveals:
    lo Link encap:Local Loopback
    LOOPBACK MTU:16436 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
    My rc.conf:
    MODULES=(!8139too ppp_generic hcfpcihw snd-es1938 snd-pcm-oss usblp)
    lo="lo 127.0.0.1"
    eth0="dhcp"
    INTERFACES=(lo !eth0)
    Thanks

    try to connect to
    http://127.0.0.1:631
    if it works maybe is a proble with your hostname file or the name resolution order.

  • BT Broadband and MTU

    Hi folks,
    To those forum users who are comfortable with tweeking their line connection, and have the knowledge to do so....I thought it worth a mention about MTU.
    I know a lot of members tune MTU already, so if so, ignore this post, it's intended for those who don't know.
    MTU is nothing new, it's always been around, and it's the Maximum Transmission Unit.
    The MTU runs hand in hand with another system variable called RWIN, the Windows receive page file segment setup configuration.
    MTU can be fine tuned, but RWIN cannot be fine tuned in Vista, it sets it dynamically, but it can be set in XP.
    In broad terms MTU determines the "best" packet size for data transfer across a WAN, wide area network, and thus between you, your ISP and the net in general, depending on your latency.
    Windows and router manufacturers often by default made any MTU setting the value of 1500.
    Any Netgear routers that were set to run on Sky broadband and other ISPs, were given the same setup configuration, however when I came back to BT from Tiscali (TalkTalk), for which my connection was tuned, I noticed a higher degree of latency on the BT network than I'd previously had on Tiscali, for a similar throughput.
    It was only when I started to look at tuning my connection again, that I found that the BT network ran significantly smoother using an MTU of 1458, rather than 1500.
    I also set my XP machine to run with same, and a RWIN of 65535, the maximum size "potentially."
    After making these changes my throughput increased from 94% to 100% testing on DSLreports.com, with very few packet acknowledgements and clearly a more spritely performance.
    The 1458 MTU value has long been a BT recommendation for data transfer in the past, but whether it is a present recommendation in BTw's config.papers I don't know, frankly I couldn't be bothered to try and find if there were any "new" present day recommendations for IP datastream products.
    It follows that the difference in throughput between 94% and 100%, is a good improvement, and would benefit those with "slower connections" and long lines....incidently my router has seen less CRC errors since doing it also, but I have no reason to suspect there's a correlation unless FEC is not as efficient as it should be.
    It doesn't necessarily follow IT WILL BE THE SAME RESULT FOR YOU,  but if you feel confident in trying it, for those that can, it was worth it for me.
    Feel free to share comments, I know a lot of folk on here have the skills and do line tweeks, but there is a majority that don't, that might like to try.....BUT
     I TAKE NO RESPONSIBILITY FOR ANY CHANGES YOU MAKE TO YOUR SYSTEM, AND YOU GET IT WRONG, AND THEY CAUSE YOU GRIEF, AND NEITHER WILL BT, but for those that have the skills, feel free to try. 
    You can set MTU in your WAN setup, depending on router.
    and you need a programme called DR.TCP to set the RWIN in XP, it's freely available, Google is your friend.
    For those with home hubs there is an external link here:
    USE IT AT YOUR OWN RISK, IF YOU ARE NOT SKILLED LEAVE IT ALONE.
    http://www.stevelarkins.freeuk.com/bthomehub_softw​areupgrade.htm
    I CAN NOT VOUCH FOR THE FILES ON THIS SITE, AND NEITHER DO I KNOW WHETHER THE LATEST HUB IS SUPPORTED BY THEM, I DON'T USE ONE, YOU NEED TO CHECK YOUR OWN HUB AND READ THE INFORMATION SUPPLIED ON THE SITE, AND AGAIN, IT NEEDS SKILL, IF YOU DON'T HAVE THE SKILLSET DON'T GO THERE.
    Solved!
    Go to Solution.

    You change it from within Windows.
    if you want to find out what MTU value is ok(no packet fragmentation), or be like some and set it to as close as to near max. as possible, open a command window and type, obviously the MTU value set will affect the result so if you've already changed it from 1500 to 1458, and try an MTU value of 1458 it will show fragmented packets 'packet needs to be fragmented'. You may want to do this first just to try out the value, some get it as near as possible but 1458 is pretty fine for most people here.
    ping www.bt.com -f -l {MTU value}
    For Windows 7, you can look ar what your existing MTU is opening a command window(might save time for next command and open an elavated command window) and typing:-
    netsh interface ipv4 show subinterfaces
    The standard MTU for Windows 7(and as I remember Vista) is 1500, you will get a list consisting of, Loopback Pseudo-Interface then, Local Area Connection if you are using an ethernet cable or Wireless Network if you are using wireless. If like me you have a few ports/devices you can easily tell which interface is being used by the amount of data it will show under the Bytes In/Bytes Out.
    If you wish, type:-
    ipconfig /all 
    for a more descriptive list(well in depth).
    Then you can set your MTU by opening an elevated command window or if you've already opened one type. The command we will be using is netsh, like so(I take it's obvious what parameters represent the necessary information in this exercise).
    netsh interface ipv4 set subinterface "Local Area Connection" mtu=1458 store=persistant
    or ir could be
    netsh interface ipv4 set subinterface "Wireless Network Connection" mtu store=persistant
    If you want to find out what this all means then it's very googable and pretty easy to understand, some go to the trouble of complex registery alterations, I do not know why but maybe there is some reason I am unaware of, this method seems to work perfectly and easily. It's a dead easy fix and results are good.

  • QinQ MTU

    Hello,
    we are using the following configuration to a QinQ link in the subinterface to our users:
    interface GigabitEthernet0/0/0/3.900 l2transport
    description To CUSTOMER - PSEUDOWIRE A
    encapsulation default
    l2protocol cpsv tunnel
    interface TenGigE0/1/0/3.900 l2transport
    description To BACKBONE - PSEUDOWIRE A
    encapsulation dot1q 900 second-dot1q any
    rewrite ingress tag pop 1 symmetric
    Everything is working fine and frames with a payload with 1500 bytes is beeing transported. The issue is that
    a ethernet frame with a payload of 1500 has a total size of 1518 bytes. I know that IOS XR MTU
    concept discard 4 bytes for the ethernet trailer (FCS or CRC). So for Cisco and MTU the original frame size is 1514.
    However the frame received in the GigabitEthernet0/0/0/3.900 has a VLAN TAG because we
    have a trunk to our customer with multiples VLANS. So the MTU size should be 1518. But if we get the
    out of the show interface command:
    sh interface GigabitEthernet0/0/0/3.900
    Wed Sep 12 12:56:32.130 CEST
    GigabitEthernet0/0/0/3.900 is up, line protocol is up
      Interface state transitions: 1
      Hardware is VLAN sub-interface(s), address is 6c9c.ed09.295f
      Description:To CUSTOMER - PSEUDOWIRE A
      Layer 2 Transport Mode
      MTU 1514 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)
         reliability Unknown, txload Unknown, rxload Unknown
      Encapsulation Default,
        Default match
        Ethertype Any, MAC Match src any, dest any
      loopback not set,
      ARP type ARPA, ARP timeout 04:00:00
      Last input never, output never
      Last clearing of "show interface" counters never
         1924812905 packets input, 1293208601922 bytes
         3 input drops, 0 queue drops, 0 input errors
         778056641 packets output, 447390756224 bytes
         0 output drops, 0 queue drops, 0 output errors
    sh interface TenGigE0/1/0/3.900          
    Wed Sep 12 13:02:26.173 CEST
    TenGigE0/1/0/3.900 is up, line protocol is up
      Interface state transitions: 7
      Hardware is VLAN sub-interface(s), address is 4055.3968.7d2b
      Description: BACKBONE - PSEUDOWIRE UPCT-FTALMO
      Layer 2 Transport Mode
      MTU 1518 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
         reliability Unknown, txload Unknown, rxload Unknown
      Encapsulation 802.1Q Virtual LAN,
        Outer Match: Dot1Q VLAN 900
        Inner Match: Dot1Q VLAN any
        Ethertype Any, MAC Match src any, dest any
      loopback not set,
      ARP type ARPA, ARP timeout 04:00:00
      Last input never, output never
      Last clearing of "show interface" counters never
         778152164 packets input, 450515418508 bytes
         31813 input drops, 0 queue drops, 0 input errors
         1902517045 packets output, 1287687321444 bytes
         308359 output drops, 0 queue drops, 0 output errors
    We have a 1514 bytes MTU instead of 1518 bytes in GigabitEthernet0/0/0/3.900 and 1518 bytes instead
    1522 (there is two 4 bytes tags). Why frames are working fine?. In the following document explains that
    by default the MTU are:
    1514 bytes for normal frames
    1518 bytes for 802.1Q tagged frames
    1522 bytes for QinQ frames
    http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r3.9/lxvpn/configuration/guide/lesc39ethi.html#wp1200718
    How can we explain the 4 bytes difference?.
    Thanks.

    Hello Antonio,
    Here are numbers which are used for L2 MTU calculation:
    "encapsulation untagged” and "encapsulation default”  counts 0 tags. >> 1514
    “encapsulation dot1q 900 second-dot1q any”. The any keyword used as the innermost tag match does not increase the number of tags in the calculation. This is to ensure consistency with the old style XR VLAN Id semantics. >> 1518
    “encapsulation dot1q 900 second-dot1q 900”. No any keyword >> 1522
    but for L2VPN we’d use payload MTU to properly transfer our data.  The rationale behind the payload MTU calculation is to get the correct maximum payload size of frames that may be carried over an xconnected PW relative to the L2 MTU of the interface.
    Let’s take your example:
    interface TenGigE0/1/0/3.900 l2transport
    description To BACKBONE - PSEUDOWIRE A
    encapsulation dot1q 900 second-dot1q any
    rewrite ingress tag pop 1 symmetric
    sub-l2-mtu = parent-l2-mtu + (4 * encaps-tag-count)
    sub-l2-mtu = 1514 + ( 4 * 1 ) = 1518
    sub-l2-payload-mtu = sub-l2-mtu – (14 + (4 * (encaps-pop-tags-count – encaps-push-tags-count)))
    sub-l2-payload-mtu = 1518 - (14 + (4 * (1 - 0)))= 1500
    So we’d be still forwarding 1500b payload.
    You should be able to find your xconnect/BD MTU using “show l2vpn xconnect detail” or “show l2vpn bridge-domain detail”.
    Regards,
    /A

  • Confused about mpls mtu command

    hi,
    i confuse about mpls mtu command
    test platforms are 76 pfc3b,mpls,gigabit sip400 spa interface
    if i didn't config mpls mtu command ,using default,ping command is successful,if more than 1496 packets, i can see fragment from show ip traffic.
    if i config mpls mtu override 1504,ping command is sucessful too. there is fragment too when i use 1501 byte packet.
    if i config mpls mtu override 1524 byte.
    ping command failed if i use packet more than 1500, , all packet are droped,even 1501 byte.only 1500 byte packet can success.
    all config above interface mtu is 1500.
    this confused me.
    why i use default 1500 interace mtu, mpls mtu override 1504 ,ping packet can fragment,ping success, but i use mpls mtu override 1524, i can see fragment in show ip traffic,but ping command failed. i can't see packet in destination router,how this work.
    thank you!
    jun

    topology is simple
    7609-1--sip GE spa----7609-2--pos---7609-3--flexwan E1-----7604-1--ge--ce
    i config mpls mtu 1524 between 7609-1 and 7609-2 . and keep interface mtu 1500 default.
    ping packet from 7609-1 to 7604-1 loopback 0.
    ping 1500 byte packet is ok, but ping 1501 byte packet is totally lost.then i config mtu 1524 between 7604-1 and 7609-3, it is useless,notwork, i can't see packet coming from 7609-1 on 7604-1.
    but i add config mtu 1524 between 7609-1 and 7609-2. config mtu 1500 between 7604-1 and 7609-3,ping 1501 bytes from 7609-1 to 7604-1 loopback0 is ok. but i can see fragment from show ip traffic command in 7609-3.
    i have a question, why we need mpls mtu command. if we don't change interface mtu,just only config mpls mtu 1524, it doesn't work, if we just change mpls mtu,how it work in the ios. if we config interface mtu 1524,interface mtu size is big enough, it seems mpls mtu command is useless, we don't need mpls mtu command, just interface mtu 1524 is ok.
    why we need mpls mtu command. we just only change interface mtu is enough.
    thank you!
    jun

  • NSX Lab on Workstation 11 - Nested ESX crashes with unrecoverable error when trying to test VTEP connectivity with MTU 1500

    I'm trying to install and configure NSX 6.1.2 / ESX 5.5 in a nested environment using VMware Workstation lastest bits "VMware-workstation-full-11.1.0-2496824"
    I've configured the MTU on the virtual adapter (VMNet1) used by the VXLAN transport network to 9000 bytes.
    C:\Users\admin>netsh int ipv4 show int
    Idx     Met         MTU          State                Name
      1          50  4294967295  connected     Loopback Pseudo-Interface 1
    19          25        1500  connected     Wireless Network Connection 4
    16          40        1500  disconnected  Bluetooth Network Connection
    11           5        1500  disconnected  Local Area Connection
    20           5        1500  disconnected  Wireless Network Connection 5
    18           5        1400  disconnected  Local Area Connection* 11
    31          20        9000  connected     VMware Network Adapter VMnet1
    when I test VTEP connectivity between ESXi nested host with MTU > 1500, using the following command,
    ping ++netstack=vxlan -d -s 1572 -I vmk2 192.168.192.102
    the ESXi crashes with the following error
    2015-05-21T11:20:47.180+02:00| vcpu-1| I120: Coredump encountered overflow 10218:10218 (2172 duplicates)
    2015-05-21T11:20:48.969+02:00| vcpu-1| I120: Backtrace:
    2015-05-21T11:20:48.970+02:00| vcpu-1| I120: backtrace[00] frame 0x0881eb38 IP 0x13f0820de params 0 0xa6 0x64e 0x312d75706376 ??? [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x000310de]
    2015-05-21T11:20:48.971+02:00| vcpu-1| I120: backtrace[01] frame 0x0881f460 IP 0x13f068129 params 0x13f78dc30 0x13f890928 0x2ce 0x3fff ??? [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x00017129]
    2015-05-21T11:20:48.971+02:00| vcpu-1| I120: backtrace[02] frame 0x0881f8b0 IP 0x13f4498bc params 0x13fb8e840 0x3a63ec0 0x13f050000 0x13fb8e840 opus_decoder_destroy + 0x1dec0c [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x003f88bc]
    2015-05-21T11:20:48.972+02:00| vcpu-1| I120: backtrace[03] frame 0x0881f8e0 IP 0x13f6809a2 params 0x161 0x35a59e0 0 0xa36333237 opus_repacketizer_get_nb_frames + 0x163fc2 [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x0062f9a2]
    2015-05-21T11:20:48.972+02:00| vcpu-1| I120: backtrace[04] frame 0x0881f920 IP 0x13f6b8229 params 0x258 0 0 0 opus_repacketizer_get_nb_frames + 0x19b849 [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x00667229]
    2015-05-21T11:20:48.973+02:00| vcpu-1| I120: backtrace[05] frame 0x0881faa0 IP 0x13f680d3c params 0x13f809d60 0x13f7c7374 0x5 0x13fd65da0 opus_repacketizer_get_nb_frames + 0x16435c [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x0062fd3c]
    2015-05-21T11:20:48.973+02:00| vcpu-1| I120: backtrace[06] frame 0x0881fb00 IP 0x13f20c736 params 0 0 0 0 ??? [C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe base 0x13f050000 0x0001:0x001bb736]
    2015-05-21T11:20:48.976+02:00| vcpu-1| I120: backtrace[07] frame 0x0881fb08 IP 0x76ee59cd params 0 0 0 0 BaseThreadInitThunk + 0x000d [C:\Windows\system32\kernel32.dll base 0x76ed0000 0x0001:0x000149cd]
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120: backtrace[08] frame 0x0881fb38 IP 0x7701b891 params 0 0 0 0 RtlUserThreadStart + 0x0021 [C:\Windows\SYSTEM32\ntdll.dll base 0x76ff0000 0x0001:0x0002a891]
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120: Msg_Post: Error
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.log.error.unrecoverable] VMware Workstation unrecoverable error: (vcpu-1)
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120+ VERIFY d:/build/ob/bora-2496824/bora/devices/vmxnet3/vmxnet3_hosted.c:718
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "X:\vCACupdate\Capricornus\vmware.log". 
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support. 
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.windowsOrLinux]
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120+ To collect data to submit to VMware support, choose "Collect Support Data" from the Help menu.
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120+ You can also run the "vm-support" script in the Workstation folder directly.
    2015-05-21T11:20:48.980+02:00| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement.
    Any help is appreciated.

    One detail:
    I use Vcloud from my work, so I changed iPv4 addresses of machines. For example, DC1 192.168.2.101,
    Internet names are 192.169.2.101 and so on.
    I mean it is fine that IP addresses differ from mentioned in guide

  • [Solved] MTU settings lost with wifi connection

    Hi
    After reboot the
    ip link show | grep mtu
    shows me
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
    2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
    3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000
    But after a few second if I ran again this command it's show me
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
    2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
    3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 576 qdisc mq state UP mode DORMANT qlen 1000
    I cannot ran anything except Tilda, but mtu is changing from 1500 to 576
    My /etc/rc.local is
    #!/bin/bash
    # /etc/rc.local: Local multi-user start-up script.
    ip link set wlan0 mtu 1500
    Why it's change without any reason?
    Last edited by saalty (2012-11-11 09:17:26)

    Are you using dhcp? If so, dhcpd will helpfully adjust your MTU to what the network claims it wants. However, this can cause problems in various cases. (It stopped me accessing aur from home, for example.) If you would rather it not do this, comment the line in /etc/dhcpd.conf like so:
    #option interface_mtu

  • How is NTP reply routed when requesting router uses loopback as source address

    The Cisco NTP Best Practices White Paper and DISA STIGs recommend setting the NTP source address to a loopback interface (e.g. "ntp source loopback0").
    But this only seems to work if the requesting (NTP client) router is the default gateway for the NTP server. 
    Specifically, the NTP server will attempt to reply to the requesting router's loopback-based source address (taken from the NTP request packet).  Since that address will always be non-local from the perspective of the NTP server, the NTP server will encapsulate the reply in a Layer 2 frame addressed to its default gateway.  If the gateway was the source of the original NTP request, that should work.  But in most other situations that gateway won't know how to reach a loopback-based address, and will discard the reply.
    I have verified this in tests with routers running both 12.4 and 15.1 releases (and NTP debugging enabled).  When the NTP source is a loopback address, NTP replies never reach the requesting router.  With the default NTP source address (i.e. based on the exit interface) everything works fine.
    Obviously, you could employ workarounds, such as static routes or injecting loopback addresses into your routing protocols.  But that seems uglier than leaving NTP source addresses at their defaults.
    Why is this "best practice" so commonly advocated without mention of some significant caveats regarding routing?  Am I missing something? 
    Thanks,
      Mark

    Michel:
    Thanks for the response.  Actually, I understand what kind of routing workarounds could allow NTP to function in spite of this "best practice."  But I am mystified as to why a Cisco "NTP best practice" paper (http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml) and various security policies would call for setting a loopback address as the NTP source when that practice will often cause more problems than it solves.
    The stability of a loopback address is nice when that address is used to uniquely identify the platform for a routing protocol or syslog.  A loopback-based source address can also simplify ACL management, since that address won't change if an interface or link failure forces the router to send traffic from a different interface.  But I keep seeing security configuration guides/policies that call for also using a loopback address as the source for two-way protocols, such as FTP and NTP. That just doesn't make sense to me when you balance the routing implications against the limited security benefits (stable device identification, simplified ACL maintenance, and obfuscation of device addresses).
    I was hoping to learn that some obscure command might allow me to control which NTP exchanges use the loopback-based source address.  For example, the loopback source address would work fine on outgoing NTP broadcasts (and probably in replies from NTP servers).  But I would prefer that NTP client requests use a source address based on the exit interface. That way replies can be routed back to the client without cluttering up routing tables with routes to loopback addresses.
    So far, it looks like I'll need to chalk this up to poor coordination between the network security and network administration communities.
    Thanks again,
      Mark

  • VIP loopback rc.conf

    Hello everyone,
    I'm trying to set up a load-balanced website using keepalived.
    I have to set up a virtual ip on the loopback interface on each web node.
    I'm trying this syntax in the rc.conf file :
    eth1="eth1 192.168.41.253 netmask 255.255.254.0 broadcast 192.168.41.255"
    lo_1="lo:1 192.168.41.250 netmask 255.255.255.255 broadcast 192.168.41.250"
    INTERFACES=(eth1 lo_1)
    On the machine startup, i get this message :
    SIOCSIFFLAGS Cannot assign requested address
    The interfaces seems ok, but i would like to have a clean startup.
    When i restart the network, i always have a failure on network shutdown, but the startup is ok.
    eth1      Link encap:Ethernet  HWaddr 08:00:27:14:E9:07 
              inet addr:192.168.41.252  Bcast:192.168.41.255  Mask:255.255.254.0
              inet6 addr: fe80::a00:27ff:fe14:e907/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:17 errors:0 dropped:0 overruns:0 frame:0
              TX packets:875 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:1020 (1020.0 b)  TX bytes:47298 (46.1 Kb)
              Interrupt:9 Base address:0xd240
    lo        Link encap:Local Loopback 
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:61 errors:0 dropped:0 overruns:0 frame:0
              TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:9806 (9.5 Kb)  TX bytes:9806 (9.5 Kb)
    lo:1      Link encap:Local Loopback 
              inet addr:192.168.41.250  Mask:255.255.255.255
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
    [root@hanzel ~]# /etc/rc.d/network restart
    :: Stopping Network                                                                                            [FAIL]
    :: Starting Network                                                                                            [DONE]
    [root@hanzel ~]#ifconfig
    eth1      Link encap:Ethernet  HWaddr 08:00:27:14:E9:07 
              inet addr:192.168.41.252  Bcast:192.168.41.255  Mask:255.255.254.0
              inet6 addr: fe80::a00:27ff:fe14:e907/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:26 errors:0 dropped:0 overruns:0 frame:0
              TX packets:943 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:1560 (1.5 Kb)  TX bytes:50994 (49.7 Kb)
              Interrupt:9 Base address:0xd240
    lo        Link encap:Local Loopback 
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:192 errors:0 dropped:0 overruns:0 frame:0
              TX packets:192 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:22826 (22.2 Kb)  TX bytes:22826 (22.2 Kb)
    lo:1      Link encap:Local Loopback 
              inet addr:192.168.41.250  Mask:255.255.255.255
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
    Is there another syntax in the rc.conf file in order to remove theses failure messages.
    Last edited by foudebassan (2010-05-11 08:56:03)

    Thanks for testing Sin.citadel.
    fukawi2,
    I mistyped "l0_1" in my first post, i corrected it.
    I think you use keepalived doing NAT, that's why you dont use the loopback interface.
    In my network configuration, my LVS and my web nodes are on the same subnet. I'm using direct routing in my keepalived configuration.
    Using NAT is useless for me, and requires more CPU ressources.
    When using DR, the VIP is shared by each node on the loopback interface, with some tuning in the sysctl.conf file to correct arp issues, it runs fine.
    I was just looking for a way to have a clean boot. Using the rc.local file could be a solution
    Last edited by foudebassan (2010-05-11 09:07:56)

  • Keepalive and layer 2 loopback detection

    My question is concerned with how Cisco switches use keepalive at layer 2 to detect loopbacks. All the info on keepalive that I could find was concerned with its use at higher layers (eg tunnels, routing protocols etc).
    We had an incident where a mismatch in switch configurations caused a loop that wasn't blocked by spanning tree. This caused a number of our switches to err-disable their uplinks "%ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected". Some of these switches where fairly deep down a chain of switches with only a single uplink path.
    We have also had a situation (which eventually went away) where the single uplink on a particular switch was err-disabled loopback detected although we could find no evidence of a loop. I have my suspicions about keepalive packets not being dealt with properly especially if vlan 1 is removed from trunk links (which we have to do in some cases) or ether channels are involved. Bugs CSCeg58877 and CSCdt82690 describe such problems but neither of these match our circumstances.
    Because of the above I am considering disabling keepalive on my Cisco switches layer 2 links, especially uplinks, is this a good or bad idea?
    Alex McLaren

    Hi Alex-
    Loopback detection was a mechanism that was put in place to detect loops in the network
    caused by Type1a or tyep2 copper cabling. While it is a good mechansim for those special
    situations , there seems to be no need for having it enabled on the Gig ports where you
    can use features like UDLD to detect a fiber loop or unidirectional fiber.
    But in 12.1EA releases , loopback detection is enabled by default on the fiber ports as
    well as copper ports. On some fiber ports , neighboring switch may just switch the
    keepalive packet back w/o making any change in the packet causing the original switch that
    sent out the keepalive to recive its own packet back kicking in this mechanism of
    error-disabling the port.
    What you can do is you can disable keepalives on the uplink Gig ports of the 2950 and that
    should take care of the problem
    On 2950
    int gig
    no keepalives
    But make sure you have UDLD enabled. Once you have disabled the keepalives , please make
    sure you have low cpu on the 2950s that were showing the problem as well as make sure the
    mac-aging timer stays at 300 sec.
    show proc cpu
    show mac- aging
    UDLD should however be enabled on fiber Gig ports to detect spanning tree loop problems.
    Keepalive detection mechansim is speciafically there for Type1a and type 2 cabling and has
    no significance on fiber ports.
    This is also documented in the the release notes of the following Cisco DDTS id #
    CSCea46385.
    An interface on a Catalyst switch is errordisabled after detecting a loopback.
    Mar 7 03:20:40: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet0/2.
    The port is forced to linkdown.
    Mar 7 03:20:42: %LINK-5-CHANGED: Interface GigabitEthernet0/2, changed state to
    administratively down
    Mar 7 03:20:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2,
    changed state to down
    Conditions:
    This might be seen on a Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560 or
    3750 switch running 12.1EA or 12.2SE based code.
    Workaround:
    Disable keepalives by using the "no keepalive" interface command. This will
    prevent the port from being errdisabled, but it does not resolve the root cause of
    the problem. Please see section below for more information.
    Additional Information:
    The problem occurs because the keepalive packet is looped back to the port that sent
    the keepalive. There is a loop in the network. Although disabling the keepalive
    will prevent the interface from being errdisabled, it will not remove the loop.
    The problem is aggravated if there are a large number of Topology Change Notifications
    on the network. When a switch receives a BPDU with the Topology Change bit set,
    the switch will fast age the MAC Address table. When this happens, the number of
    flooded packets increases because the MAC Address table is empty.
    Keepalives are sent on the Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560
    or 3750 switch to prevent loops in the network. The primary reason for the keepalives
    is to prevent loops as a result of Type 2 cabling. For more information, see:
    http://www.cisco.com/en/US/netsol/ns340/ns394/ns74/ns149/networking_solution
    s_white_paper09186a00800b4249.shtml
    Keepalives are sent on ALL interfaces by default in 12.1EA based software. Starting
    in 12.2SE based releases, keepalives are NO longer sent by default on fiber and uplink
    interfaces. Since there is no 12.2SE release for 2950s , you will have to manually disable
    the keepalives on uplink Gig ports.
    Hope this helps.
    thanks
    Salman Zahid

  • Linux下验证listener.ora配置loopback地址(127.0.0.1),client是否任然可以连接数据库

    群里有朋友认为监听配置文件如果改为loopback(127.0.0.1)地址,client不能访问数据库的问题,做以下实验来验证
    实验环境:
    Linux (RHEL)5.5
    Oracle Database 10g Release 2(10.2.0.5)
    Linux oracle10g_primary 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:43 EDT 2010 i686 i686 i386 GNU/Linux
    SQL> select * from registry$history;
    ACTION_TIME                                                                      ACTION                         NAMESPACE                      VERSION                                ID COMMENTS
    23-11月-12 05.30.56.431167 AM                                                  VIEW RECOMPILE                                                                                  8289601 view recompilation
    23-11月-12 05.30.56.501303 AM                                                  UPGRADE                        SERVER                         10.2.0.5.0                                Upgraded from 10.2.0.1.0将listener.ora文件中的host从/1.1.1.2改为127.0.0.1(loopback)地址(删除192.168.70.203),测试client(1.1.1.1)是否任然可以连接数据库
    [oracle@oracle10g_primary admin]$ vi listener.ora
    # listener.ora Network Configuration File: /oracle/product/10.2/network/admin/listener.ora
    # Generated by Oracle configuration tools.
    PRIMARY =
      (DESCRIPTION_LIST =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.70.203)(PORT = 1521))      以前的Data Guard环境
          (ADDRESS = (PROTOCOL = TCP)(HOST = 1.1.1.2)(PORT = 1521))
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    SID_LIST_PRIMARY =
    (SID_LIST =
        (SID_DESC =
          (SID_NAME = PLSExtProc)
          (ORACLE_HOME = /oracle/product/10.2)
          (PROGRAM = extproc)
        (SID_DESC =
          (GLOBAL_DBNAME = ora10)
          (ORACLE_HOME = /oracle/product/10.2)
          (SID_NAME = ora10)
    #----ADDED BY TNSLSNR 24-OCT-2012 06:51:24---
    PASSWORDS_LISTENER = E2DD162210C10912
    #--------------------------------------------客户端连通性测试:
    C:\Users\John>tnsping ora10_test_203
    TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 - Production on 25-11月-
    2012 21:41:50
    Copyright (c) 1997, 2010, Oracle.  All rights reserved.
    已使用的参数文件:
    D:\OracleCLT\product\11.2.0\client_1\network\admin\sqlnet.ora
    已使用 TNSNAMES 适配器来解析别名
    尝试连接 (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 1.1.1
    .2)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = ora10)))
    OK (30 毫秒)接着我们将server端 listener.ora中HOST地址改为127.0.0.1(loopback)地址。
    [oracle@oracle10g_primary admin]$ vi listener.ora
    # listener.ora Network Configuration File: /oracle/product/10.2/network/admin/listener.ora
    # Generated by Oracle configuration tools.
    PRIMARY =
      (DESCRIPTION_LIST =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    SID_LIST_PRIMARY =
    (SID_LIST =
        (SID_DESC =
          (SID_NAME = PLSExtProc)
          (ORACLE_HOME = /oracle/product/10.2)
          (PROGRAM = extproc)
        (SID_DESC =
          (GLOBAL_DBNAME = ora10)
          (ORACLE_HOME = /oracle/product/10.2)
          (SID_NAME = ora10)
    #----ADDED BY TNSLSNR 24-OCT-2012 06:51:24---
    PASSWORDS_LISTENER = E2DD162210C10912
    #--------------------------------------------重新启动listener服务
    [oracle@oracle10g_primary admin]$ lsnrctl reload
    LSNRCTL for Linux: Version 10.2.0.5.0 - Production on 25-NOV-2012 13:30:24
    Copyright (c) 1991, 2010, Oracle.  All rights reserved.
    Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
    The command completed successfully查看监听状态:
    [oracle@oracle10g_primary admin]$ lsnrctl status
    LSNRCTL for Linux: Version 10.2.0.5.0 - Production on 25-NOV-2012 13:30:57
    Copyright (c) 1991, 2010, Oracle.  All rights reserved.
    Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
    STATUS of the LISTENER
    Alias                     LISTENER
    Version                   TNSLSNR for Linux: Version 10.2.0.5.0 - Production
    Start Date                25-NOV-2012 13:14:52
    Uptime                    0 days 0 hr. 16 min. 4 sec
    Trace Level               off
    Security                  ON: Password or Local OS Authentication
    SNMP                      OFF
    Listener Parameter File   /oracle/product/10.2/network/admin/listener.ora
    Listener Log File         /oracle/product/10.2/network/log/listener.log
    Listening Endpoints Summary...
      (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oracle10g_primary)(PORT=1521)))
    Services Summary...
    Service "ora10" has 1 instance(s).
      Instance "ora10", status READY, has 1 handler(s) for this service...
    Service "ora10_XPT" has 1 instance(s).
      Instance "ora10", status READY, has 1 handler(s) for this service...
    The command completed successfully
    本机双网卡,eth0:192.168.70.203   eth1:1.1.1.2
    [oracle@oracle10g_primary admin]$ /sbin/ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 08:00:27:73:2D:E9 
              inet addr:192.168.70.203  Bcast:192.168.70.255  Mask:255.255.255.0
              inet6 addr: fe80::a00:27ff:fe73:2de9/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:0 (0.0 b)  TX bytes:6744 (6.5 KiB)
    [oracle@oracle10g_primary admin]$ /sbin/ifconfig eth1
    eth1      Link encap:Ethernet  HWaddr 08:00:27:7F:F0:8A 
              inet addr:1.1.1.2  Bcast:1.255.255.255  Mask:255.0.0.0
              inet6 addr: fe80::a00:27ff:fe7f:f08a/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:1697 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1667 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:168543 (164.5 KiB)  TX bytes:394523 (385.2 KiB)
    [oracle@oracle10g_primary admin]$ ping oracle10g_primary
    PING oracle10g_primary (192.168.70.203) 56(84) bytes of data.
    64 bytes from oracle10g_primary (192.168.70.203): icmp_seq=1 ttl=64 time=0.024 ms
    64 bytes from oracle10g_primary (192.168.70.203): icmp_seq=2 ttl=64 time=0.029 mslistener.ora配置文件已将监听地址配置为127.0.0.1(loopback)地址,我们再看看client是否还能正常使用数据库:
    Client IP地址1.1.1.1
    C:\Users\John>ipconfig |more
    Windows IP Configuration
    Wireless LAN adapter Wireless Network Connection 2:
       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
    Wireless LAN adapter Wireless Network Connection:
       Connection-specific DNS Suffix  . :
       Link-local IPv6 Address . . . . . : fe80::9e3:7005:a225:c0bd%14
       IPv4 Address. . . . . . . . . . . : 192.168.1.5
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 192.168.1.1
    Ethernet adapter Bluetooth Network Connection:
       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
    Ethernet adapter Local Area Connection:
       Connection-specific DNS Suffix  . :
       Link-local IPv6 Address . . . . . : fe80::35c8:958b:ac2f:d064%11
       IPv4 Address. . . . . . . . . . . : 192.168.70.200
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
    Ethernet adapter VirtualBox Host-Only Network:
       Connection-specific DNS Suffix  . :
       Link-local IPv6 Address . . . . . : fe80::5c6d:1a75:f795:16aa%21
       IPv4 Address. . . . . . . . . . . : 1.1.1.1
       Subnet Mask . . . . . . . . . . . : 255.0.0.0
       Default Gateway . . . . . . . . . :
    C:\Users\John>tnsping ora10_test_203
    TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 - Production on 25-11月-
    2012 21:36:41
    Copyright (c) 1997, 2010, Oracle.  All rights reserved.
    已使用的参数文件:
    D:\OracleCLT\product\11.2.0\client_1\network\admin\sqlnet.ora
    已使用 TNSNAMES 适配器来解析别名
    尝试连接 (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 1.1.1
    .2)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = ora10)))
    OK (30 毫秒)从client登录数据库
    C:\Users\John>sqlplus john/12345@ora10_test_203
    SQL*Plus: Release 11.2.0.1.0 Production on 星期日 11月 25 21:36:04 2012
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    连接到:
    Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL> select instance_name,status from v$instance;
    INSTANCE_NAME    STATUS
    ora10            OPEN可以看到,即便listener.ora配置文件中HOST IP改为loopback地址,client也是可以通过server上的相应网卡地址连接数据库。。
    原因:
    如果你有观察过server上1521端口发布的情况,你会发现,其实无论你在listener.ora写了什么ip地址,在Linux环境下(AIX/HP-UX除外),端口都会发布在0.0.0.0的地址上
    [oracle@oracle10g_primary admin]$ netstat -an |grep  1521
    tcp        0      0 0.0.0.0:1521                0.0.0.0:*                   LISTEN client连接后观察OS上系统端口和地址的变化:
    [oracle@oracle10g_primary admin]$ netstat -an |grep 1521
    tcp        0      0 0.0.0.0:1521                0.0.0.0:*                   LISTEN     
    tcp        0      0 1.1.1.2:1521                1.1.1.1:50446               TIME_WAIT这就是为什么在Linux环境下Oracle listener.ora配置成127.0.0.1(loopback)地址,client还是可以通过server上的其他IP地址连接数据库的原因
    备注:只针对Linux环境,AIX/HP-UX除外。

    你可以尝试着在监听上加上IP=FIRST,再测试
    我以前关于IP=FIRST的测试
    [IP=FIRST作用说明|http://www.xifenfei.com/2713.html]

  • MTU Question.

    Can some one please explain the two different behaviour of MTU as per below output :
    In the first output why we dont see the packet loss although the packet size is bigger than the MTU size.
    where as in the output 2 we notice the packet loss where as the packet size it 1481 and MTU size is 1480.
    === OutPut 1 ===
    ROU#sh int t3
    Tunnel3 is up, line protocol is up
    Hardware is Tunnel
    Description: ***Connect to Ro_03 Tunnel1 Fe0/0/0***
    Internet address is 21.233.41.21/30
    MTU 17920 bytes, BW 4096 Kbit/sec, DLY 50000 usec,
         reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation TUNNEL, loopback not set
    Keepalive set (10 sec), retries 3
    Tunnel source 21.233.7.22 (GigabitEthernet0/0/4), destination
    21.233.41.246
       Tunnel Subblocks:
         src-track:
             Tunnel3 source tracking subblock associated with
    GigabitEthernet0/0/4
             Set of tunnels with source GigabitEthernet0/0/4, 10 members (includes iterators), on interface <OK>
    Tunnel protocol/transport IP/IP
    Tunnel TTL 255, Fast tunneling enabled
    Tunnel transport MTU 1480 bytes
    Tunnel transmit bandwidth 8000 (kbps)
    Tunnel receive bandwidth 8000 (kbps)
    Last input never, output never, output hang never
    Last clearing of "show interface" counters never
    Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: fifo
    Output queue: 0/0 (size/max)
    5 minute input rate 12000 bits/sec, 1 packets/sec
    5 minute output rate 13000 bits/sec, 1 packets/sec
         16274329 packets input, 3173533969 bytes, 0 no buffer
         Received 0 broadcasts (0 IP multicasts)
         0 runts, 0 giants, 0 throttles
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
         18686934 packets output, 8984626725 bytes, 0 underruns
         0 output errors, 0 collisions, 0 interface resets
         0 unknown protocol drops
         0 output buffer failures, 0 output buffers swapped out
    ITC#ping
    Protocol [ip]:
    Target IP address: 21.233.41.22
    Repeat count [5]: 1000
    Datagram size [100]: 2048
    Timeout in seconds [2]:
    Extended commands [n]:
    Sweep range of sizes [n]:
    Type escape sequence to abort.
    Sending 1000, 2048-byte ICMP Echos to 21.233.41.22, timeout is 2 seconds:
    Success rate is 100 percent (1000/1000), round-trip min/avg/max = 33/33/76 ms
    === OutPut 2==
    ROU#ping
    Protocol [ip]:
    Target IP address: 21.233.179.241
    Repeat count [5]: 1000
    Datagram size [100]: 1481
    Timeout in seconds [2]:
    Extended commands [n]:
    Sweep range of sizes [n]:
    Type escape sequence to abort.
    Sending 1000, 1481-byte ICMP Echos to 21.233.179.241, timeout is 2 seconds:
    Success rate is 98 percent (984/1000), round-trip min/avg/max = 69/70/175 ms
    ===
    Best Regards,

    Hi,
    I think you should move this post to the appropriate section because I don't see any relationship with IPv6 here.
    Hi if you had an MTU problem all your packets should be dropped and you would have to set the DF-bit in the extended ping to test because by default if the DF bit is not set the routers will fragment the packets.
    Regards.
    Alain.

  • MTU 1500

    Folks,
    I keep reading in this forum that in an MPLS network if the MTU is 1500 bytes (default), a lot of packets would get dropped as the labels added to the original packet make it bigger than 1500 bytes(4 bytes per lable).
    So i did a test today, I built a small network of three routers. I connected one of the routers to the internet and connected my laptop of the 3rd router on the far end. Had the router connected to the internet advertise a default route in a vrf to the router on the far end. I made sure that my traffic was being tag switched inside the core before going to the internet.
    All interfaces inside my core had only 1500 mtu set.
    to my surprise, i was able to go to yahoo, msn, hotmail, cnn and many other sites without any problem.
    Does anyone know of a site that marks the packet as df=1 so that it is not fragmented inside the core?
    I used the extended ping test with mtu of 1504 and df=1 and it failed as suspected.
    does anyone know of an other application I can use to prove that mtu of 1500 would not work in an MPLS network rather than using a ping?
    How will i know that packets were dropped because the mtu was more than the interface that support?
    Thanks,

    Parwal,
    Since your packets were label switched inside your small core, DF value has no significance, since IP headers were not visible to LSRs. Obviously in this environment PMTUD is not relevant because of the same reason.
    When accessing web sites, you usually get the data in spikes and not in constant stream as for example with file transfers (FTP). With these spikes TCP never reaches full speed, so IP packet size stays below 1500bytes.
    Try to do an FTP file transfer through your network and you will see it "hang" very quickly. This is an indication that you're running into MTU issues, which you will :-)
    David

  • Why we need mpls mtu command?

    if interface mtu is not big enough to take mpls packet. we just increase interface mtu. why we need mpls mtu command.
    if we just only increase mpls mtu.there is problem if mpls mtu biger than interface mtu. so it seem mpls mtu command is useless.
    why we need mpls mtu command!
    thank you!
    Jun

    Hi,
    i test it in netowork,like this\
    topology is simple
    7609-1pe--sip GE spa----7609-2p--pos---7609-3p--flexwan E1-----7604-1pe--ge--ce
    i config mpls mtu 1524 between 7609-1 and 7609-2 . and keep interface mtu 1500 default.
    ping packet from 7609-1 to 7604-1 loopback 0.
    ping 1500 byte packet is ok, but ping 1501 byte packet is totally lost.then i config mtu 1524 between 7604-1pe and 7609-3, it is useless,not work, i can't see packet coming from 7609-1 on 7604-1.
    then i add config mtu 1524 between 7609-1pe and 7609-2. config mtu 1500 between 7604-1 and 7609-3,ping 1501 bytes from 7609-1 to 7604-1 loopback0 is ok. but i can see fragment from show ip traffic command in 7609-3.
    i have a question, why we need mpls mtu command. if we don't change interface mtu,just only config mpls mtu 1524, it doesn't work, if we just change mpls mtu,how it work in the ios. if we config interface mtu 1524,interface mtu size is big enough, it seems mpls mtu command is useless, we don't need mpls mtu command, just increase interface mtu 1524 is ok.
    why we need mpls mtu command. we just only change interface mtu is enough.
    when i config mpls mtu override 1524,this is a warning in ios:
    Setting the mpls mtu to 1524 on interface serial1/0/0:0, which is higher than the interface MTU
    1500. This could lead to packet forwarding problems including packet drops.
    You must set the MPLS MTU values equal to or lower than the interface MTU values.
    thank you!
    jun

  • About svi mtu

    hello netpro:
    i increate a int vlan x in sw3550emi ,I have no configure,but the int vlan x show it's mtu 1501.who can tell me what's the problem? thank you
    sw1#sh int vlan 5
    Vlan5 is up, line protocol is up
    Hardware is EtherSVI, address is 0013.1ab4.fe00 (bia 0013.1ab4.fe00)
    MTU 1501 bytes, BW 1000000 Kbit, DLY 10 usec,
    reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation ARPA, loopback not set
    ARP type: ARPA, ARP Timeout 04:00:00
    Last input never, output never, output hang never
    Last clearing of "show interface" counters never
    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    Queueing strategy: fifo
    Output queue: 0/40 (size/max)
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute output rate 0 bits/sec, 0 packets/sec
    0 packets input, 0 bytes, 0 no buffer
    Received 0 broadcasts (0 IP multicast)
    0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 packets output, 0 bytes, 0 underruns
    0 output errors, 0 interface resets
    0 output buffer failures, 0 output buffers swapped out
    sw1#sh run int vlan 5
    interface Vlan5
    no ip address
    end
    sh version
    IOS (tm) C3550 Software (C3550-I5Q3L2-M), Version 12.1(20)EA1, RELEASE SOFTWARE
    (fc1)
    Copyright (c) 1986-2004 by cisco Systems, Inc.
    Compiled Wed 04-Feb-04 23:28 by yenanh
    Image text-base: 0x00003000, data-base: 0x00827298
    ROM: Bootstrap program is C3550 boot loader
    sw1 uptime is 5 minutes
    System returned to ROM by power-on
    System image file is "flash:/c3550-i5q3l2-mz.121-20.EA1.bin"
    cisco WS-C3550-24 (PowerPC) processor (revision P0) with 65526K/8192K bytes of m
    emory.
    Processor board ID CAT0819X0FZ
    Last reset from warm-reset
    Bridging software.
    Running Layer2/3 Switching Image

    I'm not sure if there is a problem becuase a standard Ethernet frame MTU is 1500 bytes. This does not include the Ethernet header and Cyclic Redundancy Check (CRC) trailer, which is 18 bytes in length, to make the total Ethernet frame size of 1518.

Maybe you are looking for

  • Internal Storage VI error

    I am acquiring multiple channels at 5KHz (continuous) and down-sampling some of them to then store using the storage VIs. There is also some online signal processing (i.e. FFT) and visualization. On the block diagram I open a file using the event str

  • ISight only working with a few people.

    ok. this problem is a little hard to explain....my iSight video chat occationally works with some people...and then sometimes it doesnt work. then there is this one person where video chat ALWAYS works. Then there are people that NEVER work on my isi

  • [Solved] How to use Oracle Java 6 for specific applications

    I use an IDE called PyCharm. On its download page, it recommends using Java 6 instead of OpenJDK. I currently have jdk7-openjdk installed, and from what I had read in the Arch Wiki on Java, it should be possible to install Oracle Java 6 along side Op

  • Where and how can I find enigmail on Thunderbird?

    I am trying to install enigmail from Thunderbird and cannot find it as an add-on. I thought it would be there. Can you advise where and how to find it?

  • Adobe Digital Edition Error E_IO_CANNOT_OPEN

    When I clic to an url link.acsm downloded from Kobo, I have this error. In french: erreur lors de l'obtention de la licence.(Communication error with the licence server). Impossible to download the ebook. My autorisation is ok, I have 4.0.1.101645 ve