Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs
On 12/09/2015 11:31 AM, Chuck Anderson wrote: > What has been your experience of the Juniper support of those SNMP > products to correctly report Port/VLAN memberships and VLAN/MAC FDB > information? I did this with custom software, but it's been 5+ years. Details are fuzzy, but here's what I recall. > Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a > working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB > (jnxExVlan). Because Q-BRIDGE-MIB refers only to internal VLAN > indexes, you need to use both MIBs to get Port/VLAN mappings including > the 802.1Q VLAN tag ID (jnxExVlanTag). This means custom software, or > an NMS vendor willing to implement the Juniper Enterprise MIBs. Yea, this sounds familiar. > All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is > broken (doesn't follow RFC 4363 standard PortList definition, instead > storing port indexes as ASCII-encoded, comma separated values), > apparently for a very long time. So again, you need custom software > or an NMS vendor willing to implement the broken Juniper version of > Q-BRIDGE-MIB (along with detecting which implementation is needed on > any particular device). I never ran into this, but it's not too surprising - I had unending problems with poor Q-BRIDGE-MIB. We used at least Junos, Procurve, and a few flavors of IOS 12. Only HP had a Q-BRIDGE-MIB that was correct enough to use - and if you poked it wrong, the switch would crash. So I just wonder - is there any off-the-shelf software that depends on correct, vendor neutral Q-BRIDGE-MIB? I always needed platform specific hacks. > I'm pushing to have Juniper fix this, but their > concern is that it may break SNMP software that has been assuming the > broken Q-BRIDGE-MIB implementation for all these years. This response might be right - unless Q-BRIDGE-MIB implementations are much more useful than they were five years ago, "fixing" it is just going to break software from folks that bothered to get it working in the first place. On Junos, I got sick of all this and switched to netconf. Ross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX secure wire and layer 2 pdus
Hi all, The documentation for SRX secure wire has thrown me for a loop. It says: secure wire is a kind of transparent mode, and transparent mode interfaces pass all ARP and non-IP broadcast/multicast. So a secure wire should pass BPDUs and LACPDUs. I think that's a mistake. If both secure wire interfaces land on the same switch, RSTP/MSTP ought to block one of the interfaces. Separate switches won't help if both are multihomed to common distribution switches. The secure wire will look like two edge interfaces were cabled together, and RSTP/MSTP will block. I setup a test with two ex4200s and a secure wire between them. No BPDUs or LACPDUs make it across. Seems good, but now I'm nervous that the behavior doesn't match the documentation. Have I missed something? Case is open, but it stalled at the repeat the documentation stage. https://www.juniper.net/techpubs/en_US/junos12.3x48/topics/concept/layer-2-secure-wire-understanding.html Ross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Arguments for commit scripts
On 2015-03-18 18:00, Phil Shafer wrote: Yup, apply-macro is the perfect spot for stuffing data. Consider using a top-level apply-macro with a name indicating your script, and then the value under it: Great, that's exactly what I wanted. Thanks! Ross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Arguments for commit scripts
Hi all, Working on a commit script with a regex that might need occasional updates. Ideally, this could be stored in the config, and loaded at run-time. Possible? If not: any catches with abusing annotate to provide this? Thanks, Ross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] One or more stream blocked
Hello all, Does this mean anything to anyone: [Aug 16 22:41:12.103 LOG: Info] ICHIP (0) one or more stream blocked detected: 0x0400 One MX we have is spamming this on a PFE console every second or two. The index at the end if the same, always ICHIP 0. From what I can tell poking around stream may refer to fabric streams. This MX displays low, but consistent, packet loss. No interface or PFE errors have accumulated. Light levels are good. Patch cables, panels, and transceivers have been replaced and tested. Any info on whether or not the above constitutes a symptom (of hardware failure or misconfiguration) would be appreciated. None of our other MXes behave this way. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 virtual-chassis and vme access
On Thu, Aug 05, 2010 at 03:47:55AM +0200, Malte von dem Hagen wrote: * That's an explanation based on the effects. I don't know for sure what happens under the hood. It must be a bit different - according to our SE, it's possible to have both configs. After setting up vme management through JUNOS, drop to a shell and assign an IP to the interface via ifconfig. I haven't tested it, but he claims it works. You can't save it, so it has to be done on each boot. Any changes to the me0 interface probably blow it away. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 1000 VRRP instances per IFD and IRB
On Fri, Jul 09, 2010 at 12:23:45AM -0400, Stefan Fouant wrote: See if you can push your account team to discuss their Stratus convergence strategy on the MX and their other data center products - their so-called 3-2-1 Data Center network architecture strategy. You might be surprised to find that you probably won't have to run VRRP in the very near future... Yea, heard all about Stratus at last year's EBR. We haven't stopped laughing at it with our account team since. We got the info under NDA, so I'm not really sure what I can talk about. It'll take 10 years to proven stability before anyone here is going to deploy anything like that. The MX is one of the most predictable and consistent platforms I've ever used. Messing with that is scary. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 1000 VRRP instances per IFD and IRB
Hey guys, Accoridng to our account team, VRRP scales to about 1000 instances per IFD. Not that I want to scale beyond Juniper's tested specs, but has anyone pushed on this? Anyone have any experience on many VRRP instances per IFD? How many? We're planning on doing vrrp inheritance so only a single IFL is actually sending keepalives to keep that work to a minimum. Is there any way to get more IRB IFDs? Per-interface limits aren't a major problem for ethernet interfaces - this is a datacenter, we run a few more cables. But it's crippling for virtual interfaces. We'd love to toss 4000 or so customer VLANs into individual VPLS with IRB, but we can't justify the cost of 4 pairs of MXes to get more IFDs for VRRP instances. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] The status of VLAN ID spaces on the MX
Hi everyone, Suppose that I have redundant aggregation switches, S1 and S2. Every access device gets an uplink from each. S1 and S2 have a trunk between them. STP is running to break the loops. All of this is at layer 2. Is there any way to provide multihomed VPLS to some or all VLANs without introducing a forwarding loop? I've been unable to come up with an effective solution. This is on MX if it makes a difference. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Templates for logging from EX series
On Wed, Jun 23, 2010 at 03:26:06PM -0500, Richard A Steenbergen wrote: Managing priorities is pretty dynamic, and uploading/managing/syncing revisions of slax scripts is a giant pain in the ass already. Is there any software to help with this task? Common group config has some of the same issues. Should be like the inverse of RANCID - manage versions of JUNOS groups and scripts with options to push out approved new versions. Should not require the device to be exclusively managed via this system - must play nicely with others. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
On Mon, Jun 21, 2010 at 12:29:00PM +0200, Laurent HENRY wrote: Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? We make some use of layer 3 services on the EX-4200, and largely, our experience has been good in this department. Be aware that their FIB size is very limited, so you'll need defaults. We have EXes working a customer edge boxes for people that don't want a full table and it's reliable and cost effective if you can live without the missing features. We do OSPF, iBGP, and some MPLS, though the EXes are feature crippled there. If you care, uRPF sucks big time, but I'm used to that from the 6500. Be somewhat cognizant of RE CPU performance. Unfortunately, the EX CPU doesn't cope too well with large VC installations in complicated configuration. In my experience, you'll be fine if you stay away from virtual-chassis. We've only really hit this in our layer 2 deployments, where committing a config can cause STP to miss BPDU timers. However, I don't see any reason why a 10 member layer 3 VC wouldn't exhibit the same issue with (for example) OSPF hellos. Software choice can be annoying - things are still changing. 9.6 is my current target for layer 3 boxes because you finally get capable loopback filters with recent bugfixes. If you want to police LSPs though, you'll need 10.1. I've had good luck so far with 10.1R2 in this application. Of course neither of these are extended EOE... To sum up - if you can live with some missing features and headaches, they aren't bad. The price point is pretty attractive. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 10.1 on MX?
Hey everyone, Has anyone running 10.1 on an MX yet? We were just shipped a pair of boxes with the new high-speed fan trays, and JUNOS prior to 10.1 doesn't correctly read the fan sensors - so it constantly thinks the fan tray needs to be checked. Not really keen on going to 10.1 for this, but I don't want us to miss a fan failure because we get in the habit of thinking it's a bug. If folks have had good experiences, maybe I'll put 10.1 through its paces. If not, maybe I'll bug my account team to send us older fans :). Thanks, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS 10.1 on EX
Hello everyone, Anyone run any EX3200/4200 boxes with 10.1 yet? How good/bad is it? 10.1R1 is a lot of ones :) Need to police some CCCs, and it looks like I need 10.1 for that. Got it running on two lab switches and no major disasters yet... Thanks, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junoscriptorium patches?
Hey Junoscriptorium folks, I have a new version of the drain-vrrp script that fixes a lot of shortcomings, but the author info for that script is incomplete. Is there someone around that I can send this to? Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] AC power distribution for the MX
Hi everyone, Juniper docs claim this about the power system for an MX480: Each inlet requires a dedicated AC power feed and a dedicated 15 A (250 VAC) circuit breaker. This seems silly - so long as we're careful not to overload any circuits and pull from diverse panels, why would they care? Does Juniper have a good reason to require this, or are they just trying to prevent people from plugging all four PEMs into the same circuit and thinking that they are redundant? Any suggestions for good AC distribution gear? APC AP9570 looks like what I'd use if left to my own. Thanks, Ross signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex-series and ifOutDiscards ?
On Mon, Apr 05, 2010 at 04:41:25PM +0400, Alexandre Snarskii wrote: That's from EX-3200 running 9.3R4.4, the same error still present in 9.3S7.2. Does anybody knows if it fixed in more recent JunOS ? 9.6R3 shows the same behavior on this EX-4200: rvandegr...@switch show interfaces ge-0/0/0 extensive Physical interface: ge-0/0/0, Enabled, Physical link is Up Interface index: 132, SNMP ifIndex: 215, Generation: 135 ... Output errors: Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0 Egress queues: 8 supported, 4 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 best-effort0 19050048 23076148 rvandegr...@malaclypse:~$ snmpget -v 2c -c hmscomm switch ifOutDiscards.215 IF-MIB::ifOutDiscards.215 = Counter32: 0 rvandegr...@malaclypse:~$ snmpget -v 2c -c hmscomm switch ifOutErrors.215 IF-MIB::ifOutErrors.215 = Counter32: 0 Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 sFlow on cluster
On Wed, Mar 31, 2010 at 09:59:08PM -0400, Abel Alejandro wrote: Hello, I am running 4 x EX4200 in a virtual chassis configuration. I configured sFlow but I can not get it to work. Basically the configuration is accepted and no errors are given but no flows are sent to the collector. I tried placing the collecting within the same subnet as the vme 0 management interface and also moving it to a physical port. According the EX4200 the flows are being sent but I am running a tcpdump on the collector and nothing is coming from the EX4200. I'm running sFlow on EX4200 VCs with JUNOS 9.6R3 and everything works as expected. The only difference from your configuration is that I'm exporting to a collecter via an RVI. Point of annoyance - JUNOS fails to expand apply-group interface wildcards under [edit protocols sflow]. So I'm going to need a few hundreds lines of config on my VCs instead of a nice and compact group. I don't suppose anyone has discovered a way around this? Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bridge-domains and L2 virtual switches
On Tue, Mar 09, 2010 at 02:44:06PM +, Humair Ali wrote: you could use a routing instance , with layer 2 virtual switch, and use multiple bridge domain as part of that virtual switch routing instance , with the L3 interface How many such instances would you expect to work? With all the config that entails, I'd rather put every customer into a VPLS instance. I know that at least 8000 are supported, so that's better than 4094 and it at least comes with the benefit that I could turn up VPLS service for any customer at any time if they happened to want it. But if I could support 16k instances via bridge domains, that would definitely be worth the added complexity. I'm hoping there's a way that keeps most setups simple, will let me scale out the number of VLANs I'm serving, and doesn't require me to sacrifice the ability to sell a customer a VPN. If really you need more than 4094 Vlans, you could possibly used PVLAN (Private VLAN) it would allegedly split the domain into multiple isolated broadcast ?subdomains without you having to use much of the vlan's ID and have STP as well. It's a good theory, but it doesn't work in practice. PVLANs come with far too many limitations on the various platforms we have in production. It might be great if the datacenter were for our internal use, but we're a hosting services provider and customers expect (fairly!) to have access to the full range of network services on their installations. If a PVLAN could be trunked, then it could help me. But so long as it requires access ports, it's worthless for me. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] bridge-domains and L2 virtual switches
Hey everyone, I'm working on replacing some datacenter Cat 6500s with Juniper MX and the more I read about bridge domains and L2 virtual switches, the more I'm completely mystified. Our current deployment is VLAN-based (one per customer installation). L3 services are provided on SVIs. If I create IRB interfaces without creating a bridge domain, is there any way to extend beyond 4094 VLANs? What I *want* is to carve off virtualized L2/L3 aggregation routers with isolated VLAN ID domains and STP instances. Looks like a bridge domain can only have a single L3 interface. Am I supposed to configure a bridge domain per installation? If so, is there a limit to the number of bridge domains? The Layer 2 Virtual Switch feature appears to require the creation of a bridge domain, and thus is subject to the same constraints. Any way around that? I could create multiple logical systems: one to handle all L3 services, and a few to behave as L2 aggregation. Then, hand off logical tunnels from the first to each of the second. This doesn't seem that bad, but I'm worried I'll hit surprising limitations down the road. I could keep the Cat 6500s as L2 aggregation and just hand-off normal L3 interfaces. This isn't so attractive, since it ties us to the keeping the existing boxes and just doing less with them. But it Am I missing any options? Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-series automation, NETCONF woes
On Fri, Mar 05, 2010 at 02:26:59PM +0300, Alexandre Snarskii wrote:
On Wed, Jan 28, 2009 at 03:40:10PM -0500, Ross Vandegrift wrote:
Can you do that without providing a map that maps the abbreviated
namespace back to the fully-qualified namespace? If so, I'd love to
know how.
Just run into the same problem myself, and workaround is here:
you can use local-name() function to do namespace-agnostic
searches, and you can use partial checks on namespaces to be
sure that you getting what you want.
Example: iterate over physical interfaces:
xsl:for-each select=//*[local-name()='physical-interface' and
starts-with(namespace-uri(), 'http://xml.juniper.net/junos/')]
Select operational state:
xsl:variable name=oper
select=normalize-space(*[local-name()='oper-status'])/
Select dropped packets for first queue:
select=normalize-space(*[local-name()='queue-counters']/*[local-name()='queue'
and
*[local-name()='queue-number']=0]/*[local-name()='queue-counters-red-packets'])/
Syntax is ugly, but it works...
I've been meaning to write up my solution to this, but haven't had the
chance. It turns out that lxml exposes namespace assignments in a
programmatically accessible manner.
Building the map I mention above ends up being very easy and means I
can rid myself of all the absurd XSLT mangling I had to do. I wish
the exposure of the namespace information had been more clearly
documented - or that I had noticed it earlier!
For Python folks, suppose that ncdoc is a netconf document. Then
here's the quick version of how to build an appropriate map of
specific namespaces from a given JUNOS response:
namepsaces = set()
nsmap = dict()
for i in ncdoc.getiterator():
namespaces.update(set(i.nsmap.values()))
for ns in namespaces:
shortname = ns.split('/')[-1]
nsmap[shortname]
# Now you can use normal XML tree traversal techniques
e = nsdoc.getroot()
name = e.xpath(./junos-interface:name/text(), namespaces=nsmap)
operstat = e.xpath(./junos-interface:oper-status/text(), namespaces=nsmap)
...etc...
This should works for any JUNOS platform that uses the consistent
namespace abbreviations we're all used to reading. Hopefully that's
all of them, forever :)
Ross
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
signature.asc
Description: Digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] email from commit or op script?
On Wed, Feb 17, 2010 at 01:56:19AM -0600, Richard A Steenbergen wrote: If you really stop and think about it, email is the perfect choice for event notification both from router-generated events and op scripts. Even the client implementation is pretty darn simple compared to all the fancy modern protocols people love to churn out, just a simple ssmtp style tcp session to port 25 to hand off the data to a real mail server. If that's all you do, then you have a server anyway - so just have the server turn the syslog message or SNMP trap into an email. The reason I think these are preferable is that they are completely one shot - the router kicks it off and forgets about it. If you used SMTP, there'd be a quite reasonable expectation that mail should be queued if something goes wrong with delivery. If you don't queue the mail in the case of an error, what was the point of using SMTP? The only answer I can see to that question - a config diff doesn't necessarily fit into syslog or SNMP traps. That's fair, but JUNOS can resolve that in other ways: fix the archive-on-commit feature so it's more flexible. In particular, what you really want for this is the ability to have the router commit the new config to local version control and have the option to push a sequence of changes to a remote branch. There's now tons of free distributed version control systems that would trivially support this. First one to port git to the MX and EX wins a case of beer from me :) -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] email from commit or op script?
On Wed, Feb 17, 2010 at 10:42:18AM -0500, Phil Shafer wrote:
That said, we could make [transfer-on-commit] run a command, like:
[edit system archival configuration]
transfer-on-commit;
archive-sites {
scp://m...@my-server/whatever;
}
archive-command ssh %A incoming-config-file --host %H --date %D --file %F;
What happens to this if you commit a change that breaks management
access or causes the control plane to go insane due to idiotic config,
bug, or whatever?
If the router doesn't retry those uploads, the above solution fails to
record precisely the change that you're most interested in! That's
why I want it to commit to a local database first - so it can be
replayed later to a central repo exactly as happened.
What VC system is used is immaterial - I mentioned git because if I
could install software on my router, there's easy and obvious ways to
do implement the idea.
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
signature.asc
Description: Digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Clearing ARP on Logical Interface (M/MX Series)
On Tue, Feb 02, 2010 at 11:56:56AM +0100, Felix Sch?ueren wrote:
show arp no-resolve | match x/y/z | save tempfile
(which takes ~5 seconds on an ethernet router with just ~20k ARP entries)
start shell
awk '{print clear arp hostname $2}' tempfile
and then copy-paste hundreds or thousands of clear arp lines.
A quick tip - JUNOS's cli is generally well-behaved shell, which means
you can just use cli in your pipeline. This will do it:
echo show arp no-resolve | cli | grep 'x/y/z' | awk '{ print clear arp
hostname $2 }' | cli
Ross
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
signature.asc
Description: Digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JunoScript VRRP Information
On Sat, Jan 23, 2010 at 03:22:49PM -0800, Curtis Call wrote: There is no XML API element for show vrrp brief. However, you can use the command API element to execute this by including show vrrp brief as the element's text contents. Is there a sure way to determine this for any particular operational command? I'm thinking in particular of EX-specific stuff which has no API documentation and impoverished JUNOS documentation. show spanning-tree interface ge-0/0/0.0 detail is what I'm specifically after here. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 resilience (VC vs 10GB cross-connect)
On Wed, Jan 13, 2010 at 08:32:45PM +, Joe Hughes wrote: I've read the VC Best practice guide and in all their examples, they have two sets of 2-switch VCs at the aggregation layer - which is making me wonder if a single VC (of two switches) and treated as one switch poses more of a risk than simply two distinct switches. I'm guessing if you have two links back from each rack - each to a different member of the VC, then the 'risks' are pretty much the same as having two separate switches? The risks are the same in terms of physical failures, but having a single VC doesn't insulate you from control-plane failures. If you need to sustain a control plane failure and the extra interfaces are worth the cost, don't VC. If that's too expensive, or a control-plane failure isn't something you care about surviving, go with the VC. In terms of software upgrades - is it possible to upgrade one member at a time (as you would in a non-VC setup) so as to not interrupt connectivity from the access\rack switches? Nope - you have to upgrade the whole chassis and reboot it when you do an upgrade. This works quite smoothly. Are there any other situations\operations on a VC that would take both switches offline - further making it more sense to either have two switches, or two sets of 2 members VCs? JUNOS bugs - by far, the #1 source of downtime in our EX4200s VCs. If your aggregation layer is supposed to be HA, I'd keep the two apart. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bfd = busted failure detection :)
On Wed, Dec 09, 2009 at 05:21:21PM -0600, Richard A Steenbergen wrote:
I've personally never had any luck reproducing it in the lab, so I
understand Juniper's frustration. It seems to require a complexity of
routes, ports, and/or protocols which we simply don't have the time or
money to reproduce in the lab, but I can reproduce it in the field (with
undesired customer impact of course) nearly every time I reboot a
router. Maybe we just need to help provide them with an example
configuration that they can try to reproduce themselves.
Hmmm, I may have just reproduced something like this in the lab. I
had two static routes for 10.57.55.0/24 and realized I hadn't applied
a per-packet load balancing policy to the forwarding table export. So
I wrote a policy and applied it to the forwarding-table export. This
has been stuck in the KRT queue for over four hours now.
This is different than the indirect next-hop change, but I wonder if
its related. Note that interesting error EPERM -- Jtree walk in
progress.
Ross
{master:0}
rvandegr...@lab-4200 show route 10.57.55.0 extensive
inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
10.57.55.0/24 (1 entry, 1 announced)
TSI:
KRT queued (deferred) change
10.57.55.0/24 - {172.16.23.2}={172.16.23.2, 172.16.23.3}
in-kernel 10.57.55.0/24 - {172.16.23.2}
*Static Preference: 5
Next hop type: Router
Next-hop reference count: 2
Next hop: 172.16.23.2 via me0.0, selected
Next hop: 172.16.23.3 via me0.0
State: Active Int Ext
Age: 8:49
Task: RT
Announcement bits (1): 0-KRT
AS path: I
{master:0}
rvandegr...@lab-4200 show krt queue
Routing table add queue: 0 queued
Interface add/delete/change queue: 0 queued
Indirect next hop add/change: 0 queued
MPLS add queue: 0 queued
Indirect next hop delete: 0 queued
High-priority deletion queue: 0 queued
High-priority change queue: 0 queued
High-priority add queue: 0 queued
Normal-priority indirect next hop queue: 0 queued
Normal-priority deletion queue: 0 queued
Normal-priority composite next hop deletion queue: 0 queued
Normal-priority change queue: 1 queued
CHANGE FROM gf 1 inst id 0 10.57.55.0/24 nexthop
172.16.23.2, me0.0
(15)
error 'EPERM -- Jtree walk in progress'
TO gf 1 inst id 0 10.57.55.0/24 nexthops
172.16.23.2, me0.0
172.16.23.3, me0.0
(15)
error 'EPERM -- Jtree walk in progress'
Normal-priority add queue: 0 queued
Routing table delete queue: 0 queued
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
signature.asc
Description: Digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J-series RVI/IRB functionality
On Thu, Dec 10, 2009 at 09:55:13PM +0800, ?? wrote:
you need trun on enhanced switching mode in coresponding uPIM.
Yea, I have that - the config example you give is the EX-like version
of JUNOS's switching config (it works, and I like it better).
But, if the J-series don't support the MX-style config, then I guess
I'm not going to be able to develop MX automation against these boxes.
Ross
chassis:
*
fpc 5 {
pic 0 {
ethernet {
pic-mode enhanced-switching;
}
}
}
interfaces:
ge-5/0/0 {
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members VLAN899;
}
}
}
}
vlans
**
VLAN899 {
vlan-id 899;
}
On Thu, Dec 10, 2009 at 4:44 AM, Ross Vandegrift r...@kallisti.us wrote:
Hey everyone,
I'm working on developing JUNOS support for the existing features in
our automation software. We are purchasing two MXes next quarter and
don't have lab MXes for me to develop against.
Instead, I have setup a pair of J2360s with the GigE uPIM. I was
hoping to develop exactly the same software that will one day talk to
the MXes. Unfortunately, it seems that the layer 2 feature set of the
J and MX are very different.
All of the documentation claims that the J-series support the
bridge-domains and family bridge style of layer 2 service [1]. But these
won't take any of that config - no bridge-domains, no family bridge.
However, I can configure EX-style layer 2 config with family
ethernet-switching and vlans. I kinda prefer this, but it looks like
my production MXes don't have this support.
I'm running JUNOS 10.0 on these J-series boxes. I've read some things
[2] that indicate the CLI is changing. Is the EX- way of doing things
the way it's all going to go moving forward? If so, this is a major
omission from the release notes - could break a lot of config.
I mostly want to make sure I'm automating the right target. :)
Ross
[1] -
http://www.juniper.net/techpubs/software/junos-security/junos-security10.0/junos-security-swconfig-interfaces-and-routing/config-l2-bridging-transparent-mode-chapter.html
[2] - http://www.gossamer-threads.com/lists/nsp/juniper/19161
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksgDCEACgkQMlMoONfO+HCXPwCbBzuk1XuicemMsS4GiTaMB2/y
l0MAnRySnaE8/b/tFR2yllDkSybylS8d
=Oj7+
-END PGP SIGNATURE-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
BR!
James Chen
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
signature.asc
Description: Digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] J-series RVI/IRB functionality
Hey everyone, I'm working on developing JUNOS support for the existing features in our automation software. We are purchasing two MXes next quarter and don't have lab MXes for me to develop against. Instead, I have setup a pair of J2360s with the GigE uPIM. I was hoping to develop exactly the same software that will one day talk to the MXes. Unfortunately, it seems that the layer 2 feature set of the J and MX are very different. All of the documentation claims that the J-series support the bridge-domains and family bridge style of layer 2 service [1]. But these won't take any of that config - no bridge-domains, no family bridge. However, I can configure EX-style layer 2 config with family ethernet-switching and vlans. I kinda prefer this, but it looks like my production MXes don't have this support. I'm running JUNOS 10.0 on these J-series boxes. I've read some things [2] that indicate the CLI is changing. Is the EX- way of doing things the way it's all going to go moving forward? If so, this is a major omission from the release notes - could break a lot of config. I mostly want to make sure I'm automating the right target. :) Ross [1] - http://www.juniper.net/techpubs/software/junos-security/junos-security10.0/junos-security-swconfig-interfaces-and-routing/config-l2-bridging-transparent-mode-chapter.html [2] - http://www.gossamer-threads.com/lists/nsp/juniper/19161 -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bfd = busted failure detection :)
On Fri, Dec 04, 2009 at 02:40:14PM -0600, Richard A Steenbergen wrote: FYI I found the root problem and hereby take back any comments impugning BFD's reputation. It turns out there actually WAS some kind of pfe bug which was causing intermittent blackholing of traffic for a few seconds at a time at seemingly random intervals several times a day. Ping from the affected devices didn't catch the issue becuase of the re-pfe forwarding path, only traffic routed entirely via pfe was being affected. BFD was actually doing its job and detected the failures that were too short to be noticed by normal routing protocols. I discovered the issue on several MX960s (mostly running 9.2R4, but one pair was running 9.4R3), and upgrading them to 9.5R3 seems to solve it (or perhaps it was just the pfe rstart that did it, remains to be seen). Is there a PR number for this issue? Sounds like it could be a drag. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Getting configuration diffs via NETCONF
On Mon, Nov 16, 2009 at 02:57:43PM -0800, Curtis Call wrote: Would file compare ... output, rather than show | compare output, be good enough? Because you can do that through an op script. Couldn't these RPC calls be translated into an equivalent NETCONF script? This looks perfect! I should easily be able to translate this into a NETCONF process that does exactly what I hoped for. I'll lay around with this today to make sure it behaves as I want. Thanks a ton, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Getting configuration diffs via NETCONF
On Tue, Nov 17, 2009 at 08:37:42AM -0500, Ross Vandegrift wrote: On Mon, Nov 16, 2009 at 02:57:43PM -0800, Curtis Call wrote: Would file compare ... output, rather than show | compare output, be good enough? Because you can do that through an op script. Couldn't these RPC calls be translated into an equivalent NETCONF script? This looks perfect! I should easily be able to translate this into a NETCONF process that does exactly what I hoped for. I'll lay around with this today to make sure it behaves as I want. Looks like I spoke too soon - the NETCONF equivalent of get-configuration doesn't provide format control - it always returns the full XML tree. I can use NETCONF to call the op script, but at that point, ssh does basically the same thing without needing to distribute a script to all of my boxes. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Getting configuration diffs via NETCONF
On Tue, Nov 17, 2009 at 01:43:31PM -0500, Phil Shafer wrote: Ross Vandegrift writes: Looks like I spoke too soon - the NETCONF equivalent of get-configuration doesn't provide format control - it always returns the full XML tree. I can use NETCONF to call the op script, but at that point, ssh does basically the same thing without needing to distribute a script to all of my boxes. You can use any JUNOS XML API call a NETCONF session, so get-configuration format=text/ will work. It doesn't work as an RPC call on 9.5R2: rvandegr...@malaclypse:~$ ssh -s lab-4200 netconf !-- No zombies were killed during the creation of this user interface -- !-- user rvandegrift, class j-super-user -- hello capabilities capabilityurn:ietf:params:xml:ns:netconf:base:1.0/capability capabilityurn:ietf:params:xml:ns:netconf:capability:candidate:1.0/capability capabilityurn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0/capability capabilityurn:ietf:params:xml:ns:netconf:capability:validate:1.0/capability capabilityurn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file/capability capabilityhttp://xml.juniper.net/netconf/junos/1.0/capability capabilityhttp://xml.juniper.net/dmi/system/1.0/capability /capabilities session-id24377/session-id /hello hello/hello rpcget-configuration format=text'//rpc rpc-reply xmlns=urn:ietf:params:xml:ns:netconf:base:1.0 xmlns:junos=http://xml.juniper.net/junos/9.5R2/junos; /rpc-reply Any get-configuration RPC gives me empty responses. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Getting configuration diffs via NETCONF
Hey all, Is there anyway to programmatically request a diff of the candidate and committed configurations? I want the exact output of show | compare, and I want it in the form at the CLI for human documentation purposes. I've seen that I can request the candidate configuration hierarchy with junos:changed attributes on all elements that either have been changed or have changed children. Generating a diff from this will be awful... I assume that JUNOS uses some XSLT/SLAX to convert XML hierarchies to the form presented at the CLI. Are those sheets available somewhere for me to use? An acceptable solution might be to fetch the candidate and committed configurations, process them with the appropriate style sheets, and produce the diff myself. Thanks, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Getting configuration diffs via NETCONF
On Mon, Nov 16, 2009 at 12:43:47PM -0500, Phil Shafer wrote:
Ross Vandegrift writes:
Is there anyway to programmatically request a diff of the candidate
and committed configurations? I want the exact output of show |
compare, and I want it in the form at the CLI for human documentation
purposes.
No, we don't have this yet, but should. We can easily make both
the text output and the equivalent XML (think of the content that
will make that delta using the delete, insert, etc attributes), but
we simply have not done it.
Damn, that'd have been a really great feature. I need to record
deltas of automated changes for approval by a human in a change
control application.
The idea was:
1) Collect and submit the user's proposed change.
2) Collect the delta, rollback the candidate.
3) Submit delta to change control system.
4) Wait for human approval of change request.
5) Resubmit change, but commit instead of rollback.
I assume that JUNOS uses some XSLT/SLAX to convert XML hierarchies to
the form presented at the CLI. Are those sheets available somewhere
for me to use? An acceptable solution might be to fetch the candidate
and committed configurations, process them with the appropriate style
sheets, and produce the diff myself.
JUNOS does not use XSLT internally at all. Most command output is
generated at the source (RPD, DCD, etc) as XML and is converted to
XML in the CLI using a proprietary formatting language called ODL
(Output Definition Language). But config is handled differently,
with MGD generating text or xml (as required) from the config
database as needed. For normal show configuration output, MGD
does the heavy lifting and the CLI just displays the lines in an
opaque way.
Wow, that's pretty surprising. Though I guess JUNOS's move to XML
could've happened before the prevalence of stylesheets.
It looks like I can kind of emulate what I need by piping scripts to
/usr/sbin/cli through ssh. For the archives, something like this does
the trick for now:
-
rvandegr...@malaclypse:~$ cat EOF | ssh lab-4200
configure
show | compare
EOF
{master:0}
rvandegr...@lab-4200 configure
Entering configuration mode
The configuration has been changed but not committed
{master:0}[edit]
rvandegr...@lab-4200# show | compare
[edit interfaces ge-0/0/0]
+ description asdfasdf;
{master:0}[edit]
rvandegr...@lab-4200#
rvandegr...@malaclypse:~$
-
Ross
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
signature.asc
Description: Digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Getting configuration diffs via NETCONF
On Mon, Nov 16, 2009 at 09:32:52PM +, jmadr...@gmail.com wrote: Maybe what you want/need would be Rancid. It does exactly what you are requesting. Its distributed by Shrubbery Networks. No, Rancid isn't going to address this, since I need diffs between candidate and commited configurations without committing. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 routing weirdness
On Wed, Oct 14, 2009 at 05:58:50PM -0700, Cord MacLeod wrote: I have 2 switches in a 2 member virtual chassis and one of them my siteops knocked over. The use ISIS for the point to point links. BGP to carry the networks. They take a default BGP route from both routers and reflect a default to the top of rack 6 member virtual chassis switch. The 2 member switch receives 2 BGP routes from the to of rack virtual chassis and reflects them to the routers. When switch in the 2 member virtual chassis died, I experienced some strangeness in routing: Do you have graceful-switchover enabled? Are you using single, physical point-to-point links or aggregated ethernet across memeber? If you are using graceful-switchover, and you have point-to-point links that terminate in only the failed member of the VC, then you can run into that situation as follows: When the member fails, graceful-switchover keeps the forwrding plane intact until restart is complete. However, for whatever reason (bug or design, not sure), the top of rack switch fails to invalidate the path over the link to the restarting peer that is now down. This means the top of rack switch blackholes all return traffic until the failed member comes back, or the restart timer expires and routing reconverges about the other member. GRES with 4200 VC is weird, since you know you'll lose a large number of ports when you lose the master. So even if you want forwarding paths maintained (there's plenty that will be unaffected by a mastership change - best not to mess with those), there are other paths that you definitely *want* invalidated, since the links have gone away. I'm avoiding this by making all of the L3 point-to-point links between VCs aggregated ethernet devices that cross stack members. This gives you the most possible isolation of forwarding path failure from control plane failure - LACP will notice that the individual link is down, and disable that particular member without losing the layer 3 forwarding path. So in your case, I'd build a single point-to-point link from the top of rack switch to the aggregation VC, at least one element of the AE on each member of the aggregation VC. If you're not using graceful-switchover, then I'd expect your config to work fine, modulo some forwarding impact while routing reconverged. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Routing Throughput
On Thu, Oct 08, 2009 at 01:42:13AM +, Chris Morrow wrote: check out snmp support as well, good times and spinlocked snmpd, weee! ( forget the order but something like snmpwalk the standard v2 accessible mib tree and boom snmpd spins itself into the ceiling, until 9.5something code) Do you have any more information on this issue? Our VCs running 9.3R4 have begun displaying an oddly high CPU utilization, evidenced by SNMP data collection timeouts - our graphs will sometimes have gaps of no data for 2-10 contiguous five minute polling cycles. Sounds like we could be seeing the issue you describe, though we didn't see it until 9.3R4. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Delete Interface
On Thu, Sep 17, 2009 at 11:21:10AM -0500, venkata saranu wrote:
i want a netconf command for delete interfaces ge-x/x/x{.}
Could you please assist me? we are using MCR using netconf
Submit a document with a default action of none and specify the
subtree you'd like to delete with opeartion=delete. Something like
this should do the trick:
rpc
edit-config
targetcandidate//target
default-operationnone/default-operation
config
interfaces
interface operation=delete
namege-x/x/x/name
/interface
/interfaces
/config
/edit-config
/rpc
Here's the reference:
http://www.juniper.net/techpubs/software/junos/junos93/netconf-guide/deleting-configuration-elements.html
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Delete Interface
On Thu, Sep 17, 2009 at 12:01:10PM -0500, venkata saranu wrote:
Got the Error as below
Ah - I missed the top-level configuration tag. Try this instead:
rpc
edit-config
targetcandidate//target
default-operationnone/default-operation
config
configuration
interfaces
interface operation=delete
namege-1/1/0/name
/interface
/interfaces
/configuration
/config
/edit-config
/rpc
Ross
rpc-error
error-severityerror/error-severity
error-info
bad-elementinterfaces/bad-element
/error-info
error-messagesyntax error, expecting lt;configurationgt;/error-message
/rpc-error
load-error-count1/load-error-count
rpc-error
error-severityerror/error-severity
error-messagesyntax error/error-message
/rpc-error
/rpc-reply
Could you please suggest me ... Thanks in advance...
On Thu, Sep 17, 2009 at 11:52 AM, Ross Vandegrift r...@kallisti.us wrote:
On Thu, Sep 17, 2009 at 11:21:10AM -0500, venkata saranu wrote:
i want a netconf command for delete interfaces ge-x/x/x{.}
Could you please assist me? we are using MCR using netconf
Submit a document with a default action of none and specify the
subtree you'd like to delete with opeartion=delete. Something like
this should do the trick:
rpc
edit-config
targetcandidate//target
default-operationnone/default-operation
config
interfaces
interface operation=delete
namege-x/x/x/name
/interface
/interfaces
/config
/edit-config
/rpc
Here's the reference:
http://www.juniper.net/techpubs/software/junos/junos93/netconf-guide/deleting-configuration-elements.html
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
--
o__
-,/'_
(_) \ (_) - - - - -??? - - - -
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-4200 VC, unable to lock config on fpc
On Fri, Sep 04, 2009 at 04:06:10PM +0100, samuel@bt.com wrote: Have you got some news about this PR? Do you know in which JUNOS version it will be fixed? Yes! This was fixed as part of 9.3S4, but that release contained a bug that would cause copper ports to spam pause frames. 9.3R4.4 is out and contains the fix for this issue from 9.3S4. We have tested this version and confirmed it looks good. It's in production on some of our VCs and is working great. Upgrades for the rest are in the works. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200
On Mon, Aug 17, 2009 at 02:18:16PM -0400, Brendan Mannella wrote:
I was wondering if anyone has ever seen a EX4200 drop OSPF/BGP session when
adding a vlan member to a interface?
ge-0/1/2 {
description ge-1-3-0.m7i.pit2;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ v101 v501 v510 505 ];
This link connects to a gig interface on a m7i, which I have not configured
the additional vlans on yet. Though 101, 501, 510, and 505 are configured on
there.
All I did was added vlan members 513, 514, 515 and commited it and that
brought down all connections that pass through the 4200 interface ge-0/1/2
to the m7i.
Brendan,
Could you comment a bit more on your config with this issue? I just
attempted to replicate it on a 9.5R2 lab box and was unable.
I tested with OSPF running on an RVI with two upstream routers.
Changing trunks unrelated to OSPF didn't flap. Neither did changing
trunks carrying the VLAN for my RVI.
I just want to make sure I'm 100% avoiding this potential issue.
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200
On Thu, Aug 20, 2009 at 08:15:57AM -0400, Brendan Mannella wrote: I have just went to 9.3r4.4 and it fixed most issues Seems very stable so far. Have you reported this issue to JTAC? Is it documented in a PR? This has huge potential impact for system I'll be turning live in the coming months, so the report makes for very good information. I'd like to see that addressed. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 throughput trouble on 10GE interface
On Tue, Aug 04, 2009 at 11:32:12PM +0400, Michael wrote: Uplink is connected to catalyst 6500: c6500-BGW-XL#sh int te3/6 | i flow input flow-control is on, output flow-control is off The 6500 10G cards that have more than four ports are oversubscribed. Are you sure you don't have contention on the other side due to traffic levels on other interfaces? Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX960 SCB Alarm
On Tue, Jul 28, 2009 at 03:10:28PM +0300, Walaa Abdel razzak wrote: show chassis alarms 2 alarms currently active Alarm time Class Description 2009-07-28 02:45:51 UTC Minor Check CB 1 Fabric Chip 0 2009-07-28 02:45:51 UTC Minor Backup RE Active I need to know the meaning of the CB 1 Fabric Chip 0 alarm and if it's harmful or not and how to resolve. Check your logs - there should be some reasons given for the alarm. We recently saw this and the box had logged a series of CRC errors from that chip. JTAC issued an RMA. It seems there's an extremely rare software issue that can sometimes log CRC errors on the MX SCB, but that in the vast majority of cases, it just means that the board is flaky. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Bulk updates to Netscreen 5400
On Fri, Jun 26, 2009 at 12:52:49PM +0100, Phil Mayers wrote: However - I have it on good authority that NSM merely uses a hidden CLI command to start commit bulk updates all at once, a bit like SQL e.g. set mode bulk set address Trust ... ...100 more lines set mode bulk-commit ...or something like that. Does anyone know what those magic commands are, if they really exist? Are there any caveats to using them? I don't know the total sequence of commands, as I've never actually done this, but I think you're looking for exec config lock ... -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] as-path filtering
On Thu, Jun 25, 2009 at 11:17:58AM +0545, Samit wrote: Works..! Thanks for you help. Samit Nalkhande Tarique Abbas wrote: Try this.. set policy-options as-path a .*1234 set policy-options as-path b .*5678 I didn't notice this before, but you probably don't mean that. The regex above also matches AS paths like 1000 2000 71234 3000 and 1000 2000 12345678 3000 You want: set policy-options as-path a .* 1234$ set policy-options as-path b .* 5678$ Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-4200 VC, unable to lock config on fpc
On Thu, Jun 25, 2009 at 07:51:03PM +0100, Firth,MJC,Michael,DMJ R wrote: Could you keep us updated with the progress of this? In particular a PR number if you get one, and whether the issue only affects VCed EXes, or if it can also cause issues on standalone units. I just finished a secure meeting with ATAC and Juniper engineering. It definitely only affects virtual chassis EX-4200s, as it requires a backup RE. No idea if it affects EX-8200s. dcd on the backup RE is leaking one file descriptor per physical interface in the virtual chassis. When the number of leaked descriptors exceeds 2000 (the kern.maxfiles limit), any commit causes mgd to corrupt the configuration database on the backup RE. A PR is being filed on the issue (don't have a number yet). You can clear the condition by killing dcd on the backup, blowing away the config database on the backup, restarting mgd, and HUPing init. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-4200 VC, unable to lock config on fpc
On Thu, Jun 25, 2009 at 12:26:17PM -0700, Cord MacLeod wrote: Did they explain which versions of code this affects, or is it specific to your code train of 9.3S1.6? Not sure yet. I'm also curious why you went with 9.3S1.6 as opposed to 9.3R3, which JTAC tells me is the release they recommend. We were suggested run 9.3S1.6 because of PSN-2009-05-398. Two bugs with forwarding impact were found in 9.3R3.8, both of which are relevant to our use of EX4200s in virtual chassis. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-4200 VC, unable to lock config on fpc
On Tue, Jun 23, 2009 at 05:30:38PM -0700, Cord MacLeod wrote: I had this issue adding members to an existing VC. Did you upgrade all of the members to the same code? When I did, the issue was fixed. You run VC with mis-matched code versions? You are braver than I! We always run the same code on all members and upgraded the entire VC at the time of upgrade. We have yet to observe the issue returning to a member that has been rebooted, but it's still a bit early in the troubleshooting process to say that a reboot fixes it for sure. JTAC claims they saw this issue with 9.2 but not 9.3, and that it was very rare. Meanwhile, we didn't see it until three days after moving to 9.3. They are sticking to the flash corruption line, which I'm still not convinced by - they are working on getting the documentation they have on the issue. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ping vs. traceroute in an L3 routing-instance
Hi everyone, I have some MX240 routers that have been configured with four extra routing-instances. Each routing instance has interface routes and a default route pointing to a different transit provider. If I try to ping with the routing-instance and source options, I get: ping: sendto: Can't assign requested address But, if I use traceroute instead, things work fine. Am I missing something silly? Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper EX AE Bundle with LACP active
On Tue, May 26, 2009 at 02:18:25PM -0400, Brendan Mannella wrote: just wondering if anyone else has experienced any issues with EX switches and ae bundles. Very much so. For no reason the bundle has been flapping at random, a few times per day. The physical interfaces never flap, just the bundle. Can you find any relation to config commits? I once saw a VC develop a problem where any commits caused aggregated ethernet devices to flap, though the individual member interfaces did not flap. I was able to resolve this issue by changing the LACP mode fast and then back to default. My feeling is that restarting lacp should've fixed it as well, but that's not the tact that JTAC wants to take on the issue. All switches are running 9.5R1.8 Everyone that I've talked to inside Juniper has suggest JUNOS 9.3R3 as the suggested version for all of my deployments, but all of my EX boxes are 4200 virtual chassis. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Advanced BGP with JUNOS
Hi everyone, Is there a resource that delves a bit more into the guts of BGP on JUNOS? I've got JUNOS Enterprise Routing and JUNOS Cookbook, but neither one digs deeper into BGP than basic config. If you're familiar with BGP Design and Implementation from Cisco Press, I'm interested in something like Chapter 3, Tuning BGP Performance. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 log message question
On Thu, May 21, 2009 at 10:37:30AM -0700, Cord MacLeod wrote: Can you elaborate on 'the whole routing seems to fail'? I was actually told by JTAC to upgrade to 9.3R3 as soon as it came out as it would be exceptionally stable code. For what it's worth, I've been running some interim 9.3R3 builds for a while now and it's resolved all of the issues we had. I configured a VC with 9.3R3 the other day, and unlike 9.3R2, boots in our config! At least it's off to a better start :). I'd also love to know what the aforementioned routing failures are, since I'm about to start turning up a bunch of larger L3 VCs on 9.3... Ross On May 21, 2009, at 2:13 AM, Thomas Eichhorn wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Malte, Cord, according to our SE this is just debugcode - which should have been fixed in the 9.3 service release and also 9.3R3 - but at a current state I would really recommend not to upgrade to this version - I'm not yet really sure, but under some cirumstances the whole routing seems to fail. I really recommend to everyone to test all the needed features first in a lab. Tom Malte von dem Hagen schrieb: Cord, Am 21.05.2009 02:23 Uhr, Cord MacLeod schrieb: Every now and again I'm seeing the following log message: May 20 22:23:34 gsw1 fpc1 Resolve request came for an address matching on Wrong nh nh:1499, type:Hold...? May 20 23:08:03 gsw1 fpc1 Resolve request came for an address matching on Wrong nh nh:1501, type:Hold...? Any ideas what this could mean? JUNOS Base OS boot [9.3R3.8] this matches PR/412240 and can be ignored (according to JTAC, which I asked about that in 9.3R2.8). I was not able to get information about the root cause out of them. Kind regards, Malte ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoVGycACgkQrUvjMoak8ZdLpQCeK1djeTn5hYxGVeZ2uj9nvMv7 moIAoKI8yhIZpCE6jyChN+1MSrkdJYOd =QDGS -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] nsrp ha link over ex4200
On Tue, Apr 28, 2009 at 11:17:04AM +0300, Yordan Boikov wrote: Hi, we have two SSG 520M firewalls and two ex4200 switches [ SSG520M fw1 ][eth1/7] - [ge-0/0/3][ ex4200 sw1 ][ge-0/1/2]===trunk===[ge-0/1/2][ ex4200 sw2 ][ge-0/0/3] [eth1/7][ SSG520M fw2 ] I want to configure HA between fw1 and fw2 the problem is that sw2 doesn't see fw1 sw1show ethernet-switching table vlan ha-vlan Ethernet-switching table: 2 unicast entries VLAN MAC address Type Age Interfaces ha-vlan * Flood - All-members ha-vlan 00:22:83:88:38:15 Learn 0 ge-0/0/3.0 ha-vlan 00:22:83:88:3f:15 Learn 0 ge-0/1/2.0 sw2 show ethernet-switching table vlan ha-vlan Ethernet-switching table: 1 unicast entries VLAN MAC address Type Age Interfaces ha-vlan * Flood - All-members ha-vlan 00:22:83:88:3f:15 Learn 0 ge-0/0/3.0 both switches have same config and same junos version. IGMP snooping is disable for all VLANs Two things to check: 1) The trunk connecting ge-0/1/2.0 to ge-0/1/2 needs to permit ha-vlan on both switches. 2) Have you renamed or changed the tag on ha-vlan on sw2? If so, there is a bug on the ex4200 that prevents reliable learning of MAC addrs. Delete ha-vlan, commit, recreate ha-vlan, and then try again. Remember to enable active NSRP HA probing with a setup like this. It's also useful to pick a production interface as an NSRP secondary path. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ISG IDP modules dropping traffic in tap mode
Hi everyone, I just experienced a very strange issue. We have a pair of ISG2000s with IDP modules in an Active/Passive NSRP configuration. A few policies have IDP processing enabled in Inline Tap mode. We're running 6.1.0r3.0-IDP. For no obvious cause (no one updated the config at all), sessions through the firewalls began dropping approximately 10-20% of all final ACK packets in the three-way TCP handshake. No messages were logged. Flow debugging indicated that SM_RULEs were sucessful and that session installation was completed. Pushing policy to disable Inline Tap processing on the four or five policies with it enabled fixed the problem instantly. Qualitatively, it looked as if the IDP module was inline and out of TCP reassembly buffers except that the modules were in tap mode. Almost all of the IDP module bugs I've seen include no logging of action taken. But I don't know what to think about the fact that the modules were in tap mode. Has anyone seen anything similar? -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex-series: etherchannel bpdu loop ?
On Wed, Mar 18, 2009 at 02:35:11PM -0400, Jeff S Wheeler wrote: On Wed, 2009-03-18 at 20:39 +0300, Alexandre Snarskii wrote: After power failure on one of our pop's we faced strange problem: etherchannel between juniper ex-4200 and cisco 2960g started to flap. By logs I saw that Cisco determined 'etherchannel Are you on 9.2R2.15 or earlier? I believe this is a bug on the EX. Any chance you can point me to a JUNOS PR or release notes that fixes this? I've got a few VCs of 4200s that exhibit very bizarre aggregated ethernet issues -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] License : Juniper ISG-2000
On Fri, Feb 20, 2009 at 11:30:39AM +0100, Sidney Boumendil wrote: VR are routing instance, 3 is generally enough for most setups. If you need additional ones you have to buy a vsys licence. Instructions on how to generate and install it are provided by Juniper with the licence file. Just to be clear - the vsys licenses and the vrouter licenses are different. A vsys license enables a vrouter for each purchased vsys, but the converse does not hold. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Commit delays, Netconf/XML order-of-operations
Hi everyone, Does anyone know what JUNOS will do if you disconnect a Netconf session after issuing a commit but prior to receiving the response, when the candidate configuration is locked? According to the docs: If the candidate configuration is not committed before the client application unlocks it, or if the NETCONF session ends for any reason before the changes are committed, the changes are automatically discarded. The candidate and committed configurations remain unchanged. It's not clear to me if the changes count as committed after issuing the commit operation but before it completes. I'd test it in my lab, but only my production EX-4200 virtual chassis seem to take long enough to commit for this to be an issue. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-series automation, NETCONF woes
On Wed, Jan 28, 2009 at 11:00:27AM -0500, Joe Abley wrote: On 27 Jan 2009, at 16:23, Ross Vandegrift wrote: 3) XML is far more complicated than SNMP with marginal benefits to a switching environment. This whole message was a great read, and I'm glad you took the time to write it. On this particular point, though, I think you need to compare apples with apples. XML is a data representation; SNMP is a protocol. It would make more sense to compare XML with ASN.1, in which case I'd assert ASN.1 is far more complicated -- to the extent that you don't think about constructing or parsing PDUs by hand, and instead use tools to do the job for you. Well, that's a fair enough point, but not really what I am getting at. I'm really concerned about the consequences of using XML vs. ASN.1 and how this affects the naming of things I need to find. Using ASN.1 with SNMP, I always know how to reach the table of interfaces. This is defined in the IF-MIB: .1.3.6.1.2.1.2.2. All of devices that implement the IF-MIB use this fixed name. This makes it easy for the developer to know where to go for specific information. In XML with NETCONF, the namespaces mean that names of things aren't fixed. For example, on an EX switch with JUNOS 9.2R2, my interfaces are found under the XML element named: http://xml.juniper.net/junos/9.2R2/junos-interface:interfaces. Now let's upgrade to JUNOS 9.3R2. The same interfaces, in the same configuration, are now collected under: http://xml.juniper.net/junos/9.3R2/junos-interface:interfaces. See how the name in the tag changed based on the version? XML parsers enforce proper use of namespaces to maintain document structure. You can't search for the interfaces tag because there is no such tag! You have to search in a namespace, and that means writing code that generates version-specific naming for JUNOS. I'm not saying that ASN.1 is necessarily simpler. But because the namespace is global, implementation of ASN.1 in SNMP forces vendors to produce consistent names. NETCONF fails to enforce that, permitting vendors to run wild with their own names and come up with schemes that are difficult to handle programmatically. If you take the same approach with NETCONF and use tools to generate, validate and parse request and response documents, then I'd suggest that the difference in complexity boils down to how good your tools are. Yup - and that's been my approach. I have a library that abstracts out the hacks I had to do to parse the serialized XML before I give it to the XML toolkits. It's ugly, but it does work. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX-series automation, NETCONF woes
Hello everyone, I've spent the past few weeks developing automation software for the JUNOS EX-series switches. During this time, I have come to miss IOS for its SNMP-based configuration. In case anyone from Juniper is reading, I'd like to describe why I have found NETCONF to be such a painful experience. If anyone has come up with practical solutions to these problems, or if I have overlooked some solution, I'd be very interested in hearing. I'd love to hear that I'm barking up the wrong tree! I'll also note that we're using the EX-4200 as a top-of-cabinet switch for datacenter deployments. Config is relatively simple layer 2 switching with LACP and MSTP. This strongly shapes how we interact with the devices. - Four central problems - 1) NETCONF performs very poorly. Running over SSH means that I'll always have TCP session and SSH key exchange to wait for. I can't start a NETCONF session in less than 3-5 seconds. SNMP latency is a fraction of this and it's very easy to make interactive applications that make realtime changes. Furthermore, I have to manage connection lifecycles. My only real optimization recourse is to try and reuse open connections, which is tricky to do without leaking connections. 2) NETCONF is inefficient. Want to enumerate the switch ports and their assigned VLANs for the server guys? You'll need get-interface-information/ as well as get-vlan-information/. In my lab setup, this is over 150K of data so I can produce a table like: Interface VLAN ID ge-0/0/05 ge-0/0/16 ... In a production VC of a few members and a hundred or so customers, this is like half a meg. What's that going to look like when we have 400 servers on a VC of ten switches? Almost all of that data is waste - tags and namespaces have no operational value. I only wanted a fraction of the info I got back, but there's no way to make my queries more specific. I can produce the above info with SNMP by walking IF-MIB::ifName and either Q-BRIDGE-MIB::dot1qPVid or CISCO-VLAN-MEMBERSHIP-MIB::vmVlan. Juniper doesn't expose dot1q tags via SNMP - only the internal VLAN index that JUNOS uses. 3) XML is far more complicated than SNMP with marginal benefits to a switching environment. If you're automating MPLS VPN creation on a router, XML makes sense - you need to load a fairly decent amount of structured config, and you want to do so atomically. But in a datacenter switching environment, the vast majority of the changes are single attribute changes: changing an interface description or updating an access vlan. Automating these two things means 99% of our manual switch work goes away. Want to update the description? Here ya go: rpc lock target candidate/ /target /lock /rpc !-- wait for acknowledgement of the lock -- rpc edit-config target candidate/ /target config configuration interfaces interface namege-0/0/10/name descriptiontest/description /interface /interfaces /configuration /config /edit-config /rpc rpc commit/ /rpc With SNMP, all I need to do is set ifAlias. One action, it's atomic. No need to generate documents describing minor operational work in horrifying detail. Same deal with changing an access vlan. 4) Juniper seems to change the XML namespaces with every release. This means that the XML responses from two different versions of JUNOS require different parsing rules. The XML patterns that are widely implemented assume that the namesapce is a granted thing. Mucking about with it at runtime, based on responses from a switch, has required a very ugly stack of hacks. Now I'm stuck with a very complicated software to do two very basic things. If I had to start over - I'd use expect. - How I would address these - 1) The Q-BRIDGE-MIB on the EX-series is great except for one crucial oversight: the dot1q VLAN ID (arguably the most important piece of data) is not exposed anywhere. This is easy to fix - just add a table mapping the JUNOS VLAN Index to the dot1q VLAN ID. 2) Permit read-write access to the IF-MIB and Q-BRIDGE-MIB. Single attribute changes become trivial. This would probably be a harder change, since JUNOS has a candidate config model. If you've made it this far, thanks for reading, Ross Vandegrift -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 static arp
On Sat, Jan 17, 2009 at 10:45:04PM +0200, boi...@spnet.net wrote: the interface of ex4200 switch is connected to other switch and the port is in ethernet-switching mode. I found how to setup static arp entry in the vlan but I get error when commiting, something like multicast mac xx:xx:xx... is not allowed Multicast addresses are explicitly prohibited by RFC 1812 in section 3.3.2: A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address. Sadly, it looks like your vendor has ignored this. Microsoft similarly ignores the requirement as well. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX-series VLAN info via SNMP
Hi everyone, I've written a lot of software that uses SNMP for querying various things about a switch's config for a lot of different vendors. Everyone does this simple thing in bizarre and confusing ways. But never until the EX series have I seen a switch that appears to have no way to get the dot1q VLAN tag via SNMP. Q-BRIDGE-MIB::dot1qPvid is equal to the internal VLAN ID (which has no relation to the dot1q tag) Q-BRIDGE-MIB::dot1qVlanStaticName lets you walk the names of VLANs. The name indexes tables under jnxExVlan, none of which expose the dot1q tag. jnxVlanID sounds promising, but maps the name back to the internal VLAN ID. Their Q-BRIDGE-MIB implementation leaves almost every field blank. No VLAN has a valid dot1qVlanStaticEgress or dot1qVlanStaticUntaggedPorts map - all are the empty string. I understand I'm probably supposed to use Netconf to get this data, but boy, it'd have been nice to not have to reimplement all my SNMP tools... Just venting. Anyone found something I missed? -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX sw license
On Sun, Oct 19, 2008 at 11:04:18AM -0500, Derick Winkworth wrote: I hope Juniper doesn't start licensing their products to death, like the big C has in some cases... You've obviously never used other products from Juniper. They are far worse than Cisco in the which features did you pay for department. SSL VPNs, firewalls, NSM, STRM are all license controlled out the ears. The EX and MX series seem reasonable in this department - I asked our SE before we bought an MX if there were any licensing surprises for features waiting and he assured us that there wasn't. Ross -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] OpenSSH V5.1 with ScreenOS
Hello, Looks like something changed during a recent upgrade to OpenSSH V5.1. When connecting to ScreenOS firewalls, the firewalls closes the connection as soon as authentication has passed. We've got a ticket open with JTAC, but I'm not sure it's going to go anywhere quickly. I've run into different quirks with Netscreen-SSH before, so I'm guessing there's some new option that confuses the firewall. Anyone run into this and found a workaround? -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DRAM for M7 / crash of M7
On Tue, Aug 26, 2008 at 03:19:38PM +0100, Dermot Williams wrote: My question is a more general one about whether or not Juniper reserve the right to refuse to support a chassis that has had non-Juniper components installed, whether that's DRAM, SFPs or compact-flash cards. Obviously if a problem is identified as originating with a dodgy non-Juniper stick of RAM, I wouldn't expect them to provide a replacement for the RAM but I would be wary about installing it in the first place if I thought that they (or any other vendor) would refuse to provide any support whatsoever once it became apparent that there was one or more non-branded components present - even if the actual problem isn't necessarily related to the component in question. JTAC told me that they will refuse to support an SSG box if we upgraded the memory without purchasing it via the Juniper SSG upgrade kit. It was a particularly bad case, since the Juniper-rebranded RAM was the exact same brand that we purchase in bulk. Oh yea, except that instead of costing $100 for the upgrade, it was $1500. Precisely the same model as the sticks we were ordering at that point, from precisely the same manufacturer. -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper support vs. Cisco TAC - experiences?
On Wed, Jul 09, 2008 at 08:50:50AM -0500, Boyd, Benjamin R wrote: I agree, the web interface with Juniper is far superior to Cisco's. For any non-critical issue I rarely even have to speak with JTAC it's all accomplished via e-mail/messaging. On the Netscreen side of the fence, it's a different story... Everyone seems to be @juniper.net, but first and second tier support are typically rather bad. We've asked a lot of rather sophisticated NSRP questions over the years, and it's pretty evident that their NSRP techs don't have that much experience. I've had to argue with techs to have them escalate a question that they obviously didn't understand. On the other hand, there have been two or three occasions over the years where I have had to open an emergency case due to firewalls crashing repeatedly. In each of these cases, JTAC has quickly and effectively escalated my case to someone with not only superior knowledge and experience, but someone with access to things like interim software builds that fix known issues. In the worst example of this, I had a new build of ScreenOS that fixed the issue in under 10 minutes. So while JTAC is occasionally like pulling teeth, I'm kind of willing to grin and bear it since when we've *really* needed them, they've come through. That's more than I can say for our emergency cases at Cisco, where we've been told BGP updates cause memory fragmentation and we just need to reboot sometimes. Or my personal favorite, cosmic rays. Ross -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
