WCS SNMP Communications over PAT, Fragmentation Issues

Unanswered Question
Aug 10th, 2007

I'm currently researching an issue we have with SNMP communications between Wireless Control System (WCS) and remote Wireless LAN Controllers (WLC) (WLC-NM with 2811 router) in which when Port Address Translation (PAT) is used the Getbulk SNMP requests from the WCS ends in the WLC responses becoming fragmented and only a partial response being recieved by the WCS. That being the first part of the fragmentation and the second part being dropped at the router FE interface.

Has anyone else come across this issue? Or may be problems with SNMP getbulk requests over NAT/PAT in general?

Regards,

Mick

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
steve.busby Sat, 08/11/2007 - 06:37

Mick,

I'm not sure how your NAT/PAT is setup, or what device is performing NAT/PAT, but SNMP by default uses UDP for it's transport. To make this work you would need use NAT (no PAT) with static entries for both your WCS and WLC(s).

HTH

Steve

SLB_Mick_Shaw Mon, 08/13/2007 - 10:52

Thanks Steve. Appreciate your response.

We're remotely connecting the WLC and WCS via an IPSEC VPN through the internet and as such the 2811 router FE interface has NAT applied.

We are using PAT for SNMP requests bound for the inside WLC-NM address/interface on port 161 as we can't address the router FE interface directly to issue commands to the WLC. Configured as follows:

ip nat inside source static udp 10.x.x.x 161 interface FastEthernet0/0 161

ip nat inside source static udp 10.x.x.x 162 interface FastEthernet0/0 162

What we're finding is that the requests and responses do occur but when a GetBulk request is issued that response is fragmented and only the first part of the packet transmitted over the NAT interface, the second part of the packet appears to be dropped at the ingress as shown below:

508678 packets input, 124903074 bytes

Received 271751 broadcasts, 109 runts, 0 giants, 0 throttles

4556 input errors, 4446 CRC, 0 frame, 0 overrun, 1 ignored

0 watchdog

0 input packets with dribble condition detected

358124 packets output, 47031975 bytes, 0 underruns

0 output errors, 62 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Anyone know how to get round this or have come across this before?

Actions

This Discussion