WRT54GC v2.0 - UDP Traffic issue

Hi, i've bought last week the wireless router WRT54GC v2.0 and it works good for normal navigation, port forwarding, wireless signal, ecc...
I've only a problem, a big problem, it can't handle high UDP traffic, this issue can be experienced, e.g. with Kad network of eMule. I can connect to Kad and i'm not firewalled, but if i try to search something, the search results are always empty or almost empty. If i made the same search connecting with my ISP router it works fine.
I tried with both wireless and wired connection from WRT54GC and the result is the same, so it's not a wireless problem. I tried to disable firewall, playing with settings, using DMZ o port triggering. The result was the same. I've updated the firmware to version 1.01.0 too.
Is there a solution for this problem??
Sorry for my english
Message Edited by RedKite on 08-31-2008 02:39 AM

I am not sure about the workwround ... however you can try filtering the UDP packets that are incoming .....

Similar Messages

Routing non-TCP/UDP traffic while using FWLB on CSS 11503s

Hello all,
I've been tasked to setup up FWLB with CSS 11503's as shown below. The issue is that intranet workstations use VPN client software when connecting to certain sites through the Internet and other times they use http or https (for connection to different sites). Because no flow is setup for ipsec and ECMP uses per packet routing for non TCP/UDP traffic, I'm concerned that load balancing through the firewalls will occur on a per packet basis. If that is true, stateful inspection in the firewalls will block asymmetrical traffic flows.
Is my understanding correct? And, if so, is there a way to configure the CSS units to deal with this?
Thanks in advance.
(sorry for the dots in the drawing but the spaces kept getting deleted)
.| Internet |
..........|
.| CSS-outside |
.............|
........|...............|
.| FW1 |.....| FW2 |
.......|................|
............|
.| CSS-inside |
............|
.| Intranet |

for non-flowy traffic like IPSEC, we use a hash algorithm to decide where to send the traffic.
So, it's not per packet loadbalancing.
The same source/destination ip/port will always go to the same firewall.
Gilles.

Doesn't Managed Server's sip channel support udp traffic by default ?

Hi All,
I am new to the WebLogic Server. I have tried to set up a Managed Server via an AdminConsole of BEA WebLogic 9.2.
My configurations in config.xml are as shown below. In the AdminConsole, I could startup the Managed Server successfully. However, when I generated a SIP message (to the listening port of Managed Server, which is 5068) using sipp, the Managed Server could not receive the sip message.
When, I used "netstat -a" to check listening ports. It showed that the Managed Server (Server-5) listened on tcp port 5068 but NOT on udp port 5068. And, since my sipp generated a sip message to udp port 5068, the Managed Server could not obtain the sip message.
I read the online document and it states that when a channel is created for a server, it will automatically support both tcp and udp traffic. Therefore, from my understanding, the Managed Server should automatically listen on both udp and tcp port when it starts up. In fact, I have checked that my Admin Server listens on both udp port and tcp port (in this case, port 5060).
I doubt that I may miss something in the configuration of the Managed Server. I woud be appreciated if someone could enlighten me up.
Kind Regards,
Kirati
<server>
<name>Server-5</name>
<machine>Machine-0</machine>
<listen-port>7007</listen-port>
<web-server>
<web-server-log>
<number-of-files-limited>false</number-of-files-limited>
</web-server-log>
</web-server>
<listen-address>10.252.8.241</listen-address>
<network-access-point>
<name>Channel-8</name>
<protocol>sip</protocol>
<listen-address>10.252.8.241</listen-address>
<public-address>10.252.8.241</public-address>
<listen-port>5068</listen-port>
<public-port>5068</public-port>
<http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
<tunneling-enabled>false</tunneling-enabled>
<outbound-enabled>true</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
</network-access-point>
</server>
Edited by: user10871458 on Jan 30, 2009 1:17 AM

I have found an answer to my question.
I simply forgot to load a sip-container service to my new created server..

UDP traffic analyzed in L4 traffic monitor?

Dear all,
I just wonder if anyone knows whether UDP traffic is analyzed by the WSA's L4 traffic monitor?
It just tells "all ports" in the settings and reports also only reflect port numbers but no details like
which protocol (tcp/udp).
Anyone?
Best,
Hascha

