[j-nsp] about 10.4R3 on EX
Hi, sarcasm To whomever who decided to introduce new features in a R3 release, thanks ;-( Specifically installing jloader separately is highly appreciated. /sarcasm Kaj ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
It took 838 seconds on a 2 member EX4200 VC bundle. Yes, I did time it. ;-) Kaj On 22/3/2011 22:46, Richard A Steenbergen r...@e-gerbil.net wrote: On Tue, Mar 22, 2011 at 12:54:25PM -0700, Kaj Niemi wrote: Hi, sarcasm To whomever who decided to introduce new features in a R3 release, thanks ;-( Specifically installing jloader separately is highly appreciated. /sarcasm Sadly, they've been silently introducing new features in the middle of a bug fix release (and introducing new bugs too, which is how I find out about them) for a while now. But for extra bonus points, be prepared for the upgrade to take a REALLY long time to complete too. :) From the release notes: How Long Will the Upgrade Process Take? The process of upgrading to a resilient dual-root partitions release takes longer due to the additional step of upgrading the loader software and a longer reboot time while the disk is reformattedto four partitions during the reboot of the switch that completes the Junos OS upgrade. The reformat increases the reboot time for EX2200, EX3200, EX4200, and EX4500 switches by 5 to 10 minutes. For EX8200 switches, the reboot time increases by 10 to 25 minutes per Routing Engine, and additional reboots are required. -- 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] Interface Index(ifIndex) changes when router is rebooted
Hi, You should be doing a bulkwalk on ifTable/ifXTable or parts of it for performance anyway so why is this a problem? If your performance management software is blindly getting just a specific counter each and every time it's doing it wrong. There are other ways of getting counters if you do not like snmp. -- Kaj Sent from my Nokia N900 - Original message - I have to agree here - having the monitoring software rediscover where the ifindex for an interface is after a reboot isn't ideal in my opinion. Paul -Original Message- From: juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of martin Sent: Saturday, August 14, 2010 5:18 AM To: Chris Adams; juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Interface Index(ifIndex) changes when router is rebooted ok, but what do you mean by fix the software? You don't poll interfaces by ifindex number? 2010/8/14 Chris Adams cmad...@hiwaay.netmailto:cmad...@hiwaay.net: Once upon a time, martin m4rti...@gmail.commailto:m4rti...@gmail.com said: As ifindex value has to be persistent in order to use it for SNMP based monitoring solutions(for example Nagios), Basically, fix the software. It isn't that hard to do; Cricket (among others) has managed to handle it for 10+ years. There will always be cases where instance numbers change, so you might as well go ahead and deal with it. For Nagios, I use a plugin wrapper that can walk a specified tree, cache the tree, match the desired value, and then call another plugin with the instance number. -- Chris Adams cmad...@hiwaay.netmailto:cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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] M7i DHCP Relay
On 12/8/2010 15:33, Chuck Anderson c...@wpi.edu wrote: 1. MX shouldn't require Option 82 (relay-agent-option) in order to function as a stateless DHCP Relay Agent (BOOTP Helper), but it does. 2. MX shouldn't get confused and fail to function when the edge switch has added it's own DHCP Option 82 information to the packet. On IRB, I *think* it must have relay-agent-option because it seems like it wants to write the interface name in the Option 82 packet no matter what and if the helper is stateless by itself it must somehow be able to figure out where (what interface) to return the packet to... With stateful dhcp relay that isn't an issue. I think it does count licensing wise (1 address = 1 subscriber license)? Kaj ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M7i DHCP Relay
Hi, This is supposedly fixed in PR/523902 which is resolved in 10.2R2 10.3R1 10.1R3 10.0R4 10.4R1. It includes two hidden commands which should allow the forwarding of DHCP traffic on interfaces that are not configured for DHCP (when using dhcp-relay or dhcp-local-server). I haven't had the time to test it out yet. On another note, does anyone have unnumbered and helpers bootp working on MX? All I can coax out of them is request from 0.0.0.0 if ge-1/0/3.2070 no useful gateway address in fud log with maximum logging, show helper statistics claiming the reason being Due to no valid local address: and incrementing drop counters. There's a ticket open on that, too. Kaj On 18/3/2010 21:26, sth...@nethelp.no sth...@nethelp.no wrote: Yes. This is a serious bug which basically makes M/MX routers unusable if you want to have DHCP relay agent functionality *on the router* at the same time as you have other DHCP unicast traffic (for instance generated by a Cisco CPE with ip helper, or a client sending its renewal request directly to the DHCP server) passing *through* the router. I find it absolutely incredible that Juniper with its ERX history has managed to botch the M/MX DHCP functionality this badly. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] reliable static routing/ip tracking
Hi, You should be able to do this with scripting.. Check out http://junos.juniper.net/scripts/op_scripts/default.asp?docId=13055 which combines RPM and disabling an interface in case the RPM initiated ping fails. It should be relatively easy to modify that for your purposes. The site does require registration, though. More info about scripting in general is available in the Configuration and Diagnostic Automation Guide. Kaj :) From: matthew wyath mwy...@gmail.com Date: Wed, 16 Sep 2009 07:42:59 -0700 To: juniper-nsp@puck.nether.net Subject: [j-nsp] reliable static routing/ip tracking Hi All, I wonder if it is possible to do static routing based on the availability of an IP. Let's say that I am connected by Ethernet (through a modem) link to my upstream provider. I am not using any dynamic routing protocol with my ISP (so I can't use any generated route) ...I can't use BFD either. I want to put a default static route through my upstream provider but I want that route to be valid only and only if a specific IP address is reachable in the Internet (by echo request). Is it possible on Juniper J series routers? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] understanding 'show route ... extensive'
Hi, Check out http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-co llections/swcmdref-protocols/show-route-extensive.html#show-route-extensive- command I think it'll answer your question pretty well. :-) Kaj From: The Dark One thedark...@list.ru Reply-To: The Dark One thedark...@list.ru Date: Tue, 1 Sep 2009 13:13:14 -0700 To: Juniper Puck juniper-nsp@puck.nether.net Subject: [j-nsp] understanding 'show route ... extensive' Experts, the output of this command presents a huge amount of information of which a big share is quite cryptic. Do you know if there is a reference table that explains field by field the output of this command. Probably the most complex is 'show route protocol bgp extensive' Thanks, bit. Я в Моем Мире - http://my.mail.ru/list/thedarkone/ ___ 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] Firewall filtering in EX3200
On Apr 28, 2008, at 21:01, Richard A Steenbergen wrote: On Sun, Apr 27, 2008 at 11:14:29PM +0300, Juha Suhonen wrote: Hello, Juniper gurus! We recently got few Juniper EX3200's, after paging thru the (quite inconsistent and scattered) documentation on Juniper's web site I still haven't been able to find a solution to this (probably quite simple) problem. ... In Juniper routers, I'd stick a firewall filter to the lo0 interface and be happy with it, but EX3200 complains about this configuration - Filters are not supported on loopback or LAG interface lo0. Yeah I found the same problem, and I'm pretty sure there is currently no other way to do it (short of filters on every other interface, with hardcoded IPs). With any luck this will be fixable in future versions of code, but technically speaking we really have no idea if this is even supported in hardware at all. Hopefully someone from Juniper can confirm. To me things like oh woops we forgot to mention, no filters on the control-plane or LAG interfaces are 1000x more interesting than hooking up a box to a traffic generator and watching it pass ordinary packets successfully. Wait until you see the reduced number of things you can match on once you actually do get a filter working. :) IMNSHO, control-plane filtering (and CoPP) should have been there from FCS. While technically the box seems nice and the per-port price seems to be a bit lower than vendor C some features just need to be there for the box to participate in the internet as we know it today. ;-) This holds true especially if you're planning to use the EX as a router instead of a layer 2 switch with the management interface protected in a management lan (or something). The lack of filtering isn't obvious when one reads through the documentation either (until you try it and are negatively surprised). The closest thing to an unsupported statement list is Table 123 on page 820 which lists specific filter features not supported in EX. To be fair, the manual does state that filters aren't supported on LAG interfaces (page 748 ;-)) but there is no mention on loopbacks at all. HTH Kaj -- Kaj J. Niemi [EMAIL PROTECTED] +358 45 63 12000 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
