Re: [j-nsp] EX4550 and MX104
> Richard McGovern : > > I am not sure that the MX logic is from the 1990s. It should be first >> released with the MX in... was it 2006 or 2007? While the first EX came >> around in 2008. Not that big gap between the two. >> > > > ð First came M before MX in mid-90s, I believe. > I might be wrong but if memory serves, M/T had no ethernet switching. So all this bridge-domain machinery should have come around with the MX series. It's not legacy but intentionally designed to be like this, as it's SP-oriented. And yeah, I forgot that MX also has two Ethernet switching config styles. So... I am out of fingers to count the ether-switching config styles in JUNOS. And it's OK, in fact. The point of this discussion is that adding more instances is not the right way to reduce the number of them. And it's arguable if it really needs to be reduced. JUNOS has always been known to have multiple ways to do the same thing. And it's OK. > While you are right about the fact that a given EX box supports either one >> model or another and not both, this change has nothing to do with the >> Marvel to Broadcom migration. It's purely software and, as you said, there >> are some EoL boxes which have seen both. It rather looks like Juniper said >> to themselves that they lost the enterprise market anyway, and for the DC >> MX-like model should be a bit better. >> > > > ð I repeat. Agreed, and fortunately all those people are now gone > within Juniper. > I am not sure that it's about people. I'd say it's more general story of trying to repeat the M/T/MX/JUNOS success with other products. Back in the early 2000s Juniper managed to revolutionize software design for Service Provider routers. This is where the company feels safe and knows what it does. Look how much attention Juniper pays to user behavior consistency of the SP products. I am too lazy to check but I am sure that there are still spare parts for M/T available for purchase. This "per-packet" which is not really per-packet but per-flow ECMP thing is pure legacy and could be changed easily, but behavior consistency is the king. 64 bit RE for M7i when everyone seemed to forget what M7i was. Lots of such examples in the M/T/MX world. And it's good, it works. However when it comes to the non-SP/DC world, it's just the opposite. ScreenOS to SRX migration. WiFi. SSL VPN. Traffic Optimization. Space. J Series. CDN caching. SRX media gateway. I am sure, I forgot something. I doubt that it was the same people who killed those products. It's not comparable with the MX as a business. So let's mess everything up twice a year, because "JUNOS was a success at the beginning, we want a single JUNOS for everything, it must be a success again". Or just because "it doesn't sale". But yes, if you change the product behavior twice a year, it won't sale. ScreenOS had a kind of 30% of the market and SRX... you know... Not because it's a bad firewall but because it was a lot of pain at the time of that ScreenOS->JUNOS migration. BTW, a few months ago I've promenaded around in one of the major European telco sites just to have a look at what people had in their racks. Oh Dear, I've seen A LOT of Netscreen/SSG/ISG and even a couple of J-series. Racked, powered, blinking LEDs. This should be some OOB in most cases, I think, but anyway, they are still here! I was impressed. -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
We encountered this on T1600 chassis. After months troubleshooting, i discovered myself it is due to some monitoring system were still polling using snmp v1. After all changed to v2c. Problem resolved. As usual JTAC would suspect here and there, and luckyly i have another chassis with identical software / config but not affected as comparison. On Wed, 18 Jul 2018 at 14:37, Gert Doering wrote: > Hi, > > On Wed, Jul 18, 2018 at 02:50:13AM +, Richard McGovern wrote: > > As well the really important stuff comes after the sale, not before. > > Yeah. JTAC really excels on this. > > (We have an open case where SNMP on *some* EX4600 is abysmally slow while > the same queries on other EX4600 with the same software / SNMP config > behave quite normally. Not proceeding in meaningful ways since half > a year...) > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ > 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] EX4550 and MX104
On 18/Jul/18 18:03, Pavel Lunin wrote: > I might be wrong but if memory serves, M/T had no ethernet switching. So > all this bridge-domain machinery should have come around with the MX > series. It's not legacy but intentionally designed to be like this, as it's > SP-oriented. That's exactly the way I remembered it. I mean, M/T had basic 802.1Q VLAN trunking support, but that was about it. STP and them first appeared on the MX. > And yeah, I forgot that MX also has two Ethernet switching config styles. > So... I am out of fingers to count the ether-switching config styles in > JUNOS. And it's OK, in fact. The point of this discussion is that adding > more instances is not the right way to reduce the number of them. And it's > arguable if it really needs to be reduced. JUNOS has always been known to > have multiple ways to do the same thing. And it's OK. +1. > It's not comparable with the MX as a business. So let's mess everything up > twice a year, because "JUNOS was a success at the beginning, we want a > single JUNOS for everything, it must be a success again". Or just because > "it doesn't sale". But yes, if you change the product behavior twice a > year, it won't sale. ScreenOS had a kind of 30% of the market and SRX... > you know... Not because it's a bad firewall but because it was a lot of > pain at the time of that ScreenOS->JUNOS migration. Don't remind me - just when we were about to settle on the J-series as a route reflector, it went and became the SRX with firewall or packet mode. > BTW, a few months ago I've promenaded around in one of the major European > telco sites just to have a look at what people had in their racks. Oh Dear, > I've seen A LOT of Netscreen/SSG/ISG and even a couple of J-series. Racked, > powered, blinking LEDs. This should be some OOB in most cases, I think, but > anyway, they are still here! I was impressed. Doesn't surprise me, if I'm honest. We still use the Cisco 7201 as looking glass routers, because they were well built for purpose and were supported for a very long time. And even when Cisco decided to stop forgetting about them, it was because you knew they had squeezed them for all they were worth, and it was now time for something else. Not these haphazard changes that you aptly describe in this post. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
