Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
Saku Ytti writes: > I think best compromise would be, that JNPR would offer good filter, > dynamically built based on data available in config and referring to > empty prefix-lists when not possible to infer and customer can fill > those prefix-lists if needed. And also have functional ddos-protection > configuration out-of-the-box. People who want and can could override > and configure themselves. That would be really wonderful. A great start would be if there was a way to get just the /32 (or /128) interface IP addresses in apply-groups. Another great thing would be if you could match, in interface filters other than lo0, "is destined for the RP" or the opposite. In most cases, traffic that is destined for the router itself has completely different security requirements to passthrough-traffic, which is also completely different from router-generated traffic. It is a pain to use IP-addresses to guess which category the traffic is. Linux (and therefore RouterOS) does this by having THREE filters, input, output, and forward. On router platforms you only get input and output. In practice JunOS attaches filters to interfaces, so that kind of design would lead to 4 filters: inputlocal, input, output, outputlocal. Having "src-local", "dst-local", and "local" as terms instead would keep it at 2 filters. The challenge might be that the input filter does not yet know whether it is going to forward the traffic to the RP, since input filtering necessarily happens before routing. It would definitely work for output filters. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [OT] unit-level vs interface-level description
Phil Shafer p...@juniper.net writes: Cool. Consider it not done. You could publish a commit script to handle that... That way people can install it or not, and it should be a nice example script. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [OT] unit-level vs interface-level description
Phil Shafer p...@juniper.net writes:
---
version 1.0;
ns jcs extension = http://xml.juniper.net/junos/commit-scripts/1.0;;
import ../import/junos.xsl;
match configuration {
for-each (interfaces/interface[description]/unit[not(description)]) {
var $content = description ../description;
call jcs:emit-change($content, $tag = transient-change);
}
}
---
Thank you, much prettier than what I would have done.
/Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti s...@ytti.fi writes: Microbursts will drop UDP has well, you'll experience this as packet loss just the same, so you want to find value which has 0 packet loss. This same number will indicate when TCP will start dropping (and reducing window-size) There will only be packet loss if you test while there is background traffic on the link. If the only load is a perfect stream of UDP packets, the buffers will not fill and no packets will be dropped. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti s...@ytti.fi writes: Obviously microbursts can (in both TCP or UDP) scenario happen without any background traffic. Consider you're connected to 1GE port, testing another host in 100M port, if you limit your rate to 100M, you still causes the 100M port to congest, as incoming rate is always 1GE for variable duration (depending on how you police the sending). Yes, you can in theory cause microbursting of UDP if you want. I am just not sure which tool I would use to do that. Typical UDP tests like iperf attempt to do perfect timing of packets so bursts are avoided, and they seem to do a fairly good job of it. In contrast, iperf TCP can get awfully bursty. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti s...@ytti.fi writes: make sure with tshark what your actual window size is, don't trust iperf. Best thing is to configure OS TCP stack to window scaling and dont touch iperf window settings, I don't know why, but they just seem to break stuff. In my experience, you cannot trust iperf to not override the OS window size. Explicit -w seems to be the only reliable solution. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Saku Ytti s...@ytti.fi writes: This highlights the fact that you should not test network with TCP, always UDP, with TCP there are so many things to go wrong which are not network related, UDP is much more reliable indication that problem actually may be in the network. UDP tests can be too generous on the network. A stream of perfectly spaced UDP packets will not show problems with microbursts. Almost all bulk transfer protocols are TCP, so it is important to test with TCP. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 port numbering
Pavel Lunin plu...@senetsy.ru writes: Why not convert this ritualistic stuff into something more useful, like, say, turn particular port LED blue when user types request interface highlight ge-blah/blah? But for some reason vendors don't care and even switches/routers with ID-shields are rare things despite modern DCs and POPs are becoming more and more dense. Yet another thing that server vendors have done right for years and router vendors haven't discovered... ethtool --identify en0 /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
Luca Salvatore l...@ninefold.com writes: I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? VPLS presents a layer 2 link. There is no way for a L2 link to send ICMP messages. Fix your VPLS core to present a 1500 byte (or preferably much higher) MTU or tell the servers what the actual MTU is. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Splitting Dot1q VLAN across Logical Systems
Skeeve Stevens skeeve+juniper...@eintellego.net writes: I'm hearing I have to allocate a whole physical interface to a Logical System which means I can't use a VLAN from it for another Logical System. Does this make sense with what I am looking to do? You should be able to assign logical interfaces to each logical system. E.g. place xe-0 unit 100 in logical system A and xe-0 unit 200 in logical system B on both routers. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Smallest size IPv6 allocation typically advertised?
Morgan McLean wrx...@gmail.com writes: Just curious what the smallest v6 advertisement providers will accept is these days? I've seen no smaller than /48 mentioned on various boards, but I see arin will allocate all the way down to /32. We currently have a /48, and I advertise the whole thing but I'm considering splitting it up among multiple sites. Please do not split up smaller than /48. You will be heavily filtered. If you have reasonable connectivity between sites, get something larger than /48, perhaps /44 or even /32 if you are a hosting provider. Announce /48 for each site and announce each /48 plus a covering /44 or /32 or whatever you were given. That way you will be reachable even from those providers who filter by database objects. On the other hand, if the sites each live in their own world, consider whether you can live with PA space from whichever provider you have at each site. If you must have PI, get a separate /48 for each site if possible. Akamai can get away with taking a /32 and splitting it to deaggregated /48's, because any ISP which cannot reach Akamai is going to get complaints from its customers. If you have that kind of clout, you can do whatever you want. For the rest of us, being strict in what you send and liberal in what you accept is the only -- and strict means no deaggregation without covering routes or separate database objects. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Paul Stewart p...@paulstewart.org writes: Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) That sounds like hierarchial shaping. You need MX for that, and even then you may meet challenges doing it on ingress. I would have thought that the 6500 needed ES cards for that, but those have only been available for about 5 years? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper cisco switch interconnection
Patrick Dickey dickeypj...@yahoo.com writes: Just a quick note: if you need multiple vlan STP (like what PVST+ has...), use VSTP on the Juniper. Yes, my advide was wrong, I read RSTP as VSTP. I have only tried VSTP against a Cisco, never RSTP. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper cisco switch interconnection
harbor235 harbor...@gmail.com writes: Has anyone connected a Juniper EX series switch with a Cisco switch (I have a 3550)? Yes Do you use a standard crossover cable? MDIX? I have only attempted 1Gbps, that just worked with a straight cable. Any Layer 2 issues with RSTP and PVST+? It seems to work so far... Any specific configuration required to make it work? Avoid VLAN 1. You can probably make VLAN 1 work if you try, but for me it was easier to simply not use it. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
Ryan Goldberg rgoldb...@compudyne.net writes: Do you see an issue with blowing up ex4200s with all this ospf and vrrp? I'm labbing tomorrow and will try to get the boxes to thrash. From a routing table size POV I'm not worried (many customers having no extra routes, lots have 4-6, a handful having as many as 30 or 40), I'm a little concerned all those processes might upset the RE if things get flappy. I can handle a little bump but if they just freak out that wouldn't be good. I do not really have much experience with EX-series and layer 3. I let the MX80s do the VRRP and OSPF, which has not been entirely smooth sailing lately. Good thought. Can you hook up L3 addresses to the inner tags on EX boxes? I'll have to play with that. No, the EX4200 would have to handle a dual tag push, and the hardware can't do that. Rumour has it that the EX4500 and EX4550 has the necessary hardware, but even if that turns out to be true, their software can't do it (yet?). /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] small multitenant datacenter
Ryan Goldberg rgoldb...@compudyne.net writes: I will re-review what we may need/what may be lacking. It seems the 3300s are catching up, and we have had good luck in small single-tenant deployments (3 vmware host + SAN), using them strictly as stacked L2 switches, generally in place of a pair of 3750x or 2960s. I avoid the EX3300 because it requires a feature license for q-in-q tunneling. Even HP has stopped doing that. Personally I find it confusing that feature licenses are so different across the EX series. It is probably unavoidable that not all hardware is equally capable feature-wise, but checking for which features need a license on which box is a bit of a nightmare. Not as bad as a certain other vendor, but still. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Routing Instance BGP Full Routing High Memory persists
Michael Loftis mlof...@wgops.com writes: This is actually expected behavior of Unix-like OSes in general. RPD may in fact have released the memory (using free()) but will still have that RAM associated with it. This is due to the fact that Unix (BSDlike esp) generally use brk() or sbrk() under the hood during malloc() to request more RAM from the OS. There's actually no way for a process to return memory to the OS. I believe you are a few years out of date with that information. Modern malloc() implementations tend to use mmap() to get their memory, and free() tends to unmap memory if the malloc library does not expect to need the memory again soon. There is often a delay before the unmap. However, it is easy to end up with fragmented memory which cannot be returned to the OS. As long as there is even a single byte in use on a page, that page has to be kept around. The various malloc libraries vary in how good they are at avoiding fragmentation, but none of them are perfect. Most often it doesn't matter anyway; if a single almost-never-used byte keeps a page from being freed, it can just go to swap. Similarly, if an empty page is kept around just-in-case and the system needs the space, it can just go to swap. Routers, however, rarely have swap... /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Detecting OSPF packet drops
Saku Ytti s...@ytti.fi writes: RSP720 is lower spec pq3 than MX80 yet it runs circles around MX80 in terms of convergence and scale. In fact when I heard about MX80, I wasn't worried about RE performance at all, top-of-the-line pq3, faster than RSP720, should suffice no problems, how naive I was. Indeed, the ~1500 L3 VLANs which were moved to the MX80 causing the problem came from an RSP720 which had no problem at all handling the load... (It had all sorts of other interesting problems, as everyone who has worked with the 7600 before SUP2T can surely attest, but it handled OSPF load just fine.) It was a nasty surprise I must say. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Distributing OSPF load on MX80
As mentioned in the thread on OSPF packet drops, I have an MX80 dropping OSPF packets during every commit, after adding ~1500 VLAN interfaces. The major load seems to be ppmd, not rpd. On larger MX's, it is apparently possible to distribute ppmd processing to the line cards. Does that work on the MX80? Alternative, is BFD cheap on an MX80? If I turn on BFD, I could set the OSPF hello timers longer than the current 10 seconds. Of course that is no good if BFD just makes even more work for the already-busy routing engine. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Distributing OSPF load on MX80
Pavel Lunin plu...@senetsy.ru writes: AFAIK, at least as of 11.something, BFD was handled by RE on MX80, not the host-CPU like it is on the big MXes. Looks like it's because the host-CPU on MX80 is quite less quick (marketing way of reading this is it's more power and heat efficient thus more suitable for mobile applications, which is what MX80 was first primary designed for :). Fair enough, it seems that moving to BFD would not help. Unless BFD is significantly cheaper for the CPU than full-blown OSPF hellos, of course. The issue has been discussed here about a year ago: https://puck.nether.net/pipermail/juniper-nsp/2011-March/019245.html I think it's worth to check if any hellows are dropped by the control plane protection policers on the way to the RE. Thank you, I will check that. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Detecting OSPF packet drops
When I do a commit on an somewhat buxy MX80, I see Nov 27 21:14:10.443024 OSPF dropped 172 received packets due to flow blockage as long as I have set ospf traceoptions flag error. Without traceoptions, the error is not logged. Now, JTAC is telling me that I cannot run with any traceoptions on that box in production. That leaves me completely in the dark when it comes to dropped OSPF packets, and I will have no way of knowing if the packet drops hit a level where I risk losing neighbors. Is there anything I can do to monitor those drops, without using traceoptions? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Andrew Yager and...@rwts.com.au writes: By default the SRX closes the flow after 30 minutes (1800 seconds) as there is no activity on the wire during this time. I have no SRX firewalls, so I cannot help you with your actual problem, but I can provide an ugly workaround... If you play with tcp_keepalives_count tcp_keepalives_idle tcp_keepalives_interval in postgresql.conf, you can get Postgres to send TCP keepalive every so often. That should keep the session open. 30 minutes is IMHO a very low timeout for TCP sessions. Personally I set session timeout to 86400 for TCP on the firewalls that I control. If the number of sessions is becoming too large, a session timeout of 30 minutes is unlikely to help anyway, and TCP sessions tend to close properly with a FIN instead of by timer. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Julien Goodwin jgood...@studio442.com.au writes: Sadly SRX doesn't (or at least a few years ago didn't) consider TCP keepalives sufficient to keep the session open. Thank you for that heads-up, that is certainly something to keep in mind. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Tim Eberhard xmi...@gmail.com writes: While I haven't read this entire thread, it's worth mentioning that this is a correct statement. TCP connections (by default) must be initiated by a standard 3-way handshake. You can disabled this by turning off tcp-syn-checking under security - flow. I wouldn't recommend it however, as enforcing proper TCP state is always a good security practice. Enforcing proper TCP state is certainly good security practice. Dropping a TCP session with active TCP keepalives is simply buggy and wrong. That does not have anything to do with the 3-way handshake or tcp-syn-checking which should be on. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Tim Eberhard xmi...@gmail.com writes: The SRX's behavior is if any packet passes over that session to reset the timeout on that session, keep alive, data packet, whatever. As long as it matches that session it will reset the timeout to the default value and start decrementing again. So I'm not sure what you mean when it says dropping tcp sessions with active TCP keepalives. I proposed using TCP keepalives to keep sessions alive. Julien Goodwin informed me that this did not work on the SRX, as of a few years ago. If that is fixed, all is well. None of which has anything to do with tcp-syn-checking. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
Tim Eberhard xmi...@gmail.com writes: Benny, I've been working with the SRX since before it was in beta loading it up on a SSG550-M and netscreen previous to that. TCP keep alives, or any tcp packet that transverses that session has ALWAYS reset the timeout. The only time where you would see this not working is if you had a situation of asymmetric routing or some time of crazy load balancing through firewalls. You are discussing this with the entirely wrong person. I do not have any SRX's running flow mode at all. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Layer 2 circuit - Traffic not flowing between Cisco and Juniper with mismatched VLAN ID
Arun Kumar narain.a...@gmail.com writes:
Any option or workaround for this.
Have you tried just popping the VLAN completely and on the Cisco-side
simply doing:
xconnect 192.0.2.2 1234567 encapsulation mpls
On the MX80:
unit 1108 {
encapsulation vlan-ccc;
vlan-id 1108;
input-vlan-map pop;
output-vlan-map push;
}
neighbor 192.0.2.1 {
interface ge-1/0/7.1108 {
virtual-circuit-id 1234567
control-word
mtu 1500
encapsulation-type ethernet
}
}
It works for me between a 7600 and an MX80...
/Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J6350 Router recommended version
Rachid DHOU rachid.d...@gmail.com writes: Does someone use J6350 Router ? Yes :) Is this router can support JUNOS 11 or 12 ? Yes, up to 12.1, not yet 12.2. What is the recommended version ? http://kb.juniper.net/InfoCenter/index?page=contentid=KB21476 What is the requirement on DRAM and compact flash, if we go to 12 ? http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/release-notes/12.1/index.html?topic-64983.html#jd0e8639 1GB RAM, 1GB flash /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Chris Kawchuk juniperd...@gmail.com writes: BTW, I also saw in the 12.2 Release Notes that LDP-based L2CKTs are now supported on the EX4500/4550. You can maybe use an l2circut/L2CKT instead of a CCC; using martini style status-tlvs to signal end-to-end availability. ...Haven't tried this in the Lab yet. Might be worth a shot to drop the interface ccc-style. Maybe I am reading the release notes wrong, but to me it looks like that only applies to EX4500, not to EX4550. Are you referring to this bit: EX4500 standalone switches and EX4500 Virtual Chassis now support all MPLS features that are supported on EX8200 switches with the following exceptions? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Tim Jackson jackson@gmail.com writes: gigether-options asynchronous-notification is the command for MX Thank you! My Google-fu completely failed when I tried to find the command. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Ben Dale bd...@comlinx.com.au writes: I don't think the EX has this exact capability, but depending on your edge devices, you'd be better off running OAM (both CFM and LFM) which the EXs do support (though sadly not the EX4500/4550): That is an excellent suggestion. Thank you. Some of the links will be carrying BGP/LDP-signalled MPLS traffic, so BFD should save the day for those. Some of the switches which are to be connected through this setup are themselves EX4550's, using LACP. It seems the only failure detection will be LACP itself, which means several seconds of packet loss if a link fails. http://www.juniper.net/techpubs/en_US/junos11.2/topics/concept/cfm-ethernet-oam-ex-series.html http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#network-manage-monitor-features-by-platform-table Thank you very much for the links. I haven't tried, but maybe you could tunnel OAM PDUs through your CCC so that your edge devices have direct adjacency? Alternatively, you could write an event script : ( I could :) It is a bit tricky I think. If I use the event script to disable the interface when CCC fails, then the CCC will not ever come up again -- the CCC itself will get disabled along with the interface. Then I need to periodically enable the interface, just to see if CCC comes up. Not nice. More ideas welcome! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
Benny Amorsen benny+use...@amorsen.dk writes: Can the EX series do that? I'm thinking of the EX4550 in particular, but information about other EX-switches is welcome as well. I hate to reply to myself, but according to http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#mpls-features-by-platform-table the EX4550 cannot do CCC at all. That makes it all rather moot :) The EX4500 can, in 12.2. It looks like I will be doing q-in-q-tunnelling instead of CCC. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] CCC on EX, link state propagation
I am considering building a very simple setup with a number of ethernet interfaces on one switch each CCC-tunnelled through a common fiber to another switch. I.e. simply emulating a typical ethernet CWDM using EoMPLS. One feature which would be very handy is link state propagation across those EOMPLS links. Ideally, if the fiber breaks, the ports at each end go down so the equipment at each end quickly become aware of the break. Even better if loss of link on a port at one end also shuts down the link at the other end. Can the EX series do that? I'm thinking of the EX4550 in particular, but information about other EX-switches is welcome as well. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Krt queue issues
Jared Mauch ja...@puck.nether.net writes: As far as the fallback 'default' route, if you are purchasing transit from someone, you could consider a last-resort default pointed at them. You can exclude routes like 10/8 etc by routing these to discard + install on your devices. That only helps if the default gets installed first, though. If the default has to wait at boot in the krt-queue behind the 300k+ Internet-routes, I have not really gained anything... I suppose it is likely that a static default would be installed before the BGP sessions even come up. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Krt queue issues
Darren O'Connor darre...@outlook.com writes: Indeed, this is the worst thing this router can do. I have redundant routers sitting there doing absolutely nothing as this router's control-plane says everything is fine. I'm looking at using MX80 as an Internet transit router too... Do you know if it is possible to prioritize which routes get installed first into the FIB? In that case, a default route could be used to catch the wrongly-blackholed traffic. It is not particularly elegant or in keeping with being otherwise default-free, of course. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Commit status in SNMP
Tom Storey t...@snnap.net writes: What about forcing the use of configure exclusive and configure private as opposed to plain configure? This way you're either locking configuration of the box to yourself for a good reason, or multiple people/systems can work on configuration simultaneously? Its a tiny pain to get used to in the beginning, but not so bad. That is an excellent point. I will switch to using configure private when I am doing things by hand and let the provisioning system stick with configure exclusive. That should solve my problems. Thank you! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Commit status in SNMP
Is it possible via SNMP to see if the configuration is locked or whether there are uncommitted changes? If I forget to commit my changes, our automated configuration systems cannot do their job. I'm wondering if I could make OpenNMS poke me when that happens -- before the automated scripts start failing. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] OSPF Forwarding Address
I have a weird problem where I can get IOS to set the Forwarding Address for an external type 2 route (LSA type 5) in OSPF, but I cannot get Junos to do the same. The test network has 3 devices. Two of them are VRF's in an MX80 (router1 10.10.200.10 and router2 10.10.200.11), the last one is a firewall (fw 10.10.200.1). All connected to the same switch, and the network is a /27. The MX80-VRF's are talking OSPF, again completely plainly configured simply by putting the interface in area 0.0.0.0. router1 has a static route to 192.168.200.0/24 via fw 10.10.200.1. It redistributes this route into OSPF, again a completely plain policy just saying from static then accept. router2 receives the route through OSPF but Forwarding Address is not set. Therefore it sends traffic destined for 192.168.200.0/24 to router1 -- which is sort-of correct, but it would be much better if the traffic was passed directly to the firewall. If I replace router1 with a VRF on a Cisco 7600, Forwarding Address is set to 10.10.200.1 and everything works as I expected. This is obviously not my preferred solution :) /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Forwarding Address
Stefan Fouant sfou...@shortestpathfirst.net writes: In this case, router 1 is originating external the LSA through redistribution of the static, hence the other routers will see R1 as the next hop. I take it that this is expected behaviour in Junos? Although i have never done this myself, I think you should be able to manipulate your OSPF export policy to include a 'then next-hop 10.10.200.1' to manipulate the forwarding-address. I will have to try that. I already tried then next-hop peer-address which did not change anything (not even for the same scenario redistributed from BGP instead of static). Thank you for the suggestion! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Forwarding Address
Jeff Wheeler j...@inconcepts.biz writes: Do router2 and router1 have an OSPF adjacency on the /27? This is required for forwarding-address to be set. Yes, right now that is their only OSPF adjacency. Right now the VRF's only have that single interface. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Forwarding Address
Stefan Fouant sfou...@shortestpathfirst.net writes: Although i have never done this myself, I think you should be able to manipulate your OSPF export policy to include a 'then next-hop 10.10.200.1' to manipulate the forwarding-address. Alas, no luck with 'then next-hop 10.10.200.1'. It seems to only work for BGP. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Pavel Lunin plu...@senetsy.ru writes: Even 'independent tests' from Cisco's friends do not argue that SRX3k can do 20G+. http://www.cisco.com/en/US/prod/collateral/vpndevc/miercom_vs_juniper.pdf I am sorry for that sort of a link in such a respectful place :) I am sure the SRX3600 can do 22Gbps+. The question is not whether you can do 22Gbps+ using an SRX3k at all, instead the question is whether there exists a well-behaved unicast traffic profile which can force an SRX3600 which otherwise handles 20Gbps to only handle less than 10Gbps. I am asking this because a competing box I have experience with happens to have such limitations: IPv6 traffic and IPSEC passthrough do not get hardware offloaded, and CPU forwarding limits throughput to much less than we were hoping for from the specifications. So, can the the SRX3k handle 10Gbps+ IPv6? 10Gbps+ IPSEC passthrough? 10Gbps+ SCTP? (ok 10Gbps+ SCTP is unlikely to happen in practice...) /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Phil Mayers p.may...@imperial.ac.uk writes: It's only a factor of two up, and they've had 6/7 years to get there. I'm assuming the 5600/5800 can do 10Gbit/sec (of basic firewalling - no deep inspection etc.) unless anyone has compelling evidence otherwise. Yes, I am assuming that too. But does it do 10Gbps firewalling for IPv6? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Per Granath per.gran...@gcc.com.cy writes: For the record, the Miercom report is from tests without services offload - so that's without 'hardware offload'. It is great to hear that. In general, with that 22Gbps on the SPC processing, the processing power could also be eaten up by IPSec termination and 'new connections per second' processing, or IPS, which would lower amount of processing left to 'firewall' traffic. Sure, but on the other hand some traffic will be subject to services offload, even if IPv6 takes off. At least for the foreseeable future IPv4 will still represent a good chunk of traffic, which should free up some SPC power. It seems that the Juniper specifications provide conservative performance numbers which do not include the benefits of services offload. That is quite generous. Thanks to you and everyone who contributed to this thread. I am much better informed now. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Pavel Lunin plu...@senetsy.ru writes: To be honest, by now it looks like a feature for a particular customer. To me it seems like a feature for every customer... Without offloading, how would you do stateful firewalling at 10Gbps+? To put it another way, is there a hardware/software configuration for an SRX3400 which will do 20Gbps of IPv6 firewalling? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Pavel Lunin plu...@senetsy.ru writes: Em… isn't 10G+ possible on SRX HE without offloading? I don't know, that is part of what I am trying to find out :) /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Saku Ytti s...@ytti.fi writes: EZchip is very much not software, ES+ linecards and ASR9k routers use EZchip (albeit faster versions 3 and 4, SRX uses 2) for lookups also. This 'service-offload' does what box should have been doing all along, punt only first packet to RMI/Netlogic and use EZChip for subsequent packets. Thank you very much for your information, it make it a bit clearer how services offload actually works. However, I am still wondering if all traffic is eligible for services offload. Multicast traffic with fan-out 1 is not, but that is not a large concern for me. Is there any other traffic which cannot be offloaded? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Thank you very much again. No fragmentation is a potential DoS vector but probably ok. The other limitations are similar to other vendors. However, No IPv6 is really unfortunate. With Google, Youtube and Facebook on IPv6 already, that could be a serious limitation. It is pretty sad that when it comes to 1Gbps firewalling, CNG is cheaper and easier to buy than native IPv6... /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX hardware acceleration caveats
Benny Amorsen benny+use...@amorsen.dk writes: It is pretty sad that when it comes to 1Gbps firewalling, CNG is cheaper and easier to buy than native IPv6... Carrier Grade NAT, not CNG. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX hardware acceleration caveats
After having a few surprises from non-Juniper firewall equipment, I just thought I would ask here... Are there any surprises waiting when it comes to SRX enterprise firewalls and hardware acceleration? Is hardware acceleration limited to UDP and TCP, or does it work with e.g. ESP or SCTP? What about IPv6, does that get accelerated just like IPv4? /Benny (No the vendor with the surprises wasn't Cisco) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to query the results tree from a commit script?
Curtis Call cc...@juniper.net writes: In SLAX 1.1 you'd be able to use mvars, but that isn't released in Junos yet, so you'll need to use some sort of out-of-script storage such as the Utility MIB or a disk file. BTW, this could cause your unit numbers to jump around between commits. (If you remove one VPN then every following VPN will suddenly have a lower unit number). Yes, I discovered that one the hard way. Is that going to be a problem for you? Not for me personally, but apparently an MX does not like a thousand subinterfaces switching ID's... Not so surprisingly perhaps, but it took a few minutes before everything was back to normal. It might be preferable to store the assigned unit number for each VPN within the configuration, perhaps within an apply-macro, so that you can ensure that a particular VPN doesn't change. That would allow you to assign the numbers randomly as well, which would be more efficient. (i.e. when the script makes the transient change it also makes a permanent apply-macro change, recording the assigned unit [if it is a previously unconfigured VPN]) Yes, I ended up going that route, apart from not choosing randomly. You are right, random will be more efficient eventually, when a sufficient number of lines have been added and removed. My solution right now is O(n). /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to query the results tree from a commit script?
Tore Anderson tore.ander...@redpill-linpro.com writes: Hi, I'm trying to write a template for a commit script that, when called, will find the first unused unit on an interface and add some transient config to it. Unused means that that the unit isn't defined in the main configuration file and that an earlier call to the template hasn't written transient config to it yet. I had almost exactly the same problem when trying to pick unit numbers for q-in-q interfaces. I gave up on doing it transiently and now I simply save the unit numbers in apply-macros as permanent changes. If you don't care what the unit numbers are and you are parsing objects from somewhere else to generate them, you can just do position() + 5000 like I did originally. This does not work if you might reach the maximum ID or if you are parsing objects from multiple places (so position() could repeat). Curtis Call already pointed out the problem of ID's changing. I would recommend testing it, as at least when it comes to l2circuits, the router effectively tears down all the old units and builds the new ones if the ID's change -- even if everything ends up exactly the same apart from the unit ID's. That is service-impacting. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Unit-ID's revisited / accessing committed configuration
Is it possible to somehow get the committed configuration as it looked
after commit-scripts were applied? I do not want the commit-scripts
re-run, I simply want to fetch the configuration as it was after all
scripts were run and the commit succeeded.
To explain why I need to do this, it is necessary to go back to the unit
ID problem I posted about earlier.
To reiterate, the challenge is to generate unit ID's for a bunch of
q-in-q interfaces like this:
unit 5239 {
encapsulation vlan-ccc;
vlan-tags outer 1559 inner 3;
input-vlan-map pop-pop;
output-vlan-map push-push;
}
I solved it, or so I thought, by keeping all configuration in
apply-macros, like this:
apply-macro eompls-1001089 {
inner 3;
interface ge-1/0/4;
outer 1559;
}
which then generates the above q-in-q interface as a transient-change.
The unit ID is simply the position of the apply-macro in the
configuration file + 5000, so this particular apply-macro happens to be
the 239th apply-macro.
It all works really well, in general. Except I had not considered what
happens if you remove an apply-macro. All is well if you remove the last
apply-macro, but if you happen to remove one of the first ones, every
interface below changes unit ID. The MX80 was less than happy about
hundreds of interfaces being torn down and rebuilt...
At this point it is tempting to give up on that design and simply add a
unit ID to the provisioning database and to the apply-macro. Keeping
them consistent is no fun at all.
However, I would like to give the dynamic ID's one more chance. If it is
possible to find out which unit ID the previous commit used for a
particular apply-macro, I can then reuse that unit ID. Since all the
changes my commit script does are transient, this seems to be a
challenging task.
Any help is really appreciated!
/Benny
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit-ID's revisited / accessing committed configuration
Tim Jackson jackson@gmail.com writes: show configuration | display commit-scripts Sorry, I forgot to mention the crucial detail: It has to be available to a script. Unfortunately that command does not seem to have a junoscript equivalent; display commit-scripts view does have a junoscript equivalent but does not do what I need. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit-ID's revisited / accessing committed configuration
Curtis Call cc...@juniper.net writes: Junos 12.1 added new options for the get-configuration commit-scripts attribute, apply and apply-no-transients, that allow you to retrieve the post-commit-script configuration, and prior to Junos 12.1 you could always do something like command show configuration | display xml | display commit-scripts (be aware that the returned XML structure will be different than get-configuration), however, these work by running the configuration through the commit scripts again, so if you try to call them from a commit script you're liable to get a loop. Ah clever idea, but you are right, it would loop. It could only work if there was a way to get the actual configuration as it was applied after the commit scripts of the last commit, without having to actually rerun the commit script. Why not just have your commit script automatically add the unit number to the apply-macros. i.e. if the unit number is already present in the macro then use it for the logical interface, but if it is missing then figure out the first unused number, use it for the interface, and record it in the macro. Yes that sounds like a workable solution. Thank you! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Retrieving specific ID's from junoscript
Phil Shafer p...@juniper.net writes: get-configuration configuration interfaces interface namege-1/0/1/name !-- identify the interface -- unit name1017/name!-- identify the unit -- /unit /interface /interfaces /configuration /get-configuration That works perfectly, thank you! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Retrieving specific ID's from junoscript
In the continuing saga of automatic provisioning of a PE router, I am still at the stage where I am trying to retrieve information... More specifically, I would like to retrieve a specific a sub-interface. For finding a specific interface, this works fine: get-configuration changed=changedconfigurationinterfacesinterfacenamege-1/0/1/name/interface/interfaces/configuration/get-configuration interfaces interface name junos:key='key'ge-1/0/1/name flexible-vlan-tagging/ mtu9192/mtu encapsulationflexible-ethernet-services/encapsulation unit name junos:key='key'1017/name encapsulationvlan-ccc/encapsulation vlan-id1017/vlan-id /unit unit name junos:key='key'1018/name encapsulationvlan-ccc/encapsulation vlan-id1018/vlan-id /unit /interface /interfaces However, I can't figure out how to retrieve a specific subinterface, like the unit 1017 above. It is obviously possible to just fetch them all and search by hand, but there will eventually be hundreds of subinterfaces and it seems inefficient. The obvious solution of replacing ge-1/0/1 with ge-1/0/1.1017 in the request does not work. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Derick Winkworth dwinkwo...@att.net writes: Just do it sequentially and then write an op script that takes the vlan(s) as an argument to show you the interface info you are looking for... I am looking at this option, but it seems that there is no Junoscript command to get all objects with elements matching a specific pattern. More specifically, I can't even ask for all interfaces which have vlan-id=1010. Can this really be true? Obviously I can just ask for all interfaces and loop. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Derick Winkworth dwinkwo...@att.net writes: Just do it sequentially and then write an op script that takes the vlan(s) as an argument to show you the interface info you are looking for... Thank you all for your suggestions! I will try to see if a bit of scripting can save some work for me. I might still be able to get away with not storing the unit ID in the provisioning database. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Saku Ytti s...@ytti.fi writes: What ever you do, also open enhancement request. This is extremely annoying and trivial to fix. (While at it JNPR, give us tags/colours to direct routes, kthx). Certainly. What would be your preferred enhancement, just larger unit numbers or the ability to have unit ID's with dots in? If the commit check error message is to be believed, larger unit ID's are already available for certain interface types (demux0 and pp0). /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Unit ID's and q-in-q
I am wondering if any of you have suggestions for allocating unit numbers for q-in-q interfaces on the MX platform. For plain VLAN's it is quite easy; just use the VLAN as the unit ID. That does not work for q-in-q because unit numbers are integers. The obvious solution 1017 for outer 1010 inner 7 does not work either, as the unit ID seems to be limited to be at most 16384. Just adding them sequentially is a possibility, but with several hundred subinterfaces per physical interface it becomes challenging for operators to find the correct unit ID for a particular VLAN. Perhaps I will have to add a per-interface unit ID database to our provisioning system. Ideas are welcome! /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IPSEC into VRF
Which Juniper routers can terminate an IPSEC tunnel in a virtual router? M-series and T-series routers with the ES PIC can do it according to this: http://www.juniper.net/products/modules/100089.pdf What about the J-series and the MX-series? /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Which Router
Peter E. Fry [EMAIL PROTECTED] writes: I don't know if this matters to anyone, but most of the J series can be redeployed as firewalls, too, with a bit of license work (money, time, and a bit of divine intervention). How good are they in that capacity? We're considering exactly that, for hundreds of virtual systems with a low aggregate bandwidth. Netscreen doesn't let you have all that many virtual systems per box, and the price is actually higher per virtual system than simply giving each customer an SSG-5. Of course a rack full of SSG-5's would look a bit silly, and the cabling wouldn't be much fun... /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
