Re: [j-nsp] Mixing v4/v6 neighbors in BGP groups
Hi Rob, We keep the configs separate per address-family. — Sebastian Becker ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480
Right, got the message just some minutes ago: JUNOS 16.1R7.7 has deployed https://www.juniper.net/techpubs/en_US/junos16.1/information-products/topic-collections/release-notes/16.1/index.html — Sebastian Becker > Am 18.06.2018 um 16:33 schrieb Sebastian Wiesinger : > > * Vincent Bernat [2018-06-17 12:17]: >> ❦ 17 juin 2018 12:05 +0200, Sebastian Becker : >> >>> 16.1R7 is a golden release. >> >> Is it already released? Not listed here: >> https://www.juniper.net/support/downloads/?p=mx480#sw > > It's released now, backdated to the 15th, probably the build date. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > SCYTHE. >-- Terry Pratchett, The Fifth Elephant > ___ > 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] MX480
The ETA for GA was 31-MAY-2018. So hopefully only a matter of days. — Sebastian Becker > Am 17.06.2018 um 23:11 schrieb craig washington > : > > It's not released yet as far as I know. > I know it was supposed to be at least per our SE at Juniper. > Hopefully will have some sort of update this week unless anyone else knows > something. > > > From: juniper-nsp <mailto:juniper-nsp-boun...@puck.nether.net>> on behalf of Vincent Bernat > mailto:ber...@luffy.cx>> > Sent: Sunday, June 17, 2018 10:17 AM > To: Sebastian Becker > Cc: juniper-nsp@puck.nether.net <mailto:juniper-nsp@puck.nether.net> > Subject: Re: [j-nsp] MX480 > > ❦ 17 juin 2018 12:05 +0200, Sebastian Becker <mailto:s...@lab.dtag.de>> : > > > 16.1R7 is a golden release. > > Is it already released? Not listed here: > https://www.juniper.net/support/downloads/?p=mx480#sw > <https://www.juniper.net/support/downloads/?p=mx480#sw> > Download Software - Support - Juniper Networks > <https://www.juniper.net/support/downloads/?p=mx480#sw> > www.juniper.net <http://www.juniper.net/> > Juniper Software Downloads. It is important to keep your products registered > and your install base updated. > > > Is 16.1R6-S4 considered almost equivalent? > -- > The fashion wears out more apparel than the man. > -- William Shakespeare, "Much Ado About Nothing" > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > <mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > <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] MX480
16.1R7 is a golden release. — Sebastian Becker > Am 16.06.2018 um 19:49 schrieb Chris Hale : > > Wait for a golden release, ask JTAC about the next golden release coming > out. Maybe 17.3R2 or R3. They will be highly tested and classified as very > safe for production use immediately. > > On Sat, Jun 16, 2018 at 12:32 PM Sebastian Becker <mailto:s...@lab.dtag.de>> wrote: > 16.1R4 is deployed in the moment. 16.1R7 is a recommendation from Juniper to > us. > > — > Sebastian Becker > s...@lab.dtag.de <mailto:s...@lab.dtag.de> > > > Am 16.06.2018 um 13:33 schrieb Ian Goodall > <mailto:bbaa4...@gmail.com>>: > > > > > > Hi All > > > > Were looking to upgrade JUNOS on some of our older PE MX480/960 running pre > > 15 code. We've had success on the 17.x train in P roles. > > > > 15.1 is recommended by JTAC but it's EOL in under 12 months. > > > > Historically picking a recent version with a high R release was always a > > good starting point. The release strategy has changed somewhat and most > > versions now don't go beyond R2. > > > > What's everyone deploying currently? > > > > Thanks > > > > IG > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > <mailto:juniper-nsp@puck.nether.net> > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > <https://puck.nether.net/mailman/listinfo/juniper-nsp> > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > <mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > <https://puck.nether.net/mailman/listinfo/juniper-nsp> > > > -- > -- > Chris Hale > chal...@gmail.com <mailto:chal...@gmail.com> ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480
16.1R4 is deployed in the moment. 16.1R7 is a recommendation from Juniper to us. — Sebastian Becker s...@lab.dtag.de > Am 16.06.2018 um 13:33 schrieb Ian Goodall : > > > Hi All > > Were looking to upgrade JUNOS on some of our older PE MX480/960 running pre > 15 code. We've had success on the 17.x train in P roles. > > 15.1 is recommended by JTAC but it's EOL in under 12 months. > > Historically picking a recent version with a high R release was always a > good starting point. The release strategy has changed somewhat and most > versions now don't go beyond R2. > > What's everyone deploying currently? > > Thanks > > IG > ___ > 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] Upgrading from RE-S-2000-4096-S/SCB-MX960-S to RE-S-1800X4-32G-S/SCBE2-MX-S
As already mentioned: SBE exchange requires a power down. But the REs can easily upgraded by replacing first the backup RE, install correct software there and sync config to it and then do a switch over. Juniper does not support a longer period of mixed REs but the upgrading is supported. We have done that many times and it works quite well. Doing staging in a lab is from the logistic point for a bigger network not a good option. One thing: We had issues if you boot up with one empty RE (no config and newer software). This might override the configured RE. So maybe one approach will be: 1. Swap backup RE with the new one. 2. Upgrade new backup RE with software and config. 3. Power down the system 4. Replace all SBE with SCBE2 and insert only the new configured RE (was the new backup RE in 2.) 5. After boot insert second new RE and upgrade / configure it. Done. The good thing is that you have the old SBE and RE for any fallback almost untouched at the side. — Sebastian Becker s...@lab.dtag.de > Am 17.01.2018 um 11:15 schrieb James Bensley <jwbens...@gmail.com>: > > On 17 January 2018 at 09:32, Niall Donaghy <niall.dona...@geant.org> wrote: >> Hi Craig, >> >> Indeed Misak's recommendation is the one I would follow. >> >> We are in the process of upgrading SCBEs to SCBE2s and indeed you must power >> off for this. >> >> As for the RE upgrades, JNPR states here >> https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/routing-engine-m-mx-t-series-specifications-by-model.html >> that: "On routers that accept two Routing Engines, you cannot mix Routing >> Engine types except for a brief period (one minute or so) during an upgrade >> or downgrade to two Routing Engines of the same type." I suggest that if you >> try to sync in-chassis rather than use flash, it might work, but is >> technically unsupported. >> >> Br, >> Niall >> >> Niall Donaghy >> Senior Network Engineer >> GÉANT >> T: +44 (0)1223 371393 >> M: +44 (0) 7557770303 >> Skype: niall.donaghy-dante >> PGP Key ID: 0x77680027 >> nic-hdl: NGD-RIPE >> >> Networks • Services • People >> Learn more at www.geant.org >> GÉANT is the collective trading name of the GÉANT Association and GEANT >> Limited. >> >> GÉANT Vereniging (Association) is registered in the Netherlands with the >> Chamber of Commerce in Amsterdam. Registration number: 40535155. Registered >> office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands. >> GEANT Limited is registered in England & Wales. Registration number: >> 2806796. Registered office: City House, 126-130 Hills Road, Cambridge CB2 >> 1PQ, UK. >> >> >> >> -Original Message- >> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of >> Misak Khachatryan >> Sent: 16 January 2018 18:30 >> To: craig washington <craigwashingto...@hotmail.com> >> Cc: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] Upgrading from RE-S-2000-4096-S/SCB-MX960-S to >> RE-S-1800X4-32G-S/SCBE2-MX-S >> >> Hi, >> >> As i remember, you can't mix REs and/or SCBs. Better to save your >> configuration to flash, replace all cards and power it up. It's relatively >> easy to predict port number changes from DPCE to MPC, so you can edit >> configuration accordingly before loading it to updated router. >> >> Best regards, >> Misak Khachatryan, >> Network Administration and >> Monitoring Department Manager, >> >> GNC- ALFA CJSC >> 1 Khaghaghutyan str., Abovyan, 2201 Armenia >> Tel: +374 60 46 99 70 (9670), >> Mob.: +374 55 19 98 40 >> URL:www.rtarmenia.am >> >> >> On Tue, Jan 16, 2018 at 5:52 PM, craig washington >> <craigwashingto...@hotmail.com> wrote: >>> Hello smart people. >>> >>> >>> We are in the process of upgrading from the aforementioned in the title. >>> >>> My question is does anyone have a procedure they have used in the past for >>> doing this or any type of gotchas. >>> >>> We are also replacing the old DPC's for MPC's. >>> >>> I know the port numbers will change and that the MPC's aren't compatible >>> with SCB. >>> >>> So I am looking for something like what's the best process to follow, for >>> instance should I: >>> >>> >>> 1. Swap out RE-2000 for RE-1800 one at a time (leaving SCB in place) to >>> get the configuration over and sync and then once that's up swap out
Re: [j-nsp] [c-nsp] Meltdown and Spectre
No … only a one time password. My password does not leave my computer. But again. Yes, you can construct something that might be a risk. But the users (by intention very limited amount) cannot run unsigned code (a Gert described already). So in the moment we are waiting for the vendors and than use with the next software update a fixed version. But we have no need to hurry are any reason for panic. — Sebastian Becker s...@lab.dtag.de > Am 08.01.2018 um 18:11 schrieb Chuck Anderson <c...@wpi.edu>: > > > Umm, you type the password into the box, right? The box stores that password > in memory so that it can build a TACACS+ request packet to send to the > server? Unless you are using SSH keys in lieu of passwords. > > On Mon, Jan 08, 2018 at 05:16:01PM +0100, Sebastian Becker wrote: >> The password will not be seen on the box itself so no problem. The users are >> tacacs+ authorized/authenticated. >> Most scenarios are much easier to accomplish by using the already granted >> rights on the boxes per user then using these kinds of attack vectors opened >> by Meltdown and Spectre. >> >> Our boxes simply do not run other code than that what is delivered by the >> vendors. >> >> — >> Sebastian Becker >> s...@lab.dtag.de >> >>> Am 08.01.2018 um 09:32 schrieb Thilo Bangert <thilo.bang...@gmail.com>: >>> >>> Den 06-01-2018 kl. 19:49 skrev Sebastian Becker: >>>> Same here. User that have access are implicit trusted. >>> >>> You do have individual user accounts on the equipment, right? >>> >>> The idea of having secure individual logins goes down the drain with >>> Meltdown and Spectre. You want to be sure that a person logged into a box >>> cannot snoop the password of a co-worker. >>> >>> Meltdown and Spectre are relevant on all affected computing equipment. >>> >>>> So no need for panic. >>> >>> The usefulness of panic has been degrading the past couple of thousand >>> years ;-) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Meltdown and Spectre
The password will not be seen on the box itself so no problem. The users are tacacs+ authorized/authenticated. Most scenarios are much easier to accomplish by using the already granted rights on the boxes per user then using these kinds of attack vectors opened by Meltdown and Spectre. Our boxes simply do not run other code than that what is delivered by the vendors. — Sebastian Becker s...@lab.dtag.de > Am 08.01.2018 um 09:32 schrieb Thilo Bangert <thilo.bang...@gmail.com>: > > Den 06-01-2018 kl. 19:49 skrev Sebastian Becker: >> Same here. User that have access are implicit trusted. > > You do have individual user accounts on the equipment, right? > > The idea of having secure individual logins goes down the drain with Meltdown > and Spectre. You want to be sure that a person logged into a box cannot snoop > the password of a co-worker. > > Meltdown and Spectre are relevant on all affected computing equipment. > > > So no need for panic. > > The usefulness of panic has been degrading the past couple of thousand years > ;-) > > ___ > 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] [c-nsp] Meltdown and Spectre
Same here. User that have access are implicit trusted. So no need for panic. — Sebastian Becker s...@lab.dtag.de > Am 06.01.2018 um 12:58 schrieb Gert Doering <g...@greenie.muc.de>: > > Hi, > > On Sat, Jan 06, 2018 at 12:04:22PM +0100, james list wrote: >> For cve related to Meltdown and Spectre I'm wondering to know what are you >> doing or going to do on your networking gears? > > "Nothing"... > > My networking gear does not execute external code (like, JavaScript), > so the question "will untrusted external code be able to read secrets > it should not see" is not overly relevant. > > > Now, for those newfangled stuff where vendors think that you MUST HAVE > VIRTUALIZATION! on the control plane, so YOU CAN RUN STUFF THERE!!! - > we do not have any of those (yet), but if we had, we'd ask them for > hypervisor patches... > > gert > > > -- > now what should I write here... > > 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 signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Poll Question (VRF scale on MX)
Hi Jason, you’re right … the claims means that there is no (extra) software restriction besides what the hardware can deliver itself. The MX204 should have the following scale limits: FIB:10M (IPv4 and IPv6 combined) RIB:80M (IPv4); 50M (IPv6) VRFs: 6050 Mostly the given values are single scaled. So make sure you test that in a multiscale enviroment. — Sebastian Becker s...@lab.dtag.de > Am 21.12.2017 um 13:24 schrieb Jason Lixfeld <jason-j...@lixfeld.ca>: > > Hey there, > > General question - MX204-IR, for example, claims no RIB/FIB scale > restrictions. While I’m sure with that claim, RIB scale is limited to the > amount of physical memory available on the box, I’m not sure what the > physical limits are around the FIB. My understanding is that it’s Trio Gen 3 > based, but to that, I don’t actually know enough about the architecture yet > to be sure. > > Thanks! > >> On Dec 21, 2017, at 6:19 AM, <adamv0...@netconsultings.com> >> <adamv0...@netconsultings.com> wrote: >> >> Hi folks, >> >> I have this large scale rollout and while doing scaling testing and Juniper >> recommendations will get you some confidence, I'd like to understand where >> we land on the graph in comparison with other operators (can't get this info >> from Juniper folks unfortunately). >> But we can build our own anonymous public database right here on the list. >> So what I'd like to collect from you all is: >> >> Junos code version: >> Number of VRFs: >> Number of destinations (total or average per VRF): >> Output from: request pfe execute target fpc0 command "show jnh 0 pool" (+ >> type of card this was executed on) >> - this output will tell you where you are at with regards to your >> next-hop memory utilization (whether you are within the pre-allocated 2+2M >> or already borrowing something from the shared pool) >> >> You can contact me on or off list and I shall publish a summary graph >> (anonymous of course) >> >> Thank you very much. >> >> adam >> >> netconsultings.com >> ::carrier-class solutions for the telecommunications industry:: >> >> >> ___ >> 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
Re: [j-nsp] Experience with Junos 15.1 on MX960?
I recommend Junos 16.1R4 as minimum. They have done some improvements to the software quality. We are on 16.1R4-S6.3 and it looks good so far. — Sebastian Becker > Am 12.12.2017 um 10:52 schrieb Karl Gerhard <karl_g...@gmx.at>: > > > Hello > > we've had very bad experience with Junos 15.1 on our switches (EX4550, > EX4300, EX4200). > Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum > required Junos version for this RE is 15.1. Can anyone share their experience > with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be > wiser to jump directly to 16.1/16.2/17.1/17.2/17.3? > > We're especially interested in bugs/problems related to MC-LAG. > > Regards > Karl > ___ > 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] Enhanced MX480 Midplane?
Yes, this is true for the MX960. — Sebastian Becker s...@lab.dtag.de > Am 09.12.2017 um 18:34 schrieb Aaron Gould <aar...@gvtc.com>: > > > Is this true about MX960? Does it have a midplane also ? > > -Aaron > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Enhanced MX480 Midplane?
Hi all, so after checking that with Juniper we have got an update: MPC7E with SCBE2, Fabric Redundancy, Premium2 und Premium3: 340G Premium2 Chassis (non-enhanced midplane): MPC5E 205G MPC7E 400G - now 340G Premium3 Chassis (enhanced midplane): MPC5E 240G MPC7E 480G - now 340G So even the MPC7-10G will have a performace penalty on both midplanes in the redundancy mode. — Sebastian Becker > Am 17.11.2017 um 17:38 schrieb Eduard Schornig <edu...@schornig.ro>: > > Hi, > > Sebastian is correct, MPC7-MRATE has a performance penalty on old > midplane. There is no difference for MPC7-10G (40 x 10G). > > -- > BR, > Eduard Schornig > > On Thu, Nov 16, 2017 at 5:43 PM, Tobias Heister <li...@tobias-heister.de > <mailto:li...@tobias-heister.de>> wrote: > Hi, > > Am 16.11.2017 um 10:36 schrieb Sebastian Becker: > this is the information out of the "Juniper Tech Club" in Cologne in June > 2016. So not only provided to us. > If needed I can verify that with Juniper. > > Feel free to do that. My informationen and recent verification from Juniper > confirm my assumption (hence no speed difference between midplanes for MPC7 > and only 480G in 3+0) > > > -- > Kind Regards > Tobias Heister > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > <mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > <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] Enhanced MX480 Midplane?
Hi Tobias, this is the information out of the "Juniper Tech Club" in Cologne in June 2016. So not only provided to us. If needed I can verify that with Juniper. — Sebastian Becker > Am 15.11.2017 um 16:07 schrieb Tobias Heister <li...@tobias-heister.de>: > > > Hi, > > Am 15.11.2017 um 09:13 schrieb Sebastian Becker: >> that’s not right. You need to differ between redundancy and >> non-redundancy-mode: >> With Fabric Redundancy in MX960 (SCBEs: 2 active, 1 spare): >> Premium2 Chassis (non-enhanced midplane): >> MPC5E205G >> MPC7E400G >> Premium3 Chassis (enhanced midplane): >> MPC5E240G >> MPC7E480G >> In the non-redundant mode (so all three SCBEs are online and active) you >> will not suffer from any limitation as long as all three are online. But if >> one dies you will have the limitations in a Premium2 chassis. So it depends >> on the model you want to use. We need a full redundant switching fabric so >> we have to calculate with these limitations. > > At least according to my information there is no difference in enhanced/non > enhanced for MPC7 on SCBE2 in any MX. > There is no way to get full 480G with 2+1 with SCBE2. You can get 480 in 3+0 > mode. (both on MX960) > > The first SCB* with 2+1 and Linerate for MPC7 will be SCBE3. > > But hey, your version would make more sense but all my documents and > information since the release of MPC7 say otherwise. > On the other hand there are not many customers in DE who would/should know > better :) > > -- > Kind Regards > Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Enhanced MX480 Midplane?
Hi Tobias, that’s not right. You need to differ between redundancy and non-redundancy-mode: With Fabric Redundancy in MX960 (SCBEs: 2 active, 1 spare): Premium2 Chassis (non-enhanced midplane): MPC5E 205G MPC7E 400G Premium3 Chassis (enhanced midplane): MPC5E 240G MPC7E 480G In the non-redundant mode (so all three SCBEs are online and active) you will not suffer from any limitation as long as all three are online. But if one dies you will have the limitations in a Premium2 chassis. So it depends on the model you want to use. We need a full redundant switching fabric so we have to calculate with these limitations. — Sebastian Becker > Am 14.11.2017 um 23:35 schrieb Tobias Heister <li...@tobias-heister.de>: > > > Hi, > > Am 14.11.2017 um 13:27 schrieb Sebastian Becker: >> The enhanced midplane allows you already to use higher bandwidth with >> redundancy at least on the MX960. 205G per slot (not > enhanced) against >> 240G per slot (enhanced) So if you want to use a MPC5E-100G10G and populate >> every port (2x100G plus 4x10G) > you need the enhanced midplane and the >> SCBE2. Same for the MPC5E-40G10G and the Q-Versions of these cards. >> Otherwise you > overbook the midplane. > > Funny enough the MPC7 has no reduced Bandwidth with the non enhanced > Midplane, so for now only MPC4/5 suffer from that old midplane. I always > wondered why that is the case. Might be a combination of PFE/Trio Generation > and frequency/speed per Serdes to Fabric connectivity. If somebody knows the > details i am eager to know. > > We will see what SCBE3 might bring there (other than allowing us to run MPC7 > at full speed with redundancy and pave the way for future MPC) > > -- > Kind Regards > Tobias Heister > ___ > 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] Enhanced MX480 Midplane?
The enhanced midplane allows you already to use higher bandwidth with
redundancy at least on the MX960. 205G per slot (not enhanced) against 240G per
slot (enhanced) So if you want to use a MPC5E-100G10G and populate every port
(2x100G plus 4x10G) you need the enhanced midplane and the SCBE2. Same for the
MPC5E-40G10G and the Q-Versions of these cards. Otherwise you overbook the
midplane.
—
Sebastian Becker
> Am 14.11.2017 um 11:38 schrieb Olivier Benghozi <olivier.bengh...@wifirst.fr>:
>
>
> While I don't care about SONET/SDH in 2017 (sorry...), the enhanced midplane
> (in the MX240/480/960 MX generation) also (mainly?) allows more bandwidth per
> slot with the future SCBE3.
> You may find a fugitive Juniper 2016 PDF on your preferred search engine
> ("SCBE3" "premium3" "mx").
>
>> On 14 nov. 2017 at 09:56, Karl Gerhard <karl_g...@gmx.at> wrote :
>>
>> this article is mentioning an enhanced MX480 midplane. This is the first
>> time I hear of that: CHAS-BP-MX480-S (=Non-Enhanced) vs. CHAS-BP3-MX480-S
>> (=Enhanced)
>> https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/scbe2-mx480-desc.html
>>
>> Is there anyone who can give more details about the enhanced midplane?
>> As far as I understand the cross-coupling of clock input is only related to
>> SONET/SDH stuff, is that correct?
>
> ___
> 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] ACX5048 - 40 gbps ER 40 km optic
Look at the receive power … there’s no light. Cable??? Juniper may has to update their support matrix then if they support that optic in this box! ;-) Tell them! — Sebastian Becker s...@lab.dtag.de > Am 04.10.2017 um 16:00 schrieb Aaron Gould <aar...@gvtc.com>: > > Lane 0 >Laser output power: 1.135 mW / 0.55 dBm >Laser receiver power : 0.000 mW / -40.04 dBm > > Lane 1 >Laser output power: 1.517 mW / 1.81 dBm >Laser receiver power : 0.000 mW / -40.04 dBm > (…) > Lane 0 >Laser output power: 1.510 mW / 1.79 dBm >Laser receiver power : 0.000 mW / -40.04 dBm > > Lane 1 >Laser output power: 1.785 mW / 2.52 dBm >Laser receiver power : 0.000 mW / -37.01 dBm > (…) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5048 - 40 gbps ER 40 km optic
Hi Aaron, Juniper does not list that modul as supported for your platform: https://pathfinder.juniper.net/hct/product/#prd=ACX5000 <https://pathfinder.juniper.net/hct/product/#prd=ACX5000> Maybe the power budget per port is not high enough for the 40km laser. And you should not connect them directly because you may blow up the receiver - launch power is higher than the receiver might can handle: Average launch power per lane –2.7 through 4.5 dBm Average receive power per lane –21.2 through -4.5 dBm https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/transceiver-t1600-t640-40gbase-optical-specifications.html#jd0e389 <https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/transceiver-t1600-t640-40gbase-optical-specifications.html#jd0e389> — Sebastian Becker ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 MS-MPC-128G CHASSISD_SNMP_TRAP10 jnxFruOfflineReason 8 but no button press
Hi Dave, We had such an issue with the PTX and it turned out they had some bad quality of the buttons so that the normal shaking from the fan trays can lead to a button press. You need to go to the JTAC for further investigation. -- Sebastian Becker s...@lab.dtag.de > Am 08.02.2017 um 22:31 schrieb Michael Gehrmann <mgehrm...@atlassian.com>: > > > Hi David, > > Might be worth checking for core dumps. I'd also do a PR search for and > check on release notes for later releases. I have previously found on rare > occasion MS cards can get into weird corner cases which normally involve > JTAC to resolve. > > Regards > Mike > > On 9 February 2017 at 14:14, David B Funk <dbf...@engineering.uiowa.edu > <mailto:dbf...@engineering.uiowa.edu>> > wrote: > >> We have a MX480 with a pair of MS-MPC-128G service boards that are tied >> together as a 'ams' (mams-2 & mams-3 ) service aggregation for reliability. >> >> Occasionally one of them, for no apparent reason, will go offline and then >> back online while logging in 'chassid' log: >> >> CHASSISD_SNMP_TRAP10: SNMP trap generated: FRU power on >> (jnxFruContentsIndex 8, jnxFruL1Index 4, jnxFruL2Index 1, jnxFruL3Index 0, >> jnxFruName PIC: MS-MPC-PIC @ 3/0/*, jnxFruType 11, jnxFruSlot 3, >> jnxFruOfflineReason 2, jnxFruLastPowerOff 1052212977, jnxFruLastPowerOn >> 1052213068) >> (as well as a bunch of other stuff). >> >> According to Junos docs, "jnxFruOfflineReason 8" -> "buttonPress(8), -- >> offlined by button press" >> But I know that nobody was in the room at the time of those incidents, so >> the button couldn't have been pressed. >> >> I hadn't paid too much attention to this as it was only happening >> occasionally and was either one board or the other. But today there was a >> whole spate of such incidents (20 in less than 45 minutes) and at one point >> it took both MPCs off line at the same time (thus noticable >> service-interruptus ). >> >> In the 'messages' log there are lines that correspond: >> >> /kernel: peer_input_pending_internal:[4506] VKS0 for peer type 22 indx >> 12 reported a sb_state 32 = SBS_CANTRCVMORE >> /kernel: peer_inputs:4766 VKS0 closing connection peer type 22 indx 12 >> err 5 >> /kernel: pfe_listener_disconnect: conn dropped: listener idx=7, >> tnpaddr=0x13010080, reason: generic peer error >> datapath-traced[3960]: datapath_traced_connection_event_handler: >> Disconnected from MSPMAND >> mspd[3958]: Removed PIC connection state for fpc=3 pic=0 >> session=0x827a180 >> (FPC Slot 3, PIC Slot 0) ms30 kernel: svcs_ms2_app_sigcore_exit: >> sending UKERN_ST_DOWN (pid=190, td=0xc291f960, sig=6) >> (FPC Slot 3, PIC Slot 0) ms30 mspsmd[178]: mspsmd_connection_shutdown: >> Unexpected shutdown of connection, try reconnecting. >> /kernel: if_pfe_services_health_status: Generating Health status (down) >> msg for ifd : ms-3/0/0 >> /kernel: if_pfe_services_health_status: Generating health status (down) >> for AMS member mams-3/0/0 >> /kernel: if_pfe_ams_process_single_event: ifd:mams-3/0/0, ev = >> AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: ACTIVE, >> member_present_count = 2 >> /kernel: if_pfe_ams_process_member_down_event:Starting Discard Timer >> /kernel: aggr_link_op: link mams-3/0/0.1 (lidx=1) detached from bundle >> ams0.1 >> /kernel: if_pfe_ams_process_single_event:Done:mams-3/0/0, ev = >> AMS_EV_MEMBER_HSTATUS_DOWN agg_state UP, member_state: DISCARD, >> member_present_count = 2 >> /kernel: if_pfe_services_send_lb_options: PEER_BUILD_IPC_SLOT return >> NULL >> last message repeated 4 times >> mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 641, ifAdminStatus up(1), >> ifOperStatus down(2), ifName ms-3/0/0.0 >> mib2d[3969]: SNMP_TRAP_LINK_DOWN: ifIndex 734, ifAdminStatus up(1), >> ifOperStatus down(2), ifName mams-3/0/0.1 >> (FPC Slot 3, PIC Slot 0) ms30 kernel: msgring_drain_process: bind >> thread to hwtid (5) cpuid(5) >> (FPC Slot 3, PIC Slot 0) ms30 kernel: Kmernel thread "msgdrainthr5" >> (pid 21832) exited prematurely. >> >> Usually it runs for days at a time with out a single one of these >> incidents. >> So I cannot tell if I've got a hardware flakey or a software bug that is >> being triggered by some external events. >> >> Any suggestions? (other than opening a jtac case). >> >> -- >> Dave Funk University of Iowa >> College of Engineering >> 319/335-5751 FAX: 319/384-05
Re: [j-nsp] RE-S-X6-64G & ISSU?
Hi Aaron, but this is almost the other way round as you need another box where the virtual machine will run that steers both chassis. Running the master vm one one of the chassis will give you no additional redundancy at all. -- Sebastian Becker s...@lab.dtag.de > Am 14.11.2016 um 16:04 schrieb Aaron <aar...@gvtc.com>: > > > Have y'all ever thought through the benefits of having dual RE in one > chassis compared to 2 chassis with 1 RE in each ? > > Like if I'm thinking about getting a MX480 with dual RE... what about > instead, getting dual MX240 with 1 RE in each ? ...and possibly Virtual > Chassis'ing the dual MX240's as one virtual router > > Chassis diversity seems nice...then whatever would connect in that location, > can be redundantly connected to both MX240's. > > - Aaron > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE-S-X6-64G & ISSU?
Same here. Clearly the new RE will help (how good is still in evaluation) in software issues but failing hardware is not covered so there is still the need for a dual RE setup. -- Sebastian Becker s...@lab.dtag.de > Am 11.11.2016 um 07:44 schrieb Mark Tinka <mark.ti...@seacom.mu>: > > > > > On 11/Nov/16 00:44, Clarke Morledge wrote: > > >> >> Right now, we do employ redundant routing engines (1300s and 1800s), >> but mostly with ISSU in mind. The failure rate for routing engines, >> even with the older hard disk models, has been rather low, in our >> experience. So, the primary benefit has been to provide support for >> "hitless" upgrades via ISSU. > > We've had at least 3 RE's fail every year on different platforms, for > various reasons. That is too high for us. > > I think the ability to VM's is great, especially because you can > cut-over upgrades much more quickly, and you can have different versions > of Junos doing different things on the same box, e.g., one VM doing > Business services on 2 line cards, another VM doing Subscriber > Management on 2 other line cards, e.t.c. > > But I don't think it negates the need for dual RE's. RE's are still > fragile, and things happen. > > 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
Re: [j-nsp] Junos to IOS translation
Be aware that this is not like translating word by word to get the same functionality. The same will apply if you compare Google Translator against a real studied translator in person. -- Sebastian Becker s...@lab.dtag.de > Am 05.06.2016 um 17:51 schrieb Mark Tinka <mark.ti...@seacom.mu>: > > > > > On 5/Jun/16 16:37, Doug McIntyre wrote: > >> I would expect to find such a tool on *cisco's* website, its not like >> a vendor will write a tool for you to go away from them. But then >> again I wouldn't expect Cisco to be that accomidating either. >> >> I've not heard of such a tool, of course several vendors provide an IOS >> to their kit, but the opposite doesn't tend to happen all that often. And >> with the slight subtle differences in IOS vs IOS-XE and IOS-XR depending >> on what your target platform is, might be pretty difficult to maintain. >> >> It would probably be pretty straight forward to translate Juniper >> configs over to IOS, the layout of the config should be pretty >> straightforward and self-documenting (unlike IOS, with hidden defaults, >> or really magical things, like dynamic routing prefix filter lists). > > You can't even get an IOS to IOS XR converter, so no chance Cisco will > write a Junos to IOS converter. > > Back in 2008, when I deployed my first IOS XR box (a 4-slot CRS router), > I spent a month reading about IOS XR (3.9 at the time), and mapping > every IOS command to IOS XR where one existed. > > 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
Re: [j-nsp] EX4600: Splitting up one QSFP+ port into four SFP+ ports?
Same here … -- Sebastian Becker s...@lab.dtag.de > Am 18.03.2016 um 16:58 schrieb Jared Mauch <ja...@puck.nether.net>: > > We’ve seen varying quality of the MPO breakout cables where some > lanes/channels are 2dB or more weaker based on vendor when connected to the > QSFP-40G-PLR4 style optics. > > - Jared > >> On Mar 18, 2016, at 11:02 AM, Jay Hanke <jayha...@gmail.com> wrote: >> >> IIRC, The link budget isn't as strong as a 10 km Single mode. >> >> On Thu, Mar 17, 2016 at 7:42 AM, v <vekt...@gmx.net> wrote: >>> Thanks! >>> Are there any differences or disadvantages compared to a "real" SFP+ port? >>> (apart from the breakout cable that is) >>> >>> >>> Regards, >>> v >>> >>> >>> Am 2016-03-17 um 13:15 schrieb Bill Blackford: >>>> >>>> I haven't done this with an EX4600, but it is most likely the same. You >>>> need a 40G optic and an MTP breakout cable that plugs into the optic and >>>> splits out into 8 strands of LC or SC or whatever flavor you need. >>>> >>>> Sent from my iPhone >>>> >>>>> On Mar 17, 2016, at 03:40, v <vekt...@gmx.net> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I am interested in buying an EX4600 and curious about the QSFP+ ports. My >>>>> question is the following: >>>>> Can the QSFP+ ports really be split up into four fully featured SFP+ >>>>> ports? Are there any caveats or disadvantagas to this approach? >>>>> >>>>> I'm asking because the EX4600 costs just as much as the EX4550 (which has >>>>> 32 SFP+ ports). If we could split up the QSFP+ ports on the EX4600 to have >>>>> 40 fully featured SFP+ ports that would be awesome. >>>>> >>>>> Regards, >>>>> v >>>>> ___ >>>>> 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 > > ___ > 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] Optimizing the FIB on MX
Hi Ytti, I meant 9001 to 9010 and mx104 to mx240. cpu to cpu works, but than there is the software you mentioned. Back to Juniper. ;-) -- Sebastian Becker s...@lab.dtag.de > Am 18.02.2016 um 16:39 schrieb Saku Ytti <s...@ytti.fi>: > > > On 18 February 2016 at 17:29, Sebastian Becker <s...@lab.dtag.de> wrote: > > Hey Sebastian, > >> As AS9001 and AS9006/9010 have a different cpu architecture as MX104 and >> MX240/480/960 the comparison is not easy just by the type of the cpu itself. > > ASR9001 and MX104 use same Freescale QorIQ family, so it's very direct > comparison. Specsheets are publically available. > Larger MX and ASR9k use Intel X86/AMD64, so easy to compare. > > But of course the software is very different, and this MX104 issue > thread is about, does not exist in IOS-XR, regardless how slow CPU it > is rocking. > > -- > ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Optimizing the FIB on MX
Hi Ytti / Colton, ASR9001-RP cisco ASR9K Series (P4040) processor with 8388608K bytes of memory. P4040 processor at 1500MHz, Revision 3.0 This box ist only available as SE (service enhanced) version. A9K-RSP440-SE cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of memory. Intel 686 F6M14S4 processor at 2135MHz, Revision 2.174 There is a TR (transport) version with half the memory: http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/data_sheet_c78-674143.html A9K-RSP880-SE cisco ASR9K Series (Intel 686 F6M14S4) processor with 33554432K bytes of memory. Intel 686 F6M14S4 processor at 1904MHz, Revision 2.174 There is a TR (transport) version with half the memory: http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/datasheet-c78-733763.html As AS9001 and AS9006/9010 have a different cpu architecture as MX104 and MX240/480/960 the comparison is not easy just by the type of the cpu itself. -- Sebastian Becker s...@lab.dtag.de > Am 18.02.2016 um 16:06 schrieb Saku Ytti <s...@ytti.fi>: > > > On 18 February 2016 at 16:21, Colton Conor <colton.co...@gmail.com> wrote: > > Hey Colton, > >> What processor is in the Cisco 9001, and how does it compare to a MX104 in >> terms of speed and BGP Performance? > > ASR9001 is P4040 on RP, lower single core performance than MX104 > P5021. But the problem this thread addresses is not a problem IOS-XR > has. > >> What about a Cisco 9010 ASR9K Route Switch Processor with 440G/slot Fabric >> and 6GB? > > RSP440 is 4 core Intel, at about 2GHz. I'm actually sure which > specific Intel CPU. > > -- > ++ytti > ___ > 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
