My 2811 is corrupting packets

Unanswered Question
Nov 23rd, 2009

I asked a question about this last week and didn't get any replies, so I'm giving it another try.  I have a 2811 that I am using to forward multicast packets to multiple destination VLANs.  On one of these VLANs I am NATing the source IP addresses of the multicast packets.  On this interface the checksums for the UDP packets is being corrupted about 10% of the time.  About half of the corrupted packets also have the original source address instead of the NATed address.  Has anyone ever seen something like this?  I'm not used to seeing a router corrupt packets like that - usually the router either works perfectly or not at all.  I would appreciate any help the community can provide.

Patrick Griffin

CCNA

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
ougryphon Mon, 11/23/2009 - 14:49

Would have been nice if someone had replied when I posted it last week.  In any case, here's the config, edited for length.

...

interface FastEthernet0/0
ip address 192.168.11.10 255.255.255.128
ip pim dense-mode
ip nat inside
ip igmp unidirectional-link
duplex auto
speed auto
no cdp enable
!
interface FastEthernet0/1
no ip address
duplex full
speed 100
no cdp enable
no mop enabled
!
interface FastEthernet0/1.1
encapsulation dot1Q 1 native
ip address 10.82.82.10 255.255.255.0
ip helper-address 10.82.34.255
ip pim sparse-mode
no cdp enable
!
interface FastEthernet0/1.302
encapsulation dot1Q 302
ip address 10.82.32.1 255.255.255.0
ip pim dense-mode
no cdp enable
!
interface FastEthernet0/1.304
encapsulation dot1Q 304
ip address 10.82.34.1 255.255.255.0
ip directed-broadcast
ip pim sparse-dense-mode
no cdp enable
!
interface FastEthernet0/1.310
encapsulation dot1Q 310
ip address 10.82.31.1 255.255.255.0
ip pim dense-mode
ip nat outside
no cdp enable
!
router eigrp 84
network 10.82.0.0 0.0.255.255
no auto-summary
!
ip classless
ip forward-protocol udp 3012
...
ip forward-protocol udp 3007
no ip http server
ip pim send-rp-announce Loopback1 scope 16
ip pim send-rp-discovery scope 16
ip nat pool NAT-pool 10.82.1.0 10.82.1.3 prefix-length 30
ip nat inside source list NAT_sources pool NAT-pool overload
!
ip access-list standard NAT_sources
permit 10.128.0.0 0.127.255.255
!
ip access-list extended MULTICAST_ACL
permit udp any host 10.82.82.255 eq 3012
...
permit udp any host 10.82.82.255 eq 3236

Edison Ortiz Mon, 11/23/2009 - 15:06

ougryphon wrote:

I asked a question about this last week and didn't get any replies, so I'm giving it another try.  I have a 2811 that I am using to forward multicast packets to multiple destination VLANs.  On one of these VLANs I am NATing the source IP addresses of the multicast packets.  On this interface the checksums for the UDP packets is being corrupted about 10% of the time.  About half of the corrupted packets also have the original source address instead of the NATed address.  Has anyone ever seen something like this?  I'm not used to seeing a router corrupt packets like that - usually the router either works perfectly or not at all.  I would appreciate any help the community can provide.

Patrick Griffin

CCNA

If you are using wireshark/ethereal, this behavior is normal. Please refer to this URL for more information:

http://www.ethereal.com/faq.html#q11.1

Regards

Edison

Please rate helpful posts and mark the issue as resolved if this reply resolves your issue, thanks!

ougryphon Mon, 11/23/2009 - 15:16

Thank you for your suggestion, but no this is not a Wireshark TCP checksum offload error.  Even if my NIC card supported TOE, you only see those errors on packets originating from your NIC card, not in packets being received.  Also, I would be seeing errors in every packet, not random, intermittent errors.  Besides, this is more than just a problem with checksums, the router is also failing to NAT about 5-10% of the packets.

Edison Ortiz Mon, 11/23/2009 - 17:42

ougryphon wrote:

Besides, this is more than just a problem with checksums, the router is also failing to NAT about 5-10% of the packets.

Are you seeing IP addresses traversing the interface as true source?

What are you using to capture this information? Wireshark?

How is the CPU on the router?

Any errors on the main interface?

What IOS version are you running? Feature Set?

Actions

This Discussion