UDP ports will not be blocked.
The L4TM will use the T1 interface to detect traffic to destinations that are on its blacklist. Once detected, the the data interface on the WSA will send a packet with the TCP reset flag to the client to prevent a TCP connection.
I have not tested this so someone correct me if I am wrong. I am answering this based on my understanding of the L4TM feature, and how it works. Since UDP is connectionless, there is no connection for it to kill.
Now this makes me wonder about the Monitor feature though. But I am almost certain it will not block if the action is set to block.
I'll check this out when I'm in the office and will get back to you.
-Vance

Outside-PAT all UDP traffic, but exclude DNS

8.4(3)
I need to outside PAT all incoming UDP (SIP/RTP) traffic from outside to an internal IP. The following command makes it work:
nat (outside,inside) source dynamic any obj-10.0.0.173 service udp udp
But it breaks DNS resolution from inside. If I add the above command and try to nslookup from inside to an outside DNS server
64.90.175.90, DNS times out. If I remove the above nat command, it works again. It seems like even though DNS UDP originates from inside which should create a statefull connection, ASA still messes with return DNS responses.
I then tried to create an "exclusion" for that IP with the following:
object-group network nat-exclusions
network-object host 64.90.175.90
nat (outside,inside) source static nat-exclusions nat-exclusions
but it's not working.
I also tried:
nat (outside,inside) source static nat-exclusions nat-exclusions unidirectional
Also not working.
Any suggestions? How can outside-PAT all UDP traffic excluding DNS.

TAC was able to help. I needed this:
object network exclusions
host 64.90.175.90
nat (inside,outside) source dynamic any interface destination static exclusions exclusions
nat (outside,inside) source dynamic any obj-10.0.0.173 service udp udp

WISM Blocking UDP traffic

I am having a problem with the WISM blade blocking UDP traffic on port 6001. This is for a Sentinel Hardware Key. The software sends out a UDP request but it appears that the controller just drops it. I have tried an explicit permit ACL on this network for all UDP traffic. This did not work either. This software work fine on the wire. Anyone else seen this?

All layer two broadcasts (FF:FF:FF:FF:FF:FF) are stopped at the WISM. This is a function of the controller. I found a white paper from Cisco stating this. The hardware key I was trying to use, utilized a layer two broadcast and it was stopped at the controller. There were no ACL's present when I started testing. I even tried it with an allow all ACL just to make sure.

RV016 (V3) tcp and udp outgoing traffic issue

Hi everyone.
I've got a CISCO RV016 connected to a tooway SAT modem and need to reach another router connected in DSL
I need to make a TCP connection on port 8080 with my audio codec to reach the other side, and get audio.
I do not feel comfortable with all the security process, firewall, forwarding port and so on ...
What do I need to do to make the RV016 let the TCP out ?
do I need to create rules ? do I need to modify the firewall factory settings ?
does UDP outgoing traffic need some rules too ?
Thank's for your help.
Nicolas.
System Information
Serial Number : NKS16450006
Firmware Version : v4.2.1.02 (Jan 18 2012 14:10:55)
PID VID : RV016 V03
Firmware MD5 Checksum : a9817f2dbdcbd6a5c109eaa21b1c3545
LAN Working Mode : Gateway

Hi Nicolas, thank you for using our forum, my name is Johnnatan I am part of the Small business Support community. If you want other method instead forwarding I could advise you One-to-one NAT. I will share a document to you regarding this configuration.
http://www6.nohold.net/CiscoSB/Loginr.aspx?login=1&pid=2&app=search&vw=1&articleid=544
I hope you find this answer useful
“Please rate useful posts so other users can benefit from it”
Greetings,
Johnnatan Rodriguez Miranda.
Cisco Network Support Engineer.

IPSLA UDP-Jitter Issues

