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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
