Re: [j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960
I dont know when there is a an official response, but the report seems very Cisco friendly... I have performed very tough tests on the MX, putting both multicast and QoS to the test and I have seen none of the problems Miercom claims they see... Patrik On Sep 24, 2009, at 7:46 AM, Jeff Tantsura wrote: Hi, Would be interesting to see Juniper's reaction on following report: http://www.miercom.com/dl.html?fid=20090827type=report Cheers, Jeff ___ 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] Miercom Competitive Performance Testing Results: CiscoASR9000 vs Juniper MX960
You are aware of what kind of testing we are talking about with Miercom and Tolly..? The tests are paid for by one vendor in order to typically put focus on some corner case problem in another vendors equipment. I am not saying that the specific results obtained are wrong, but it is probably very interesting to see the test parameters and configurations used in the test to be able to verify how realistic they are for real-world scenarios. Information contained in this report is based upon results observed a Cisco facility in San Jose, CA. Test cases were based on parameters set by Cisco. Thanks, ///Markus Åberg -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Tantsura Sent: 24. syyskuuta 2009 8:46 To: juniper-nsp@puck.nether.net Subject: [j-nsp] Miercom Competitive Performance Testing Results: CiscoASR9000 vs Juniper MX960 Hi, Would be interesting to see Juniper's reaction on following report: http://www.miercom.com/dl.html?fid=20090827type=report Cheers, Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Experience with J series
Hi, I am currently looking after a review for a pair of Juniper J2350. The purpose is to build a mission-critical Internet access with two ISP (one on each box running full table) and have a VRRP fault tolerance and with a small budget. It is not for pushing huge traffic, I expect around 1 to 3 Mbit average and some rare peaks at 8 - 10 Mbit during backup timeframes. The features I will be using are firewall ( 30 ACLs), BGP, OSPF (both IPv4 and IPv6) and maybe one VPN tunnel + QoS (?). According to the technical datasheet, this gear supports 1 GB of DRAM and handle a maximum ~ 300k BGP routes. I have seen in some lists that these models now can be upgraded to 2 GB of DRAM with just no issue. Some people report having had successful experience handling 500k routes with these littles gears. I am just looking after some experience with them in this kind of environment. By the way, does this box include any GUI software to maintain firewall ACLs? Thanks. -- Gregory Agerba ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960
On Wed, Sep 23, 2009 at 10:46:01PM -0700, Jeff Tantsura wrote: Hi, Would be interesting to see Juniper's reaction on following report: http://www.miercom.com/dl.html?fid=20090827type=report These reports are total frauds, Cisco pays Miercom to produce them and to make sure the results always come out in their favor. They typically find edge cases to focus on, misconfigure the competition boxes, provide no way to verify their claims, and make sure to never feature any test in which the Cisco box fails. The Miercom 7600 vs M7i report for example was a work of pure comedy, if not for the thought that some poor sap might have actually believed a word of it. The FUD machine has been working overtime against the MX lately too, because it is an first rate box and the competition has absolutely nothing to compete against it technically. -- 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] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960
On Thu, 24 Sep 2009, Patrik Olsson wrote: I dont know when there is a an official response, but the report seems very Cisco friendly... I have performed very tough tests on the MX, putting both multicast and QoS to the test and I have seen none of the problems Miercom claims they see... Have you tested MX also during RIB or FIB changes? I'd like to use this as a soapbox. On Juniper platforms, when a next-hop changes, this results in first DELETE and then (maybe much later) ADD operations in FIB. We have noticed that when BGP next-hop changes for 300K prefixes, this has led to up to 7 minutes of packet loss due to a lack of FIB entry for a destination. This was seen on T-series, but MX has the same architectural limitations. This slowness was introduced sometime in JunOS 8.x. And this is working as designed and no way to speed it up. Hopefully at some point someone will do performance testing in these kind of scenarios as well; I don't recall seeing such a test myself. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Richard A Steenbergen Sent: Thursday, September 24, 2009 4:12 AM To: Jeff Tantsura Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960 On Wed, Sep 23, 2009 at 10:46:01PM -0700, Jeff Tantsura wrote: Hi, Would be interesting to see Juniper's reaction on following report: http://www.miercom.com/dl.html?fid=20090827type=report These reports are total frauds, Cisco pays Miercom to produce them and to make sure the results always come out in their favor. They typically find edge cases to focus on, misconfigure the competition boxes, provide no way to verify their claims, and make sure to never feature any test in which the Cisco box fails. The Miercom 7600 vs M7i report for example was a work of pure comedy, if not for the thought that some poor sap might have actually believed a word of it. The FUD machine has been working overtime against the MX lately too, because it is an first rate box and the competition has absolutely nothing to compete against it technically. -- 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) If I remember correctly, they configured things that caused some sort of memory search cycle to be exhausted, which is something that is not possible in a TCAM-based solution. In addition, they used cheap LAN modules to make it look as though the 7600 was low cost, even though they fail to mention that those LAN modules don't support the same features that the M10i GE ports did. You would have to purchase OSM/SIP modules to support those same features, which raises the cost considerably. There was also something having to do with the specific number of ACL entries, which makes me question why in this new report, do they choose specifically 2010 and 4020 VPNs. Not sure if it has any significance, but it sounds hinky to me. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] cannot see hard disk
Hi all, I have m7i box. It restarted today and hard disk went off. I cannot see it in my storage devices. Router1 show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 217M61M 139M 30% / devfs16K16K 0B 100% /dev/ /dev/vn0 16M16M 0B 100% /packages/mnt/jbase /dev/vn1 65M65M 0B 100% /packages/mnt/jkernel-8.4R1.13 /dev/vn28.5M 8.5M 0B 100% /packages/mnt/jpfe-M7i-8.4R1.13 /dev/vn32.6M 2.6M 0B 100% /packages/mnt/jdocs-8.4R1.13 /dev/vn4 22M22M 0B 100% /packages/mnt/jroute-8.4R1.13 /dev/vn58.0M 8.0M 0B 100% /packages/mnt/jcrypto-8.4R1.13 /dev/vn6 14M14M 0B 100% /packages/mnt/jpfe-common-8.4R1.13 mfs:136 62M 1.0K57M0% /tmp mfs:150 62M16M41M 28% /mfs /dev/ad0s1e 24M18K22M0% /config procfs 4.0K 4.0K 0B 100% /proc How i can get it back. Any idea? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960
On Thu, Sep 24, 2009 at 12:13:41PM +0300, Pekka Savola wrote: Have you tested MX also during RIB or FIB changes? I'd like to use this as a soapbox. On Juniper platforms, when a next-hop changes, this results in first DELETE and then (maybe much later) ADD operations in FIB. We have noticed that when BGP next-hop changes for 300K prefixes, this has led to up to 7 minutes of packet loss due to a lack of FIB entry for a destination. This was seen on T-series, but MX has the same architectural limitations. This slowness was introduced sometime in JunOS 8.x. And this is working as designed and no way to speed it up. Hopefully at some point someone will do performance testing in these kind of scenarios as well; I don't recall seeing such a test myself. Well, we saw something similar (that I've described on this list several times) but not exactly what you described, starting somewhere in 7.x and continuing until 8.5 where it was fixed on most platforms (including MX). Basically what happens is during a path change when it adds the new path and removes the old, something will cause the update process to stall, resulting in many minutes taken to install the new path into the hardware. If you did a show route on it while it is trying to make the update, you'll see a - on the old path and a + on the new path as it tries to update the FIB. It seemed like something would cause one particular update to stall, which would block that and all further updates behind that from taking effect for some number of minutes. Back on the M160 this could be 30 minutes to in some cases hours, but when we saw it on MX 7 minutes was a good average value. Eventually whatever route update was stalling things would go through, and then all the other routes that were stuck behind it would come flooding through. If you did a show bgp summary during this event, the stuck routes would show up in the Pending state counter up top. This normally didn't cause any packet loss for us, as it would keep forwarding via the old path until the new one became active. If the next-hop became invalid it would pull the routes immediately (or at least, we never got a complaint or saw an example where it didn't, in the many hundreds of times we observed this behavior over the years). The only time we would see packet loss was when the old path would drop BGP and not be able to continue to forward traffic, but not drop link. We complained about this for years and years, it went from we don't see this to we can't reproduce this to we have no idea whats causing this. Eventually at 8.5 it become we changed a whole bunch of things to try and fix this, but they never did tell us exactly what. After 8.5 we have not seen this problem since, at least on the MX platform (and we tossed all our M160s into the nearest landfill). Ironically enough the problem still exists on J-series running JUNOS (real JUNOS, we stopped testing after it was unfixed in the last JUNOS version to be released before the switch to -ES), despite there not actually being a hardware fib that needs updating. This pretty much put a kibosh on plans to use J-series as a BGP route-reflector, since BGP will not propagate the route change to other neighbors until it successfully installs the new path in its own FIB. If anyone from Juniper wants to step forward and describe what the problem or fix was I'd be interested in hearing it, our original issue was spread out over too many years and too many PRs to ever get anyone to even understand the question let alone give us a straight answer. -- 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] Experience with J series
The purpose is to build a mission-critical Internet access with two ISP (one on each box running full table) and have a VRRP fault tolerance and with a small budget. It is not for pushing huge traffic, I expect around 1 to 3 Mbit average and some rare peaks at 8 - 10 Mbit during backup timeframes. No Problem. J2350's are capable of this easily. e/iBGP with full tables, VRRP on the inside interface. Processing 8-10mbit/sec would hardly sweat the box. The features I will be using are firewall ( 30 ACLs), BGP, OSPF (both IPv4 and IPv6) and maybe one VPN tunnel + QoS (?). Yep. 30 ACL's with no issues (assuming straightforward things). Full BGP Tables, OSPF area 0.0.0.0 inside, QoS, IPSEC. According to the technical datasheet, this gear supports 1 GB of DRAM and handle a maximum ~ 300k BGP routes. I've seen much more in 1 Gb of RAM.; however 300k routes is fine for the global routing table. (which is ~290k or so). You'd have room-to- spare. I have seen in some lists that these models now can be upgraded to 2 GB of DRAM with just no issue. Some people report having had successful experience handling 500k routes with these littles gears. Yes. I've worked with J4350's and J6350's with 2 Gb of RAM, holding 2 complete eBGP tables each and an iBGP table. for a total of 800k routes. Also seen it (by misconfiguration) hold 1.2 Million routes in BGP/inet.0. I am just looking after some experience with them in this kind of environment. By the way, does this box include any GUI software to maintain firewall ACLs? Full GUI supported (web-Gui on the box) - however, as always, the power is in the command line. JunOS is easy to use, easy to learn, and makes sense from a command-line configuration perspective. - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Experience with J series
Chris, thanks for your input. I've seen much more in 1 Gb of RAM.; however 300k routes is fine for the global routing table. (which is ~290k or so). You'd have room-to-spare. Good. Juniper probably ensure at least 300k routes, with other features turned on. Yes. I've worked with J4350's and J6350's with 2 Gb of RAM, holding 2 complete eBGP tables each and an iBGP table. for a total of 800k routes. Also seen it (by misconfiguration) hold 1.2 Million routes in BGP/inet.0. Good again and for half price of a green C7201 ;-) Full GUI supported (web-Gui on the box) - however, as always, the power is in the command line. JunOS is easy to use, easy to learn, and makes sense from a command-line configuration perspective. I rarely use GUI. On Cisco they produce loads of useless lines. I am a big fan of CLI since my first Linux box. However, that's more in case someone less skilled has to take it and add a firewall rule in case I am off few days or whenever my plane would crash, until they change them. I've seen JunOS generates nice OpenBGPd-like configuration files. I am familiar with HP cli and Foundry CLI. I've also heard that JunOS is way different than Cisco but that once you get used to the synthax, you don't want to get back on Cisco one. However, that is no big risk. They seem to be a nice option at all levels: price, performances and features. I am just not sure to buy the DRAM from Juniper, 800$ for one extra GB is a bit expensive. 2009/9/24 Chris Kawchuk juniperd...@gmail.com The purpose is to build a mission-critical Internet access with two ISP (one on each box running full table) and have a VRRP fault tolerance and with a small budget. It is not for pushing huge traffic, I expect around 1 to 3 Mbit average and some rare peaks at 8 - 10 Mbit during backup timeframes. No Problem. J2350's are capable of this easily. e/iBGP with full tables, VRRP on the inside interface. Processing 8-10mbit/sec would hardly sweat the box. The features I will be using are firewall ( 30 ACLs), BGP, OSPF (both IPv4 and IPv6) and maybe one VPN tunnel + QoS (?). Yep. 30 ACL's with no issues (assuming straightforward things). Full BGP Tables, OSPF area 0.0.0.0 inside, QoS, IPSEC. According to the technical datasheet, this gear supports 1 GB of DRAM and handle a maximum ~ 300k BGP routes. I've seen much more in 1 Gb of RAM.; however 300k routes is fine for the global routing table. (which is ~290k or so). You'd have room-to-spare. I have seen in some lists that these models now can be upgraded to 2 GB of DRAM with just no issue. Some people report having had successful experience handling 500k routes with these littles gears. Yes. I've worked with J4350's and J6350's with 2 Gb of RAM, holding 2 complete eBGP tables each and an iBGP table. for a total of 800k routes. Also seen it (by misconfiguration) hold 1.2 Million routes in BGP/inet.0. I am just looking after some experience with them in this kind of environment. By the way, does this box include any GUI software to maintain firewall ACLs? Full GUI supported (web-Gui on the box) - however, as always, the power is in the command line. JunOS is easy to use, easy to learn, and makes sense from a command-line configuration perspective. - Chris. -- Gregory Agerba - IT Consultant Email : gregory.age...@gmail.com Phone : +41 78 667 00 34 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] cannot see hard disk
can you check if you have hard-dish using the following commands: show chassis hardware details show system boot-messaages... if not, you should have seen some hardware errors or logs relating to hard-disk..if yes, replace the RE... cheers On Thu, Sep 24, 2009 at 12:20 PM, Erol KAHRAMAN erol.kahra...@gmail.comwrote: Hi all, I have m7i box. It restarted today and hard disk went off. I cannot see it in my storage devices. Router1 show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 217M61M 139M 30% / devfs16K16K 0B 100% /dev/ /dev/vn0 16M16M 0B 100% /packages/mnt/jbase /dev/vn1 65M65M 0B 100% /packages/mnt/jkernel-8.4R1.13 /dev/vn28.5M 8.5M 0B 100% /packages/mnt/jpfe-M7i-8.4R1.13 /dev/vn32.6M 2.6M 0B 100% /packages/mnt/jdocs-8.4R1.13 /dev/vn4 22M22M 0B 100% /packages/mnt/jroute-8.4R1.13 /dev/vn58.0M 8.0M 0B 100% /packages/mnt/jcrypto-8.4R1.13 /dev/vn6 14M14M 0B 100% /packages/mnt/jpfe-common-8.4R1.13 mfs:136 62M 1.0K57M0% /tmp mfs:150 62M16M41M 28% /mfs /dev/ad0s1e 24M18K22M0% /config procfs 4.0K 4.0K 0B 100% /proc How i can get it back. Any idea? ___ 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] cannot see hard disk
If your system booted without the hard disk, it is likely the hard disk was removed from the boot order. If the hard disk was removed from the boot order, it won't show up in show chassis hardware details (at least in my experience). It probably won't even show up in the boot messages. However, that does not mean that the hard disk is permanently destroyed, defective, etc.; rather, it just means that the system detected an error (whether transient or fatal) and stopped using it (including removing it from the boot order). I believe there is at least one way to re-add it to the boot order; however, it involves dropping down to the shell (and, therefore, is not supported without JTAC blessing). You should probably contact the JTAC for help. -Jon On Thu, Sep 24, 2009 at 10:53 AM, Shankar shanka...@gmail.com wrote: can you check if you have hard-dish using the following commands: show chassis hardware details show system boot-messaages... if not, you should have seen some hardware errors or logs relating to hard-disk..if yes, replace the RE... cheers On Thu, Sep 24, 2009 at 12:20 PM, Erol KAHRAMAN erol.kahra...@gmail.com wrote: Hi all, I have m7i box. It restarted today and hard disk went off. I cannot see it in my storage devices. Router1 show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 217M61M 139M 30% / devfs16K16K 0B 100% /dev/ /dev/vn0 16M16M 0B 100% /packages/mnt/jbase /dev/vn1 65M65M 0B 100% /packages/mnt/jkernel-8.4R1.13 /dev/vn28.5M 8.5M 0B 100% /packages/mnt/jpfe-M7i-8.4R1.13 /dev/vn32.6M 2.6M 0B 100% /packages/mnt/jdocs-8.4R1.13 /dev/vn4 22M22M 0B 100% /packages/mnt/jroute-8.4R1.13 /dev/vn58.0M 8.0M 0B 100% /packages/mnt/jcrypto-8.4R1.13 /dev/vn6 14M14M 0B 100% /packages/mnt/jpfe-common-8.4R1.13 mfs:136 62M 1.0K57M0% /tmp mfs:150 62M16M41M 28% /mfs /dev/ad0s1e 24M18K22M0% /config procfs 4.0K 4.0K 0B 100% /proc How i can get it back. Any idea? ___ 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] cannot see hard disk
The command he is referring to is... From shell, as root, check the boot devices sysctl -a | grep bootdevs (You will most likely see this) machdep.bootdevs: pcmcia-flash,compact-flash,lan (at prompt, copy and paste this to put the HD back in the boot order) sysctl -w machdep.bootdevs: pcmcia-flash,compact-flash,disk,lan Repeat 'sysclt-a | grep bootdevs' to ensure that it was changed. If it happens again, there is most likely something wrong with the hard disk which seems to be common on the M7i, then your options are to RMA the RE if you have support, if not you can replace with a SSD drive. Hope this helps. Brendan Mannella - Original Message - From: Jonathan Looney jonloo...@gmail.com To: Shankar shanka...@gmail.com Cc: juniper-nsp@puck.nether.net Sent: Thursday, September 24, 2009 11:31:26 AM GMT -05:00 US/Canada Eastern Subject: Re: [j-nsp] cannot see hard disk If your system booted without the hard disk, it is likely the hard disk was removed from the boot order. If the hard disk was removed from the boot order, it won't show up in show chassis hardware details (at least in my experience). It probably won't even show up in the boot messages. However, that does not mean that the hard disk is permanently destroyed, defective, etc.; rather, it just means that the system detected an error (whether transient or fatal) and stopped using it (including removing it from the boot order). I believe there is at least one way to re-add it to the boot order; however, it involves dropping down to the shell (and, therefore, is not supported without JTAC blessing). You should probably contact the JTAC for help. -Jon On Thu, Sep 24, 2009 at 10:53 AM, Shankar shanka...@gmail.com wrote: can you check if you have hard-dish using the following commands: show chassis hardware details show system boot-messaages... if not, you should have seen some hardware errors or logs relating to hard-disk..if yes, replace the RE... cheers On Thu, Sep 24, 2009 at 12:20 PM, Erol KAHRAMAN erol.kahra...@gmail.com wrote: Hi all, I have m7i box. It restarted today and hard disk went off. I cannot see it in my storage devices. Router1 show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 217M61M 139M 30% / devfs16K16K 0B 100% /dev/ /dev/vn0 16M16M 0B 100% /packages/mnt/jbase /dev/vn1 65M65M 0B 100% /packages/mnt/jkernel-8.4R1.13 /dev/vn28.5M 8.5M 0B 100% /packages/mnt/jpfe-M7i-8.4R1.13 /dev/vn32.6M 2.6M 0B 100% /packages/mnt/jdocs-8.4R1.13 /dev/vn4 22M22M 0B 100% /packages/mnt/jroute-8.4R1.13 /dev/vn58.0M 8.0M 0B 100% /packages/mnt/jcrypto-8.4R1.13 /dev/vn6 14M14M 0B 100% /packages/mnt/jpfe-common-8.4R1.13 mfs:136 62M 1.0K57M0% /tmp mfs:150 62M16M41M 28% /mfs /dev/ad0s1e 24M18K22M0% /config procfs 4.0K 4.0K 0B 100% /proc How i can get it back. Any idea? ___ 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] cannot see hard disk
If not you could also replace the hard disk with another one or even a new SSD drive. I just went through this if you need assistance. Brendan - Original Message - From: Shankar shanka...@gmail.com To: erol kahraman erol.kahra...@gmail.com Cc: juniper-nsp@puck.nether.net Sent: Thursday, September 24, 2009 10:53:48 AM GMT -05:00 US/Canada Eastern Subject: Re: [j-nsp] cannot see hard disk can you check if you have hard-dish using the following commands: show chassis hardware details show system boot-messaages... if not, you should have seen some hardware errors or logs relating to hard-disk..if yes, replace the RE... cheers On Thu, Sep 24, 2009 at 12:20 PM, Erol KAHRAMAN erol.kahra...@gmail.comwrote: Hi all, I have m7i box. It restarted today and hard disk went off. I cannot see it in my storage devices. Router1 show system storage Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 217M61M 139M 30% / devfs16K16K 0B 100% /dev/ /dev/vn0 16M16M 0B 100% /packages/mnt/jbase /dev/vn1 65M65M 0B 100% /packages/mnt/jkernel-8.4R1.13 /dev/vn28.5M 8.5M 0B 100% /packages/mnt/jpfe-M7i-8.4R1.13 /dev/vn32.6M 2.6M 0B 100% /packages/mnt/jdocs-8.4R1.13 /dev/vn4 22M22M 0B 100% /packages/mnt/jroute-8.4R1.13 /dev/vn58.0M 8.0M 0B 100% /packages/mnt/jcrypto-8.4R1.13 /dev/vn6 14M14M 0B 100% /packages/mnt/jpfe-common-8.4R1.13 mfs:136 62M 1.0K57M0% /tmp mfs:150 62M16M41M 28% /mfs /dev/ad0s1e 24M18K22M0% /config procfs 4.0K 4.0K 0B 100% /proc How i can get it back. Any idea? ___ 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
[j-nsp] flowfilter IPv6 does not work
All, just a quick heads up: flowfilter (aka flowspec aka inetflow) does not work with ipv6. And it took JTAC just two weeks to figure it out... JTAC wrote: [...] flow filters in IPv6 are not supported A shame, really, as flowfilter is one of the best features ever. I hope they'll add v6 sooner rather than later, it's an invaluable tool for v4. I don't want to go back to having to blackhole /128s... Kind regards, Felix -- Felix Schüren Head of Network --- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller (*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] LX SFP Question
Hi folks... Does anyone know the tolerance of the LH SFP's from Juniper? We are trying to get an EX3200 switch configured and ready for production - have a case open at JTAC but haven't been able to resolve. In fairness to the JTAC engineer, I haven't had a lot of time to troubleshoot except for performing a software upgrade which has been completed (9.4) The link is up/up from the EX3200 to a Cisco 6500 but the distance at the moment (while testing) is literally 15' or so. In the Cisco world we have no problem on such short distances but wondering if something is different or causing a problem for the Juniper. We see up/up and at one point were seeing a MAC address but unable to access the Management VLAN on the switch (only VLAN configured at the moment). Since the software upgrade we cannot see a MAC address even which has me wondering about the connection running too hot JTAC verified that the configuration is correct - Cisco TAC has verified that the IOS configuration is correct. Many thanks, Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LX SFP Question
Set no negotiate on the interface. This is most likely the problem. Brendan Mannella On Sep 24, 2009, at 5:35 PM, Paul Stewart p...@paulstewart.org wrote: Hi folks... Does anyone know the tolerance of the LH SFP's from Juniper? We are trying to get an EX3200 switch configured and ready for production - have a case open at JTAC but haven't been able to resolve. In fairness to the JTAC engineer, I haven't had a lot of time to troubleshoot except for performing a software upgrade which has been completed (9.4) The link is up/up from the EX3200 to a Cisco 6500 but the distance at the moment (while testing) is literally 15' or so. In the Cisco world we have no problem on such short distances but wondering if something is different or causing a problem for the Juniper. We see up/up and at one point were seeing a MAC address but unable to access the Management VLAN on the switch (only VLAN configured at the moment). Since the software upgrade we cannot see a MAC address even which has me wondering about the connection running too hot JTAC verified that the configuration is correct - Cisco TAC has verified that the IOS configuration is correct. Many thanks, Paul ___ 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] LX SFP Question
On Thu, Sep 24, 2009 at 5:35 PM, Paul Stewart p...@paulstewart.org wrote: Hi folks... Does anyone know the tolerance of the LH SFP's from Juniper? We are trying to get an EX3200 switch configured and ready for production - have a case open at JTAC but haven't been able to resolve. In fairness to the JTAC engineer, I haven't had a lot of time to troubleshoot except for performing a software upgrade which has been completed (9.4) The link is up/up from the EX3200 to a Cisco 6500 but the distance at the moment (while testing) is literally 15' or so. In the Cisco world we have no problem on such short distances but wondering if something is different or causing a problem for the Juniper. We see up/up and at one point were seeing a MAC address but unable to access the Management VLAN on the switch (only VLAN configured at the moment). Since the software upgrade we cannot see a MAC address even which has me wondering about the connection running too hot JTAC verified that the configuration is correct - Cisco TAC has verified that the IOS configuration is correct. Did you try pulling up the optical transmit and receive dB windows from the spec sheets? That'd be the first thing I'd look into to determine if you need to put in an attenuator. -- Stefan Fouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Experience with J series
Or rather OpenBGPD and XORP generate JUNOS-like configuration files. :) On 25/09/2009, at 12:45 AM, Gregory Agerba wrote: I've seen JunOS generates nice OpenBGPd-like configuration files. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960
On Thu, 24 Sep 2009, Richard A Steenbergen wrote: Well, we saw something similar (that I've described on this list several times) but not exactly what you described, starting somewhere in 7.x and continuing until 8.5 where it was fixed on most platforms (including MX). For reference, this thread from Feb 2007 describes it at least once: http://www.mail-archive.com/juniper-nsp@puck.nether.net/msg00188.html We saw this issue as well, but it apparently (for us), resulted in in RIB sync slowness only; there was no (apparent, or at least major) packet loss. Somewhere around 8.x -- maybe 8.5 or earlier -- it got worse instead of got fixed. Now it's causing significant packet loss as well. Maybe we have a cornercase that got worse. Or there really are some architecture specific differences that might explain the difference in behaviour (in particular I'm speculating about VERY old, memory/CPU constrained T320 FPCs). But the bad news is that JTAC's response is that this is working as designed. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
