[j-nsp] General MX notes for use as a core ethernet switch...

[Doug Marschke]

When a single EQ DPC is installed in the MX960 chassis, 11 DPCs can be
supported.  These DPC can be any mix of EQ and non-EQ DPCs. So, in other
words, the addition of multiple EQ pics will not increase  the amount of
slots that need to be reduced for DPC use. If a redundant SCB is not
needed, then slot 6 should be covered with a blank panel. It is
important to remember, that in the fabric redundancy configuration, slot
6 will be taken by a SCB so no issues will arise


This is not a restriction for the Mx480/240.


Doug Marschke 
Principal Technologist 
Strategic Networks Training 
JNCIE-ER #3, JNCIE-M/T #41, JNCIS-FW, JNCI 
www.ietraining.net 
(415)902-5702 


-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of David Ball
Sent: Thursday, August 28, 2008 4:34 PM
To: Derick Winkworth
Cc: juniper at groupstudy.com; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] General MX notes for use as a core ethernet
switch...

  Somewhat related, I seem to recall reading/hearing/imagining
somewhere that an MX chassis couldn't provide enough power to 'fuel' a
full complement of DPCE-EQ cards (not sure if this was tied to a
particular chassis or not).  Sounds strange, I know, but can anyone
confirm/deny this potentially imagined limitation?

David


2008/8/18 Derick Winkworth <dwinkworth at att.net>:
> Fiddling with the MX for a POC-like session, I found a couple of
things
> others may find interesting...
>
> 1) On etherchannel bundles, traffic is distributed per
destination-mac, per
> source-mac, or both.  Unfortunately, this is not configurable on a
per-link
> basis, only globally.  So, for us, this means we will be using both...
>
> "forwarding-options hash-key family multiservice ..."
>
> 2) On an IRB interfaces, there is the annoying requirement of
specifying a
> layer-2 interface in a static arp definition.  This annoying
requirement
> remains true even in the case of a multicast-mac.  For some reason,
> configuring static ARP means the MX can't learn that MAC address...
which is
> highly inconvenient when you need to use a multicast MAC address (like
> active/active multicast mac firewall configurations).
>
> 3) To be 100% compatible with Cisco's PVST+, you need to use
"force-version"
> and make sure you are configured for STP and not rapid-pvst...
>
> 4) VRRP uses a virtual MAC, so there is no dependency on gratuitous
ARPs or
> ARP timeout parameters on hosts.  Not a big surprise or anything, but
it was
> nice to see it work as expected...
>
> 5) These are MDI-crossover ports.  If you are doing a core-switch swap
with
> existing "switches" you will need to put cross-over cables in!!!
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp