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

[Pavel Skovajsa]

Hi,

Glad it helped.

by suboptimal I meant the fact it is possible (simply by sending to
ffff.ffff.ffff) to flood the traffic from one isolated access switch
port through distribution layer, into the rest of the switching fabric
infra simply due to the fact that all uplink/downlink ports are
"switchport mode trunks". Obviously the traffic does not get into the
end-user ports, but still the trunk are utilized -> hence the
functionality is little different then the expected "pseudowire"
functionality.

One would expect to have some kind of feature configured on the
distribution layer that would not forward the traffic to the rest of
the switching fabric, just to the uplink port into the core layer ->
this is probably what the "private-vlan trunk" is trying to do.....

-pavel skovajsa

On Wed, Jan 13, 2010 at 8:41 PM, Sven 'Darkman' Michels <sven at darkman.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Pavel,
>
> first of all, thanks for your fast response!
>
> Pavel Skovajsa schrieb:
>> If I understood you correctly you can get around these limitations by
>> using the PVLAN feature on the end-user ports only and not on the
>> internal switch-to-switch links. On those links you can use normal
>> "trunk" ports and spread the PVLAN to your 6509 and terminate it on L3
>> VLAN int.
>
> Ah, okay, i thought i need the private-vlan trunk mode, and when i enabled
> it, it just "crashed" my port channel (as in removed the port from it, which
> was not what i wanted..).
>
>
>> On your distribution (6509) you configure:
>>
>> interface Vlan10
>>  ip sticky-arp ignore <--- this is important as PVLAN VLAN interface
>> gets sticky arp by default (for some unknown reason)
>>  no ip proxy-arp
>>  private-vlan mapping 100
>>
>> and normal trunk port towards the switch fabric:
>> interface GigabitEthernet6/1
>>  switchport mode trunk
>
> Ah okay, then i'll try that one, i just limited the vlans a bit, of course ;)
>
>
>> Yes this is probably suboptimal to what you would like to accoplish
>> however the end effect is that the end-user ports cannot communicate
>> with each other - which is probably what you want.
>
> Why is that suboptimal? From what you described and what i unterstood, it
> works like i want: having a etherchannel to my core and protected ports on
> my edge. If the SVI is reachable from my edge, and other hosts are not, than
> i have what i want. But maybe i missed something...?
>
>
>> Another alternative is the "private-vlan trunk" feature which is
>> described over here
>> http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/pvlans.html#wp1166138
>> - the trouble is that AFAIK currently it works only on C4500.
>
> That was what i thought i need, its available on the 3560 but it killed the
> etherchannel... and pvlan documentation says "you cannot enable pvlans on
> an etherchannel", which is "right" as if you enable any of the pvlan commands
> on a etherchannel port, it gets removed from the etherchannel... but it seems
> that normal trunks just work for that - great ;)
>
> So, from what i know now, it should work like i want... just need to test if
> it works with more than one switches etc. but at the moment it think it will
> do so far.
>
> Thanks again for your help :)
>
> Regards,
> Sven
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAktOIc8ACgkQQoCguWUBzBz48ACgjX54FYRh9fpzRmobTElDvXvv
> 8S8An1fyaboYKoWPuZErysZ6c9OH5Kyi
> =O52n
> -----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/
>