[j-nsp] EX 8200 deployment

[Fahad Khan]

I really appreciate all for their inputs. Thanks a lot.

Is there any caveat in RTG, Can we easily get rid of STP running?? do you
recommend it or not??

Is there any special socket required for powering this chassis up?? as we
need industrial sockets in case of Cisco 6500.

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fahad at pk.ibm.com
+92-321-2370510
+92-301-8247638
Skype: fahad-ibm
http://www.linkedin.com/in/muhammadfahadkhan
http://fahad-internetworker.blogspot.com
http://www.visualcv.com/g46ptnd


On Tue, Mar 23, 2010 at 4:16 AM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> 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)
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>