Hi guys,
Our customer has a WAN network (DCoS) and has voice protected across it. I work for an integrator assisting the customer with their CPE routers end-to-end. Essentially CPE routers extend PSTN lines end-to-end over voice-ports and voip call legs between locations. On CPE routers we're seeing voice traffic being marked/matched end-to-end. We're pretty sure that the ISP is somehow shaping/causing delays on the voice traffic interstate but now we're trying to gather some evidence.
To help isolate, test and provide evidence we were planning on using UDP-Jitter in IP SLA. I've been trying to get this enabled on live routers without success due to the reason "No connection" in the initiators show output. An example of the "show ip sla statistics" on a production device is shown below:
SITE-1#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Type of operation: udp-jitter
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 17:26:47 BNE Mon Jul 2 2012
Latest operation return code: No connection
RTT Values:
        Number Of RTT: 0                RTT Min/Avg/Max: 0/0/0 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 0
        Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 0
        Number of DS Jitter Samples: 0
        Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds
Packet Loss Values:
        Loss Source to Destination: 0
        Source to Destination Loss Periods Number: 0
        Source to Destination Loss Period Length Min/Max: 0/0
        Source to Destination Inter Loss Period Length Min/Max: 0/0
        Loss Destination to Source: 0
        Destination to Source Loss Periods Number: 0
        Destination to Source Loss Period Length Min/Max: 0/0
        Destination to Source Inter Loss Period Length Min/Max: 0/0
        Out Of Sequence: 0      Tail Drop: 0
        Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 0
Number of failures: 1
Operation time to live: Forever
Number of failures continues to increase every 30 seconds or so. The configuration of SITE-1 is as follows:
SITE-1#show run | sec ip sla
ip sla 100
udp-jitter 10.2.2.2 16584 source-ip 10.1.1.1 source-port 16384
tos 30
owner NetFlow
timeout 60000
ip sla schedule 100 life forever start-time now
The configuration of SITE-2 (IP SLA Responder) is as follows:
SITE-2#show run | sec ip sla
ip sla responder
For the sake of privacy I've adjusted the IPs above as well as the router hostnames. The 10.2.2.2 IP lives on SITE-2's router and 10.1.1.1 lives on SITE-1's router.
If I do the above in GNS it works perfectly so I think something else is going on here. Either I've got a bug (doubt it) or something is preventing the UDP from connecting/responding for the IP SLA. Frustratingly, if I do a "show ip sla responder" on the SITE-2 router... it says it received the packets normally without error:
SITE-2#show ip sla responder
        General IP SLA Responder on Control port 1967
General IP SLA Responder is: Enabled
Number of control message received: 123 Number of errors: 0
Recent sources:
        10.1.1.1 [18:06:35.989 BNE Mon Jul 2 2012]
        10.1.1.1 [18:06:30.989 BNE Mon Jul 2 2012]
        10.1.1.1 [18:06:25.989 BNE Mon Jul 2 2012]
        10.1.1.1 [18:05:35.989 BNE Mon Jul 2 2012]
        10.1.1.1 [18:05:30.989 BNE Mon Jul 2 2012]
Recent error sources:
        Permanent Port IP SLA Responder
Permanent Port IP SLA Responder is: Enabled
udpEcho Responder:
IP Address             Port
If I enable trace debug ("debug ip sla trace") on SITE-1's router I get the following...
Jul 2 08:13:25.993: IPSLA-INFRA_TRACE:OPER:100 slaSchedulerEventWakeup
Jul 2 08:13:25.993: IPSLA-INFRA_TRACE:OPER:100 Starting an operation
Jul 2 08:13:25.993: IPSLA-OPER_TRACE:OPER:100 Starting jitter operation
Jul 2 08:13:25.993: IPSLA-OPER_TRACE:OPER:100 Ctrl msg: id=116, type=1, len=52, dest_ip=10.2.2.2, enablePort=16584, duration=60200
Jul 2 08:13:25.993: IPSLA-OPER_TRACE:OPER:100 table_id=0, topo_id=65535
Jul 2 08:13:30.993: IPSLA-OPER_TRACE:OPER:100 Timeout
Jul 2 08:13:30.993: IPSLA-OPER_TRACE:OPER:100 Ctrl msg: id=117, type=1, len=52, dest_ip=10.2.2.2, enablePort=16584, duration=60200
Jul 2 08:13:30.993: IPSLA-OPER_TRACE:OPER:100 table_id=0, topo_id=65535
Jul 2 08:13:35.993: IPSLA-OPER_TRACE:OPER:100 Timeout
Jul 2 08:13:35.993: IPSLA-OPER_TRACE:OPER:100 Ctrl msg: id=118, type=1, len=52, dest_ip=10.2.2.2, enablePort=16584, duration=60200
Jul 2 08:13:35.993: IPSLA-OPER_TRACE:OPER:100 table_id=0, topo_id=65535
Jul 2 08:13:40.993: IPSLA-OPER_TRACE:OPER:100 Timeout
Jul 2 08:13:40.993: IPSLA-OPER_TRACE:OPER:100 No connection
Jul 2 08:13:40.993: IPSLA-INFRA_TRACE:OPER:100 Updating result

