Re: [j-nsp] 10.0 or 10.4?
Same story, here.. Upgraded to 10.4R3.4 on an MX480 with MX-MPC2-3D, here's what I've got: Mar 30 06:30:05 sns480-re0 fpc0 MQCHIP(0) LI Packet length error, pt entry 14 Mar 30 06:30:06 sns480-re0 fpc0 MQCHIP(0) LI Packet length error, pt entry 0 Mar 30 06:30:40 sns480-re0 fpc0 MQCHIP(0) LI Packet length error, pt entry 10 Mar 30 06:30:41 sns480-re0 fpc0 MQCHIP(0) LI Packet length error, pt entry 0 Is it causing any adverse effects, or simply being annoying in the logs? Has anyone confirmed? I haven't filed anything with JTAC (..yet), but this router isn't in production (..yet) for IPv4, and this isn't my first issue with 10.4R3.4. -- Jonathan Towne On Fri, Mar 25, 2011 at 12:04:43AM +0100, Daniel Roesen scribbled: # On Thu, Mar 24, 2011 at 10:19:59PM +0100, bas wrote: # I tried running 10.4R3 on the MX960, but immediately it reported MQCHIP errors. # # Mar 23 08:10:17 jun-tc2_re0 fpc4 MQCHIP(0) LI Packet length error, pt entry 9 # Mar 23 08:10:18 jun-tc2_re0 fpc4 MQCHIP(0) LI Packet length error, pt entry 0 # Mar 23 08:10:19 jun-tc2_re0 fpc1 MQCHIP(1) LI Packet length error, pt entry 28 # Mar 23 08:10:20 jun-tc2_re0 fpc9 MQCHIP(1) LI Packet length error, pt entry 0 # # We see that on MX80 too, right since upgrading the (totally idle) box. # Pending JTAC response... # # Best regards, # Daniel # # -- # CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 # ___ # 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] 10.0 or 10.4?
Has anyone tried running 10.4R3 on a M working as a MPLS-PE? Reason is I am experiencing an odd issue with an M10i not forwarding CE traffic when I have two DS-3s installed with equal cost. A/JTAC and my SE have been unable to figure this out and are pulling a brand C and saying upgrade code and all your woes will go away. On Tue, Mar 22, 2011 at 12:18 PM, Richard A Steenbergen r...@e-gerbil.netwrote: On Tue, Mar 22, 2011 at 05:18:47PM +0100, bas wrote: From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as the better choice, and people who talk to JTAC say 10.4r2 is the better choice. Oh and btw, I have multiple confirmed reports of YET ANOTHER major memory leak in mib2d in 10.4R2. Hope everyone learned their lesson about trusting JTAC version recommendations. :) From 10.4R3 release notes: The mib2d process leaks memory during SNMP walks. [PR/586074: This issue has been resolved.] I'm going to assume it's that. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] 10.0 or 10.4?
To reply to my own email. I tried running 10.4R3 on the MX960, but immediately it reported MQCHIP errors. Mar 23 08:10:17 jun-tc2_re0 fpc4 MQCHIP(0) LI Packet length error, pt entry 9 Mar 23 08:10:18 jun-tc2_re0 fpc4 MQCHIP(0) LI Packet length error, pt entry 0 Mar 23 08:10:19 jun-tc2_re0 fpc1 MQCHIP(1) LI Packet length error, pt entry 28 Mar 23 08:10:20 jun-tc2_re0 fpc9 MQCHIP(1) LI Packet length error, pt entry 0 So we are back on 10.3R3 again, this time without rpd at 100% CPU. On the maillist of a large European Internet exchange there was a post of another network that had to downgrade to 10.3 due to a big issue with IPv6 that affects all 10.4 releases. (PR/593849) So it seems 10.4 is certainly a version to avoid for now. Dear Juniper, if you are reading this; Please, please pretty please deliver _one_ single version of Junos that can run plain v4/v6 ospf and bgp with MX/trio in a decent fashion. With sugar on top. ? Bas On Tue, Mar 22, 2011 at 5:18 PM, bas kilo...@gmail.com wrote: Well, after this thread I still didn't know which version I should choose for our 960 with MPC's only. From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as the better choice, and people who talk to JTAC say 10.4r2 is the better choice. (Of course it depends on configuration and config.) But we chose to upgrade to 10.3r3, and installed the version this morning. The upgrade seemed to have gone smooth, but after all BGP sessions had been re-established, and prefixes re-learnt the CPU stayed at 100%. Dropping to shell I saw rpd consuming 99% CPU. Looking at task accounting and rtsockmon I saw no obvious causes. A failover to the backup RE had no effect, the new master RE consumed 100% within a couple of minutes. A colleague of mine did a trace of the process saw that the cycles are being consumed by getrusage system calls. Tomorrow morning we'll try to restart routing, if that has no effect we will try 10.4r2. I'll post tomorrow our findings.. Bas ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Thu, Mar 24, 2011 at 10:19:59PM +0100, bas wrote: I tried running 10.4R3 on the MX960, but immediately it reported MQCHIP errors. Mar 23 08:10:17 jun-tc2_re0 fpc4 MQCHIP(0) LI Packet length error, pt entry 9 Mar 23 08:10:18 jun-tc2_re0 fpc4 MQCHIP(0) LI Packet length error, pt entry 0 Mar 23 08:10:19 jun-tc2_re0 fpc1 MQCHIP(1) LI Packet length error, pt entry 28 Mar 23 08:10:20 jun-tc2_re0 fpc9 MQCHIP(1) LI Packet length error, pt entry 0 We see that on MX80 too, right since upgrading the (totally idle) box. Pending JTAC response... Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Tue, Mar 22, 2011 at 05:18:47PM +0100, bas wrote: Hi All, Well, after this thread I still didn't know which version I should choose for our 960 with MPC's only. From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as the better choice, and people who talk to JTAC say 10.4r2 is the better choice. (Of course it depends on configuration and config.) But we chose to upgrade to 10.3r3, and installed the version this morning. The upgrade seemed to have gone smooth, but after all BGP sessions had been re-established, and prefixes re-learnt the CPU stayed at 100%. Dropping to shell I saw rpd consuming 99% CPU. Looking at task accounting and rtsockmon I saw no obvious causes. A failover to the backup RE had no effect, the new master RE consumed 100% within a couple of minutes. A colleague of mine did a trace of the process saw that the cycles are being consumed by getrusage system calls. Tomorrow morning we'll try to restart routing, if that has no effect we will try 10.4r2. Haven't seen that here. Both 10.3R3 and 10.4R2 picked up a very similar set of fixes (they have very close release dates) for major PRs which were giving us grief, but 10.3R3 seemed to introduce less new ones in the process. 10.4R3 just came out yesterday, so feel free to give it a shot and report back, but most of our 10.3R3 issues have been relatively less bad than normal. Occasional logging of these junk messages: Mar 22 11:47:12.629 re1.xx1.xxx1 /kernel: %KERN-3: Unlist request: unilist(nh index = 1049538) found on the rnhlist_deleted_root patnode, hence returning Logging of these junk messages (note the incorrect timestamps too, these were actually logged AFTER the Mar 22 output above :P): Mar 4 10:29:50.527 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:07.860442 Mar 4 10:47:22.577 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:22.570405 Mar 4 10:55:44.479 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:21.765648 Mar 4 10:59:59.056 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:19.371199 Mar 4 11:02:04.228 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:18.704278 Weird stuff like that. Probably the worst issue we've seen so far is that on MX w/MPC cards (not sure if its the sw or hw) doing an l2circuit to a vlan-ccc endpoint and then confusing vlan-maps to push/pop the vlan tag off of the packet before encapsulating in the pseudowire (so you can mismatch vlan IDs on the endpoints) seems to block ISIS packets from being transported (most likely blocking 802.3 LLC frames is my guess). On EX there is a definite problem with the power supplies getting stuck 110v low power mode as far as the chassis is concerned, which is an issue if you need 220v power to fully and redundantly power your FPCs. But at least this code hasn't crashed or blown up massively yet (or failed to do some really important operation like say correctly counting packets in SNMP so you can bill your customers), which is definitely an improvement over a lot of other recent JUNOS code. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Tue, Mar 22, 2011 at 05:18:47PM +0100, bas wrote: From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as the better choice, and people who talk to JTAC say 10.4r2 is the better choice. Oh and btw, I have multiple confirmed reports of YET ANOTHER major memory leak in mib2d in 10.4R2. Hope everyone learned their lesson about trusting JTAC version recommendations. :) From 10.4R3 release notes: The mib2d process leaks memory during SNMP walks. [PR/586074: This issue has been resolved.] I'm going to assume it's that. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
After upgrading from 10.1 to 10.4R1.9 on a set of our dual-RE2000 MX960's we observed that the re1's fxp's were no longer IP-reachable. Console and session to other-route-engine both work fine, as does GRES. Same behavior on multiple dual-RE MXs. JTAC has confirmed the group config as OK, but hasn't been able to recreate the problem. I'd love to hear from anyone that has seen similar. Paul Z On Mar 17, 2011, at 16:52 , Keegan Holley wrote: Are these all 10.4R2 bugs or 10.2? PR588115 - Changing the forwarding-table export policy twice in a row quickly (while the previous change is still being evaluated) will cause rpd to coredump. PR581139 - Similar to above, but causes the FPC to crash too. Give it several minutes before you commit again following a forwarding-table export policy change. PR523493 - Mysterious FPC crashes PR509303 - Massive SNMP slowness and stalls, severely impacting polling of 10.2R3 boxes with a decent number of interfaces (the more interfaces the worse the situation). PR566782 PR566717 PR540577 - Some more mysterious rpd and pfem crashes, with extra checks added to prevent it in the future. PR559679 - Commit script transient change issue, which sometimes causes changes to not be picked up correctly unless you do a commit full. PR548166 - Sometimes most or all BGP sessions on a CPU loaded box will drop to Idle following a commit and take 30+ minutes to come back up. PR554456 - Sometimes netconf connections to EX8200's will result in junk error messages being logged to the XML stream, corrupting the netconf session. PR550902 - On a CPU loaded box sometimes BGP policy-statement evaluation will simply stop working, requiring a hard clear of the neighbor (or ironically enough, sometimes just renaming the term in the policy will fix it :P) to restore normal evaluation. PR521993 - Ports on EX8200 FPCs will sometimes not initialize correctly, resulting in situations where for example ports 4 and 5 on every FPC will be able to receive packets but never transmit them. If you continue to try and transmit packets down a wedged port (such as would happen if the port is configured for L2), it will cause the FPC to crash. ___ 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] 10.0 or 10.4?
You have a backup-router configured in the re1 group? -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Zugnoni Sent: Saturday, March 19, 2011 12:21 PM To: juniper-nsp Cc: Richard A Steenbergen Subject: Re: [j-nsp] 10.0 or 10.4? After upgrading from 10.1 to 10.4R1.9 on a set of our dual-RE2000 MX960's we observed that the re1's fxp's were no longer IP-reachable. Console and session to other-route-engine both work fine, as does GRES. Same behavior on multiple dual-RE MXs. JTAC has confirmed the group config as OK, but hasn't been able to recreate the problem. I'd love to hear from anyone that has seen similar. Paul Z On Mar 17, 2011, at 16:52 , Keegan Holley wrote: Are these all 10.4R2 bugs or 10.2? PR588115 - Changing the forwarding-table export policy twice in a row quickly (while the previous change is still being evaluated) will cause rpd to coredump. PR581139 - Similar to above, but causes the FPC to crash too. Give it several minutes before you commit again following a forwarding-table export policy change. PR523493 - Mysterious FPC crashes PR509303 - Massive SNMP slowness and stalls, severely impacting polling of 10.2R3 boxes with a decent number of interfaces (the more interfaces the worse the situation). PR566782 PR566717 PR540577 - Some more mysterious rpd and pfem crashes, with extra checks added to prevent it in the future. PR559679 - Commit script transient change issue, which sometimes causes changes to not be picked up correctly unless you do a commit full. PR548166 - Sometimes most or all BGP sessions on a CPU loaded box will drop to Idle following a commit and take 30+ minutes to come back up. PR554456 - Sometimes netconf connections to EX8200's will result in junk error messages being logged to the XML stream, corrupting the netconf session. PR550902 - On a CPU loaded box sometimes BGP policy-statement evaluation will simply stop working, requiring a hard clear of the neighbor (or ironically enough, sometimes just renaming the term in the policy will fix it :P) to restore normal evaluation. PR521993 - Ports on EX8200 FPCs will sometimes not initialize correctly, resulting in situations where for example ports 4 and 5 on every FPC will be able to receive packets but never transmit them. If you continue to try and transmit packets down a wedged port (such as would happen if the port is configured for L2), it will cause the FPC to crash. ___ 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] 10.0 or 10.4?
backup-router - Originally we did not have this. Our SE and JTAC suggested it, so we added it. Adding it did not change the situation (we didn't originally need a backup router because fxp0 was being used for inbound-only emergency access from a local subnet IP). I forgot to mention in this thread that fxp0 is added to a logical system to keep the mgmt subnet out of inet.0 as a direct route. Removing the logical system in our lab case made re1 fxp0 reachable again, though, its reachability didn't survive a reboot. Paul Z On Mar 19, 2011, at 13:56 , Doug Hanks wrote: You have a backup-router configured in the re1 group? -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Zugnoni Sent: Saturday, March 19, 2011 12:21 PM To: juniper-nsp Cc: Richard A Steenbergen Subject: Re: [j-nsp] 10.0 or 10.4? After upgrading from 10.1 to 10.4R1.9 on a set of our dual-RE2000 MX960's we observed that the re1's fxp's were no longer IP-reachable. Console and session to other-route-engine both work fine, as does GRES. Same behavior on multiple dual-RE MXs. JTAC has confirmed the group config as OK, but hasn't been able to recreate the problem. I'd love to hear from anyone that has seen similar. Paul Z On Mar 17, 2011, at 16:52 , Keegan Holley wrote: Are these all 10.4R2 bugs or 10.2? PR588115 - Changing the forwarding-table export policy twice in a row quickly (while the previous change is still being evaluated) will cause rpd to coredump. PR581139 - Similar to above, but causes the FPC to crash too. Give it several minutes before you commit again following a forwarding-table export policy change. PR523493 - Mysterious FPC crashes PR509303 - Massive SNMP slowness and stalls, severely impacting polling of 10.2R3 boxes with a decent number of interfaces (the more interfaces the worse the situation). PR566782 PR566717 PR540577 - Some more mysterious rpd and pfem crashes, with extra checks added to prevent it in the future. PR559679 - Commit script transient change issue, which sometimes causes changes to not be picked up correctly unless you do a commit full. PR548166 - Sometimes most or all BGP sessions on a CPU loaded box will drop to Idle following a commit and take 30+ minutes to come back up. PR554456 - Sometimes netconf connections to EX8200's will result in junk error messages being logged to the XML stream, corrupting the netconf session. PR550902 - On a CPU loaded box sometimes BGP policy-statement evaluation will simply stop working, requiring a hard clear of the neighbor (or ironically enough, sometimes just renaming the term in the policy will fix it :P) to restore normal evaluation. PR521993 - Ports on EX8200 FPCs will sometimes not initialize correctly, resulting in situations where for example ports 4 and 5 on every FPC will be able to receive packets but never transmit them. If you continue to try and transmit packets down a wedged port (such as would happen if the port is configured for L2), it will cause the FPC to crash. ___ 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] 10.0 or 10.4?
On Tue, Mar 15, 2011 at 10:57:56AM -0700, Steve Feldman wrote: What sorts of bugs did you see in 10.4R2? We were just testing 10.4 on MX, since EX features are being a lot more actively developed, thus making major version jumps much more risky. For example, when we tried moving from 10.1 to 10.2 on EX8200 we discovered a major SNMP issue caused by some internal changes that broke polling and caused severe billing issues. There are a lot of firewall specific changes in 10.4 for EX which we wanted more time to properly test before deploying, since this is an area which tends to cause major outages when bugs do pop up. I already outlined a few of the issues we found on 10.4R2 on MX in a previous post, and seeing as it seemed much less stable than 10.3R3 for near equivalent features and bugfixes I didn't see the point of pursuing it further right now. JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in 10.1R4) where some of our firewall filter rules were being silently ignored. Well, here is what I can tell you about the reasons behind our most recent move to 10.3R3 on EX8200 (where these are all fixed). A couple of these were actually fixed in 10.2R3, but a few other nasty issues were introduced at the same time, making 10.2R3 unusable in production. We're heading towards 11.1 in the near future for other reasons anyways, which is why we went after 10.3R3 instead of 10.2R4 for our next major code goal, but 10.4R2 was definitely not confidence inspiring based on the issues we saw under MX. :) PR588115 - Changing the forwarding-table export policy twice in a row quickly (while the previous change is still being evaluated) will cause rpd to coredump. PR581139 - Similar to above, but causes the FPC to crash too. Give it several minutes before you commit again following a forwarding-table export policy change. PR523493 - Mysterious FPC crashes PR509303 - Massive SNMP slowness and stalls, severely impacting polling of 10.2R3 boxes with a decent number of interfaces (the more interfaces the worse the situation). PR566782 PR566717 PR540577 - Some more mysterious rpd and pfem crashes, with extra checks added to prevent it in the future. PR559679 - Commit script transient change issue, which sometimes causes changes to not be picked up correctly unless you do a commit full. PR548166 - Sometimes most or all BGP sessions on a CPU loaded box will drop to Idle following a commit and take 30+ minutes to come back up. PR554456 - Sometimes netconf connections to EX8200's will result in junk error messages being logged to the XML stream, corrupting the netconf session. PR550902 - On a CPU loaded box sometimes BGP policy-statement evaluation will simply stop working, requiring a hard clear of the neighbor (or ironically enough, sometimes just renaming the term in the policy will fix it :P) to restore normal evaluation. PR521993 - Ports on EX8200 FPCs will sometimes not initialize correctly, resulting in situations where for example ports 4 and 5 on every FPC will be able to receive packets but never transmit them. If you continue to try and transmit packets down a wedged port (such as would happen if the port is configured for L2), it will cause the FPC to crash. There are also significant BGP convergence performance improvements introduced in 10.3R3 and 10.4R2 if you have a lot of routes with communities on them. For us this reduced convergence times on EX8200 with a few transit and ibgp rr feed views (~2mil paths) from 1 hour+ to 15-20 minutes. Still not good by any means, but significantly less bad. Of course there are a few other issues introduced in 10.3R3 too (shocker, that NEVER happens :P), but I already discussed them previously. Ultimately I think 10.4 will be more interesting in its R3 or R4 timeframe, with SRs past that, but I don't think we're going to end up using it much on EX8200 (as I said, we're being forced into 11.1 to support specific hardware anyways). -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Are these all 10.4R2 bugs or 10.2? PR588115 - Changing the forwarding-table export policy twice in a row quickly (while the previous change is still being evaluated) will cause rpd to coredump. PR581139 - Similar to above, but causes the FPC to crash too. Give it several minutes before you commit again following a forwarding-table export policy change. PR523493 - Mysterious FPC crashes PR509303 - Massive SNMP slowness and stalls, severely impacting polling of 10.2R3 boxes with a decent number of interfaces (the more interfaces the worse the situation). PR566782 PR566717 PR540577 - Some more mysterious rpd and pfem crashes, with extra checks added to prevent it in the future. PR559679 - Commit script transient change issue, which sometimes causes changes to not be picked up correctly unless you do a commit full. PR548166 - Sometimes most or all BGP sessions on a CPU loaded box will drop to Idle following a commit and take 30+ minutes to come back up. PR554456 - Sometimes netconf connections to EX8200's will result in junk error messages being logged to the XML stream, corrupting the netconf session. PR550902 - On a CPU loaded box sometimes BGP policy-statement evaluation will simply stop working, requiring a hard clear of the neighbor (or ironically enough, sometimes just renaming the term in the policy will fix it :P) to restore normal evaluation. PR521993 - Ports on EX8200 FPCs will sometimes not initialize correctly, resulting in situations where for example ports 4 and 5 on every FPC will be able to receive packets but never transmit them. If you continue to try and transmit packets down a wedged port (such as would happen if the port is configured for L2), it will cause the FPC to crash. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Mar 15, 2011, at 6:27 PM, Daniel Roesen wrote: Our RANCID caught that on on of our lab MXes within less then one hour after upgrading the box. Systest didn't - or it wasn't deemed a show-stopper for release. I've found it interesting how many defects can be caught by reviewing the pre vs post upgrade diffs on devices, including both IOS and JunOS. I've never found anyone at the vendors that seemed to care that much about it though. It's much worse in IOS and their ad-hoc configuration system. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Mar 15, 2011, at 10:42 PM, Bjørn Tore Paulen wrote: Den 15.03.2011 23:19, skrev Doug Hanks: I can confirm this as well. Junos Transformation/Ironman started with 10.4R2. There should be a meaningful difference. I know they've increased the regression testing scripts by nearly 500%. Here is one meaningful difference - DHCP relay used to work. ;-p Have you seen this on an EX? DHCP relay seems to work just fine in 10.4R2 on our lab EX8200. We haven't tested it yet on an SRX. Steve ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
This specifically did not work on the SRX. Of course, we didn't notice that until some time after the upgrade and hosts started falling offline. On Mar 16, 2011, at 11:36 AM, Steve Feldman wrote: On Mar 15, 2011, at 10:42 PM, Bjørn Tore Paulen wrote: Den 15.03.2011 23:19, skrev Doug Hanks: I can confirm this as well. Junos Transformation/Ironman started with 10.4R2. There should be a meaningful difference. I know they've increased the regression testing scripts by nearly 500%. Here is one meaningful difference - DHCP relay used to work. ;-p Have you seen this on an EX? DHCP relay seems to work just fine in 10.4R2 on our lab EX8200. We haven't tested it yet on an SRX. Steve ___ 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] 10.0 or 10.4?
On Wed, Mar 16, 2011 at 02:58:50PM -0400, Chuck Anderson wrote: Such as 10.4R2 not showing transceivers on 16-port 10GE MPC in show chassis hardware anymore, but 10.4R1 did? :-) Works for me, 16-port MPC, 10.4R2. PR/584705 - perhaps there are situations where it doesn't happen. We have a few other issues with 10.4R2/Trio: Nice ones. We're already wearing our asbestos and look forward to a lot of fun. Though I'm looking forward to the day when Virtual Chassis comes to MX which will allow us to eliminate spanning tree and perhaps sidestep many of these weird looping issues. And then discover the world of tightly coupled systems which of course crash as a whole? :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Daniel Roesen [d...@cluenet.de] wrote: Though I'm looking forward to the day when Virtual Chassis comes to MX which will allow us to eliminate spanning tree and perhaps sidestep many of these weird looping issues. And then discover the world of tightly coupled systems which of course crash as a whole? :-) You may ultimately find MC-AE more to your taste once that feature set is complete and baked in. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Wed, Mar 16, 2011 at 12:24:13PM -0700, Gregory Maxwell wrote: Daniel Roesen [d...@cluenet.de] wrote: Though I'm looking forward to the day when Virtual Chassis comes to MX which will allow us to eliminate spanning tree and perhaps sidestep many of these weird looping issues. And then discover the world of tightly coupled systems which of course crash as a whole? :-) You may ultimately find MC-AE more to your taste once that feature set is complete and baked in. Nope. It places too much faith in third-party LACP implementations that aren't up to the task in our case. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 10.0 or 10.4?
I know the subject of JunOS versions has been beaten to death, but I've never seen this specific question asked or answered. I'm trying to decide between 10.0 or 10.4 for a network of MX, M (10i, 120 and 40e) and J series routers. I'd like to choose a train with extended support. I'm trying to decide between the risk of undiscovered bugs in 10.4 and having to upgrade sooner when 10.0 goes EOS. We run L3VPN, with some L2VPN and a shrinking VPLS footprint. Most of the M's and MX's have a full table with some acting as regional route reflectors. Just wanted to get the general opinion of those running similar applications. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Just installed 14 x MX960s for a large Aussie Mobile company - The release train we've decided on is 10.4R2 for now, due to EEOL support; and the fact that 10.0 didn't support a few of the cards we added. (16x10GE Trio for example didn't come till 10.2). I have also hear that 10.4 also included a mass re-write/re-development of a lot of the JunOS code; trying to bring it back within a manageable framework. (Note how it went from 10.2R3 to 10.4, skipping a 10.3 release for some platforms). Hence, 10.4 is the new code base. I don't know if this is a good thing or a bad thing initially, but should only improve with time. I'd like to standardize all the other devices in my network to 10.4; once the suggest JTAC releases goes past 10.2R3 for things like SRX platforms. - Chris. P.S. JunOS may go to 3 releases per year now as well, so there may only be an 11.1/.2/.3 for 2011. On 2011-03-15, at 7:13 PM, Keegan Holley wrote: I know the subject of JunOS versions has been beaten to death, but I've never seen this specific question asked or answered. I'm trying to decide between 10.0 or 10.4 for a network of MX, M (10i, 120 and 40e) and J series routers. I'd like to choose a train with extended support. I'm trying to decide between the risk of undiscovered bugs in 10.4 and having to upgrade sooner when 10.0 goes EOS. We run L3VPN, with some L2VPN and a shrinking VPLS footprint. Most of the M's and MX's have a full table with some acting as regional route reflectors. Just wanted to get the general opinion of those running similar applications. ___ 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] 10.0 or 10.4?
Den 15.03.2011 09:43, skrev Chris Kawchuk: Just installed 14 x MX960s for a large Aussie Mobile company - The release train we've decided on is 10.4R2 for now, due to EEOL support; and the fact that 10.0 didn't support a few of the cards we added. (16x10GE Trio for example didn't come till 10.2). I have also hear that 10.4 also included a mass re-write/re-development of a lot of the JunOS code; trying to bring it back within a manageable framework. (Note how it went from 10.2R3 to 10.4, skipping a 10.3 release for some platforms). Hence, 10.4 is the new code base. I don't know if this is a good thing or a bad thing initially, but should only improve with time. I'd like to standardize all the other devices in my network to 10.4; once the suggest JTAC releases goes past 10.2R3 for things like SRX platforms. Second that. We tried 10.4R2.7 on SRX. I guess Juniper didn't think anybody still were using DHCP relay and stuff.. /BT ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Hi, On Tue, Mar 15, 2011 at 8:37 PM, Bjørn Tore b...@paulen.net wrote: Den 15.03.2011 09:43, skrev Chris Kawchuk: I'd like to standardize all the other devices in my network to 10.4; once the suggest JTAC releases goes past 10.2R3 for things like SRX platforms. Second that. We tried 10.4R2.7 on SRX. I guess Juniper didn't think anybody still were using DHCP relay and stuff.. Ouch. I'm pinning some (but not all) hopes on 10.4R3. I'm told it's due to be released on the 21st of this month. 10.4 is also significant for us as it's the release undergoing Common Criteria evaluation (for J, SRX and LN1000-V) in Canada. It's the release train we'll be allowed to operate in (Australian) Government networks once certified locally. For our EX fleet (which aren't subject to the same Government guidelines/recommendations as they don't do crypto), I'm eagerly awaiting 10.4 to be stable as like Chris said, running EEOL code is nice. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Haven't touched 10.4 yet, but 10.0R3.10 has been very solid for us in what sounds to be a similar environment. Mostly L2VPNs here, with some VPLS (BGP and LDP) and VRF thrown in on MXs (240/480) and T640s (full table on all of them, in a VRF), 2 of which are acting as RRs in a limited capacity. Been running it since June 2010 without a single issue (something I haven't been able to say of earlier versions for a few years now). D On 15 March 2011 02:13, Keegan Holley keegan.hol...@sungard.com wrote: I know the subject of JunOS versions has been beaten to death, but I've never seen this specific question asked or answered. I'm trying to decide between 10.0 or 10.4 for a network of MX, M (10i, 120 and 40e) and J series routers. I'd like to choose a train with extended support. I'm trying to decide between the risk of undiscovered bugs in 10.4 and having to upgrade sooner when 10.0 goes EOS. We run L3VPN, with some L2VPN and a shrinking VPLS footprint. Most of the M's and MX's have a full table with some acting as regional route reflectors. Just wanted to get the general opinion of those running similar applications. ___ 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] 10.0 or 10.4?
On Tue, Mar 15, 2011 at 07:43:25PM +1100, Chris Kawchuk wrote: Just installed 14 x MX960s for a large Aussie Mobile company - The release train we've decided on is 10.4R2 for now, due to EEOL support; and the fact that 10.0 didn't support a few of the cards we added. (16x10GE Trio for example didn't come till 10.2). I hear people make this argument a lot, but in many cases it seems to be more of a knee-jerk reaction than a logical decision. The EEOL branches are definitely interesting once you get into the post-R4 timeframe, but I question the sensibility of trying to deploy it in the R2 timeframe just because it is the EEOL train. Honestly, in many cases the code doesn't even begin to get stable until it reaches R4 and EOL status. The problem we run into is that we almost always discover at least one serious bug in every R4, no matter how well-intentioned the development efforts, but because R4 marks the end of engineering status we're constantly chasing the next branch to get a bugfix for things introduced in the previous branch. Of course what that really means is we discover all new brokeness in the new branch, and the cycle starts all over again. EEOL releases can end up being a lot more stable since you aren't introducing any new features (though anyone who tells you they don't introduce a ton of new bugs just doing service releases is completely full of it :P), so they're a good thing. But, what is the real benefit to deploying 10.4R2 now, as opposed to say 10.3R3? Either way you'll have to do an upgrade later on, so until you get to 10.4R4 there is no difference in 10.4 being the EEOL branch. We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. Why JTAC is recommending it I can't even begin to guess, I really think they have the recommended version page hooked up to a random number generator some days, but in our testing it wasn't even close. Which isn't to say 10.3R3 is perfect, but it's definitely on the less broken than ever side of things. So far we haven't had any issues with Trio hardware or snmp problems that we saw in 10.2R3 or 10.3R2, and if you carry a large number of BGP routes with communities you'll see some significant performance gains in policy evaluation which can improve convergence times quite a bit. Off the top of my head some issues we've seen with 10.3R3 so far are: * Syslogging of BGP messages seems quite broken, in many cases not logging state changes correctly at all. * ISIS packets inside a l2circuit are eatten by MX's when vlan-mapping is configured on the endpoint vlan-ccc. * EX8200 power supplies will think they're running in 1200W 110V input power mode if you reinsert them after a reboot, even if fed with 220V power which should run them in 2000W mode. This will cause cards to power down if the chassis thinks there is insufficient power, so you may not have proper power supply redundancy. No doubt there are plenty more too, but at least in a core service provider role it's been a lot less bad (lets just say its nice to not have to hard clear bgp neighbors to make policy changes take effect :P). I have also hear that 10.4 also included a mass re-write/re-development of a lot of the JunOS code; trying to bring it back within a manageable framework. (Note how it went from 10.2R3 to 10.4, skipping a 10.3 release for some platforms). Hence, 10.4 is the new code base. I don't know if this is a good thing or a bad thing initially, but should only improve with time. Actually it's the opposite, 10.3 and 10.4 were both nobody touch anything that isn't essential no-feature releases, to try and bring the development framework into a more manageable state. I'll confirm that they're less broken than 10.2, but that certainly doesn't take much. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
We are running 10.0S9 right now. 10.0S10 introduced a bug that leaves the CPU running at 100% on our M-series, and this bug is resolved in 10.0S13 which I think is out already. We haven't put 10.0S13 in production yet, but I suspect that this will be as close we will get to a bug-free release for the time being... From: Richard A Steenbergen r...@e-gerbil.net To: Chris Kawchuk juniperd...@gmail.com Cc: juniper-nsp juniper-nsp@puck.nether.net Sent: Tue, March 15, 2011 11:14:06 AM Subject: Re: [j-nsp] 10.0 or 10.4? On Tue, Mar 15, 2011 at 07:43:25PM +1100, Chris Kawchuk wrote: Just installed 14 x MX960s for a large Aussie Mobile company - The release train we've decided on is 10.4R2 for now, due to EEOL support; and the fact that 10.0 didn't support a few of the cards we added. (16x10GE Trio for example didn't come till 10.2). I hear people make this argument a lot, but in many cases it seems to be more of a knee-jerk reaction than a logical decision. The EEOL branches are definitely interesting once you get into the post-R4 timeframe, but I question the sensibility of trying to deploy it in the R2 timeframe just because it is the EEOL train. Honestly, in many cases the code doesn't even begin to get stable until it reaches R4 and EOL status. The problem we run into is that we almost always discover at least one serious bug in every R4, no matter how well-intentioned the development efforts, but because R4 marks the end of engineering status we're constantly chasing the next branch to get a bugfix for things introduced in the previous branch. Of course what that really means is we discover all new brokeness in the new branch, and the cycle starts all over again. EEOL releases can end up being a lot more stable since you aren't introducing any new features (though anyone who tells you they don't introduce a ton of new bugs just doing service releases is completely full of it :P), so they're a good thing. But, what is the real benefit to deploying 10.4R2 now, as opposed to say 10.3R3? Either way you'll have to do an upgrade later on, so until you get to 10.4R4 there is no difference in 10.4 being the EEOL branch. We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. Why JTAC is recommending it I can't even begin to guess, I really think they have the recommended version page hooked up to a random number generator some days, but in our testing it wasn't even close. Which isn't to say 10.3R3 is perfect, but it's definitely on the less broken than ever side of things. So far we haven't had any issues with Trio hardware or snmp problems that we saw in 10.2R3 or 10.3R2, and if you carry a large number of BGP routes with communities you'll see some significant performance gains in policy evaluation which can improve convergence times quite a bit. Off the top of my head some issues we've seen with 10.3R3 so far are: * Syslogging of BGP messages seems quite broken, in many cases not logging state changes correctly at all. * ISIS packets inside a l2circuit are eatten by MX's when vlan-mapping is configured on the endpoint vlan-ccc. * EX8200 power supplies will think they're running in 1200W 110V input power mode if you reinsert them after a reboot, even if fed with 220V power which should run them in 2000W mode. This will cause cards to power down if the chassis thinks there is insufficient power, so you may not have proper power supply redundancy. No doubt there are plenty more too, but at least in a core service provider role it's been a lot less bad (lets just say its nice to not have to hard clear bgp neighbors to make policy changes take effect :P). I have also hear that 10.4 also included a mass re-write/re-development of a lot of the JunOS code; trying to bring it back within a manageable framework. (Note how it went from 10.2R3 to 10.4, skipping a 10.3 release for some platforms). Hence, 10.4 is the new code base. I don't know if this is a good thing or a bad thing initially, but should only improve with time. Actually it's the opposite, 10.3 and 10.4 were both nobody touch anything that isn't essential no-feature releases, to try and bring the development framework into a more manageable state. I'll confirm that they're less broken than 10.2, but that certainly doesn't take much. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] 10.0 or 10.4?
On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote: ... We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. What sorts of bugs did you see in 10.4R2? JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in 10.1R4) where some of our firewall filter rules were being silently ignored. Thanks, Steve ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On 03/15/11 13:57, Steve Feldman wrote: On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote: ... We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. What sorts of bugs did you see in 10.4R2? JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in 10.1R4) where some of our firewall filter rules were being silently ignored. ex + firewall ... 'silently ignored' is the norm no? ;( here's a fav of mine. Loopback filters drop traceroute THROUGH the device (unless you permit all traceroute of course) because, you know.. separating the 'control plane' traffic from the 'data plane' traffic is something we all figured out 10 years ago. :( (to be fair, this 'bug' is fixed in 11.X... 'please load this daily code image on your production network, kthxbi!') -grumpy-in-north-america ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Funny My SE assures me that they have made significant changes to the way that the JUNOS code is being developed. Which will result in me finally after four years getting a stable code image. 10.4 is supposed to fix all my issues with the R3 release. Any one taking odds on this? On Tue, Mar 15, 2011 at 12:34 PM, Chris Morrow morr...@ops-netman.netwrote: On 03/15/11 13:57, Steve Feldman wrote: On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote: ... We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. What sorts of bugs did you see in 10.4R2? JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in 10.1R4) where some of our firewall filter rules were being silently ignored. ex + firewall ... 'silently ignored' is the norm no? ;( here's a fav of mine. Loopback filters drop traceroute THROUGH the device (unless you permit all traceroute of course) because, you know.. separating the 'control plane' traffic from the 'data plane' traffic is something we all figured out 10 years ago. :( (to be fair, this 'bug' is fixed in 11.X... 'please load this daily code image on your production network, kthxbi!') -grumpy-in-north-america ___ 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] 10.0 or 10.4?
Hi Nathan and all, I can confirm, 10.4 is the first JUNOS release developed with a new methodology. This would allow Juniper to catch much more bugs before releasing the code than in the past. Hope this helps Magno. On Tue, Mar 15, 2011 at 11:03 PM, Nathan Sipes nathan.si...@gmail.comwrote: Funny My SE assures me that they have made significant changes to the way that the JUNOS code is being developed. Which will result in me finally after four years getting a stable code image. 10.4 is supposed to fix all my issues with the R3 release. Any one taking odds on this? On Tue, Mar 15, 2011 at 12:34 PM, Chris Morrow morr...@ops-netman.net wrote: On 03/15/11 13:57, Steve Feldman wrote: On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote: ... We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. What sorts of bugs did you see in 10.4R2? JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in 10.1R4) where some of our firewall filter rules were being silently ignored. ex + firewall ... 'silently ignored' is the norm no? ;( here's a fav of mine. Loopback filters drop traceroute THROUGH the device (unless you permit all traceroute of course) because, you know.. separating the 'control plane' traffic from the 'data plane' traffic is something we all figured out 10 years ago. :( (to be fair, this 'bug' is fixed in 11.X... 'please load this daily code image on your production network, kthxbi!') -grumpy-in-north-america ___ 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] 10.0 or 10.4?
I can confirm this as well. Junos Transformation/Ironman started with 10.4R2. There should be a meaningful difference. I know they've increased the regression testing scripts by nearly 500%. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of magno Sent: Tuesday, March 15, 2011 3:14 PM To: Nathan Sipes Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] 10.0 or 10.4? Hi Nathan and all, I can confirm, 10.4 is the first JUNOS release developed with a new methodology. This would allow Juniper to catch much more bugs before releasing the code than in the past. Hope this helps Magno. On Tue, Mar 15, 2011 at 11:03 PM, Nathan Sipes nathan.si...@gmail.comwrote: Funny My SE assures me that they have made significant changes to the way that the JUNOS code is being developed. Which will result in me finally after four years getting a stable code image. 10.4 is supposed to fix all my issues with the R3 release. Any one taking odds on this? On Tue, Mar 15, 2011 at 12:34 PM, Chris Morrow morr...@ops-netman.net wrote: On 03/15/11 13:57, Steve Feldman wrote: On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote: ... We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. What sorts of bugs did you see in 10.4R2? JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in 10.1R4) where some of our firewall filter rules were being silently ignored. ex + firewall ... 'silently ignored' is the norm no? ;( here's a fav of mine. Loopback filters drop traceroute THROUGH the device (unless you permit all traceroute of course) because, you know.. separating the 'control plane' traffic from the 'data plane' traffic is something we all figured out 10 years ago. :( (to be fair, this 'bug' is fixed in 11.X... 'please load this daily code image on your production network, kthxbi!') -grumpy-in-north-america ___ 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] 10.0 or 10.4?
Hello Nathan, Using MX since the first code available for this platform, we always had strange issue with R2 version. I mean EACH time, and moving to R3, most of the bugs was fixed or non impacting the production Network. Our SE also assures us to move to 10.4 R2, but until R3, we will stay with the most stable version for our MX's with trio cards. We had to use 10.3R3.7 due to SNMP bugs and RE / SF crash on the previous version. So if you can wait for 10.4R3, I will strongly encourage you to setup a lab waiting for it :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Mar 15, 2011, at 11:03 PM, Nathan Sipes wrote: Funny My SE assures me that they have made significant changes to the way that the JUNOS code is being developed. Which will result in me finally after four years getting a stable code image. 10.4 is supposed to fix all my issues with the R3 release. Any one taking odds on this? On Tue, Mar 15, 2011 at 12:34 PM, Chris Morrow morr...@ops-netman.netwrote: On 03/15/11 13:57, Steve Feldman wrote: On Mar 15, 2011, at 9:14 AM, Richard A Steenbergen wrote: ... We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. What sorts of bugs did you see in 10.4R2? JTAC is recommending 10.4R2 on our EX8200s to fix a bug (PR581625 in 10.1R4) where some of our firewall filter rules were being silently ignored. ex + firewall ... 'silently ignored' is the norm no? ;( here's a fav of mine. Loopback filters drop traceroute THROUGH the device (unless you permit all traceroute of course) because, you know.. separating the 'control plane' traffic from the 'data plane' traffic is something we all figured out 10 years ago. :( (to be fair, this 'bug' is fixed in 11.X... 'please load this daily code image on your production network, kthxbi!') -grumpy-in-north-america ___ 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] 10.0 or 10.4?
On Tue, Mar 15, 2011 at 11:13:33PM +0100, magno wrote: I can confirm, 10.4 is the first JUNOS release developed with a new methodology. This would allow Juniper to catch much more bugs before releasing the code than in the past. Such as 10.4R2 not showing transceivers on 16-port 10GE MPC in show chassis hardware anymore, but 10.4R1 did? :-) Our RANCID caught that on on of our lab MXes within less then one hour after upgrading the box. Systest didn't - or it wasn't deemed a show-stopper for release. Other than that, our lab and field trials of 10.4R1 + 10.4R2 went astonishingly well. Except abovementioned bug we didn't run into any issue yet (knocking on wood - broad MPC deployment ahead). We're currently waiting for R3 to have that bug fixed and another general sweep of bugfixes (and hopefully no new issues). Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Den 15.03.2011 23:19, skrev Doug Hanks: I can confirm this as well. Junos Transformation/Ironman started with 10.4R2. There should be a meaningful difference. I know they've increased the regression testing scripts by nearly 500%. Here is one meaningful difference - DHCP relay used to work. ;-p -- Bjørn Tore ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
