Re: [j-nsp] MX960 PEMs and 3 phase power
On 23/3/23 2:27 am, Tom Storey via juniper-nsp wrote: My thought is one PEM on one phase, such that if that phase drops, you drop that PEM entirely. Or is it worthwhile spreading across phases to keep even half of a PEM alive and supplying the chassis? Start by going back to "if that phase drops", depending on where you are and how much load you present using any non-trivial amount of power may not be acceptable. Then even consider if loss of a single phase is even a plausible outage that isn't going to mean a full loss right afterwards. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Kernel errors on EX2200-C
My home EX2200-C has started logging a few kernel errors per hour, persisting after a reboot, and an upgrade to the latest 14.1 release (I'd have tried a downgrade to the latest 12.3 release suggested, except that release isn't available to me on the download site for some reason) /kernel: kuackmem_ackentry_free: Invalid input ackptr 0xd121bff8, state 0 /kernel: filt_ackevent: kn 0xc3d7e7e0 kn_data 0x-1 num_entries -1 /kernel: kuackmem_ackentry_free: Invalid input ackptr 0xd121bff8, state 0 /kernel: filt_ackevent: kn 0xc3d7e7e0 kn_data 0x-1 num_entries -1 (The exact address changes each boot, but otherwise the same) I'm guessing that this is likely a sign of imminent hardware failure and I should try and rustle up either another 2200-C or better upgrade to a 2300-C. If there's a new version coming with 2.5g & PoE I'd love to test it ;-P ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Use cases for IntServ in MPLS backbones
On 02/10/18 20:26, Saku Ytti wrote: > On Tue, 2 Oct 2018 at 13:21, Julien Goodwin wrote: > >> The trouble is, some providers might use a bit to mean something like >> "prefer cheap EU paths" for Asia->AU traffic, leaving it set then causes >> hundreds of milliseconds of latency. Some might even implement VPNs that >> way causing blackholing. > > I don't think so, If they use DSCP values as-is, then they MUST > nullify them. Full and short pipe assume you use MPLS TC for internal > decision, at which point you don't need to care or trust DSCP. If you > use DSCP internally _AND_ trust Internet DSCP, it's broken > configuration. ... and since when would *any* network ever have a subtly broken config? Except for, you know, pretty much every network in practice. >> We had a few cases where failing to set DSCP to zero at our edge (in >> either direction) caused various issues, those also took weeks to >> troubleshoot. > > It is indeed possible to misconfig things. But it's not the problem of > instance sending DSCP, it's problem of the instance having broken > config based on DSCP. > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Use cases for IntServ in MPLS backbones
On 02/10/18 20:10, Saku Ytti wrote: > Hey Mark, > >> We remark all incoming Internet traffic DSCP values to 0. >> >> A few years ago, not doing this led to issues where customers were handling >> the DSCP values in such a way that any traffic marked as such was being >> dropped. Took weeks to troubleshoot. > > Dropped by who? I as an Internet user would prefer my DSCP information > to traverse internet, I do not ask it to be honoured. The trouble is, some providers might use a bit to mean something like "prefer cheap EU paths" for Asia->AU traffic, leaving it set then causes hundreds of milliseconds of latency. Some might even implement VPNs that way causing blackholing. We had a few cases where failing to set DSCP to zero at our edge (in either direction) caused various issues, those also took weeks to troubleshoot. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Forced password resets?
On 19/04/18 19:14, Saku Ytti wrote: > Anyone up for some IETF fun? I think this PW problem can be mostly > solved by an standard API. I imagine that you have some credentials > wallet which supports the API, browser which supports the API and HTTP > server which supports the API. You have some way to locally lock down > and open the wallet, which is out-of-scope for the standard. > Now when you register to new site, your browser asks site about > authentication policy (what information is needed, what that > information can look like) it then asks wallet to provide such > information for set of hosts or URLs, and then browser offers this > information to the server. There's various proposals for that in web-land, some of which are sane-ish (the exact rant is off-topic enough I'll skip it), some of them also practical for non-interactive and non-web uses. What is on-topic is there are some folk looking at standardising TACACS as it's actually implemented, and then potentially an enhancement. I'd *REALLY* love if client key negotiation of some form was in the standard, so I could simply ssh to any router with key auth without needing to statically configure keys on each router. Draft: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-10 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 18/04/18 17:52, Gert Doering wrote: > Hi, > > On Wed, Apr 18, 2018 at 08:37:51AM +0100, adamv0...@netconsultings.com wrote: >> Ha, I really wish Juniper would look at what XR did on whole host of things >> :) > > Judging from the recent threads on JunOS upgrade pains, seems they did... > > "New feature: more annoying software upgrades than IOS XR!" Next version: Randomly disappearing config lines, hope you didn't need those BGP policies! (Also, fun bar topic, IOS XR or Ironware, which is more painful for OS upgrades?) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11/04/18 19:31, Saku Ytti wrote: > I suspect more correct reason is that they don't see sufficient market > potential in device like MX104. I think Cisco and Juniper are very > confused about market, they appear to think entire market consists > solely of large scale DC providers. That only addressable market is > market which wants extremely dense 100GE boxes. 1GE is dead, 10GE is > almost dead. Even in networks like that there's uses for 1g that won't go away (heck, some amazingly recent infrastructure kit is still 10m only). A box able to have a few 1g ports, even sacrificing some 10g ports is fine, but with a 100g uplink or two would be super handy. Not least of which, having somewhere to plug my laptop in if I need to visit a POP. The datasheet for the MX204[1] implies that all the ports can be switched to 1g mode, but I think only some can[2]. That's an improvement over when I first heard about the box (when the JNPR folk I was talking to didn't understand why I might want some 100g and 1g ports on the same box) which is great. 1: https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000597-en.pdf specifically the table on page 3. 2: https://www.juniper.net/documentation/en_US/junos/topics/concept/port-speed-capability-mx204router.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX204 and copper SFP?
On 05/04/18 05:09, Niall Donaghy wrote: > Even more sad to see that 1G ports retain their xe- naming rather than > changing to ge- as you would hope and expect. Isn't the first time that's happened, IIRC 10g PICs on T640s presented as ge-x/x/x. Newer kit seemed to be converging on et-x/x/x for any ethernet speed, but perhaps not given the 204 is a brand new model. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper UDP Amplification Attack - UDP port 111 ?
On 26/03/18 17:31, Chris Adams wrote: > Got an MX204 - all the things left running on the Wind River Linux VM > host are pretty embarrassing (even if there's no actual network access > and so not a security issue). I have no need on a router for RPC, BIND, > Gluster, NFS, Zeroconf, Postfix, or dnsmasq; I'm not sure about Open > vSwitch (haven't looked to see if JUNOS is using that or something). > > Some of it looks like libvirt was installed and left with defaults, like > autostarting a private network configured for NAT and dnsmasq. That > also probably pulled in NFS, Gluster, and Open vSwitch. That sounds a lot like the first releases of Cisco's IOS-XE VM (my memory says that it at least tried to start Samba, but I could be wrong). Which is a shame for a bunch of reasons, not least since that probably means it boots much slower than it should. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Turns out lldpd leaks after a few years
Somehow I've had stable power at home for almost 4 years ... and also forgotten to upgrade this thing. ... or fix the now very out of date interface descriptions. root@ex2200-c> show log messages | last Feb 25 22:21:58 ex2200-c newsyslog[49500]: logfile turned over due to -F request Feb 25 22:22:11 ex2200-c lldpd[1049]: TASK_OS_MEMHIGH: Using 50409 KB of memory, 100 percent of available Feb 25 22:23:11 ex2200-c lldpd[1049]: TASK_OS_MEMHIGH: Using 50409 KB of memory, 100 percent of available Feb 25 22:24:11 ex2200-c lldpd[1049]: TASK_OS_MEMHIGH: Using 50409 KB of memory, 100 percent of available root@ex2200-c> show system uptime Current time: 2017-02-25 22:29:39 EST System booted: 2013-03-09 16:47:26 EST (207w0d 05:42 ago) Protocols started: 2013-03-09 16:50:04 EST (207w0d 05:39 ago) Last configured: 2013-11-04 21:58:52 EST (172w5d 00:30 ago) by root 10:29PM up 1449 days, 5:42, 1 user, load averages: 0.59, 0.69, 0.34 And now to upgrade to 14.3 (yes eventually 15.1). signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DHCPv6 client on SRX210 - IPv6 forwarding breaks at lease expiration
On 02/08/15 02:28, Chris Woodfield wrote: TL;DR: IPv6 forwarding breaks when my DHCPv6 client lease expires, even though CLI output claims it’s been renewed. I have an SRX210 as my home gateway, running 12.1X46-D35.1. This is running dual stack to Comcast, receiving a /56 DHCPv6 delegation and RA’ing a /64 to my home LAN. I’ve noticed that after the 4-day lease time expires, I can no longer route IPv6; my outbound trace routes break at the device, like so: admin@CAW-SRX210-HOME traceroute 2a03:2880:2130:cf05:face:b00c::1 traceroute6 to 2a03:2880:2130:cf05:face:b00c::1 (2a03:2880:2130:cf05:face:b00c:0:1) from 2001:558:600a:5a:38f8:139:bba0:e7bb, 64 hops max, 12 byte packets traceroute: sendto: No route to host 1 traceroute6: wrote 2a03:2880:2130:cf05:face:b00c::1 12 chars, ret=-1 ^C This is true despite a default ::/0 route in table going to the right place (confirmed via show route table inet6 and “show ipv6 nd” to verify route-link address-MAC association. The fix is apparently to clear and renew the DHCPv6 client binding, via clear dhcpv6 client binding interface int” then request system dhcvp6 client renew interface int”. IPv6 packets immediately start flowing again :) I’ve confirmed (via show dhcpv6 client binding) bindings are identical before and after the clear/renew, as well as the next-hop for ::/0. This clearly seems buggy to me; has anyone else noticed this issue? Anyone know if this is a known issue (or even better, fixed in 12.1X47 or 12.3X48 releases)? Any additional diags I should run next Wednesday morning when this happens again? I have a related bug in 12.3X48-D10.3 that I kept meaning to post about. Every now and again (once every few weeks) the dhcpv6 client will simply expire and not attempt to renew, request ... renew ... works fine. No obvious log messages go with it, although I haven't enabled tracing. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SMB != Server Message Block
Because I know a bunch of juniper staff read this list. In the datasheet for both the QFX10k PTX1k is an error, I pointed it out back when the QFX10k launched, but it's not fixed and the PTX1k sheet has the same error. In both of them the Sub-Miniature B connectors used for timing have their names expanded as Server Message Block, which, while right for the network protocol is wrong in this case. Yay for overloaded names. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos BGP update generation inefficiency -cause for concern?
On 18/05/15 21:49, Saku Ytti wrote: The update-groups are created dynamically in JunOS as far as I know. That is if you have BGP group where neighbors have unique export policies, you will have multiple update-groups in configuration group. But I guess if you have two neighbors with same export policies in different configuration group, it likely won't share same update-group, haven't tested though. I believe the two groups same policies do get two update-groups. I'm not sure about neighbor with neighbor level policy the same as the group level case though. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX Upgrade / Configuration question
On 16/10/14 21:07, Saku Ytti wrote: On (2014-10-16 09:52 +0200), Sebastian Wiesinger wrote: Hi Sebastian, I was wondering if anyone knows where a MX router stores the boot configuration its going to use after you load a new version of code on the router. a software upgrade does not change the configuration. It will use /config/juniper.conf.gz as always. I never saw anything else during SW upgrades. If I understood Matt correctly his problem is, he has already done 'request system software add', which stores the config somewhere to be used after upgrade and further commits will not be included in that. He'd like to make changes to the configs before reloading the boxes and ensure the config changes are included. In this case you can simply follow the useful advice given by the command to cancel the scheduled upgrade and reapply it once the config changes have been made. I've been quite annoyed by this, since it means you have to be awake in maintenance window 30min-1h longer than you should, because you can't pre-load the new software then in maintenace window just boot. I'm obviously missing something here, request system software add takes less than five minutes on anything I've ever used (from SRX100 through the bigger T MX kit). Copying the image to the box may take more, but if that's true and you don't pre-stage images you deserve what comes to you. It's the reboot into the new image that's horribly slow. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Small P Router Recommendations
On 05/06/14 13:30, Ben Dale wrote: On 5 Jun 2014, at 12:00 pm, Geoff Crawford geoff.crawf...@cwct.ca wrote: Hi guys! I'm a Juniper fan too, but I'll take a non-Juniper answer today. Seems to be an MPLS heavily oriented list, so I figured you guys would know. I'm sure we'd all love an EX3200 take could run LDP, pack more than 1 label and do it over aggregated interfaces. Is anyone else making a box that can do that? If you're after a switch that'll do MPLS/L3VPN, check out the QFX5100. All 10/40G though which might not be what you're after. This. If you're after a (true) P router and can handle a BGP-free core the 5100 should be good enough for most networks not big enough to justify a PTX, at a fraction of the cost. Sure there's not the redundancy of a PTX, but given that you can buy a pair of 5100's at list and I'm fairly sure would still be cheaper than the PTX. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Small P Router Recommendations
On 05/06/14 22:22, Mark Tinka wrote: On Thursday, June 05, 2014 01:58:50 PM Julien Goodwin wrote: Sure there's not the redundancy of a PTX, but given that you can buy a pair of 5100's at list and I'm fairly sure would still be cheaper than the PTX. The issue I've always had with so-called MPLS-biased routers and line cards is that native IPv6 is not yet MPLS-enabled, today. So if your MPLS-biased line cards do not have enough FIB to support a growing IPv6 table, that's not good. And of course I doubt the 5100 has enough space for a full v6 table even today (and that's before ECMP). You're right, but things are finally improving here, and in theory this works today, depending on what vendor combination and bugs you've got. Although it'll be a while still before we can get a v6 native MPLS network with no v4 needed at all, even for loopbacks. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos: snapshot ?
On 04/03/14 20:39, R S wrote: A customer of mine runs MX960 (dual RE), SRX5800 and SRX3600 (cluster with dual RE), EX8200 (dual RE) and EX4200 (in VC), in the weekend will run a disaster recovery test powering off those devices. I’d like to avoid any problem with files corruptions, which is the safer command to use to save current file systems of those devices family ? request system snapshot enter Snapshots won't help this. Snapshots aid recovery, they don't prevent corruption. Can I ask to run this command in production time on all the mentioned devices ? Sure, on the EXen it can be a little slow, but should be 100% safe. Remember to run it on both RE's on dual-RE platforms. You may need slice alternate on the end of the command for the EXen, and the exact command depends on JunOS release. Any additional suggestion ? Make sure you actually have matching JunOS on all RE's in a chassis/cluster/VC. Ditto any scripts commit, event, etc. If you're using fxp0 ensure both RE's have it patched. Ensure system commit synchronise is set on all dual-re platforms. Make sure rancid (or your equivalent) is actually working and has current configs for all devices, sadly there's still a good chance of corruption needing a rebuild on EX[34]200 after power loss. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] proposed changes to clear bgp neighbor
On 28/02/14 00:48, Phil Shafer wrote: Sorry if I'm venturing toward shameless self promotion here, but this really is an area we try to work at. That's part of the movation for asking if this one specific case is sufficiently irritating to break our own rules. But it's not one specific case clear foo thing Is a horrible outage-causing command for a bunch of things. Unless it's been similarly fixed clear rsvp session is a great way to cause an outage[1] on many carrier networks. What about clear isis adjacency? I'd say review the lot of clear foo and fix them all. It's *extremely* rare to actually want to reset all sessions on a real production router passing traffic in my experience, in all my time I can only think of one case where we deliberately used it. Any automation relying on this I suspect has far worse problems. 1: OK, *I'd* call this an outage, but short term packet loss event for those with lower standards. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper finally launches a route reflector platform
And in a sensible form factor too. http://www.juniper.net/us/en/products-services/routing/cse2000/ Can think of plenty of other use cases for the box as well. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Power issues on 10Gig link
On 24/01/14 00:14, Ali Sumsam wrote: Hi All, I am using a SFP-10GBase-ER for my Cisco3750X for a 10gig link going to a Juniper MX5-T router (10GE XFP) I am receiving following logs on my Cisco3750X. %SFF8472-5-THRESHOLD_VIOLATION: Te1/1/2: Rx power low alarm; Operating value: -21.3 dBm, Threshold value: -20.0 dBm. No logs on Juniper. You can, and probably should, log this as you would traffic levels via SNMP, at least for longer haul optics. Does this mean I have to increase the power on the interface? Or is there anything else I need to look at? Following are the readings from my Juniper router. Those are the thresholds, not the actual power levels involved, what's the full output from show interfaces diagnostics optics Laser rx power high alarm threshold : 1.2589 mW / 1.00 dBm Laser rx power low alarm threshold: 0.0158 mW / -18.01 dBm Laser rx power high warning threshold : 1. mW / 0.00 dBm Laser rx power low warning threshold : 0.0199 mW / -17.01 dBm Regards, *Ali Sumsam - *eintellego Networks Pty Ltd Senior Network Engineer a...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)450 609 592 ; skype://sumsam.ali80 facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/alisumsam The Experts Who The Experts Call Juniper - Cisco - Cloud ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Power issues on 10Gig link
On 24/01/14 12:39, Skeeve Stevens wrote: Hmmm.. Is there actually a way on Juniper to adjust the output power though? I'm not aware of any MSA optics (SFP, XFP, GBIC, CFP, etc.) that have controllable power levels. Certainly if you're using a transmission system there's probably an adjustable attenuator involved, but not otherwise. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Heterogeneous LACP link
On 16/09/13 11:52, Laurent CARON wrote: Current setup: 2 VCs (one on each site) each composed of 2xEX4200-24T I have the possibility of having a redundant connection between 2 buildings distant of ~10/15 km. The main link is a pair of dark fibers on which I'll use 40 km XFP modules. The second link is a WDM transport on which I plan to use 2 short reach monomode SFP's (one on each side). 2 questions: - Is it wise to mix SFP and XFP on the same LACP aggregate ? - Is it wise to mix 2 different technologies on a LACP aggregate (shuoldn't matter much, but I'd prefer hearing experiences ;)) ? Others have answered well, but I think there's something missing. It's not applicable in this case, but one other major thing to care about on JNPR kit is that the ports share the same PFE type, for example on MX mixing between DPC MPC within a LAG is a bad idea, same for FPC3 vs FPC3-ES on T640/1600. They might *work*, but you're likely to eventually run in to some ugly edge-cases. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] LN2600: an 8SFP Branch SRX
Saw this come through on my RSS reader, it's worth a shout out as I'm sure more people than just me have been wanting a branch SRX with decent SFP density there's finally an option. http://www.juniper.net/us/en/products-services/routing/ln-series/ln2600/ I'm assuming it runs the same branch SRX image as the rest of the line as that's been true for the LN1000 and this looks like more of the same. It's 48v only which is a shame, and being a rugged device I'm sure it's reassuring expensive. Also hidden in the datasheet is a reference to an LN2800 which has not been announced, but is obviously a similar rugged 1ru box of some sort. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3200 Power supplies
On 26/07/13 01:52, Doug McIntyre wrote: On Thu, Jul 25, 2013 at 09:01:15AM -0400, Paulhamus, Jon wrote: Power Supply in EX3200 Switches The power supply in EX3200 switches is a hot-removable and hot-insertable field-replaceable unit (FRU) that you can install on the rear panel without powering off the switch or disrupting the switching function. The power supply in EX3200 switches is not redundant. Does that mean if I pull a power supply out, the switch stores enough power to stay running long enough to put the new one in and get powered up? What odd wording, since the EX3200 doesn't have two power supply slots. They probably took wording from the EX3300/EX4200 which do have two power supply slots, and which probably uses the same power supplies. The EX3200 does have an RPS power port, so most likely what they intend to mean are that with the optional RPS deployed, and your main supply fails, you can hot swap it at that point, while running on RPS power. And then deal with the oddities of running on RPS power. But no, it won't keep running if you pull the single power supply out. The EX[34]200's do seem to have a lot more reserves when you pull power than most kit. I actually wouldn't be surprised if you could manage to do this, although doing it without crashing the cpu or forwarding chips is a bit less likely. If course if you want to do this the power supply has already failed making this an academic concept only. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Advice on a 100Gbps+ environment
On 03/07/13 00:56, Darius Jahandarie wrote: On Tue, Jul 2, 2013 at 9:55 AM, Drew Weaver drew.wea...@thenap.com wrote: And what is wrong with the MX80 as a peering/transit router for up to 80Gbps of traffic? The lack of redundant REs + inability to have an external RE. Other than the amount of CPU capacity on the MX80 (which has been done to death here) do you really have RE's fail often enough to be a problem? Sure on the larger boxes they're cheap enough that if you're really loading the boxes you might as well have one, but if you add it up I doubt they save that much downtime. The most common failure I've seen on Juniper RE's (by far) is HDD failures, which is largely mitigated on current kit with SSD's. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3600 dropped packets - how to debug?
On 28/05/13 19:40, ashish verma wrote: That said, I can't believe the firewall was *actually* dropping 1500pps of DNS traffic; we'd have widespread problems reported, surely. So, it seems that maybe ALG-processed traffic is being counted under packets dropped for show security flow statistics? eDNS fallback perhaps? I never understood the use of DNS ALG's, unless it's to perform a NAT translation on addresses (which is a really bad idea) they just seem like a waste of valuable resources. Far better to ACL down so that DNS queries can only go to trusted DNS servers which can run something that doesn't break on a malformed query. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX - Changing MAC address on different unit of the same interface
On 06/04/13 03:59, sth...@nethelp.no wrote: No, this is not possible (and why would you need it?). If you think about this for a moment, it would require the ability to have 16k or so MAC addresses per physical interface. Highly unrealistic. I can think of one common case, many IX's and shared (colo usually) transit lans do static mac filters, and if you need to move the port being able to override the mac can get you back up far quicker then dealing with a support tech who may not understand the problem. If that's a low-speed circuit aggregating it can make sense which can easily lead to a request to do per-VLAN mac's. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX2200-C SNMP traps
I upgraded a new EX2200-c to 12.3 the other day (was shipped with a broken release of 11.4), and every hour I'm getting clearly BS traps: CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 0 @ 1/0/*, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 3, jnxContentsL2Index 1, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 0 @ 2/0/*, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, jnxContentsL1Index 4, jnxContentsL2Index 1, jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 0 @ 3/0/*, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 1, jnxContentsDescr FAN: Fan 1 @ 1/0/0, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 2, jnxContentsDescr FAN: Fan 2 @ 1/0/1, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxContentsL2Index 1, jnxContentsL3Index 3, jnxContentsDescr FAN: PSU Fan @ 1/0/2, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 3, jnxContentsL2Index 1, jnxContentsL3Index 1, jnxContentsDescr FAN: Fan 1 @ 2/0/0, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 3, jnxContentsL2Index 1, jnxContentsL3Index 2, jnxContentsDescr FAN: Fan 2 @ 2/0/1, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 3, jnxContentsL2Index 1, jnxContentsL3Index 3, jnxContentsDescr FAN: PSU Fan @ 2/0/2, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 4, jnxContentsL2Index 1, jnxContentsL3Index 1, jnxContentsDescr FAN: Fan 1 @ 3/0/0, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 4, jnxContentsL2Index 1, jnxContentsL3Index 2, jnxContentsDescr FAN: Fan 2 @ 3/0/1, jnxOperatingState/Temp 1) CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed (jnxContentsContainerIndex 4, jnxContentsL1Index 4, jnxContentsL2Index 1, jnxContentsL3Index 3, jnxContentsDescr FAN: PSU Fan @ 3/0/2, jnxOperatingState/Temp 1) Anyone know if these are a bad way of telling me something I should care about, or are they just BS? signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RAM Type for SRX240
No idea what the actual form factor is, as I never got around to opening the case of the one I had at $JOB[-1], but from the CPU's spec page: DDR2 up to 800 MHz 1x 72-bit wide On 25/03/13 13:33, Skeeve Stevens wrote: Hey all, I've heard quite a few people have self-upgraded their SRX240's from v1 to v2's simply by upgrading the RAM from 1Gb to 2Gb. Couple of questions. 1. Any one got a photo of the inside of the SRX240 (can't find any on Google) 2. What 'exact' kind of RAM is in the SRX240... slots, sizes, speed, ecc?, etc 3. Is there anything else that makes the B2/H2 from a hardware perspective other than the RAM? i.e. CPU, etc? Can anyone point to a link online where I can get some details of people selling the specific kind of RAM... be nice if it was in .au, but happy to search myself once I know what it is. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco - Cloud ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On 14/02/13 18:55, joel jaeggli wrote: When we're doing a maintence we generally let the router converge with our route-reflectors prior to bringing up the transit/peer neighbors. so that routes learned from the transits are replacing existing fib routes. that also has a salubrious interaction with our loose rpf check. spontaneous reboots aren't quite adjustable like that. This. Why Juniper don't implement (or scream from the rooftops if there is) an iBGP-settle ability I don't know. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L2ALM errors on SRX?
I've just started dumping syslog on my permanent lab devices at home, and the SRX210 is regularly throwing this: L2ALM: trying master connection, status 61, attempt 5000 The attempt increases, but the message is only logged very rarely (this is shortly after a reboot). I now see this on 11.4R2.14 11.4R6.5, but can't find any hits searching for it, other then one KB article which indicates it's perhaps VPLS related: http://kb.juniper.net/InfoCenter/index?page=contentid=KB22637 Has anyone seen this? signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX doing IPv6 on DSL
(Thunderbird crashed taking away my first response) Skeeve's post is spurred by a post of mine to Ausnog earlier today looking for a new reliable home ADSL CPE. In fact although I can now set family inet6 on a PPPoE interface, I can't do something similar to family inet negotiate-address which makes it useless for consumer circuits, even if I could avoid the need for DHCP-PD (previously my ISP required DHCP-PD before they'd route a static block, this may have changed). The fact that I can't even do SLAAC on an Ethernet port means it's also not usable if I was on FTTH. On 10/12/12 23:26, Skeeve Stevens wrote: Hey all, Does anyone know is the SRX110 is capable of doing DHCP-PD or 6RD yet? If not, does anyone know of a X release or when it may hit mainline? IPv6 is starting to get popular with engineers and at the moment all they seem to be able to use are Cisco 877/887 and ISR's with DSL WIC cards. Surely Juniper has some plans afoot? ...Skeeve * * *Skeeve Stevens, CEO - *eintellego Pty Ltd ske...@eintellego.net ; www.eintellego.net Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco – IBM - Brocade - Cloud - Check out our Juniper promotion website! eintellego.mx Free Apple products during this promotion!!! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Error while validating a JunOS
On 04/12/12 02:28, Phil Mayers wrote: On 03/12/12 14:45, Jason Fortier wrote: The export junos does not support SSH and HTTPS. Only the Domestic seems to. Correct. Interestingly, I recently seem to have lost access to download domestic JunOS for J-series, which I did previously have. I have retained domestic download access for SRX. It's probably the new download page, there's a dropdown for domestic vs worldwide that's a little non-obvious. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ 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
On 12/11/12 06:37, Benny Amorsen wrote: 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. Sadly SRX doesn't (or at least a few years ago didn't) consider TCP keepalives sufficient to keep the session open. I found any form of application keepalive sufficient. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ 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
On 12/11/12 16:03, Tim Eberhard wrote: 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. All I can say is that as of late 2009 on branch SRX (specifically SRX650, using then-current JunOS, probably 9.5) this was not the case with SSH traffic (which IIRC doesn't have an ALG). It wouldn't kill the session, just wouldn't extend it. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX - DWDM no link
On 07/11/12 21:30, Luca Salvatore wrote: The fibre run is about 40Km point to point. There are other people already using it on their own frequencies at 10Gb so I know it works. While i'll admit my knowledge about DWDM stuff is not great, I do have plenty of experience in the routing and switching space - just not much with the long haul fiber stuff. You'd also want to know the power loss (dB) to confirm loss rating. With high power optics you also have the possibility of permanent damage if you loop them back at short range, if you tried this earlier you may already have destroyed them. I presume this is all going into a passive mux or transponder-less ROADM? If its going into a transponder you usually use SX or multimode optics. I'm also pretty sure that tunables only work on MIC ports on MX80 and derivatives, not the fixed ports, here's one ref confirming: http://labs.spritelink.net/juniper-mx-and-tunable-xfps But this is apparently fixed in a JunOS new enough for the real MX10's. ... mx10-1 show interfaces diagnostics optics xe-1/2/0 Physical interface: xe-1/2/0 Laser bias current: 20.861 mA Laser output power: 1.4120 mW / 1.50 dBm Module temperature: 32 degrees C / 89 degrees F Laser rx power: 0. mW / - Inf dBm That's snipped right? IIRC you should see the wavelength listed here, but I don't have a tunable to hand (yay! excuse to buy a lab toy, shame I have no money for such) -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Security bugs in documentation
On 30/10/12 20:21, Bjørn Mork wrote: Using an open source viewer, all I see in that document is a single page displaying For the best experience, open this PDF portfolio in Acrobat 9 or Adobe Reader 9, or later. and a link to Get Adobe Reader Now!. And sure enough, inspecting the pdf shows that it is a 5MB single page document: Evince (the Gnome PDF reader) recently got the ability to view these, it's somewhat non-obvious, but I figured it out when I downloaded $DWDMVENDOR's documentation which was all in this format (last time I encountered it was more then a year ago with $POWERSYSTEMSVENDOR when I had to figure out how to extract files with pdftk, much easier now) In the evince sidebar (Which normally shows Thumbnails or Index) select Attachments and you can then read the sub-PDFs. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 to MX80 virtual chassis feature
On 23/10/12 01:53, David Miller wrote: We were told 2+ years ago that Juniper would be releasing a module for the port in the back of the MX5 - MX80 that could be used to VC another MX -or- be used as high speed link to an EX (4200 / 8500). This has changed a few times in our discussions with Juniper over the subsequent years from coming soon to no idea what you are talking about to coming soon again. Latest responses from Juniper have been reasonably solid never going to happen. My guess (merely a guess) is that marketing/product positioning folks within Juniper decided that this functionality would compete against their more expensive products and killed the development/release. I had only ever heard that the rear MIC slot was for a future services MIC, given a full size services MPC has now been shown (it's in the photos in the MX2020 datasheet) if a MIC version is going to come it'll probably be then. As for high speed link to an EX something along those lines has now been announced as Node Unifier for FEX-like support. I'd be unsurprised if VC on MX80 turns out like LNS support, where it's coming becomes we'll never do it and then here's the OS image supporting it -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX960 AC power strip
I double checked the hardware guide to ensure, and they're not fixed cable: http://www.juniper.net/shared/img/products/mx-series/mx960/mx960-rear-high.jpg (If you're using the high-cap supplies there's a second input on the PSU's themselves) So just 8x C18-19 cables would be fine. On 23/08/12 23:59, JA wrote: Hi I need advice if someone is having an MX960 up on AC power. Usually high capacity (32A) power bars (PDU) come with C13 or C19 outlets while Juniper has no provision for such power cords. If European power cords are ordered with MX960, the CEE7/7 plug can be connected to Schuko outlets. But there is no Schuko PDU that supports more than 16A. One can easily exceed 16A if two power supplies are connected on same PDU. Can anyone recommend some alternative or if anyone faced similar situation? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] root-login via ssh and 11.x
On 26/06/12 22:09, Nick Kritsky wrote: FYI: It looks like in version 11 Juniper has changed default settings for system services ssh root-login. Now if you want to login as root via ssh, you have to explicitly allow it. in 10.X it was allowed by default. Tested on EX-4200, SRX-100. Funny thing is that documentation is still claiming that default setting is to allow: http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/configuration-statement/root-login-edit-system.html I don't have any device with 12.1 to test, but I suspect that the problem exists there as well. If anyone from J is reading - please update documentation or JunOS defaults. It would be nice to keep them in sync. And a warning in the upgrade notes, I'm sure there's at least one site that only uses root. (No, nobody I've every worked for has that, at least on Juniper kit) -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper Networks fail to protect Linx from outage
On 05/06/12 15:43, Brent Jones wrote: On Mon, Jun 4, 2012 at 10:10 PM, ramesh@wipro.com wrote: Wats the product? EX Series switches responsible and couldn't protect? They're MX960's (with a Trio loadout) See: http://www.nanog.org/meetings/nanog54/presentations/Wednesday/Cobb.pdf More likely that someone didn't filter advertisements or re-distribution correctly, rather than a software bug. Only more details will tell, TFA was pretty lame. Also a shame they already blame Juniper, when it sounds like they have barely begun diagnosing what truly happened, not very classy at all (especially if it turns out to be operator error). Except that Juniper pretty much built this (according to friends-of-friends), so it's either Juniper engineer error or JunOS bug. At the very least Juniper would be fully aware of the config. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
On 01/05/12 13:15, Naveen Nathan wrote: I'm attempting to retire a cisco 6509 setup, replacing it with an EX4200 virtual chassis configuration (8 linecards). I've run into a warning when committing the configuration: warning: Exceeded vmember threshold limit, it is recommended to have not more than 32752 vmembers Our current setup has 200 VLANs defined; and can grow anywhere upto 300 in the future. (I *knew* there was a post I'd meant to reply to a while back...) It's not clear from your post whether you know how VLAN's map to ports, and how static they are, but one option that makes managing it fairly sane is using apply groups. A simple (but not EX type) example is at: http://laptop006.livejournal.com/55440.html And a variant that's EX-specific made it into last year's tips book: http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/junos-tips-techniques/ signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Extremely high failure rate of SCB-E?
On 29/05/12 07:11, Dave Temkin wrote: Anyone here running SCB-E's in a significant production deployment and found that there's an extremely high hardware failure rate? I've no idea what the stats actually are, but this does make complete sense. The chips on them will be new and should be expected to have higher failure rates, at least until the first few production runs are sold through. As they don't have large SRAM/TCAM there shouldn't be the typical first run of a new RAM process issues. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10ge wan phy with stm-64
On 22/05/12 23:00, JA wrote: Hi Can anyone please confirm if below connectivity would work with 10ge wan phy router port at one side while other end router with stm-64 port? No this won't work. rtr[10ge.wan.phy] --- sdh[stm64] --- dwdm.ring --- sdh[stm64] --- rtr[stm64] WAN-PHY doesn't magically turn Ethernet into Sonet/SDH, it just changes the bit rate, and sets enough of the framing to get through most transport equipment. Both ends need to be the same, LAN PHY, WAN PHY, or actual SONET/SDH. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] what would you put in this PoP
On 23/05/12 08:32, MKS wrote: Hi Imagine a town of 15.000-20.000 people. What type of device/devices and size would you put into this town, given the following requirements Residential triple play (HSI, VoD, Multicast) 8 IP dslams (GigE) Vod servers (4 GigE pors) Business connections (L3VPN) 10 Business connections on GigE 30-40 Business connections 10-100 mb Consider terminating these subrate services on something like an EX to save wasting gig/10g ports. AToM ATMoMPLS port mode, 4 STM1 ports needed. Except for this an MX80 should work, and now there's the ATM MIC you have that option, although it would limit you to 20 ge ports. An alternative would be a larger MX with Trio cards. Uplinks on 10GbE in a ring based structure, current traffic levels 2-3 gigs total BNG termination (pppoe) is not a requirement Spare parts are located 4-5 hours away. 1) If you where given a clean slate, what would you put in? 2) What do you put normally, given your normal capex level. Regards MKS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTBF of M-serie nodes and PICs
On 14/05/12 02:00, Rachid DHOU wrote: Hi experts, Does anyone have the MTBF of M series routers and their PIC especially Ethernet PIC. Same question also for J-series. It really is better to think in terms of *what* fails (for the larger M and up). The most common will be: - Moving parts: fans, hard drives - Memory - Optical modules Once you get past that you're into rare territory. MTBF is a horrible measurement for network kit, you really only care if you need redundency and if so how much, and MTBF doesn't actually tell you very much of that. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Regular maintenance advice
On 04/04/12 00:28, Skeeve Stevens wrote: 1. Show log messages a. Look at last few days for anything suspicious i. Interfaces flapping show int | match flap is your friend. Also chassisd 2. Show interfaces terse a. Anything down that shouldn’t be? Also anything *up* that shouldn't be. If you can be strict about it you can say anything but up/up and down/down are problems. 3. Show chassis alarm a. Look for any alarm information If you have any EX (at least, can't remember for SRX/J, not for M/...) also add: show system alarms (It's sad how few people know about this) 4. Show system snapshot a. If older than 1 week then – ‘Request system snapshot’ er, why? Do a snapshot on OS upgrade, shouldn't be needed after that. Verifing commit sync is default is also good. 5. Show system uptime a. As expected? 6. Show system storage a. Confirm / (root) disk space is not getting full. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 12.1 and a bunch of new product details out
It's worth reading the 12.1 release notes if you run any M/MX/T as there's a bunch new and possibly useful, eg MPLS-TP, LLDP enhancements. EX4[25]00 also now have NSSU in virtual chassis. In other news there's a bunch of new inter MIC's: ATM - MIC-3D-8OC3-2OC12-ATM (12.1 release notes) 1xOC192 - MULTISERVICE INTERFACE MICS FOR MX SERIES 1x100Ge - 100g mic (both CFP and CXP) 2x40ge - 100g mic 10x10ge - 100g mic MPC's: MPC3 - 130g of bandwdith 100g MX - http://www.juniper.net/us/en/local/pdf/datasheets/1000353-en.pdf OC192 MX - http://www.juniper.net/us/en/local/pdf/datasheets/1000378-en.pdf 12.1 release notes - http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/release-notes/12.1/junos-release-notes-12.1.pdf SRX: SRX550 - (essentially) an SRX650 with two GPIM becoming two mini PIM, two more copper gig-e and four SFP gig-e datasheet - http://www.juniper.net/us/en/local/pdf/datasheets/1000281-en.pdf ACX series: Looks like new versions of BX series datasheet - http://www.juniper.net/us/en/local/pdf/datasheets/1000397-en.pdf PTX PTX5000 HW guide is out HW guide - http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/ptx-series//hwguide/ptx5000-hwguide.pdf PTX PIC guide - http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/ptx-series/pic/ptx-series-pic.pdf There's also a bunch of T4000 docs up now. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Only announce BGP learned networks
On 21/02/12 01:10, Jonas Björklund wrote:
policy-statement my-export-routes {
term t10 {
from {
protocol bgp;
route-filter 1.2.3.0/21 prefix-length-range /21-/24;
route-filter 4.5.6.0/20 prefix-length-range /20-/24;
}
then accept;
}
term t100 {
then reject;
}
}
Some of my network begin to be announced. But not all of them.
The one which was learned by OSPF *AND* BGP was not able to pass the
policy. Only those which was learned from BGP.
I want all networks learned from BGP (even those from OSPF) pass the
policy.
Then remove from protocol bgp. The router is doing exactly what you
asked, you're simply missing two things:
1. Only active routes are considered in filters (for values of only that
suffice for this)
2. IGP (OSPF, IS-IS) routes are preferred over BGP in JunOS, unlike IOS
The way I do self export is a little more complex, but prevents route spam:
1. For my large blocks (really anything in more then one OSPF area) I
configure an aggregate route covering them, for example:
set routing-options aggregate route 10.23.64.0/18
Unless you specifically add a policy these will never be advertised
outside the router.
2. For all blocks I'm advertising I create a prefix-list:
set policy-options prefix-list self 10.23.64.0/18
set policy-options prefix-list self 10.2.3.4/24
3. Inside my outbound chain I simply do:
set policy-options policy-statement self-out from prefix-list self
set policy-options policy-statement self-out then accept
Which means the prefixes I expect (and *only* those exact prefixes) get
advertised.
(This only makes sense in smaller networks with few edge BGP speakers,
larger networks should use their existing confederation / reflector
boundries as points to inject that regions self into BGP)
--
Julien Goodwin
Studio442
Blue Sky Solutioneering
signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hash algorithms for LAG
On 21/01/12 03:48, Pavel Lunin wrote: It depends on a platform. For M/MX/T the hashing algorithm is considered to be a kind of business secret (said to be patented, etc). For EX it's Just to make an important point, it's either a secret *or* it's patented, part of the point of a patent is that you publish your invention in a way that others can replicate once it expires (true that rarely happens these days) -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
On 07/01/12 15:50, Salman Zahid wrote: 2. In terms of 3rd party optics support , we are evaluating the support for 3rd party optics . Please continue to check the Juniper documentation and talk to your account team for roadmap information . My ire has cooled considerably since reading this statement yesterday, so here's an attempt at a sane response. Nobody is asking Juniper to *support* third party optics, they never have before. All we want is, that like all other Juniper products to date (that I'm aware of) that third party optics work, and have feature parity. If you're so worried about latency within a Qfabic making Juniper branded (because I'll bet they're not even a special run, let alone special model) optics required on the internal side of a fabric is annoying, but not all that objectionable. There's also nothing wrong with WONTFIXing latency tickets if the path is not 100% Juniper optics, much as other issues with third party optics are handled today. To lock third party optics out you had to *add* code to JunOS, remember that. Even ignoring common optic types (SR, LR, etc) there's still plenty of reasons to want third party optics, passive C/DWDM is just the start, RAD's [TE][13] SFP modules are another type that Juniper just don't offer. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
On 07/01/12 13:34, Chuck Anderson wrote: To clarify my original question, does anyone know of any such server/storage/NIC/HBA vendors out there that insist you use their DAC cables? I want to be sure not to buy those either, because last I checked, you can't put SFP+ DAC Vendor A on one end and SFP+ DAC Vendor B on the other end of the same DAC cable assembly. At the very least NetApp used to require use of their DAC cables, with an exception for (IIRC) Brocade cables going to a Brocade switch, I doubt they actually locked it out though. In the early days of UCS Cisco were weird (even for them) about this as well. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS 9.6R3.8 on MX
On 16/03/10 06:15, Richard A Steenbergen wrote: ... Mar 1 02:22:28.128 re1.router rpd[1281]: %DAEMON-4: bgp_pp_recv: peer x.x.x.x (Internal AS ) sent unexpected extra data, probably insane ... Saw this today, combined idea with a coworker was to open a JTAC case with the subject Insane in the Control Plane -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J-Series Router Options
On 07/11/11 06:18, R. Benjamin Kessler wrote: Hello All - We have a client with a lot of J-Series routers running 9.3 code or earlier. We really like the features and functionality of JUNOS as a router and are more than a little annoyed that Juniper seems to be forcing us to turn these routers into firewalls. What are others doing to deal with the flow issues associated with more recent versions of code? You can essentially disable the flow mode, it still sucks up RAM (if you're doing full BGP tables you need, at minimum 2GB, 3 or 4 is better) but it can still pretty much do the old throughput. Also, many of these routers have small CF cards (e.g. 256MB or 512MB) which will also cause issues with more modern versions of code. Yep, replace with = 1GB cards. But if you have to open them anyway for RAM doing both makes sense. Most likely you'd build the new image config in the lab and send out RAM+CF to be upgraded on site. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On 16/10/11 16:55, Mark Tinka wrote: and if all you need is 10g LAN-PHY the MX with the 16-port MIC does it nicely. There should be a newer version of this line card coming with WAN-PHY support. 10g WAN-PHY helps, but isn't actually enough. Some long-haul applications require actual Sonet (well, usually SDH). Fortunately those are few enough that a lack of density compared to 10g ethernet isn't a massive issue. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On 16/10/11 13:28, Richard A Steenbergen wrote: snip openflow rant Of course the traditional router vendors are also realizing that they won't be able to compete on price given the massive volumes that third party ASIC makers are doing, so they've already started building systems around those chips. The Cisco ASR is EZChip, the Juniper EX is Marvell, the Juniper QFX and a dozen other similar products are Broadcom, etc. But ultimately, it still comes down to software. The exact same Broadcom reference design box can be sold by Dell for $1k or by Force10 for $15k, and the difference is the software. :) Well, that's Dell and DellForce10 now... Arista is the one company that seems poised to actually take this on and keep coming out with good hardware, at a decent price, with a powerful, open control plane. Their kit isn't Openflow interoperable yet that I know of, but that should be doable. There are other potential solutions, for example: http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk17.swhyte_Opensource_LSR_Presentation.pdf Yup, this is an example of software using OpenFlow. So openflow... It's no secret that my corporate overlords are playing with openflow (that above presentation for example), but what everyone seems to be espousing is big, single controllers managing large distributed environments, something very much like Juniper's Qfabric, but that only seems interesting, for now, in large datacenter environments. The one above is using it simply as an abstraction layer for the hardware, not for distributed features which I think is more practical in the near term, at least outside of flat datacenter networks. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TCAM full on EX8200?
On 16/10/11 05:33, Richard A Steenbergen wrote: Hehe. Tag switching will make core routers really cheap, you'll have a few really big PE routers only. Wasn't that the line we were sold with TDP? And they totally could be too, if anyone bothered to actually make them. You don't even need to spin custom ASICs (one could argue that their might not be enough business to justify it anyways), label switching is so easy from a hardware perspective that it's not even funny. Everyone and their mother is busy churning out Broadcom Trident+ based 64x10G 1U boxes right now (see: Juniper QFX, etc), and at a price of a couple hundred bucks a 10G even on the high end. Why aren't these boxes making great LSRs? The chip with massive potential that's got me excited is the BCM56846, 64 10g or 16 40g (or a mix), essentially all on a single chip, no need for external PHY's. What's needed is for an OEM to build a generic router chassis that has separate control plane, power, and forwarding modules that can be swapped as needed. Potentially ATCA might be a good platform for this But without someone building the full protocol suite already this might be a hard business proposal. The problem is, the software side of MPLS (i.e. all of the associated protocols surrounding it) is so complicated, only Cisco and Juniper have figured out how to actually implement it correctly (and that is only because they wrote most of it :P). All the hardware in the world doesn't help you if you don't have the right software, and C/J shockingly don't want to make a $10k box that obsoletes the need for a $1mil T-series. This is why OpenFlow has them all running scared. :) There are other potential solutions, for example: http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk17.swhyte_Opensource_LSR_Presentation.pdf The PTX is the first thing to actually attempt to be a label switching router only, but even that one is a) still vaporware, and b) designed to be sold to only a handful of super large carriers, and still at fairly premium prices. All they're trying to do is keep the T-series business unit from losing money to the MX-series business unit (since the MX is just as capable of doing everything T does w/MPLS as a core router, but at 1/4 the price), they aren't ACTUALLY trying to make a cheaper LSR. :) I do object to the still vaporware, not due to ship until the end of the year is closer. The main threat to the T-series is that 10ge slowly removing the need for Sonet/SDH, and if all you need is 10g LAN-PHY the MX with the 16-port MIC does it nicely. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and 128.0.0.0 martian (JFYI)
On 10/10/11 23:39, Tima Maryin wrote: Hello! Recently RIPE NCC started to allocate addresses from 128/8 to end users, example: https://apps.db.ripe.net/whois/lookup/ripe/inetnum/128.0.0.0-128.0.7.255.html inet.0: 128.0.0.0/16 orlonger -- disallowed It's only the first /16, so not a huge problem, although I'm amazed that RIPE didn't do reachability testing (APNIC are almost certainly the best at this, see their reports for 1/8 for example). There's more then enough Juniper's out there to cause massive issues if they'd tested. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Questions
On 27/08/11 22:13, Saku Ytti wrote: Hardwarewise scaling is same as any MPC in larger MX, but control-plane is lot less beefy than big brothers. Not really sure why, it's not like intel CPU would be significant BOM addition to MX80 compared to freescale. tinfoilhatdownscaling trio would have been expensive, lot cheaper to reduce the scale of the box is to fit it with poorer RE with less memory/tinfoilhat OK that's not really fair. Even a trivial embedded Intel x86 (and most usably performing clones) are a *lot* more complex then PowerPC can be (which is still worse then the single-chip ARM systems now available). In dollar terms after everything's added in it should have worked though. I've yet to open up an MX80 (the one we had in the office was only around for two days before it got shipped off to one of our POP's for an experiment) to even see if there is space that could have hosted one. Hopefully an SMP JunOS for it will come out sometime soon to let the RE catch up with at least the slow Intel RE's. I am still aggro about the storage issue though (I suspect in a few years selling retrofit storage upgrades for a few hundred dollars could be a profitable side-business for someone). -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX SCBE-MX-R
On 08/11/11 19:00, Daniel Roesen wrote: On Wed, Aug 10, 2011 at 11:29:23PM -0400, Rakesh Shetty wrote: What I got from juniper is that the enhanced SCB will only be supported in 11.4 which is April 2012. We're hearing 11.4 is due end of 2011. At the rate Juniper is slipping these days... 11.2 finally came out last week, just over a month late. Juniper staff at various levels keep assuring me things are being put in place to improve this, yet the trend is backwards. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On 03/06/11 10:10, Richard A Steenbergen wrote: The integrated RE is probably the biggest design limitation. For example, we just got bit by a bad flash drive on one, which caused the kernel to lock up when writing to the disk. This required a physical That's the bigger problem. As I understand it, the flash is soldered on similar to the EX's instead of just using an internal CF or SD slot which would have helped. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On 03/06/11 10:10, Richard A Steenbergen wrote: Juniper would really do well to introduce a 1U small/simple external RE which can be connected over Ethernet, to redundantize a box like the MX80, and to be a reasonably sized BGP route reflector. There was talk of a VC-like implementation for the MX80, although I don't know if that went anywhere. Now that they have the XRE200 what about letting us install Junos64 on it and making it a reflector platform. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX, Nat + BGP
On 18/05/11 10:34, OBrien, Will wrote: I've been working through a nat configuration on my lab MX960 with a MS-DPC blade that I've borrowed. To start, I'm trying to create a simple nat'd subnet. However, the NAT guide that I've been provided doesn't really fit my current design. The example I'm looking at uses a nat pool that's defined like so: 150.150.150.0/24 with an outside interface that has say, 150.150.150.1/24 on it, Ok. Well, in my world, I use MX's for BGP announcements. So I'm trying to put the NAT source interface on a lo0 instead of a normal interface. Is anyone else doing it this way or is there some other sneaky trick I'm missing? So far applying the service filter only seems to break traffic. I've not done NAT on MX only SRX, but with an SRX just announce the NAT pool as a route (static and readvertise, for whatever reason just adding a pool isn't enough to make it eligible for redist), don't need to assign it to an interface at all. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
On 03/04/11 02:13, Jesus Alvarez wrote: It should be trivial to implement a configurable SSH port in the Junos True. firmware and this would help in securing the router. Practically all I doubt it. scanners attempt SSH logins when port 22 is available but very few check all available ports. It is surprising that Juniper does not provide a way to change the SSH port. In my experience if you change the port all that happens is the really simple scans go away, but anything the least bit smart is still there. The way to stop SSH being an issue is: 1. If possible firewall the port to allow known management traffic only. Obviously most networks need to leave a few bounce hosts for emergencies, but these can be *nix hosts that can run fail2ban or similar 2. Disable root auth (*especially* with JunOS, I find I need a root [not super-user] shell roughly once a year, and start shell; su takes care of that) 3. Disable password auth. As long as you don't trust any known compromised keys (Debian SSL bug bites again) this stops everything. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS scalability question.. OTV answer?
The short answer is: http://www.juniper.net/techpubs/software/junos/junos92/swconfig-vpns/configuring-vpls-without-a-tunnel-services-pic.html This is meant to just need recent-ish pic's facing the MPLS cloud. On 28/03/11 09:53, Chris Evans wrote: All the communication that we've received from Juniper is that they perceive MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS on the Juniper platforms and I cannot find any definite information as to how much it can scale performance/bandwidth wise. VPLS requires either a VT interface or a LSI interface on that hardware. The VT interfaces can only be obtained by hardware that can do tunnel services, and the LSI interface is only on the MX platforms from what I can read. As tunnel PICs have limited performance and LSI interfaces 'steal' physical 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE blades) how does Juniper expect to be able to provide high bandwidth VPLS while still providing high port density? The TRIO cards have some inline services, but does they offer these services? It seems like Juniper is expecting to throw another half baked solution out there to compete with Cisco and I'm not sure how they're going to scale the infrastructure. The Cisco solution uses the built in ASIC hardware to do this and do not require ports to be stolen, etc.. It really bothers me that you have to lose interfaces and/or install special hardware to do inline services, which only increases the cost of the platforms drastically. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] virtual router, M or J?
On 10/03/11 18:42, Richard Zheng wrote: SRX seems to be a really good candidate. It looks like all models have almost identical features, the only difference is performance. I will buy a SRX100, maybe even 2 to test high availability. The SRX100 is a nice test platform, but it does have a bunch of annoying limitations vs the rest of the line. (Jumbo frames, MPLS bits, a bunch of performance), although at least you can be sure it will work on anything. Customers may have overlapping address space and the virtual router may interact with their CPE routers too. That only needs a routing instance, not a full virtual router which makes things easier to manage. The only issue is that it doesn't support DC power and can't be deployed in some cases. Depends on the model. SRX240 650 have DC variants (see the HW guide), SRX1400 will get DC according to the data sheet. J-series seems much more expensive and doesn't have nearly as many features. DC power is available though. Just wonder what's application? The J's are getting on a bit, they do support some interfaces that SRX don't (xDSL, T/E3, ISDN BRI), and except for needing ~1GB more RAM with the -ES (AKA SRX) code still make nice routing boxes for those places where 1Gb throughput isn't needed. M-series seems really over priced for this application. The smaller M's at this point are also old and due for replacement, the MX80 covers a lot, but wouldn't suit your needs due to (current) lack of services. If and when Juniper launch SONET MIC's I think that will be the end of the smaller M's. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] virtual router, M or J?
It sounds like what you really want is just an SRX (Probably 2x240, 650 or 1400). And unless you have overlapping address space there's no need for virtual routers at all (and even then they'd only need to be routing instances) The J's at this point are essentially just (branch) SRX's with a different chip. On 10/03/11 16:36, Richard Zheng wrote: I'd like to solicit some advice on router selection. The requirement is to support many virtual routers, up to 50 to 100. It only needs a few GE interfaces. Many customers are aggregated to it. A virtual router is created for each customer to segregate among them. Built-in NAT and firewall services are used to route traffic to the Internet so that no external router/firewall is required. Since the traffic is not too heavy, I believe both M or J would do it. But I am not sure which one is better in this particular setup? M is hardware based, J is software based. But J seems to support more features although they are both based on the same software. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] virtual router, M or J?
On 10/03/11 16:50, Julien Goodwin wrote: It sounds like what you really want is just an SRX (Probably 2x240, 650 or 1400). Scratch the 240's, from the data sheet: Maximum security zones: - SRX240 - 32 - SRX650 - 128 - SRX3k - 256 (1k should be the same, but not listed on it's data sheet) And unless you have overlapping address space there's no need for virtual routers at all (and even then they'd only need to be routing instances) The J's at this point are essentially just (branch) SRX's with a different chip. On 10/03/11 16:36, Richard Zheng wrote: I'd like to solicit some advice on router selection. The requirement is to support many virtual routers, up to 50 to 100. It only needs a few GE interfaces. Many customers are aggregated to it. A virtual router is created for each customer to segregate among them. Built-in NAT and firewall services are used to route traffic to the Internet so that no external router/firewall is required. Since the traffic is not too heavy, I believe both M or J would do it. But I am not sure which one is better in this particular setup? M is hardware based, J is software based. But J seems to support more features although they are both based on the same software. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] J2350 Dual fast ethernet PIM
What's the deal with the J23X0 and not supporting the dual fast-e pim. Given the UPIM's are supported this makes little sense. Although the pim guide, and JunOS itself say unsupported (and just disabled in JunOS). They are used as an example in the hardware guide: http://www.juniper.net/techpubs/hardware/junos-jseries/junos-jseries96/junos-jseries-hardware-guide/hw-hardware-features-j2320-j2350.html#hw-hardware-features-j2320-j2350 -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX advice
On 04/02/11 16:12, Ryan Goldberg wrote: watchguard a) is the outbound nat box for about 70 small offices (we are a small ISP too, these are fiber-connected customers). it also handles some amount of inbound nat for those customer's various servers, which may be in the customers office, or a virtual host in our racks. and maybe a half dozen ssl-vpn road-warrior types. There's also a dozen or so lan-to-lan ipsec tunnels on it. sustained 2-20 inbound. light outbound. That's an odd setup. watchguard b) is for internet facing windows boxes. lotsa inbound nat. sustained 2-20Mbit outbound watchguard c) is for our office, 55ish users. some inbound nat too. 0-50Mbit inbound, widely varying watchguard d) is for one particular hosting customer where stability is paramount. The other firewalls get touched a lot (and as of late, have been puking when they feel like it). 2-15Mbit of sustained web traffic, with the odd spike or lull. These three are fairly trivial. a 2821) terminates a bunch of lan-to-lan ipsec tunnels (VTI style) to 1841s all over the place. box is completely VRFed, no global table, all the tunnels land in the INTERNET vrf and pop out in customer vlans, each their own vrf. 10-30Mbit So - goal is to collapse all this onto a single pair of boxes running in an HA config. Watchguard a, b, and c are problematic, and are becoming more problematic. watchguard d is pretty quiet, but we are contractually obligated to remove all SPOF from that clients setup. the 2821 is very quiet, no troubles. My main question revolves around number of virtual routers. We can't afford a big enough box to stuff everything (as in, every customer network) in its own vrf/routing-instance. I will admit that I've become hooked on using vrfs in cisco land on ISRs (a lot of double-ISP configs, random dirty hacks). But for our future firewall setup, I don't know what a bunch of routing-instances really buys us, if anything (aside from the psychological aspect). All we really need is for all the private networks behind this thing to get natted to their corresponding public ip(s), and if something behind the firewall needs to talk to something else behind the firewall, it should go out and back in (getting source nattted, then dest natted). If the J-boxes can do that without separate routing-instances, then we're good. You only need instances (on SRX) for two things: * Overlapping IP's need forwarding instances * Multiple protocol instances (eg, seperate OSPF on either side) take non-forwarding instances My other question involves HA stability. I've seen instances with other kit where introducing HA actually reduced availability. SRX boxes like running in HA, or are they fussy? I don't run SRX's in HA, the only issues I've had in production are firmware related (note that you can't do an online firmware upgrade of a HA cluster, there's still a hit). I would suggest an SRX650 over the SRX240, would be far more confident in that handling your traffic load (on the services side, forwarding should be trivial for even an SRX100). -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Sync-E and PTP (1588v2) support on Juniper equipment
On 21/01/11 23:02, Timo Mallas wrote: It would be great if somebody who has got some experience with this could shed a little light on frequency (and ToD/phase) synchronization protocol like Sync-E and 1588v2 support on Juniper equipment? A customer of ours is considering to migrante from legacy SDH network to IP/MPLS Ethernet network. At the moment IP/MPLS parti s clear, no problems there .. what's missing is synchronization part. I'm more or less aware of options Cisco is offering, but it would be nice to see if Juniper can offer something competitive as well J .. any input will be highly appreciated. Have you actually figured out exactly what needs timing? Unless it's Cellular, DOCSIS, or SDH/PDH tunnels you shouldn't need it, and for all of those AFAIK you can use local clocks. Juniper did add sync-e support to the MX80 (modular version only) in 10.4, and they have better then average timing, but not sync-e or PTP in the BX line. Don't see any big likelihood of PTP support soon given that it's only accurate on the LAN scale and not much better then NTP once it's gone a few hops. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Routing to tunnel interfaces on M10i
On 19/01/11 00:42, Alexander Shikoff wrote: But it seems that M10i does not route anything to this tunnel: I cannot ping 109.68.40.158 from any other place of my network. What's wrong with it? Thanks in advance. So, here's a few things: 1. Are you running at least JunOS 9.2? - I had some issues with IPIP in 9.0 and 9.1, 9.2 and 10.0 have been fine 2. Do you have a tunnel pic? - Some quick googling does seem to confirm IPIP needs a tunnel pic - However traffic to the RE may still work without one 3. Are you advertising the routes for traffic behind the tunnel via your IGP? - What does show route somewhere else say? - Does a traceroute show the expected path? 4. Does the *remote* site do the same for return traffic 5. Are you advertising a better route to the tunnel source (either way) - Some gear will bring a tunnel up, negotiate the IGP, then try to send the encapsulated traffic over the tunnel itself (JunOS will do this with both SRX and ES-pic IPSec), static /32's can help here -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Routing to tunnel interfaces on M10i
On 19/01/11 01:35, Alexander Shikoff wrote: On Wed, Jan 19, 2011 at 01:20:00AM +1100, Julien Goodwin wrote: 2. Do you have a tunnel pic? - Some quick googling does seem to confirm IPIP needs a tunnel pic - However traffic to the RE may still work without one I do not have it. I thought that tunnel pic is needed only for hardware processing of IP-IP or GRE tunnels, but it seems that without it traffic is allowed only to RE. Yes. Juniper's hardware routers simply don't do software fallback for forwarding. You either get line-speed (or PIC-speed for ES, AS, Tunnel etc) forwarding or nothing at all. There is *one* case of software fallback I'm aware of in that BFD can, on some platforms, be done at the hardware level with less RE involvement (from an old thread on this list I think, should research it). Another case worth mentioning is the VPLS no-tunnel-pic option which uses the enhanced capabilities in some of the newer pic's (presumably for double push operations) to run without a tunnel pic. If you're willing to do the evil of using a P-style pic in a PE-style FPC (well, chassis in this case) you can pick up a compatible tunnel pic for less then US$500 on eBay, add some form of handle and remove the steel base plate (if installed) and it works fine. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] logical-systems loopback's
I'm starting to get logical-systems going on my M5, and I've hit something odd that I've not seen before, and Google isn't helping. Juniper M5, running 10.0R2.10. When I configure a loopback in a logical-system (eg, lo0.6 for one of them) all seems fine. When I try and use lo0.6 as the source address for an unnumbered address (aggregated SDH in this case) I get a commit error: [edit logical-systems zeta interfaces as1 unit 0 family inet] 'unnumbered-address' unable to get address from lo0.6 error: configuration check-out failed I also get the same error when trying to use unnumbered-address on an LT interface (as an aside, why only Ethernet frame-relay options for LT interfaces, PPP and/or HDLC would seem to make more sense, having no encap at all would make even more) If I try any other loopbacks I get: [edit logical-systems zeta interfaces as1 unit 0 family inet unnumbered-address] 'lo0.0' referred interface must have address configured under family inet error: configuration check-out failed: (statements constraint check failed) Which seems right, so there's clearly something special happening. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] logical-systems loopback's
While I'm on the topic of things which aren't quite right, why does commiting an aggregated-sonet or ethernet connection without setting device count (chassis - aggregated-devices) not throw at least a warning that this will silently fail? -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco 7206 replacement
On 29/12/10 04:39, Mark Tinka wrote: The things that currently annoy me with Juniper are: - JUNOS has been terrible, hopefully 2011 is a better year. Absolutely, although I've found that only really in the SRX line where both 10.3 10.4 are unusable as RPD never comes up (*second* JTAC case for this to be opened this week). - Strange and silly hardware restrictions that inconvenience you when you least expect it, e.g., lack of Translation Tables support on the MX DPC's, lack of H-QoS on the current 16-port 10Gbps MPC card, the need for additional Services PIC's for certain basic services (I agree that very advanced services would scale best when offloaded to dedicated hardware), e.t.c. And Cisco aren't *worse* at this? Look at the supported platforms for VPLS for example. I can run VPLS on an M40 if I had one (yes, with a tunnel PIC, or specific other PIC's). - No decent contender to Cisco's ASR1000 platform - it currently makes no sense for us to invest in the M7i/M10i boxes, and yet the M120 and MX-series boxes are too large. I hope this can be rectified soon. I'm not so sure about that. If you're ethernet only, *and* you need more interfaces then an ASR1002 then the MX80 is a nice combo, but yes an even smaller ethernet-only platform would still be great, although I doubt Juniper will launch one as it would likely just cannibalise sales of the MX80 (Something with just the interfaces from an SRX1400-10G would be awesome). -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] On upgrading an M5
I've just spent the last few days (when not gorging myself on seasonal fare) upgrading an M5 for lab use, and thought a few notes might be useful for next time I need to do it. CF Upgrade: 1. Changing the CF in an RE-2.0 is a pain, disassemble, do the complete upgrade, only then reassemble, you'll thank yourself after going back for the tenth time. 2. If you don't zero the new CF (at least the first few MB) you'll need to change the boot order *before* installing it: r...@m5 start shell r...@m5% sysctl machdep.bootdevs machdep.bootdevs: pcmcia-flash,compact-flash,disk,lan r...@m5% sysctl -w machdep.bootdevs=pcmcia-flash,disk,lan machdep.bootdevs: pcmcia-flash,compact-flash,disk,lan - pcmcia-flash,disk,lan 3. If you have pre-8.5 JunOS on a device it seems like it will ignore = 1GB CF, so you may need to snapshot, remove CF, upgrade JunOS, install CF, snapshot back 4. If the CF isn't in the boot list some version of JunOS will simply ignore it 5. If CF isn't in the boot list a major alarm goes in 9.3 (doesn't in 8.5, didn't test anything in between) 6. If the CF isn't in the boot list on upgrade, it will be added back (at lest in a 9.3 - 10.0 upgrade) PIC's: P-style pic's still work without alarm, at least as of 10.0R2.10. Just remember to add some form of ejector *before* installing into the chassis, or at least mount it next to a PE pic. -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SRX and ssh freeze
On 23/12/10 21:34, Florian Weimer wrote: * Julien Goodwin: For my SRX at the office back when I installed it (9.6 IIRC) *TCP* keepalives would not extend session timeouts, but *SSH* keepalives worked very well, that's the ServerAliveInterval setting in OpenSSH. Typically, TCP keepalives happen at such long intervals that they do not keep firewall state alive. In my specific case (whinging admin in internal IT, not production) they were at least every minute. We do actually have some systems that are so old/weird they don't support the ServerAliveInterval, but they're all fairly minor so it's not usually a problem. -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SRX and ssh freeze
On 22/12/10 04:53, Alfred Schweder wrote: Does SRX support ssh keepalive (like M- or J-serie)? SSGs drop the ssh session if they get a keepalive. Juniper isn't willing to fix this in the near future ;-( For my SRX at the office back when I installed it (9.6 IIRC) *TCP* keepalives would not extend session timeouts, but *SSH* keepalives worked very well, that's the ServerAliveInterval setting in OpenSSH. It's arguable whether this is correct, but as everything I use supports the SSH keepalives it works for me, as well as being much better at noticing when a connection *does* drop. -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX unsupported filter policer and actions on loopback lo0
On 18/12/10 07:28, Chris Morrow wrote: yea, so... from: http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf AFL includes licenses for IS-IS, BGP, MPLS and IPv6 routing While we're on the topic, I'm still annoyed at this. Juniper have publicly stated that they won't charge for IPv6, so why are they still doing so on EX? I can currently use OSPF3 due to what I presume is a bug in licence enforcement, but that's not really a sane long-term option. See Dave Ward's talk at the Google IPv6 implementers conference: https://sites.google.com/site/ipv6implementors/2010/agenda -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2tp sessions on MX
On 13/12/10 17:21, Amos Rosenboim wrote: L2TP termination is not currently supported on the MX. According to an SE I work with this is on their radar but no committed date yet. More to the point it's publicly advertised in the marketing materials for the Trio boards MX80. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2tp sessions on MX
On 14/12/10 04:22, Phill Jolliffe wrote: MX + MPC + L2TP LAC functionality just arrived in 10.4 For those playing along at home it's page 23 of the release notes. L2TP LAC support for subscriber management (MX Series routers) But no LNS, or was that supported by way of the other platforms with LNS support? -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using SRX's for BGP and Firewalling
On 09/11/10 20:12, Keegan Holley wrote: On Mon, Nov 8, 2010 at 10:26 PM, Julien Goodwin jgood...@studio442.com.au mailto:jgood...@studio442.com.au wrote: On 09/11/10 14:17, Keegan Holley wrote: BGP full feed on an SRX650 is fine, if you disable flow mode (as much as you can, don't forget the ALG's). What's the point of doing BGP on a firewall with firewallling turned off? Because they're cheaper then the J-series. Why bother with either if you're all ethernet? Because an SRX650, after discounts, is cheaper, and more robust then a PC based (ie, standard rack pc, not a special one) router. Especially once you add support, and don't forget that many carriers want a DC PSU option, even if they don't use it. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using SRX's for BGP and Firewalling
On 09/11/10 02:38, Maqbool Hashim wrote: Hi, I'm looking at doing a multihomed BGP setup using two upstream Internet providers. We are obtaining PI space and would like to announce our PI space via BGP to our upstreams.I'm looking at using one of the SRX range from Juniper to handle the BGP and firewalling requirement for us. We don't need a full routing table. Is it a realistic proposal to do the BGP and firewalling on one device (an SRX) ? Or am I creating a rod for my own back by not using separate BGP routers and using separate devices to do the firewalling for me. I'd be interested in hearing if other people are using the SRX's in a similar way. Thunderbird just ate my response, grr. BGP full feed on an SRX650 is fine, if you disable flow mode (as much as you can, don't forget the ALG's). BGP with a default inbound and advertising a few routes is fine with firewalling. Combining a full feed with firewalling is a bad idea, at least on the branch kit, and probably the SRK1k and 3k. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 JunOS Recommendation
On 09/11/10 06:31, Keegan Holley wrote: I'm looking for a code recommendation for EX4200's. I'm planning some network wide upgrades and I have an idea of what I want to run, but I was curious what the list would recommend. Most of the switches will be layer-2 only with, 10G or AE uplinks, VC of course. We've run into some pretty significant bugs in the past, just wondering what everyone else is running. I'm still running 9.5 everywhere. Apart from one DHCP relay oddity it works fine. Once DHCP6 relay is in I'll upgrade, but the main reason I haven't is that I currently have one feature working that shouldn't. If Juniper actually delivered on their promise of IPv6 equality this wouldn't be an issue (and that's enough for anyone who cares to figure out what I mean). -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using SRX's for BGP and Firewalling
On 09/11/10 14:17, Keegan Holley wrote: BGP full feed on an SRX650 is fine, if you disable flow mode (as much as you can, don't forget the ALG's). What's the point of doing BGP on a firewall with firewallling turned off? Because they're cheaper then the J-series. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Fwd: router recommendation
On 26/10/10 08:54, Gabriel Blanchard wrote: We in fact use a J-6350 at our office and we couldn't even get it to handle a full routing table. (at least not very well). They handle a full routing table just fine. With the old packet-mode software they could do a full table (as of January) in 1g of ram. With flow-mode I've had to up ours to 3GB (above Juniper spec) at which point they handle three full tables with plenty to spare. -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 10GbE Interfaces
On 20/10/10 23:20, Skeeve Stevens wrote: Hey all, On the Juniper product page for the SRX650 under interfaces it lists: 2 x 10 GbE SFP+ / 10 GbE Base-T Copper I've found some obscure references to the PIM - code SRX-GP-2XE-SFPP-TX Which seems to suggest you get 2 * SFP+ and 2 * 10GBase-T. That is a little odd. Fairly standard, you get the copper or the SFP. Same with plenty of switches (eg, EX3200). Has anyone used these... I can't even find a picture on Google, and most of my suppliers don't even list it - but one does. I could *swear* I had some more details, but can't find anything. If you trawl through the 10.2 release notes you get this: 2-Port 10-Gigabit Ethernet XPIM—The 2-Port 10-Gigabit Ethernet XPIM is supported on SRX650 devices. The 2-Port 10-Gigabit Ethernet XPIM provides a connection to high-speed Ethernet networks through branch WAN service and allows carriers to provide multiple levels of Ethernet service with a single connection option for all service ranges. The 2-Port 10-Gigabit Ethernet XPIM is a single-slot XPIM that can be installed only in the 20-gigabit GPIM slots (slot 2 or 6) on the front panel of the SRX650 Services Gateway. The 2-Port 10-Gigabit Ethernet XPIM contains two 10-Gigabit Ethernet interfaces with both copper and small form-factor pluggable transceiver (SFP) terminations, to support redundancy and enable the SRX650 Services Gateway to be used as a pure security service device. The following key features are supported on the 2-Port 10-Gigabit Ethernet XPIM: Online Insertion and Removal (OIR) capable. Contains a total of four ports (two SFP+ and two 10GBASE-T). Only two of the four ports can be active at any time; mix and match between the copper and fiber types is supported. ... Quad speed support for copper mode: 10GBASE-T IEEE 820.3an, 1000BASE-T IEEE 802.3ab, 100BASE-T IEEE 802.3u, and 10BASE-T IEEE 802.3. Standard quality-of-service (QoS) features. User-configuration of fiber and copper ports: When the interface is configured as a copper port, a typical Ethernet configuration such as Autoneg is supported. Forced rate and link mode are allowed. Four forced and Autoneg rates are provided: 10 gigabits, 1 gigabit, 100 Mbps, and 10 Mbps. Also, does anyone know why these modules are so damn expensive (about US$9000) where most Cisco 2 port SFP+ modules, Juniper EX3200/4200 and HP E2910al cards are all around the $1200-$1500 range. If they're not shipping in quantity that alone could be enough, the 4SFP / 2SFP+ module for the EX4200 cost a customer nearly $5k each when first available. Then remember it's (essentially) a 2x10g module for a router that doesn't just do ethernet (even if that's all anyone does use them for) and so a lot of bits that are included as standard in ethernet-only gear is on the module. -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Non-M SSG5X0 JunOS
I recently picked up (due to being an idiot who forgot to *read*) a non-M SSG550 intended for the lab. I've put a J-series CF in it and it boots through to Initializing product: 28 but appears to get in a hard hang after that. Has anyone made JunOS work on them, or is there an actual hardware change? -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF default-lsa
On 27/07/10 18:42, Luca Tosolini wrote: the default-lsa is not generated because of Junos 'active backbone detection' http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/configuring-the-backbone-area-and-other-areas.html Active backbone detection is implemented to verify that area border routers are connected to the backbone. If the connection to the backbone area is lost, then the router’s default metric is not advertised, effectively rerouting traffic through another area border router with a valid connection to the backbone. I don't know if and how it can be disabled. And a quick google later the magic appears to be (from Network Mergers Migrations, my copy of which is at home, and I wouldn't have looked to it for OSPF insight). set protocols ospf no-active-backbone Which is now on all my area 0 routers. Thanks a lot. signature.asc Description: OpenPGP 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 22/06/10 18:13, Richard A Steenbergen wrote: With a healthy dose of complex commit scripts you can get an MX commit time up to 20 seconds in no time flat. Well at least you could, I noticed they did something in 9.6 to make it a lot faster (at least for me, with commit sync, etc). EX on the other hand can get to a 30 sec config with half the number of commit scripts and a much smaller config. Of course if you really want suffering try SRX, which takes 30 seconds to commit a nearly blank config. :) I had a J6350 last night take over 10 minutes to commit. Under heavy BGP load, and although it won't admit it I strongly believe heavy memory pressures (two full feeds, plus four other feeds totalling ~50k routes on a 1GB system in 10.0R2, RAM has been ordered and the second full feed turned off). -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 L2TP Functions
Have a look at the hardware guide, it's out now (finally...). The MX80 is four XFP slots (30Gbit bandwidth), plus two MIC slots for interfaces, all Trio 3D based. Alternately the two MIC slots can be replaced by 48 10/100/1g copper ethernet ports (40Gbit bandwidth) *NONE* of the existing MX interface cards are used. The one bit of good news from the hardware guide is that there's a third MIC slot (or for the fixed, *a* MIC slot) reserved for later services MIC's on the rear panel. The Trio chipset is meant to, eventually, support nearly all the services that currently require an MS-DPC. Bad news from the hardware guide is that the RE is poor. 1.2Ghz CPU and 2Gb of ram (not 100% if it can be expanded, looks so), but in a nod to the EX4200 two 4GB *fixed* storage drives on the board. The RE is also not a separate board from the base. There are cl[oc]k and sync BNC's on the rear panel as well, but no details on them, sonet clocks are as RJ45's on the front panel. Still, all said and done I'd love one on my desk as a VPLS/etc. testbed, much smaller then the M40e I just got rid of. On 11/06/10 16:14, Georgios Vlachos wrote: According to the pricelist the ms-dpc is not supported on the MX80 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of OBrien, Will Sent: Friday, June 11, 2010 7:18 AM To: Julien Goodwin Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX80 L2TP Functions L2tp is supported... With the ms-dpc on the mx960. I imagine it's the same for the 80 Will O'Brien On Jun 10, 2010, at 9:30 PM, Julien Goodwin jgood...@studio442.com.au wrote: On 11/06/10 10:38, Skeeve Stevens wrote: Hey all, Does anyone know if they MX80's LNS/L2TP functions are available out of the box as suggested in the datasheets, or will it be available 'later' (with no specified timeframe). According to someone in Juniper AU I spoke to, the answer is later, possibly into next year. However that was prior to actual hardware shipment and not a definitive statement. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc ATT1..txt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 L2TP Functions
On 11/06/10 10:38, Skeeve Stevens wrote: Hey all, Does anyone know if they MX80's LNS/L2TP functions are available out of the box as suggested in the datasheets, or will it be available 'later' (with no specified timeframe). According to someone in Juniper AU I spoke to, the answer is later, possibly into next year. However that was prior to actual hardware shipment and not a definitive statement. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX deployment / issues
On 23/03/10 04:05, Hoogen wrote:
I think the EX thread was really good and the feedback was awesome. I would
like hear about similar experiences while deploying SRX Series gateways, I
am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would
also love to hear feedback on SRX 3000/5000 if people have been using it in
their setup, problems that their facing, improvements and general deployment
scenario that have been used.
So the big gotcha with the SRX line is the lack of IPv6 support. I've
been assured by a Juniper tech rep that over 10.2-10.4 it should get
closer to parity.
From my big evil list:
* SRX650 allowed me to configure {{family ethernet-switching}} on the
internal ports, which isn't supported
* SRX650 only supports LACP on {{family ethernet-switching}} ports,
which excludes the internal ports, EX4200 doesn't have this problem
From the firewall section (much of these are feature reqs)
* Allow to change the default policy per {{from-zone a to-zone d}}
* Allow to do {{from-zone any ...}} or perhaps just {{from-zone [ a b c
] to-zone d}}, this would be a *major* PITA in a hosting environment
with a zone per customer.
* Allow to have {{from-zone ... to-zone ...}} with no rules, I know the
default is implied with it not there
* Allow to have {{address-set}} inside {{address-set}} (ie, group of
groups), this is a *huge* PITA for us now
* The warning on {{show}} for an undefined application is {{Warning:
application or application-set must be defined}} which sucks when
multiple apps are defined, {{commit check}} is fine
* Documentation is unclear re NAT pool IP addresses. I had to add the
pool address to a loopback to get things working, until then the route
was never offered.
--
Julien Goodwin
Studio442
Blue Sky Solutioneering
signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
On 21/03/10 02:03, Richard A Steenbergen wrote: We just deployed our first EX8208 a few days ago, running 10.1R1. Gotchas so far: * Obviously this is a very different architecture from Juniper's normal boxes, so be prepared for vlan space being shared across the entire box, not a per-interface basis. So far, apart from the MX I'm not aware of any Juniper gear that does switching with multiple VLAN spaces. * In a move straight out of Foundry's playbook of how to fail at making a useable product, EX has no packet counters (cli or snmp) available for L3 vlan interfaces. It DOES have working counters if you do traditional Juniper subinterface style vlans (interface blah, vlan-tagging, unit 123 vlan-id 123), but it does NOT work if you have to do RVI style (vlan blah l3-interface vlan.123 and then put vlan blah in an ethernet switching interface). Subinterface style is my preference anyways, so as long as you only ever use vlans on point-to-point links this isn't a problem, but the instant you need to put a VLAN on more than one port you no longer get packet counters. Thank you for doing the testing on this, I was assuming this was a bug as I'd thought they couldn't be *that* stupid. To make things worse counters for vlan.XXX traffic are also only the traffic destined *to* the interface, not counting traffic routed *through*. * Related to the issue above, you can't mix subinterface style and RVI style vlans on the same trunk port. The instant you need to do anything more than classic subinterface style vlans, you have to convert everything on the trunk to vlan/rvi style. For example, where I might otherwise be able to get away with doing interface xe-1/0/0 unit 123 vlan-id 123 family inet blah, if I want to trunk a layer 2 vlan on that same interface I now have to convert unit 123 to RVI style. One possible workaround I have yet to test is doing a CCC instead of a vlan, to keep the subinterface style. This would only work with 2-port member vlans though, and I have yet to test the implications for mixing tagged and untagged ports on EX, so this may not actually work for anyone at all. Either way please post. * Firewall filters are still a bit of a mess. You can't count or log anything, you can't use policers on either control plane or egress filters (heck you can't even commit a firewall filter with a policer in it if applied as an output filter), you can't match frags, etc, etc. Lack of outbound policers also makes it fairly useless in many roles where enforcing max bandwidth on a WAN link is required (At least here in Australia carriers complain if you actually dump 100Mbit of traffic on a 100Mbit point-to-point link). * I don't know who thought 2GB of storage on an RE was sufficient, but it isn't. The best idea I've come up with so far is to grab some small USB flash devices like http://www.geckoandfly.com/tag/small-usb/ and deploy them on every RE so you have a little bit of working space. I've only just upgraded a bunch of stuff *to* 2GB, and don't have any real space issues. I would very much appreciate if Juniper would just give us two, externally accessible CF slots for storage and have that be it. Other than that we haven't found any fundamental flaws in the box yet (though that may change by the time MPLS features get implemented :P). Plenty of bugs to be sure, DOM isn't working right on any of our interfaces, pfe statistics don't work right, monitor interface on vlans isn't displaying correctly, prior to 10.1 the FPCs crashed if you tried to speak BGP flowspec to the box, etc, but we have cases open on all of the above. IMHO it definitely has the potential to be a very good box in the long term, but whoever didn't think to put vlan counters into the hardware really screwed the pooch something fierce. :) So the EX (4200) bits from my personal list: * EX4200 - bootp relay doesn't work when configured inside a routing-instance, works when configured at top to use an instance * The commands in http://kb.juniper.net/index?page=contentid=KB13206cat=JUNOS_EXactp=LIST don't exist in 9.5 I'm mostly on 10.0R2.10, but all our EX's are still 9.5. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX-80 rumors and heresay - any comments?
On 19/03/10 16:49, Phil Pierotti wrote: Given the size/shape/ports of the soon-to-be-delivered MX-80, it's fairly obvious that it's targeted at the 7206-G2/ASR1004/SmartEdge-400 size of the market. Has anyone heard any rumors (or otherwise) of there being L2TP LAC/LNS/Tunnel-Switching functionality available on this platform (ie in real JunOS). So I've yet to see a definitive statement, but I was looking at this last night. The MX MPC data sheet indicates L2TP support: http://www.juniper.net/us/en/local/pdf/datasheets/1000294-en.pdf Inline services include... Layer 2 Tunneling Protocol (L2TP), L2TP access concentrator (LAC), and L2TP network server (LNS). (Page 2, Junos Trio Chipset) I have not seen a statement one way or the other on the MX80. I too would love such a statement, as a potential project of mine is contingent on that support. Julien -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
