[j-nsp] NSM API resources with SRX
Hi- I read the NSM API guide already on Juniper technical site, but its very basic and not very clear. Looking for advance information of NBI handling/scripting with SRX such as "configuration" push, "commit" validation, etc. Any useful document or available scripts ? could you please share. -Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
http://packetpushers.net/internet-as-a-service-in-an-mpls-cloud/ Check that out... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Mark Smith To: juniper-nsp@puck.nether.net Sent: Thursday, January 19, 2012 9:05 AM Subject: [j-nsp] Internet routes in MPLS network, global table or own VRF? Hi How should the global Internet routes be organized in IP/MPLS network? Should they be put into global (inet.0) routing table or in their own VRF (e.g. internet.inet.0)? Assume same P/PE routers are used to route internet and VRFs. What are the pros and cons of these approaches? Pointers to good materials are appreciated. (please excuse me if this is in the series of stupid questions ;) Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Whitebox 10Gb/s capture challenge
http://info.iet.unipi.it/~luigi/netmap/ port whatever analysis software you want to use to the netmap interface OBrien, Will [obri...@missouri.edu] wrote: > I'm pondering the idea of trying to build a relatively inexpensive 10Gb > capture box. > The simple solution is a dell R710 with 10Gb nics. I have some, they work, > but I'd have to spend $50k to get enough of them. > > So, my challenge is keeping the price point is something around $1000-$1500 - > basically the 10Gb version of a 1u gigE capture system. > > In general, I probably don't need to ever write 10Gb/s to disk, but it would > be nice load the dice for success. > My thoughts are a reasonable performance motherboard with 10Gb PCIe nics or a > white box mobo with onboard SFP+ ports. > > Anyone gone this route? > > > Will O'Brien > University of Missouri, DoIT DNPS > Network Systems Analyst - Redacted > > obri...@missouri.edu > > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- There are only three sports: bullfighting, motor racing, and mountaineering; all the rest are merely games. - E. Hemingway ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DR deployment of SRX
Depends on what model of SRX you're talking about. High end or branch? High end: http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/technotes/SRX%20High%20Availability%20Deployment%20Guide.pdf http://www.juniper.net/us/en/local/pdf/app-notes/3500168-en.pdf Branch: http://www.juniper.net/us/en/local/pdf/app-notes/3500132-en.pdf http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/8010055-EN.PDF The HA chapter in the book Junos Security is also pretty comprehensive, but in the name of full disclosure.. I'm bias as I'm a co-author. As for challenges/limitations. I would highly recommend you read the release notes for whatever code you're running. Juniper does a really good job at listing the limitations for clusters with features (i.e. you can't do a packet capture on a reth interface,) I hope this helps, -Tim Eberhard On Sat, Jan 21, 2012 at 3:07 AM, Dan Chevrie wrote: > Hi- > is there any document related to DR deployment of SRX? challenges, services > and benefits? > > any help would be highly appreciated. > > > -Dan > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hash algorithms for LAG
On (2012-01-21 22:17 +1100), Julien Goodwin wrote: > *cough* Broadcom Trident(+) *cough* Speaking of which, someone should do round-up (lightreading? is there anyone really doing non-vendor paid testing these days?) of trident+ boxes, there must be dozen vendors pimping them by now, and differentiating them seems hard. Does anyone pimp L3 MPLS VPN enabled trident+ boxes? What about pure MPLS switching? -- ++ytti ___ 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 19:59, Phil Mayers wrote: > Pavel Lunin wrote: > >> >> >> Sounds alright, though I'm not a specialist in this. But I've heard the >> word 'patented' from someone from Juniper, this is why I used it. It's >> been >> a few years ago and I even went to the trouble of skimming through the >> US >> patent DB (very quickly). Found a bunch of Juniper's patents but none >> looking to be related to this. So if nobody can justify, let's consider >> it's a secret :) > > Doesn't have to be a juniper patent. They may have licensed it from someone. > In fact this may explain their secrecy - they may want to downplay that they > bought in tech! *cough* Broadcom Trident(+) *cough* -- 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] DR deployment of SRX
Hi- is there any document related to DR deployment of SRX? challenges, services and benefits? any help would be highly appreciated. -Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hash algorithms for LAG
Pavel Lunin wrote: > > >Sounds alright, though I'm not a specialist in this. But I've heard the >word 'patented' from someone from Juniper, this is why I used it. It's >been >a few years ago and I even went to the trouble of skimming through the >US >patent DB (very quickly). Found a bunch of Juniper's patents but none >looking to be related to this. So if nobody can justify, let's consider >it's a secret :) Doesn't have to be a juniper patent. They may have licensed it from someone. In fact this may explain their secrecy - they may want to downplay that they bought in tech! -- Sent from my phone. Please excuse brevity and typos. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Site-to-Site Question
This works for a few hours approximately and then no traffic will pass. > As a quick test try to decrease the SA timelive (both phase 1 and 2) to possible configurable minimum. If the freezing time changes (AFIAR it's rekeyed each half-life period), you'll have a way to go further. Also check if clearing ike and ipsec SAs (instead of rebooting the whole box) helps. Didn't understand whether your case is SRX-to-SRX or SRX-to-something. I've heard from colleagues they ran into similar symptoms, caused by inability to rekey due to Cisco ASA software issue (not apparent in the ASA-to-ASA case), don't know much details though. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Site-to-Site Question
> In my experience, I have used a looback interface address of the SRX as > the destination of the GRE tunnel on both sides then just send the /32 > route of the loopback at the other end to the st0.0 address. > One important thing here. When you use loopback for IPSecs, GRE, iBGP or any other sort of peering, you must keep in mind the traffic by default is first considered to be transit in contrast to the direct interface peering where it's considered local right after it enters the physical interface. So for loopbacks (or any other interface except the one, which the packets come through) you either need to correctly pass packets though the firewall engine (policy-shmolisy, flow sessions, etc) or explicitly bypass it using selective stateless filtering. This is true both for JUNOS Voyager (SRX/J) and ScreenOS (if someone remember that thing) except ScreenOS can (or could? :) not do stateless. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hash algorithms for LAG
> 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) > Sounds alright, though I'm not a specialist in this. But I've heard the word 'patented' from someone from Juniper, this is why I used it. It's been a few years ago and I even went to the trouble of skimming through the US patent DB (very quickly). Found a bunch of Juniper's patents but none looking to be related to this. So if nobody can justify, let's consider it's a secret :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
