Hello all, just to follow up on this, I had exactly the same issue as Sven and opened a TAC case. The result is CSCso63119 [1]
In short -> a bug in strict mode uRPF in combination with PVLANs punts packets to CPU where they die screaming&horrible death on the MLS rate-limiter. The only workaround is to change to loose uRPF. <quote> "This bug has a Minor severity 4 designation. Things fail under very unusual circumstances but operation essentially recovers without intervention. Users don't necessarily need to install any workarounds, and performance impact is tolerable" </quote> Now, I while I understand that bugs in software exist, I do not necessarily agree with the Severity, as my plan was to implement scrict uRPF and loose uRPF does not really pose a fully acceptable solution. Not speaking about the fact that this bug makes the performance untollerable. Therefore - does somebody know whether there is any way to make the Severity higher? -pavel skovajsa [1] http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCso63119 On Wed, Feb 24, 2010 at 2:43 PM, Sven 'Darkman' Michels <s...@darkman.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Matt Buford schrieb: >> Have you confirmed that the problem happens to packets going through the >> switch? What you pasted before was pings originating from the switch. >> In general, I wouldn't assume that the behavior of pings to/from the >> switch are the same as packets through the switch. They take a very >> different path through the switch. >> >> For example, put one host on a non-pvlan SVI, and then put another host >> on your pvlan SVI. Do you get the same packetloss problem? > > i've tested it, again, just to be sure. The device is on the 3650 Switch > in the pvlan, 6500 does the routing and holds the svi for the pvlan. I started > pinging the testdevice which worked fine so far. Then i enabled > ip verify unicast source reachable-via rx > and got massive loss. After disableing it, the ping worked fine again: > 64 bytes from x.x.x.13: icmp_seq=50 ttl=63 time=603 usec > 64 bytes from x.x.x.13: icmp_seq=51 ttl=63 time=613 usec > 64 bytes from x.x.x.13: icmp_seq=52 ttl=63 time=616 usec > 64 bytes from x.x.x.13: icmp_seq=53 ttl=63 time=616 usec > 64 bytes from x.x.x.13: icmp_seq=54 ttl=63 time=599 usec > 64 bytes from x.x.x.13: icmp_seq=55 ttl=63 time=616 usec > - - enable - > 64 bytes from x.x.x.13: icmp_seq=58 ttl=63 time=726 usec > 64 bytes from x.x.x.13: icmp_seq=60 ttl=63 time=640 usec > 64 bytes from x.x.x.13: icmp_seq=67 ttl=63 time=667 usec > 64 bytes from x.x.x.13: icmp_seq=69 ttl=63 time=641 usec > - - disable - > 64 bytes from x.x.x.13: icmp_seq=71 ttl=63 time=642 usec > 64 bytes from x.x.x.13: icmp_seq=72 ttl=63 time=625 usec > 64 bytes from x.x.x.13: icmp_seq=73 ttl=63 time=617 usec > 64 bytes from x.x.x.13: icmp_seq=74 ttl=63 time=591 usec > 64 bytes from x.x.x.13: icmp_seq=75 ttl=63 time=574 usec > 64 bytes from x.x.x.13: icmp_seq=76 ttl=63 time=605 usec > 64 bytes from x.x.x.13: icmp_seq=77 ttl=63 time=609 usec > 64 bytes from x.x.x.13: icmp_seq=78 ttl=63 time=582 usec > > so its definitivly a problem with the verify stuff and pvlan :( > > Regards and thanks, > Sven > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkuFLOoACgkQQoCguWUBzBy88wCfXCYsR58eEM+JMUg60kQP1Vqt > sQEAoITLxOKnzAcNFDNtBS2KY1iK2w+2 > =u4HR > -----END PGP SIGNATURE----- > _______________________________________________ > cisco-nsp mailing list cisco-...@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/