Checked the ports and found I am using different ones on each VoIP gateway. I just added a new operation with a totally unique port that I know is not in use on the source or destination and it still failed:
voipgw02(config)#ip sla 4033
voipgw02(config-ip-sla)# udp-jitter 10.205.50.5 17333 source-ip 10.225.50.5 codec g711ulaw codec-numpackets 100
voipgw02(config-ip-sla-jitter)# tos 184
voipgw02(config-ip-sla-jitter)# timeout 18000
voipgw02(config-ip-sla-jitter)# threshold 1000
voipgw02(config-ip-sla-jitter)# frequency 30
voipgw02(config-ip-sla-jitter)#ip sla schedule 4033 life forever start-time now ageout 3600
voipgw02#sh ip sla stat
IPSLAs Latest Operation Statistics
IPSLA operation id: 4033
Type of operation: udp-jitter
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 21:47:43 EDT Mon Sep 3 2012
Latest operation return code: No connection
RTT Values:
        Number Of RTT: 0                RTT Min/Avg/Max: 0/0/0 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 0
        Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 0
        Number of DS Jitter Samples: 0
        Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds
Packet Loss Values:
        Loss Source to Destination: 0
        Source to Destination Loss Periods Number: 0
        Source to Destination Loss Period Length Min/Max: 0/0
        Source to Destination Inter Loss Period Length Min/Max: 0/0
        Loss Destination to Source: 0
        Destination to Source Loss Periods Number: 0
        Destination to Source Loss Period Length Min/Max: 0/0
        Destination to Source Inter Loss Period Length Min/Max: 0/0
        Out Of Sequence: 0      Tail Drop: 0
        Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 0
Number of failures: 1
Operation time to live: Forever
Do you know if there are any licensing issues?
barvoipgw02#show ip sla appl
        IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-III
Supported Operation Types:
        icmpEcho, path-echo, path-jitter, udpEcho, tcpConnect, http
        dns, udpJitter, dhcp, ftp, VoIP, rtp, icmpJitter
        802.1agEcho VLAN, Port, 802.1agJitter VLAN, Port, udpApp
        wspApp
Supported Features:
        IPSLAs Event Publisher
IP SLAs low memory water mark: 63126085
Estimated system max number of entries: 46234
Estimated number of configurable operations: 39313
Number of Entries configured : 3
Number of active Entries      : 3
Number of pending Entries     : 0
Number of inactive Entries    : 0
Time of last change in whole IP SLAs: .21:47:43.954 EDT Mon Sep 3 2012

Low-latency prio queue for udp traffic, but not matching ACL?

Hi,
I have an OpenVPN service running behind an ASA for which I would like to prioritize the packets.
The OpenVPN service connects to a remote OpenVPN service on 1194/udp, and accepts traffic on udp/1194 for yet another OpenVPN server.
Here's what I did:
access-list priority extended permit udp any any eq 1194
priority-queue outside
class-map priotraffic
match access-list priority
policy-map QoS_policy
class priotraffic
priority
service-policy QoS_policy global
priority-queue outside
I know there are hundreds of packets per second on this OpenVPN, but still I only see 2 matched packets on the ACL "priority":
# show access-list | inc priority
access-list priority line 1 extended permit udp any any eq 1194 (hitcnt=2) 0xbbdd01d4
Am I missing something? Must I know both src AND destination ports in order to achieve this?

