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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Ball Sent: Thursday, August 28, 2008 4:34 PM To: Derick Winkworth Cc: [EMAIL PROTECTED]; juniper-nsp@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 <[EMAIL PROTECTED]>: > 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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp