[c-nsp] Cisco 7600 vlan issue

[Julio Arruda]

Gert Doering wrote:
> Hi,
> 
> On Sun, Nov 30, 2008 at 02:23:35PM +0000, Matthew Melbourne wrote:
>>> And yes, this is one of the most serious design limitations of the 
>>> 6500/7600 - "global VLAN space" (with LAN interfaces).  But it's a 
>>> well-known and well-documented limitation, so usually people know in
>>> advance and can decide for themselve whether the tremendous price 
>>> advantage of LAN cards is worth the associated restrictions.
> 
>> Can you point me in the direction of any "global VLAN space" documentation
>> for the Catalyst 6500? 
> 
> I can't point you to a given document on cisco.com.  It has been mentioned
> a number of times on this mailing list, though.
> 
> It is easy to understand if you look at the way the "big catalyst boxes"
> are built (more prominent in the cat5000 series):
> 
>   - there's a layer2 switching engine
>   - loosely coupled to that is a layer3 forwarding box
>   - ports are put into a L2 VLAN
>   - the L3 engine has a VLAN trunk into the L2 box of the switch, and
>     this is used for routing between VLANs
> 

I was under impression the L3 forwarding and the L2 forwarding was done 
by the same engine, in the PFC card(s) ? and behind it, the EARL for the 
lookup and the rewriting of the header info (mac rewrite, dec ttl and 
goes on) ?
That is how Nortel 8600 (and earlier gen, rapidcity-legacy) did the 
work, the same lookup engine would do l2 and l3, so I may be messing up 
things in my mind :-), in a little more distributed fashion (more like DFCs)

> on the 6500, you can have "no switchport" ports, which sort of hide this
> mechanics - but under the hood, the cat65 will allocate an internal VLAN,
> put the port in that VLAN (disable spanning tree and other switch things,
> though) and trunk it to the routing engine...
> 
> [Yes, this is simplifying things a lot, but the basic architecture works
> that way - and all the rest is "powerups" to improve throughput]
> 
> 
> Some of the line cards have "more intelligence", like the SIP boards - those
> are, basically, a router-on-a-stick that taps into the switch fabric and
> has its own brains - so it doesn't know anything of the "switch VLAN" stuff,
> but can allocate dot1q tags on a per-port basis.
> 
> 
>> The helps to explain why the same dot1q tag
>> shouldn't be re-used on separate routed sub-interfaces.
> 
> Yep.  Because it's a switch - and VLAN IDs are global.
> 
> [..]
>> I was hoping to re-use VLANs 100/101, as it looks like it should only be
>> locally significant on the L3 trunk
> 
> L3 "trunks" are an illusion, created for convenience.
> 
> gert
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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/