[c-nsp] PVLAN and trunks (for redundancy and more bandwidth), any idea?

[Pavel Skovajsa]

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 <sven at 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-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>