Re: [j-nsp] AS-PIC for flow export licensing requirement
> On the other hand - with a sufficiently low sampling rate, RE based > sampling may be feasible. No license needed for that. > > We use RE based sampling on MX. Works for us, YMMV. > We used RE-based sampling (with 1:1000 sampling), which worked just fine since the M5 days. Sadly, there is no version 9 netflow using RE-based, hence no ipv6 stats, so we were forced to buy MS-DPCs eventually. :( Regards, Felix -- Felix Schüren Head of Network --- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Patrick Pulvermüller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS-PIC for flow export licensing requirement
> Check these web pages out. Individual licenses must be purchased for > additional services such as Network Address Translation (NAT), stateful > firewall, intrusion detection services (IDS), IPSec. J-Flow accounting, and > voice services On the other hand - with a sufficiently low sampling rate, RE based sampling may be feasible. No license needed for that. We use RE based sampling on MX. Works for us, YMMV. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS-PIC for flow export licensing requirement
Hi Samit, Check these web pages out. Individual licenses must be purchased for additional services such as Network Address Translation (NAT), stateful firewall, intrusion detection services (IDS), IPSec. J-Flow accounting, and voice services http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/pic-m7i-adaptive-services-2-fips.html http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/pic-m7i-supported.html Thanks, Siva -- Date: Sat, 03 Sep 2011 19:40:16 +0545 From: Samit To: juniper-nsp Subject: [j-nsp] AS-PIC for flow export licensing requirement Message-ID: <4e6231c4.40...@wlink.com.np> Content-Type: text/plain; charset=ISO-8859-1 Hello all, I am planning to buy an AS-PIC from ebay for my M7i , but I am confused do I need to buy the additional Jflow license along with the PIC from Juniper in order to export the flows? or buying just PIC will suffice? Regards, Samit ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] AS-PIC for flow export licensing requirement
Hello all, I am planning to buy an AS-PIC from ebay for my M7i , but I am confused do I need to buy the additional Jflow license along with the PIC from Juniper in order to export the flows? or buying just PIC will suffice? Regards, Samit ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISG Dropping TCP packets
Dear Nicholas Thanks a lot for sharing this with everybody. Regards Farrukh On Fri, Sep 2, 2011 at 3:29 PM, Nicholas Oas wrote: > An update, this issue is officially PR 677385. JTAC is working on a fix. > > Since I last posted we have observed the bug on an additional ISG-1000. To > date, we have observed this in 6.3.0r7, 6.3.0r8, and 6.2.0r9. > > We were able to get packet captures of both the V1-Untrust and V1-Trust > interface, in addition to numerous debug outputs as requested by JTAC. > > Analysis of the packet captures reveals that the ISG-1000 is actually > sending response traffic when it erroneously activates TCP Proxy. The > conversation looks like this: > > Packet 1: > 10.0.2.4:56742 10.0.1.10:80 SYN > (Correct src-mac) (Correct dst-mac) > > Packet 2: > 10.0.1.10:80 10.0.2.4:56742 SYN-ACK > (src-mac: 00:00:00:00:00:00) (dst-mac: 00:00:00:00:00:00) > > The full packet capture shows some other oddities with sequence numbers > sent > by the ISG, but the above is enough to prove the point. > > To summarize, this bug can be experienced if the following conditions are > true: > 1. ISG platform > 2. ScreenOS 6.2 or 6.3 > 3. Transparent / Layer-2 mode > 4. Undelivered TCP packets > 5. UDP and ICMP packets delivered without issue > 6. debug flow basic shows 'tcp proxy processing' > > ex: > get ff > (make sure no FF are set, if so use unset ff ) > clear db > debug flow basic > get db str | include "tcp proxy processing" > > I hope this helps if anyone else ever experiences this issue. > ___ > 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] Securing management access to Juniper gear
On Saturday, September 03, 2011 09:18:51 PM Richard A Steenbergen wrote: > 2) EX lo0 filters don't actually work correctly for DoS > prevention, they get applied *AFTER* the packets have > already destroyed the RE, and thus are completely > ineffective at defending the boxes from attack. The only > way to correctly block control plane traffic on EX is > with ingress filters on "real" intefaces (or RVIs). Just to add, in case you're planning to perform any egress filtering on an RVI for IPv6, it won't work if one of your match conditions is a destination address: [edit interfaces vlan unit 998 family inet6] 'filter' Referenced filter 'filter-outgoing6' can not be used as destination-address not supported on egress IRB error: configuration check-out failed This is Junos 10.4R4.5. Don't know if anything later fixes this. Ingress filtering with that match condition is fine, however. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Securing management access to Juniper gear
On Fri, Sep 02, 2011 at 02:37:11PM -0400, Mark Kamichoff wrote: > > I'm not an EX guru, but I believe the same concepts can be applied. With the caveats that: 1) lo0 filters *WILL* (quite incorrectly) match data plane exception packets that get punted to the RE for further processing as well, such as TTL expiring traceroute packets routing THROUGH the box. Mostly this issue applies to EX, which seems to punt a whole bunch of everything to the RE rather than deal with it on the FPC CPU like traditional Juniper hardware, but the same thing actually still happens with TTL expiring packets being popped out of an LSP on MX Trio hardware too. You need to make exceptions for this in your lo0 filter, or else you'll find your control plane filters matching more than just control plane packets, breaking traceroute/etc, and generally pissing everyone off. I believe there was also a related ongoing issue on EX where an lo0 filter with an explicit deny of all traffic at the end would actually match ARP traffic too, so you should probably be careful with those as well. :) 2) EX lo0 filters don't actually work correctly for DoS prevention, they get applied *AFTER* the packets have already destroyed the RE, and thus are completely ineffective at defending the boxes from attack. The only way to correctly block control plane traffic on EX is with ingress filters on "real" intefaces (or RVIs). -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Experiences - Was: JUNOS 10.4S6 for EX8200 - PR/676826
Am 02.09.2011 14:11, schrieb Derick Winkworth: 1. Have you opened tickets? 2. Did you look in the Defect Search tool? To be honest - no. I've solved the issue by only filtering the traffic on one virtual router, that did the trick. Unfortunately we have so many bugs in our NSM installation/database, that we cannot simply upgrade the NSM and thus I'm currently stuck with JunOS 10.1 (due to NSM 2008). We have plenty of open cases for the NSM which has way more priority. Hopefully an update to a recent JunOS release will solve some problems... We'll see... We have SRXs in our environment and there has been some issues, but thus far all have been identified and resolved over time. Months actually rather than years. At least for us, Juniper has been quick to resolve issues. Hmm, my mileage varies here. Some issues (mainly with ScreenOS) have been identified and solved quite fast. Others (primarily NSM) are now open for over a year without significant progress. It depends heavily on the type of bug that you discover, and if engineering is able to reproduce the issue. Best regards, Stephan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
