[j-nsp] EX 8200 deployment

[Richard A Steenbergen]

On Mon, Mar 22, 2010 at 11:35:19PM +0300, Alexandre Snarskii wrote:
> EX-series (at least [34]200) has the same "local vlan significance" 
> principle that applies, for example, to OSM-equipped 6500/Sup2: 
> "you can create chassis-wide vlan, and it will be used on all LAN 
> cards, but you still can reuse the same vlan id on OSM subinterface", 
> and the idea is actually stolen from some old recipe on "how to run 
> 6500/sup2 Vlan as a part of VRF". 
> In case of ex-series it's even better - there are no 'internal vlan'
> allocation that happens in case of 65xx/76xx. 

That is indeed a fair bit better than the 6500/7600 vlan model, I guess
EX's vlan support isn't quite as bad as I thought. I swear I tested this
on EX4200 when we first got one (2 years ago) and I have a very strong
memory of this behavior not working this way, but damned if I can find
the emails with the test results to prove it.

On 6500, when you do something like this:

interface TenGigabitEthernet1/1.101
 encapsulation dot1Q 101
 ip address 1.2.3.4 255.255.255.0

It simply creates vlan 101 as an internal vlan, which consumes vlan 101
across the entire chassis and blocks the creation of another vlan 101 
anywhere else. Of course if you didn't do a subinterface but simply 
slapped an IP directly on the physical interface, it would simply pick a 
pseudo-random vlan ID to use, like so:

crisco6509#sh vlan internal usage 

VLAN Usage
---- --------------------
901  TenGigabitEthernet8/2.901
910  TenGigabitEthernet4/2.910
1606 TenGigabitEthernet8/2.1606
2201 TenGigabitEthernet8/2.2201
4032 TenGigabitEthernet3/4
4033 TenGigabitEthernet3/3
4034 TenGigabitEthernet3/2
4035 TenGigabitEthernet3/1
...


So... I'm wondering how much of this counter issue is really a hardware 
limitation, and how much is just design limitation. For example, would 
it be possible for Juniper to implement ethernet switching as 
essentially a multi-port ccc, like so:

interfaces {
    xe-1/0/0 {
        vlan-tagging;
        unit 101 {
            family inet {
                address 1.2.3.1/24;
            }
        }
        unit 201 {
            vlan-id 201;
            family ethernet-switching;
        }
    }
    xe-2/0/0 {
        vlan-tagging;
        unit 101 {
            family inet {
                address 2.3.4.1/24;
            }
        }
        unit 201 {
            vlan-id 201;
            family ethernet-switching;
        }
    }
}
vlans {
    blah {
        interface {
            xe-1/0/0.201;
            xe-2/0/0.201;
        }
    }
}

To me this seems like a much more natural way of handling mixed L2 and 
L3 configs on a single port anyways, and it could potentially let you 
have everything on a port which could be properly counted. Extra bonus 
points if there was a way to strip the vlan tag before putting it into 
the "multi-port ccc" so you could do vlan translation, but I don't know 
if that is possible in hardware (there is certainly no input-vlan-map to 
pop the vlan like on MX/etc, but this will be a problem when they get 
around to implementing mpls l2circuits).

The funny thing about the above configuration is that it doesn't seem to
be complaining about the lack of a vlan-id under vlan "blah", only about
the mixing vlan-tagging and family ethernet-switching. :)

Now say I took the above scenario and made it:

vlans {
    blah {
        interface {
            xe-1/0/0.201;
            xe-2/0/0.201;
            ...
        }
        l3-interface vlan.201;
    }
}

Today they don't have working counters on vlan.201, and Juniper claims
it is a hardware limitation they can't solve without some hackery like
firewall filter counters applied to each interface, but... If I can get
xe-1/0/0.101 counters today, could I also get xe-1/0/0.201 counters in
the above configuration? Possibly those could be added up internally to 
make a virtual vlan.201 counter, but worst case I could definitely do 
the additionl on my side post-SNMP collection.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)