I started suspecting that it only matched packets for new connections (in iptables called NEW / UNREPLIED). I tested my thesis by restarting one of my openvpn tunnels, and indeed I see now a hit count of one packet.
Question is, how come only new udp connections being matched? I would obviously like to prioritize all packets for an already established session.
Thanks,
By the way, the statistics after I reinitiated one of the tunnels:
asa# show access-list | inc priority
access-list priority line 1 extended permit udp any any eq 1194 (hitcnt=1) 0xbbdd01d4
asa# show service-policy
Global policy:
Service-policy: QoS_policy
    Class-map: priotraffic
      Priority:
        Interface outside: aggregate drop 0, aggregate transmit 0
      Priority:
        Interface inside: aggregate drop 0, aggregate transmit 0
      Priority:
        Interface mobenga: aggregate drop 0, aggregate transmit 0
      Priority:
        Interface escom: aggregate drop 0, aggregate transmit 0
      Priority:
        Interface management: aggregate drop 0, aggregate transmit 0
      Priority:
        Interface server: aggregate drop 0, aggregate transmit 0
      Priority:
        Interface vpn: aggregate drop 0, aggregate transmit 0
      Priority:
        Interface cafe_member: aggregate drop 0, aggregate transmit 0
    Class-map: class-default

Server 2k8 r2: UDP traffic from over 30K IPs causing tcpip.sys to contend on spinlocks resulting in 1/2 second DPCs. Works fine in Win2k3.

