Hello,
somewhere in an old document (CatOS) it states the problem:
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008013565f.shtml
Known Limitations of VACLs and PVLANs
Unicast Reverse Path Forwarding (uRPF) does not work well with PVLAN host
ports, so uRPF must not be used in combination with PVLAN.
There is a fix to this problem, which is achieved by means of VACLs
configured on the primary VLANs. The case study provides the VACLs that
need to be configured on the primary VLAN to drops the traffic originated
by the same subnet and routed back to the same subnet.
Hope this is helpful
Regards,
John
On Wed, 3 Mar 2010, Pavel Skovajsa wrote:
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/
_______________________________________________
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/
