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

[John Kougoulos]

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 <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/
>>
>
> _______________________________________________
> 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/
>