We have a UDP server that accepts many connections. In Win2k3 it can talk to anywhere from 90K to 120K IP addresses with no problem.
On Win2k8R2 it throttles and often tips over at 30K users.
I have xperf logs showing the problems. DPCs start out taking reasonable amounts of time, but eventually grow to take half a second upwards of 3/4 of a second; at that point the network stack seems to tip over and start again.
I've appended some of the xperf data. I don't see a way to provide an attachment.
The nic is the Intel 82576 with only one link active. Again - same code same hardware runs fine on win2k3.
There are various routes to it, but huge swaths of code always end up in: NDIS.SYS!NdisAcquireReadWriteLock.
I would assume on the same lock, and I would guess it's a spin lock since it spends all its time in ntkrnlmp.exe!KeAcquireSpinLockAtDpcLevel.
In our sample the process had a weight of 540,714 units. Of that at least 210,597 ended up trying to acquire that lock via WSASendTo. Gory details appended.
From the DPC view, you can see the calls that were taking 1/2 a second or longer. There are 110 of them in a 37 second sample. The time to process varies randomly and there are many thousands in between. This is appended as the second set
of voluminous data.
OS is Win2k R2 SP1
The Intel 82576 NIC has the latest available drivers
I've already tried altering just about every network parameter to observe the results. RSS enabled/disabled. RSS NIC configured for 1 or more CPUs. Various timings for Interrupt deferral, etc...
The net effect of all this was that I could move the shape of the curves, and even stop the network from tipping over entirely; however the DPC times are still awful; the spinlocks are still spinning and the net throughput is still 1/4 of Win2k3.
Any suggestions? What's the next step?
Joe
Stack
Weight
% Weight
Count
| | | | | |- ws2_32.dll!WSASendTo
210597.1896
5.33
210735
| | | | | | |- mswsock.dll!WSPSendTo
210222.4585
5.32
210356
| | | | | | | |- ntdll.dll!ZwDeviceIoControlFile
209948.2971
5.31
210079
| | | | | | | | ntdll.dll!LdrInitializeThunk
209948.2971
5.31
210079
| | | | | | | | ntdll.dll! ?? ::FNODOBFM::`string'
209948.2971
5.31
210079
| | | | | | | | wow64.dll!Wow64LdrpInitialize
209948.2971
5.31
210079
| | | | | | | | wow64.dll!RunCpuSimulation
209948.2971
5.31
210079
| | | | | | | | wow64cpu.dll!DeviceIoctlFileFault
209948.2971
5.31
210079
| | | | | | | | wow64cpu.dll!CpupSyscallStub
209948.2971
5.31
210079
| | | | | | | | |- ntkrnlmp.exe!KiSystemServiceCopyEnd
209865.9437
5.31
209996
| | | | | | | | | |- ntkrnlmp.exe!NtDeviceIoControlFile
209861.9414
5.31
209992
| | | | | | | | | | |- ntkrnlmp.exe!IopXxxControlFile
209856.0089
5.31
209986
| | | | | | | | | | | |- afd.sys!AfdFastIoDeviceControl
209456.9132
5.3
209583
| | | | | | | | | | | | |- afd.sys!AfdFastDatagramSend
209323.6618
5.3
209448
| | | | | | | | | | | | | |- afd.sys!AfdTLFastDgramSend
208405.7464
5.27
208521
| | | | | | | | | | | | | | |- tcpip.sys!UdpTlProviderSendMessages
208270.0504
5.27
208384
| | | | | | | | | | | | | | | |- ntkrnlmp.exe!KeExpandKernelStackAndCalloutEx
208216.8802
5.27
208330
| | | | | | | | | | | | | | | | |- tcpip.sys!UdpTlProviderSendMessagesCalloutRoutine
208164.7757
5.27
208277
| | | | | | | | | | | | | | | | | |- tcpip.sys!UdpSendMessages
208158.8001
5.27
208271
| | | | | | | | | | | | | | | | | | |- tcpip.sys!UdpSendMessagesOnPathCreation
204713.1138
5.18
204823
| | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAleFastUdpInspection
127845.6429
3.23
127912
| | | | | | | | | | | | | | | | | | | | |- NDIS.SYS!NdisAcquireReadWriteLock
127041.047
3.21
127099
| | | | | | | | | | | | | | | | | | | | |- ntkrnlmp.exe!RtlLookupEntryHashTable
264.272245
0.01
267
| | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAleFastUdpInspection<itself>
171.42808
0
173
| | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAlepIsSameEndpoint
131.641229
0
133
| | | | | | | | | | | | | | | | | | | | |- netio.sys!WfpRefreshEntryLru
125.181435
0
126
| | | | | | | | | | | | | | | | | | | | |- tcpip.sys!memset
39.508324
0
40
| | | | | | | | | | | | | | | | | | | | |- netio.sys!KfdIsLayerEmpty
30.500205
0
31
| | | | | | | | | | | | | | | | | | | | |- netio.sys!KfdGetLayerCacheEpoch
18.334937
0
19
| | | | | | | | | | | | | | | | | | | | |- NDIS.SYS!NdisReleaseReadWriteLock
15.799406
0
16
| | | | | | | | | | | | | | | | | | | | |- ntkrnlmp.exe! ?? ::FNODOBFM::`string'
3.992942
0
4
| | | | | | | | | | | | | | | | | | | | |- tcpip.sys!KfdIsLayerEmpty
3.937052
0
4
| | | | | | | | | | | | | | | | | | | |- tcpip.sys!IpNlpFastSendDatagram
63245.49252
1.6
63271
| | | | | | | | | | | | | | | | | | | | |- tcpip.sys!IppSendDatagramsCommon
62205.09904
1.57
62216
| | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpProcessOutTransportStackIndication
61667.95687
1.56
61676
| | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!ProcessALEForTransportPacket
61615.13818
1.56
61623
| | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAleMatchStatefulEndpoint
50338.28726
1.27
50346
| | | | | | | | | | | | | | | | | | | | | | | | |- NDIS.SYS!NdisAcquireReadWriteLock
50260.6444
1.27
50268
| | | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAleMatchStatefulEndpoint<itself>
31.797626
0
32
| | | | | | | | | | | | | | | | | | | | | | | | |- ntkrnlmp.exe!RtlLookupEntryHashTable
20.90588
0
21
| | | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAlepIsSameEndpoint
8.997452
0
9
| | | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!memset
8.940707
0
9
| | | | | | | | | | | | | | | | | | | | | | | | |- netio.sys!WfpRefreshEntryLru
2.999293
0
3
| | | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!_security_check_cookie
2.001804
0
2
| | | | | | | | | | | | | | | | | | | | | | | | |- NDIS.SYS!NdisReleaseReadWriteLock
2.000098
0
2
| | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAleConnectAcceptIndicate
11225.06641
0.28
11225
| | | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAleAuthorizeSend
11219.07252
0.28
11219
| | | | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAlepAuthorizeSend
11208.09459
0.28
11208
| | | | | | | | | | | | | | | | | | | | | | | | | | |- tcpip.sys!WfpAleInsertRemoteEndpoint
11035.14208
0.28
11035
| | | | | | | | | | | | | | | | | | | | | | | | | | | |- NDIS.SYS!NdisAcquireReadWriteLock
10873.02754
0.28
10873
DPC Raw Info:
Function
Count
Max Actual Duration (ms)
ndisInterruptDpc
554751
713.847
1
713.847
1
708.4239
1
677.1281
1
672.813
1
672.2575
1
660.812
1
660.0321
1
655.2213
1
647.1885
1
641.3311
1
632.4002
1
622.6813
1
621.7657
1
620.5844
1
617.5036
1
615.4015
1
610.9474
1
606.8938
1
604.7577
1
594.5486
1
587.6109
1
581.5086
1
580.0222
1
579.7739
1
576.6219
1
576.4333
1
575.1572
1
574.4537
1
574.1743
1
573.7621
1
560.8745
1
559.7798
1
557.8415
1
557.8143
1
557.5373
1
553.3025
1
553.172
1
550.6415
1
549.8416
1
549.612
1
549.5203
1
548.3752
1
548.0821
1
547.8116
1
547.4588
1
547.2672
1
545.9869
1
544.6088
1
544.3772
1
542.6019
1
542.4782
1
542.2717
1
542.2666
1
542.2051
1
540.3364
1
538.9678
1
538.8142
1
538.3009
1
537.85
1
535.7837
1
534.7581
1
534.7572
1
532.4798
1
532.2034
1
532.0741
1
531.8791
1
530.7899
1
529.894
1
528.7522
1
527.006
1
526.6041
1
526.3972
1
525.4709
1
525.351
1
524.2444
1
522.7439
1
521.5258
1
520.562
1
520.4451
1
518.5009
1
517.4765
1
517.375
1
517.282
1
512.0087
1
511.5543
1
511.5373
1
510.6021
1
509.3328
1
508.7159
1
507.1279
1
505.7661
1
505.1325
1
504.612
1
501.9754
1
501.9476
1
501.94
1
500.7436
1
500.625
1
500.5376
1
499.567
1
499.5614
1
499.36
1
499.2837
1
499.0861
1
499.0537
1
498.7743
1
498.4466
1
498.3967
1
496.5591
1
495.4409
Joe Rohde

