Re: [j-nsp] EX Switch Question
On 2 April 2013 09:06, Ben Dale wrote: > I couldn't agree more. Funnily enough when I saw the EX2200C-12 get > released being both fanless and shallow depth the first use case I thought > was ME NTU/Small PoP. > > Front-mounted power would have been nice, but hey, I'll deal. > > There are enough dot1q-tunnelling knobs built-in* for most applications, > and aggregating this back to an MX somewhere would make this a pretty solid > design. Port ERPS down to the 22xx code (once Juniper get it sub 50ms) and > this would kick ass. > > I've seen a couple of MX80s sitting in basements where there is little or > no air-con, and I can't imagine them being long for this world. > > *Having to pay more than the price of the switch to activate EFL to use > Q-in-Q does dampen the idea somewhat though. When the ex2200C came out, I considered it as a Metro-E CPE / demarc device. It was missing to many features for that role at the time and lost out to devices targeted for that market such as the T-marc 340 or an ADVA FSP(?). As much as disliked working on the T-marcs, they were cheap and it was easy enough to dump a template on it and never touch them again. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
>> Epic fail on Juniper's part to think that networks will >> still go for "too big" boxes for "small box" deployments. >> The ERBU head promised that they were looking at a 1U MX80 >> box that would rival the Cisco and Brocade options in the >> access, but I think they thought coming up with the MX5, >> MX10 and MX40 were far better ideas :-\. > It's really interesting, that you say 2RU is too much for MX80. I never > heard such a claim from a customer. At least, it's never been a serious > problem. Much more often they ask whether it fits into a 60 cm deep rack > and how much power it eats. I think, the lack of this requirement comes > from completely different economics of real estate, access networks > structure and all. In many countries (where telecom markets are > emerging) access network is often an interconnection of places like > this: http://nag.ru/upload/images/20519/1877875733.jpeg In a hell I'd > put there something closely priced to MX5, be it 1 or 2 RU height :) So > people often come up using something extremely cheap in the PoPs (don't > even think "MPLS") and aggregate them in a location, where 1 or 2 RU > doesn't make much difference. I couldn't agree more. Funnily enough when I saw the EX2200C-12 get released being both fanless and shallow depth the first use case I thought was ME NTU/Small PoP. Front-mounted power would have been nice, but hey, I'll deal. There are enough dot1q-tunnelling knobs built-in* for most applications, and aggregating this back to an MX somewhere would make this a pretty solid design. Port ERPS down to the 22xx code (once Juniper get it sub 50ms) and this would kick ass. I've seen a couple of MX80s sitting in basements where there is little or no air-con, and I can't imagine them being long for this world. *Having to pay more than the price of the switch to activate EFL to use Q-in-Q does dampen the idea somewhat though. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 1000Base-T SFP shows Link Up without cable inserted
On 01/04/2013, at 5:55 AM, Mathias Sundman wrote: > I've just upgraded two of my MX5-T boxes to 11.4R7.5 and after that my 3rd > party 1000Base-T SFP (Transmode originals based on Finisar) started to show > Link Up as soon as the SFP is inserted (no cable inserted). > > On 11.2R5.4 it worked as it should. 11.4R1.14 that the boxes came with was > also broken. > > Bug or feature? Has anyone used any Juniper original 1000Base-T SFPs on the > MX-5/10/40/80-T platform with JunOS 11.4? Both ; ) I've seen this a few times across various versions with different 3rd-party 1GBaseT transceivers. I don't know the specifics of why the issue is caused, but after swapping suppliers, and upgrading code, the issue appears to have gone away. I guess that is the risk of using 3rd party - I'm not sure how much luck you'll have logging a case ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX960 Error Message - MPC2
Hi all, Has anyone ever experienced this error message on MX960 with a single DPC-E and a single MPC2-3D? The MPC has a single MIC in it, a MIC-3D-4XGE-XFP. The DPCE is a DPCE-R-20GE-2XGE. JUNOS version 10.4R8.5. The configuration that causes the issue appears to be a VLAN-bundled logical interface for MPLS transport across the network. Mar 25 10:19:16 fpc1 trinity_insert_ifl_channel ifl 134 NOENT Mar 25 10:19:16 fpc1 jnh_ifl_topo_handler_pfe: Failed to insert L2PD channel for ifl 134 I don't seem to be getting anywhere with JTAC after a week of back-and-forth. thanks, evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Different media in an AE cause framing issues?
Hey guys... So I just bought a bunch of avago SFP+'s from a local distributor, about 250 of them, so I'm in relatively deep here. I'm wondering if I just made a general mistake by adding another 20gbit of MM OM3 with these new modules to an existing 20gbit AE which is using DAC. I started noticing framing errors mostly on the two additional links I had added. It was around 100-300 per second per interface..the DAC interfaces were fine. The AE was only pushing around 1-2gbit duplex at the time when I noticed it (packet loss), and I shut down those interfaces. I'm using these modules to convert existing top of rack connections from twinax/DAC to fiber, which I haven't started, but I DID just roll out another 8 cabinets using these modules, and so far I haven't seen any framing errors...but then again I'm not pushing much traffic. I also didn't see these issues when I tested a couple modules before we bought them... The core AE is between two EX8208's, and the TOR connections are going out from the core to EX3300's. Here are the stats for one of the cabinet AE's from the core switch side, which looks clean: Interface: ae5, Enabled, Link is Up Encapsulation: Ethernet, Speed: 2mbps Traffic statistics: Current delta Input bytes: 264708836 (2040 bps) [1928] Output bytes: 5520922123 (23832 bps)[25257] Input packets: 2013442 (1 pps) [16] Output packets: 35600334 (22 pps) [256] Error statistics: Input errors:0[0] Input drops: 0[0] Input framing errors:0[0] Carrier transitions:18[0] Output errors: 0[0] Output drops:0[0] The EX3300 side looks good, as well as the AE for the VC between the 3300's, which also use these modules... So at this point I'm wondering if mixing the fiber and DAC connections is a nono? Due to timing issues? Not sure how that would screw up the frame, but maybe somebody has more insight. -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
31.03.2013 18:18, Mark Tinka wrote: > On Friday, January 11, 2013 01:41:47 PM Pavel Lunin wrote: > >> Looks like Juniper just did not much care metro ethernet. >> BTW, it's sometimes said, that the reason is a lack of >> such a market in North America (where I've even never >> been to, thus can't judge whether this sentence is >> correct :). Another reason (more serious, I would say) >> is a strong Juniper's position in the MPLS battle, which >> doesn't allow them to invest much into the plain >> ethernet metro access technologies to not kill the goose >> that lays the golden eggs (from the pure engineering >> point of view there is also some logics in such an >> approach). > Well, Cisco must be seeing some market that Juniper aren't, > considering these are both American companies. It was just the story as I heard it. I don't know really how right this statement is (and for me it also seem a bit strange). Generally speaking "American company" does not mean "make most money in the North America" though I have no idea how different the ratios of NA/other are for Cisco and Juniper these days. I think more correctly this idea sounds like "Juniper don't believe they can earn money on ME market for whatever reason". At least for me, not playing the MetroE game seems to be a conscious decision, not an oversight. Maybe just same story as the VoIP, where Cisco successfully played for ages and Juniper gave up completely after a couple of silly attempts (my special thanks to Juniper for deliverance from the SRX "converged services" nightmare). > When the MX80 was still codenamed Taz, and all we got to > test was a board with no chassis, I asked Juniper to rethink > their idea about a 1U solution for access in the Metro, > especially because Brocade had already pushed out the > CER/CES2000, Well, as I involved into selling both Juniper and Brocade, from this perspective I can say, Juniper's decision was just right :) I love CES/CER but when it comes to real competition with MX5-80, there are really few chances for Brocade. Small MX usually costs about the same in a comparable configuration. A bit more expensive, but Brocade is by far #3 in terms of MPLS features and all. Some exceptional niches exist, also Brocade is going to launch a 4×10GE ports CER, but generally it's really hard to position CER against MX/ASR and CES against Catalyst ME or, say, Extreme X460. > and Cisco were in the final stages of commissioning the ME3600X/3800X, at the > time. Well, I'd also really like to have a Juniper box competing against Catalyst ME, but, again, I believe there might be (I don't say "there is") some common sense in not even trying to play this game. I can easily imagine sane reasons for which they decided to spend money and time on ACX (PTX, QFabric, WiFi) instead of just trying to catch up Cisco, Extreeme and others in the straightforward ME game. > Epic fail on Juniper's part to think that networks will > still go for "too big" boxes for "small box" deployments. > The ERBU head promised that they were looking at a 1U MX80 > box that would rival the Cisco and Brocade options in the > access, but I think they thought coming up with the MX5, > MX10 and MX40 were far better ideas :-\. It's really interesting, that you say 2RU is too much for MX80. I never heard such a claim from a customer. At least, it's never been a serious problem. Much more often they ask whether it fits into a 60 cm deep rack and how much power it eats. I think, the lack of this requirement comes from completely different economics of real estate, access networks structure and all. In many countries (where telecom markets are emerging) access network is often an interconnection of places like this: http://nag.ru/upload/images/20519/1877875733.jpeg In a hell I'd put there something closely priced to MX5, be it 1 or 2 RU height :) So people often come up using something extremely cheap in the PoPs (don't even think "MPLS") and aggregate them in a location, where 1 or 2 RU doesn't make much difference. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 generates power supply and fan alarms when environment is good
After an upgrade to 12.3R2.5 I still see errors for the power supplies, 3 messages per hour. The Fan/Blower alarms seems to be solved. Mar 28 14:30:52 chassisd[1308]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 1, jnxContentsL2Index 3, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 2 @ 0/2/*, jnxOperatingState/Temp 1) Mar 28 14:30:52 chassisd[1308]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 1, jnxContentsL2Index 4, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 3 @ 0/3/*, jnxOperatingState/Temp 1) Mar 28 14:30:52 chassisd[1308]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsCoontainerIndex 2, jnxContentsL1Index 1, jnxContentsL2Index 5, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 4 @ 0/4/*, jnxOperatingState/Temp 1) Kind regards, Peter Tavenier Op 24 mrt. 2013, om 12:48 heeft Peter Tavenier het volgende geschreven: > I got the two PR numbers (PR842933, PR858565) for this issues which will be > fixed in 12.3R2. > > Which other problems do 12.3 have with the chassisd process? > > Kind regards, > Peter Tavenier > > Op 22 mrt. 2013, om 22:09 heeft Giuliano het > volgende geschreven: > >> Never mind about 12.3 >> >> It has big trouble with chassid daemon >> >> Sent from my iPhone >> >> On 22/03/2013, at 17:12, JP Velders wrote: >> >>> Date: Thu, 21 Mar 2013 09:04:49 + From: Peter Tavenier Subject: [j-nsp] EX4200 generates power supply and fan alarms when environment is good >>> On my EX4200 running version 12.3R1.7 is see the following alarms in the logging: >>> Mar 21 08:46:46 chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 1, jnxContentsL2Index 3, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 2 @ 0/2/*, jnxOperatingState/Temp 1) ... 41 more times same type of alarms ... Mar 21 08:46:46 chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 1, jnxContentsDescr FAN: Fan 1 @ 1/0/0, jnxOperatingState/Temp 1) Mar 21 08:46:46 chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 8, jnxContentsL2Index 1, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 0 @ 7/0/*, jnxOperatingState/Temp 1) Mar 21 08:46:46 chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 2, jnxContentsDescr FAN: Fan 2 @ 1/0/1, jnxOperatingState/Temp 1) Mar 21 08:46:46 chassisd[1290]: %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 8, jnxContentsL2Index 3, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 2 @ 7/2/*, jnxOperatingState/Temp 1) ... 32 more times same type of alarms ... >>> >>> Seen here on EX2200C's, EX4200's and EX4500's as well, even funnier, >>> take a look at what items it is actually complaining about: >>> non-existing components, basically all other _possible_ VC members. >>> >>> Was busy with other things, so didn't bother to contact JTAC yet, >>> think I should have a good laugh this weekend with them on this. :) >>> >>> Mind you, identical configs do not exhibit this on 11.4 or 12.1. Would >>> guess this is either a 12.2 or (more likely) a 12.3 oddity. >>> >>> Kind regards, >>> JP Velders >>> ___ >>> 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
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
Ingress ipv6 marking is supported on MX. You need to use 'then traffic class'. On Apr 1, 2013 2:25 AM, "Mark Tinka" wrote: > On Monday, January 14, 2013 10:55:11 AM Per Granath wrote: > > > On egress you may apply a rewrite rule to a class (on an > > interface). Essentially, this means you cannot rewrite > > on ingress. > > On IQ2 and IQ2E PIC's, you can remark on ingress with the > ToS Translation Tables feature. > > On the MX running Trio line cards, you can remark on ingress > with an ingress firewall filter, but sadly, this doesn't > support EXP or IPv6 DSCP bits. > > I like the ToS Translation Tables, but it's limited to > platforms that run those line cards (which is not to say > that an IQ2 or IQ2E PIC in an MX-FPC will work - never > tried). > > Mark. > > ___ > 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
[j-nsp] MS NLB multicast mode and EX 12.x new behaviour issues
hey, I just want to let everyone know about the new behaviour for unknown multicast that was introduced in junos 12.1 for EX switches. I'm also looking for feedback from other EX users because we have been unable to convince juniper to rethink this for 4 months now. In 12.1, EX will now copy all transit multicast packets matching destination mac 03:bf:* to control plane. This is normally used for MS NLB multicast mode and should be flooded. I would somewhat understand if they would do it in management vlan but this is done for all vlans, including ones that should be pure transit in L2 device. The side effect of this is that multicast will totally congest some of your inband management queues leaving you without ssh and telnet. You can verify this by running "show sh packet-descriptor dev 1 pcl-out" from SFID shell and looking whats in the packet queue. Cut-down example (original output has lot more fields): CPU code : 253 Dest IP addr : 192.168.17.95 Dest MAC addr : 03:bf:c0:a8:11:5f Ether type : 0x800 IP TTL : 62 Is routed : 0 MAC DA lookup rslt : 0 MAC DA type: Multicast Packet command : Mirror to CPU Src IP addr: 192.168.16.58 Src MAC addr : 44:d3:ca:ba:55:c1 TCP/UDP dest port : 3389 TCP/UDP src port : 47679 Vlan ID: 12 JTAC is now proposing using scripts and cronjobs to run some commands from pfe shell on every startup to ratelimit this multicast. Not only is this not deployable in large scale, but this is head-in-the-sand type of solution. They should really fix the root cause (by redesigning it) or revert the change. EX software quality has been going downhill for a while now and still keeps doing so. -- tarko ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
