Re: [mpls-linux-general] UDP traffic problem
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
Re: [mpls-linux-general] UDP traffic problem
|
From: James R. L. <jl...@mi...> - 2008-02-15 04:29:45
|
On Thu, Feb 14, 2008 at 05:42:38PM -0500, Chris Robson wrote: > James > > The problem does occur in a LER<--->LER LSP. I also have proven that there > is a checksum problem with UDP packets. If I turn off MPLS dns udp packets > do not generate a checksum error but when I standup a MPLS LSP the path > generates UDP checksum errors on DNS queries. Below is a wireshark capture > of one packet with a checksum erro, hope it helps. > .....chris Interesting. Can put a host on one side of the LER<->LER and have it send the DNS packet? Then capture the packet on the IPv4 link and capture the same packet on the MPLS link? I want to see if the packet size increases by more then 4 bytes, that would explain the invalid checksum. > No. Time Source Destination Protocol > Info > 88 16.175819 10.128.0.13 10.128.142.215 DNS > Standard query AAAA limestone.uoregon.edu > > Frame 88 (85 bytes on wire, 85 bytes captured) > Arrival Time: Feb 14, 2008 17:01:19.156776000 > [Time delta from previous captured frame: 0.094658000 seconds] > [Time delta from previous displayed frame: 0.094658000 seconds] > [Time since reference or first frame: 16.175819000 seconds] > Frame Number: 88 > Frame Length: 85 bytes > Capture Length: 85 bytes > [Frame is marked: True] > [Protocols in frame: eth:mpls:ip:udp:dns] > [Coloring Rule Name: Checksum Errors] > [Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || > ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1] > Ethernet II, Src: Dell_f5:3d:96 (00:15:c5:f5:3d:96), Dst: Dell_f0:7a:a6 > (00:1d:09:f0:7a:a6) > Destination: Dell_f0:7a:a6 (00:1d:09:f0:7a:a6) > Address: Dell_f0:7a:a6 (00:1d:09:f0:7a:a6) > .... ...0 .... .... .... .... = IG bit: Individual address (unicast) > .... ..0. .... .... .... .... = LG bit: Globally unique address > (factory default) > Source: Dell_f5:3d:96 (00:15:c5:f5:3d:96) > Address: Dell_f5:3d:96 (00:15:c5:f5:3d:96) > .... ...0 .... .... .... .... = IG bit: Individual address (unicast) > .... ..0. .... .... .... .... = LG bit: Globally unique address > (factory default) > Type: MPLS label switched packet (0x8847) > MultiProtocol Label Switching Header, Label: 4002, Exp: 0, S: 1, TTL: 64 > MPLS Label: 4002 > MPLS Experimental Bits: 0 > MPLS Bottom Of Label Stack: 1 > MPLS TTL: 64 > Internet Protocol, Src: 10.128.0.13 (10.128.0.13), Dst: 10.128.142.215 > (10.128.142.215) > 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: 67 > Identification: 0x7939 (31033) > Flags: 0x04 (Don't Fragment) > 0... = Reserved bit: Not set > .1.. = Don't fragment: Set > ..0. = More fragments: Not set > Fragment offset: 0 > Time to live: 64 > Protocol: UDP (0x11) > Header checksum: 0x1d8d [correct] > [Good: True] > [Bad : False] > Source: 10.128.0.13 (10.128.0.13) > Destination: 10.128.142.215 (10.128.142.215) > User Datagram Protocol, Src Port: 32845 (32845), Dst Port: domain (53) > Source port: 32845 (32845) > Destination port: domain (53) > Length: 47 > Checksum: 0xa424 [incorrect, should be 0xc0b5 (maybe caused by "UDP > checksum offload"?)] > [Good Checksum: False] > [Bad Checksum: True] > Domain Name System (query) > Transaction ID: 0x8db9 > Flags: 0x0100 (Standard query) > 0... .... .... .... = Response: Message is a query > .000 0... .... .... = Opcode: Standard query (0) > .... ..0. .... .... = Truncated: Message is not truncated > .... ...1 .... .... = Recursion desired: Do query recursively > .... .... .0.. .... = Z: reserved (0) > .... .... ...0 .... = Non-authenticated data OK: Non-authenticated > data is unacceptable > Questions: 1 > Answer RRs: 0 > Authority RRs: 0 > Additional RRs: 0 > Queries > limestone.uoregon.edu: type AAAA, class IN > Name: limestone.uoregon.edu > Type: AAAA (IPv6 address) > Class: IN (0x0001) > > > James R. Leu wrote: >> Can you try to duplicate with just two LERs (ie no LSR)? I'm trying to narrow >> down where I have to look in the code. >> >> On Wed, Feb 13, 2008 at 08:28:46PM -0500, Chris Robson wrote: >> >>> James >>> >>> I dont think the push is the problem. First, it can't be removed based >>> on how the LER needs to be configured. Remembering my network >>> configuration is LER_1<->LSR<->LER_2, below is the CLI's MPLS commands >>> for each router. Also, another test using "iperf -u" works, although >>> performance is very poor, so it seems only dns and traceroute using udp >>> are not working. >>> >>> Iperf output: >>> [LER_1]# iperf -u -c 10.128.0.237 (NOTE this is LER_1 interface) >>> ------------------------------------------------------------ >>> Client connecting to 10.128.0.237, UDP port 5001 >>> Sending 1470 byte datagrams >>> UDP buffer size: 109 KByte (default) >>> ------------------------------------------------------------ >>> [ 3] local 10.128.0.14 port 32800 connected with 10.128.0.237 port 5001 >>> [ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec >>> [ 3] Sent 893 datagrams >>> [ 3] WARNING: did not receive ack of last datagram after 10 tries. >>> >>> [LER_2]# iperf -u -s >>> ------------------------------------------------------------ >>> Server listening on UDP port 5001 >>> Receiving 1470 byte datagrams >>> UDP buffer size: 109 KByte (default) >>> ------------------------------------------------------------ >>> [ 3] local 10.128.0.10 port 5001 connected with 10.128.0.14 port 32800 >>> >>> >>> LER_1 >>> /usr/sbin/mpls nhlfe add key 0 instructions push gen 2000 nexthop eth0 >>> ipv4 10.128.0.9 >>> /usr/sbin/ip route add 0.0.0.0/0 via 10.128.0.9 mpls 0x2 >>> /usr/sbin/mpls labelspace set dev eth0 labelspace 0 >>> /usr/sbin/mpls ilm add label gen 1001 labelspace 0 >>> /usr/sbin/mpls nhlfe add key 0 instructions nexthop eth1 ipv4 10.128.0.238 >>> /usr/sbin/mpls xc add ilm_label gen 1001 ilm_labelspace 0 nhlfe_key 0x3 >>> >>> LER_2 >>> /usr/sbin/mpls nhlfe add key 0 instructions push gen 1000 nexthop eth1 >>> ipv4 10.128.0.13 >>> /usr/sbin/ip route add 10.128.143.0/24 via 10.128.0.13 mpls 0x2 >>> /usr/sbin/ip route add 10.128.0.8/30 via 10.128.0.13 mpls 0x2 >>> /usr/sbin/ip route add 10.128.0.236/30 via 10.128.0.13 mpls 0x2 >>> /usr/sbin/mpls labelspace set dev eth1 labelspace 0 >>> /usr/sbin/mpls ilm add label gen 2001 labelspace 0 >>> /usr/sbin/mpls nhlfe add key 0 instructions nexthop eth0 ipv4 10.128.0.226 >>> /usr/sbin/mpls xc add ilm_label gen 2001 ilm_labelspace 0 nhlfe_key 0x3 >>> >>> LSR >>> mpls labelspace set dev eth1 labelspace 0 >>> mpls ilm add label gen 1000 labelspace 0 >>> mpls nhlfe add key 0 instructions push gen 1001 nexthop eth1 ipv4 >>> 10.128.0.10 >>> mpls xc add ilm_label gen 1000 ilm_labelspace 0 nhlfe_key 0x2 >>> mpls labelspace set dev eth0 labelspace 0 >>> mpls ilm add label gen 2000 labelspace 0 >>> mpls nhlfe add key 0 instructions push gen 2001 nexthop eth0 ipv4 >>> 10.128.0.14 >>> mpls xc add ilm_label gen 2000 ilm_labelspace 0 nhlfe_key 0x3 >>> >>> >>> >>> James R. Leu wrote: >>> >>>> On Wed, Feb 13, 2008 at 10:02:44AM -0500, Chris Robson wrote: >>>> >>>>> Not familiar with the PHP implementation, let me collect up the test >>>>> configuration and send it to you for advice on what you want. A test >>>>> update, the problem seems, so far, to only manifest itself with dns and >>>>> traceroute. An "iperf -u -c [target_ip}" test does not have a problem. >>>>> >>>> PHP config example: >>>> >>>> mpls nhlfe add key 0 instructions nexthop eth0 ipv4 192.168.1.1 >>>> (notice no push in the instructions) >>>> >>>> Then bind it to a route or netfilter rule like normal. >>>> >>>> Can you try 'traceroute -I' which sends ICMP not UDP packets. >>>> >>>> >>>>> James R. Leu wrote: >>>>> >>>>>> I haven't seen it, but I can look into it. Can you try routing traffic >>>>>> through the same boxes, but use PHP (ie NHLFE without push) at each hop >>>>>> to see if that breaks it too? >>>>>> >>>>>> On Tue, Feb 12, 2008 at 06:22:25PM -0500, Chris Robson wrote: >>>>>> >>>>>>> Anyone notice udp traffic problems through a LER<->LSR<->LER LSP? >>>>>>> For example, if I attempt to issue the command "traceroute -n >>>>>>> [target-ip]" the traceroute will fail. If I add the TCP switch, aka >>>>>>> "traceroute -n -T [target-ip]", the trace works fine. Also, any >>>>>>> nslookups fail, again because the lookup request are udp packets. >>>>>>> Wireshark is showing checksum errors on the traceroute packets but >>>>>>> I'm not sure that is causing the problem as the error maybe >>>>>>> misleading. >>>>>>> >>>>>>> >>>>>>> James R. Leu wrote: >>>>>>> >>>>>>>> If the goal is to use NFS as root filesystem all one needs to do is create >>>>>>>> a initrd with the NFS modules, it is not required to build a kernel >>>>>>>> with NFS statically included. >>>>>>>> >>>>>>>> The key to allowing this to happen is you need to make sure your >>>>>>>> /etc/fstab has an entry for the root filesystem that spells out what NFS >>>>>>>> resource to use. >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> 172.16.1.1:/my/nfs/root / nfs defaults 0 0 >>>>>>>> >>>>>>>> Then install the MPLS enabled kernel RPM and as part of that it builds >>>>>>>> an initrd, and now that you have a fstab that indicates where to get root >>>>>>>> from it should build you a nfs enabled initrd. >>>>>>>> >>>>>>>> On Sun, Feb 10, 2008 at 05:12:44PM +0200, Adrian Popa wrote: >>>>>>>> >>>>>>>>> James, the original problem was that he needs NFS compiled into the kernel >>>>>>>>> in order to boot and the binary kernel you provide has it as a module... >>>>>>>>> >>>>>>>>> On Feb 9, 2008 6:07 AM, James R. Leu <jl...@mi...> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I haven't really been following along with your setup, so excuse me >>>>>>>>>> if I'm asking questions that you already answered. >>>>>>>>>> >>>>>>>>>> Why are you install SRPMs as opposed to the binary RPMs? If you're >>>>>>>>>> on a different distribution and compiling them by hand, please include the >>>>>>>>>> commands you used to do the compilation and installation. >>>>>>>>>> >>>>>>>>>> On Fri, Feb 08, 2008 at 06:45:09PM +0530, Bhartendu Maheshwari wrote: >>>>>>>>>> >>>>>>>>>>> Hello All, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I have compiled and installed 2.6.22 mpls enabled >>>>>>>>>>> kernel(kernel-2.6.22.5-76.fc7.mpls.1.958.src.rpm), and also installed >>>>>>>>>>> the following packages:- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ebtables-2.0.8-1.fc7.mpls.1.958b.src.rpm >>>>>>>>>>> >>>>>>>>>>> iproute-2.6.20-2.fc7.mpls.1.958b.src.rpm >>>>>>>>>>> >>>>>>>>>>> iptables-1.3.8-2.1.fc7.mpls.1.958.src.rpm >>>>>>>>>>> But unable to find mpls utility to configure system, >>>>>>>>>>> please let me know >>>>>>>>>>> if I am missing any package or any patch. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> System Information:- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [root@localhost linux-2.6.22]# cat /var/log/dmesg | grep MPLS >>>>>>>>>>> >>>>>>>>>>> MPLS: version 1.958 >>>>>>>>>>> >>>>>>>>>>> MPLS: protocol driver interface - <jl...@mi...> >>>>>>>>>>> >>>>>>>>>>> MPLS: IPv4 over MPLS support >>>>>>>>>>> >>>>>>>>>>> MPLS: Ethernet over MPLS support >>>>>>>>>>> >>>>>>>>>>> [root@localhost linux-2.6.22]# sysctl -A|grep os >>>>>>>>>>> >>>>>>>>>>> kernel.ostype = Linux >>>>>>>>>>> >>>>>>>>>>> kernel.osrelease = 2.6.22.5 >>>>>>>>>>> >>>>>>>>>>> kernel.hostname = localhost.localdomain >>>>>>>>>>> >>>>>>>>>>> net.core.message_cost = 5 >>>>>>>>>>> >>>>>>>>>>> net.ipv4.route.error_cost = 1000 >>>>>>>>>>> >>>>>>>>>>> net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 >>>>>>>>>>> >>>>>>>>>>> net.netfilter.nf_conntrack_tcp_timeout_close = 10 >>>>>>>>>>> >>>>>>>>>>> net.netfilter.nf_conntrack_tcp_loose = 1 >>>>>>>>>>> >>>>>>>>>>> dev.cdrom.info = Can close tray: 1 >>>>>>>>>>> >>>>>>>>>>> dev.cdrom.autoclose = 1 >>>>>>>>>>> >>>>>>>>>>> [root@localhost linux-2.6.22]# >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Kernel Configuration enabled are:- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. >>>>>>>>>>> >>>>>>>>>>> In Networking Options the following items will be compiled in kernel : >>>>>>>>>>> >>>>>>>>>>> <*> Multiprotocol Label Switching >>>>>>>>>>> >>>>>>>>>>> <*> MPLS: Virtual tunnel interface >>>>>>>>>>> >>>>>>>>>>> <*> 802.1d Ethernet Bridging >>>>>>>>>>> >>>>>>>>>>> <*> Bridge: MPLS support >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. >>>>>>>>>>> >>>>>>>>>>> In Bridge: Netfilter configuration menu the following minimum options >>>>>>>>>>> will be selected: >>>>>>>>>>> >>>>>>>>>>> <*> Ethernet Bridge tables (ebtables) support >>>>>>>>>>> >>>>>>>>>>> <*> ebt: broute table support >>>>>>>>>>> >>>>>>>>>>> <*> ebt: filter table support >>>>>>>>>>> >>>>>>>>>>> <*> ebt: nat table support >>>>>>>>>>> >>>>>>>>>>> <*> ebt: 802.3 filter support >>>>>>>>>>> >>>>>>>>>>> <*> ebt: MPLS target support >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3. >>>>>>>>>>> >>>>>>>>>>> In Networking Options select QoS and fair queueing >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks & Regards >>>>>>>>>>> >>>>>>>>>>> Bhartendu M. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Conexant E-mail Firewall (Conexant.Com) made the following annotations >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> ********************** Legal Disclaimer **************************** >>>>>>>>>>> >>>>>>>>>>> "This email may contain confidential and privileged material for the >>>>>>>>>>> >>>>>>>>>> sole use of the intended recipient. Any unauthorized review, use or >>>>>>>>>> distribution by others is strictly prohibited. If you have received the >>>>>>>>>> message in error, please advise the sender by reply email and delete the >>>>>>>>>> message. Thank you." >>>>>>>>>> >>>>>>>>>>> ********************************************************************** >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>>> This SF.net email is sponsored by: Microsoft >>>>>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpls-linux-general mailing list >>>>>>>>>>> mpl...@li... >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> James R. Leu >>>>>>>>>> jl...@mi... >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------- >>>>>>>>>> This SF.net email is sponsored by: Microsoft >>>>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls-linux-general mailing list >>>>>>>>>> mpl...@li... >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> ------------------------------------------------------------------------- >>>>>>>> This SF.net email is sponsored by: Microsoft >>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpls-linux-general mailing list >>>>>>>> mpl...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general >>>>>>>> >>>>>>> -- >>>>>>> Christopher Robson >>>>>>> Senior Computer Scientist, GS-15 >>>>>>> Naval Research Laboratory >>>>>>> Center for Computational Science >>>>>>> Networking, Code 5591 >>>>>>> 4555 Overlook ave. >>>>>>> Washington, D.C. 20375-5320 >>>>>>> (COM) 202-404-3138 >>>>>>> (VoIP) 2024043138@GIGEF >>>>>>> (CHAT) Chris.Robson@GIGEF >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> This SF.net email is sponsored by: Microsoft >>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>>> _______________________________________________ >>>>>>> mpls-linux-general mailing list >>>>>>> mpl...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general >>>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.net email is sponsored by: Microsoft >>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> mpls-linux-general mailing list >>>>>> mpl...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general >>>>>> >>>>> -- >>>>> Christopher Robson >>>>> Senior Computer Scientist, GS-15 >>>>> Naval Research Laboratory >>>>> Center for Computational Science >>>>> Networking, Code 5591 >>>>> 4555 Overlook ave. >>>>> Washington, D.C. 20375-5320 >>>>> (COM) 202-404-3138 >>>>> (VoIP) 2024043138@GIGEF >>>>> (CHAT) Chris.Robson@GIGEF >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> mpls-linux-general mailing list >>>> mpl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general >>>> >>> -- >>> Christopher Robson >>> Senior Computer Scientist, GS-15 >>> Naval Research Laboratory >>> Center for Computational Science >>> Networking, Code 5591 >>> 4555 Overlook ave. >>> Washington, D.C. 20375-5320 >>> (COM) 202-404-3138 >>> (VoIP) 2024043138@GIGEF >>> (CHAT) Chris.Robson@GIGEF >>> >>> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mpls-linux-general mailing list >> mpl...@li... >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general >> > > -- > Christopher Robson > Senior Computer Scientist, GS-15 > Naval Research Laboratory > Center for Computational Science > Networking, Code 5591 > 4555 Overlook ave. > Washington, D.C. 20375-5320 > (COM) 202-404-3138 > (VoIP) 2024043138@GIGEF > (CHAT) Chris.Robson@GIGEF > -- James R. Leu jl...@mi... |