Hi Joe,
The issue can be checked only by dump file. In this scenario, we may have to capture the dump file and MPS reports to analysis. I am afraid
that your issue falls into the paid support category which requires a more in-depth level of support. Please visit the below link to see the various paid support options that are available to better meet your needs.
http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone
Thanks for your understanding and efforts with the issue.
Annie

C897-VA-K9 Version 15.2(4)M6dialer 0 interface high gig outbound traffic issue

Hi i have recently upgraded one of my branch office router from C876 to C897-VA-K9, and after 1 week i deployed the new router i started to see 1 gbps + traffic in my dialer 0 interface outbound in my MRTG. and after i restarted the router the graph looks normal for 5 to 6 days and detects gig traffic and the graph keeps moving up from 1 gbps+ to 2gbps + and so on and keeps up until restarted.
1# sh int dialer 0
Dialer0 is up, line protocol is up (spoofing)
Hardware is Unknown
Description: Internet - Internode -
Internet address is x.x.x.x/24
MTU 1500 bytes, BW 56 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 255/255, rxload 255/255
Encapsulation PPP, LCP Closed, loopback not set
Keepalive set (10 sec)
DTR is pulsed for 1 seconds on reset
Interface is bound to Vi2
Last input never, output never, output hang never
Last clearing of "show interface" counters 3d02h
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 1382000 bits/sec, 152 packets/sec
5 minute output rate 2309042000 bits/sec, 74 packets/sec
     4640078 packets input, 46025807702 bytes
     4174133 packets output, 76966587324883 bytes
