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