So far i haven't been able to figure out the issue, i did shared the issue with my provider as per them there is nothing unusual in our usage. Looking after my issue it look like bug i tried identical c897-VA-K9 router have same issue but yet unable to find bug info for the series of router in cisco.
Appreciate your prompt help and suggestion.
Regards
khagen
really appreciate if you can share any re

Node Bandwidth is 8 Mbps.
virtual-Access2 interface, it gives exact traffic information. that made me feel there is something wrong with dialer 0 interface.
but want to know what is causing such unusual outbound throughput in dialer interface. is it bug on the router hardware or software?

Network Load Balancing not working with UDP traffic (Server 2012)

Hi all,
I manage an application that receives traffic from mobile devices on cellular networks. The traffic is UDP. I have set up two x Server 2012 VMs to form part of a NLB cluster. Each server has a second NIC dedicated to NLB. The traffic is simply NATed from
our firewalls to the virtual IP. When looking at the traffic using a packet sniffer, I can see the traffic being routed correctly to the virtual IP, but the problem is that the return traffic is sent from the IP address on the actual NIC. My application does
not like the fact that the return traffic is coming from a different source IP. Is there any way to force the return traffic to also come from the virtual IP address?
Thanks!

Hi
NLB return traffic for UDP would come from the node IPs.
You could use NAT on your firewalls so they come from the same public IP.
Otherwise you'd be looking at something other than MS NLB.
Cheers
GF

Bypassing Firewall With UDP Traffic

I have a real time 2d game networked over UDP port xxxx. Performance is an issue. The game works great without lag, however to connect to the server, the client must forward port xxxx on their router to their computer. Is there any way around this without gaining latency? I have heard that maybe changing it to UDP port 80 might work? Or TCP 80? Or use the HTTP protocol?
It would be nice if it wasn't necessary to reprogram it to TCP.
Thank you for the help.

From what little I know it looks like UPnP provides a standardized way to communicate with the router to tell it which ports you want forwarded to which internal IP/port (it does many other things as well).
This might be worth investigating for you.

CSM 4.2 Service per packet for udp traffic

Hi,
We have a problem with the predictor round robin. We have to balance traffic UDP with the same source IP and PORT. Round robin algorithm use the same server for all the traffic as well as see the same source address. We use the service per packet option, but if we use this the nat server doesn't work? It is possible?
Thanks
Ira

if you do per-packet the csm does not create a flow entry, so when the server response comes back from the server ip, the CSM is unable to map it to the vserver.
So your servers need to be configured with the same loopback ip address which will be the same as the vserver ip address.
The servers need to be directly connected to the CSM [no next-hop] so the CSM can forward traffic without changing destination ip.
Another solution instead of per-packet, would be to reduce the idle timeout to a minimum, so the CSM removes the flow entry earlier and permit the next packet to be loadbalanced to a diffirent server.
Regards,
Gilles.

UDP traffic not hitting ACL when logged

2821 ISR
I've got a DAPE ACL I'm trying to build. One of the entries that caused a lot of problems was permitting NTP (UDP 123). I had an entry like this on an ACL:
permit udp <my.src.lan.ip> 0.0.0.255 host <our.external.NTP.server> log
This line did not get any hits, and NTP updates were failing on our Windows clients. (the final line is a deny ip any any)
I changed this line to read:
permit udp <my.src.lan.ip> 0.0.0.255 host <our.external.NTP.server>
Note that the only difference is that I'm not logging this line.
Once change, I saw hits on this line, and NTP updates on our Windows clients suddenly started going through and working.
Is this normal behavior? I can't see why logged ACL entries would make them fail to get picked up and let through.

Hello.
I believe the entry is not interface ACL, but NAT ACL.
"log" keyword is not supported inside NAT ACLs, that is why you observed connectivity issue.

WRT54GC v2.0 - UDP Traffic issue

Similar Messages

Maybe you are looking for