Re: [j-nsp] Recommended sampling rates on MS-500 pic
There are no universal rules which apply to sampling. Obviously the more packets you can capture during a given sample, the better. Determining your sampling rate depends on a lot of variables. You should start by looking at the intended application for deployment of sampling. For DDoS alerting, as little as 1:100 or even in some cases 1:1000 can be enough due to the higher probabilities of capturing a known malicious packet within the overall sample. If you need visibility on all network traffic, especially short-lived flows, then you are going to need to reduce your sampling rate quite to something as close to 1:1 as possible. Ideally, you can optimize the sampling rate based on an analysis of the existing flow rates in your network - this of course might be impossible given the fact that this is the reason you are deploying a monitoring application in the first place. There are design considerations that will also allow you to scale your sampling application to support higher numbers than might otherwise be possible - for example, limiting your firewall filters to monitor only that which is relevant to the sampling application is a common technique. Ultimately, you should take a look at the datasheet for the hardware you intend on deploying and compare that to what you expect to see on your network. I have personally observed 1:1 sampling in several production networks where monitoring hardware (AS-PIC, MS-PIC, etc.) was used with no performance degradation. I've also seen 1:100 sampling on an M7 without the ASM and this worked fine as well with little increase in CPU on the RE. HTHs. Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of tim tiriche Sent: Sunday, June 20, 2010 8:23 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Recommended sampling rates on MS-500 pic Hello, I would like to know what is the recommended sampling rates to use on a network and what can the juniper support. In addition, what factors determine what sampling rate to use. Thanks you! --tim ___ 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
[j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? Regards ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX80 = vaporware?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, does anybody have the slightest clue about the availability or hold-up of those boxes? Our sales representatives are shrugging, MX80 demonstrations are lacking the boxes etc pp. Make way for the 2010 awards? http://www.wired.com/epicenter/2009/12/vaporware-2009-inhale-the-fail/ Boggling regards, Mit freundlichen Gruessen, i. A. Sven Juergensen - -- Fachbereich Netze und Rechenzentren KielNET GmbH Gesellschaft fuer Kommunikation Preusserstr. 1-9, 24105 Kiel Telefon : 0431 2219-053 Mobil : 0170 403 5600 Telefax : 0431 2219-005 E-Mail : s.juergen...@kielnet.de Internet: http://www.kielnet.de Geschaeftsfuehrer Eberhard Schmidt HRB 4499 (Amtsgericht Kiel) PGP details at http://pgp.kielnet.de/sjuergensen/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAkwfRAsACgkQnEU7erAt4TI7SgCfQBPnw4WET20S2O6h7TTntERZ JQoAn2tvuq+yqxJofG9hFip710P8pFhF =7bfb -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 = vaporware?
Why don't you just get an MX240? They are available and on the market. On Mon, Jun 21, 2010 at 6:50 AM, Sven Juergensen (KielNET) s.juergen...@kielnet.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, does anybody have the slightest clue about the availability or hold-up of those boxes? Our sales representatives are shrugging, MX80 demonstrations are lacking the boxes etc pp. Make way for the 2010 awards? http://www.wired.com/epicenter/2009/12/vaporware-2009-inhale-the-fail/ Boggling regards, Mit freundlichen Gruessen, i. A. Sven Juergensen - -- Fachbereich Netze und Rechenzentren KielNET GmbH Gesellschaft fuer Kommunikation Preusserstr. 1-9, 24105 Kiel Telefon : 0431 2219-053 Mobil : 0170 403 5600 Telefax : 0431 2219-005 E-Mail : s.juergen...@kielnet.de Internet: http://www.kielnet.de Geschaeftsfuehrer Eberhard Schmidt HRB 4499 (Amtsgericht Kiel) PGP details at http://pgp.kielnet.de/sjuergensen/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAkwfRAsACgkQnEU7erAt4TI7SgCfQBPnw4WET20S2O6h7TTntERZ JQoAn2tvuq+yqxJofG9hFip710P8pFhF =7bfb -END PGP SIGNATURE- ___ 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] MX80 = vaporware?
On Jun 21, 2010, at 4:58 AM, Scott T. Cameron wrote: Why don't you just get an MX240? They are available and on the market. Significantly different price structure! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
I would use a rewrite rule to modify DSCP on egress, so that its consistent across platforms. I still prefer the IOS way, where TOS byte values are re- written on ingress (I believe we began a small petition for this capability a year or more back, but it didn't gain any traction). However, it works just as well in JUNOS, just on egress. I actually prefer the Junos method for at least some scenarios. In my case, we connect to several other QoS-aware networks that all use different values for different things (ie: AF41 = EF = AF42 = AF21 = me going crazy). Using Junos's method its very simple to do a different rewrite map on the egress interface toward the other networks. So there's basically a single piece of configuration to make everything function.. and a single place that things could get broken. However, I would agree that for smaller sites (ie: J-series, SRX, etc) the ingress method is much easier. Having a FULL CoS stanza just to mark some traffic EF is kind of annoying. And I can see the arguments for ingress methods in other networks as well. Of course this is just my opinion and I certainly don't run a huge network like some of you guys! ___ 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 Monday 21 June 2010 06:29:00 pm Laurent HENRY wrote: Does anyone actually use these features actively with this platform ? We once used 2x EX4200-24F's as routers located in the centre of a core network built to drive a regional operator conference. They ran iBGP + IS-IS (IPv6 support included, for both) with Cisco 7206-VXR/NPE-G2's and originated the allocation that the conference was using. Given they were at the centre of the core (core switches, actually), their failure would have been more accurate/indicative of network problems rather than originating said routes on the border routers. In this role, they were very stable (they also run regular Layer 2 Ethernet features, e.g., RSTP, 802.1Q, e.t.c.). Haven't used them as routers elsewhere, yet (although I had plans to, until the MX80 came out). 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] MX80 = vaporware?
You may want to seek out new sales people, or alternatively, sign an NDA with Juniper. David On 21 June 2010 04:50, Sven Juergensen (KielNET) s.juergen...@kielnet.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, does anybody have the slightest clue about the availability or hold-up of those boxes? Our sales representatives are shrugging, MX80 demonstrations are lacking the boxes etc pp. Make way for the 2010 awards? http://www.wired.com/epicenter/2009/12/vaporware-2009-inhale-the-fail/ Boggling regards, Mit freundlichen Gruessen, i. A. Sven Juergensen - -- Fachbereich Netze und Rechenzentren KielNET GmbH Gesellschaft fuer Kommunikation Preusserstr. 1-9, 24105 Kiel Telefon : 0431 2219-053 Mobil : 0170 403 5600 Telefax : 0431 2219-005 E-Mail : s.juergen...@kielnet.de Internet: http://www.kielnet.de Geschaeftsfuehrer Eberhard Schmidt HRB 4499 (Amtsgericht Kiel) PGP details at http://pgp.kielnet.de/sjuergensen/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAkwfRAsACgkQnEU7erAt4TI7SgCfQBPnw4WET20S2O6h7TTntERZ JQoAn2tvuq+yqxJofG9hFip710P8pFhF =7bfb -END PGP SIGNATURE- ___ 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] EX 4200 stability with BGP and OSPF redistribution ?
On Mon, Jun 21, 2010 at 12:29:00PM +0200, Laurent HENRY wrote: Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? We make some use of layer 3 services on the EX-4200, and largely, our experience has been good in this department. Be aware that their FIB size is very limited, so you'll need defaults. We have EXes working a customer edge boxes for people that don't want a full table and it's reliable and cost effective if you can live without the missing features. We do OSPF, iBGP, and some MPLS, though the EXes are feature crippled there. If you care, uRPF sucks big time, but I'm used to that from the 6500. Be somewhat cognizant of RE CPU performance. Unfortunately, the EX CPU doesn't cope too well with large VC installations in complicated configuration. In my experience, you'll be fine if you stay away from virtual-chassis. We've only really hit this in our layer 2 deployments, where committing a config can cause STP to miss BPDU timers. However, I don't see any reason why a 10 member layer 3 VC wouldn't exhibit the same issue with (for example) OSPF hellos. Software choice can be annoying - things are still changing. 9.6 is my current target for layer 3 boxes because you finally get capable loopback filters with recent bugfixes. If you want to police LSPs though, you'll need 10.1. I've had good luck so far with 10.1R2 in this application. Of course neither of these are extended EOE... To sum up - if you can live with some missing features and headaches, they aren't bad. The price point is pretty attractive. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Config Question
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming traffic
on
the ports i opened below on the policies. Anyone have any ideas what i am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214:
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector off into
the NAT policy which will translate from 111.111.111.214 to 192.168.1.214.
I think you might also need to use an address book entry whereby you put the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Config Question
Yes that makes sense. And the policy pre srx was like this. But I am
almost positive I read somewhere the srx was different in that the
policy is looked at post NAT and so the private ip should be used.
I will give that a shot though.
Brendan Mannella
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Mobile: 412.592.7848
Efax: 412.202.7094
On Jun 21, 2010, at 12:50 PM, Stefan Fouant sfou...@shortestpathfirst.net
wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming
traffic
on
the ports i opened below on the policies. Anyone have any ideas
what i am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214:
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector
off into
the NAT policy which will translate from 111.111.111.214 to
192.168.1.214.
I think you might also need to use an address book entry whereby you
put the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Config Question
Your rules actually seem fine at a glance. Are those the only rules in your
system? No deny that might otherwise be blocking the traffic? I also
migrated from ScreenOS and ditched all the old catch-all denies that I had
at the bottom of zone policies because they don't work the same way in JunOS
land.
You're right, you run the policies against the post-translated address, not
the pre-translated. The NAT is separate entirely from policies.
scott
On Mon, Jun 21, 2010 at 12:54 PM, Brendan Mannella bmanne...@teraswitch.com
wrote:
Yes that makes sense. And the policy pre srx was like this. But I am almost
positive I read somewhere the srx was different in that the policy is looked
at post NAT and so the private ip should be used.
I will give that a shot though.
Brendan Mannella
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Mobile: 412.592.7848
Efax: 412.202.7094
On Jun 21, 2010, at 12:50 PM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming traffic
on
the ports i opened below on the policies. Anyone have any ideas what i am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214:
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector off
into
the NAT policy which will translate from 111.111.111.214 to 192.168.1.214.
I think you might also need to use an address book entry whereby you put
the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
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] SRX Config Question
Nope, i actually dont see any deny statements at all. Does the system, just
deny everything thats not defined as allowed? Any other thing i should look at?
Brendan Mannella
President and CEO
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Toll-Free: 866.583.6338
Mobile: 412-592-7848
Efax: 412.202.7094
- Original Message -
From: Scott T. Cameron routeh...@gmail.com
To: juniper-nsp juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 1:35:06 PM
Subject: Re: [j-nsp] SRX Config Question
Your rules actually seem fine at a glance. Are those the only rules in your
system? No deny that might otherwise be blocking the traffic? I also
migrated from ScreenOS and ditched all the old catch-all denies that I had
at the bottom of zone policies because they don't work the same way in JunOS
land.
You're right, you run the policies against the post-translated address, not
the pre-translated. The NAT is separate entirely from policies.
scott
On Mon, Jun 21, 2010 at 12:54 PM, Brendan Mannella bmanne...@teraswitch.com
wrote:
Yes that makes sense. And the policy pre srx was like this. But I am almost
positive I read somewhere the srx was different in that the policy is looked
at post NAT and so the private ip should be used.
I will give that a shot though.
Brendan Mannella
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Mobile: 412.592.7848
Efax: 412.202.7094
On Jun 21, 2010, at 12:50 PM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming traffic
on
the ports i opened below on the policies. Anyone have any ideas what i am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214:
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector off
into
the NAT policy which will translate from 111.111.111.214 to 192.168.1.214.
I think you might also need to use an address book entry whereby you put
the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Config Question
The system does default deny if you haven't specified a default policy
action.
set security policies default-policy permit-all
As far as the policy is concerned, the policy is applied AFTER destination
nat is performed and BEFORE source nat is performed.
What is the output of 'show security policies' or 'show security policies
from-zone untrust to-zone trust'?
-Ben
On Mon, Jun 21, 2010 at 1:18 PM, Brendan Mannella
bmanne...@teraswitch.comwrote:
Nope, i actually dont see any deny statements at all. Does the system, just
deny everything thats not defined as allowed? Any other thing i should look
at?
Brendan Mannella
President and CEO
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Toll-Free: 866.583.6338
Mobile: 412-592-7848
Efax: 412.202.7094
- Original Message -
From: Scott T. Cameron routeh...@gmail.com
To: juniper-nsp juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 1:35:06 PM
Subject: Re: [j-nsp] SRX Config Question
Your rules actually seem fine at a glance. Are those the only rules in
your
system? No deny that might otherwise be blocking the traffic? I also
migrated from ScreenOS and ditched all the old catch-all denies that I had
at the bottom of zone policies because they don't work the same way in
JunOS
land.
You're right, you run the policies against the post-translated address, not
the pre-translated. The NAT is separate entirely from policies.
scott
On Mon, Jun 21, 2010 at 12:54 PM, Brendan Mannella
bmanne...@teraswitch.com
wrote:
Yes that makes sense. And the policy pre srx was like this. But I am
almost
positive I read somewhere the srx was different in that the policy is
looked
at post NAT and so the private ip should be used.
I will give that a shot though.
Brendan Mannella
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Mobile: 412.592.7848
Efax: 412.202.7094
On Jun 21, 2010, at 12:50 PM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming
traffic
on
the ports i opened below on the policies. Anyone have any ideas what i
am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214:
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector off
into
the NAT policy which will translate from 111.111.111.214 to
192.168.1.214.
I think you might also need to use an address book entry whereby you put
the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
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
___
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] SRX Config Question
I noticed you didn't include all of the nat config.make sure you have
the from-zone configured for the static nat rule-set...
ex.
set security nat static rule-set natting from zone untrust
set security nat static rule-set natting rule 214 match destination-address
111.111.111.214/32
set security nat static rule-set natting rule 214 then static-nat prefix
192.168.1.214/32
I've also noticed strange things when using . inside of an address-book
address. I use _ instead.
-Ben
On Mon, Jun 21, 2010 at 2:57 PM, ben b benboyd.li...@gmail.com wrote:
The system does default deny if you haven't specified a default policy
action.
set security policies default-policy permit-all
As far as the policy is concerned, the policy is applied AFTER destination
nat is performed and BEFORE source nat is performed.
What is the output of 'show security policies' or 'show security policies
from-zone untrust to-zone trust'?
-Ben
On Mon, Jun 21, 2010 at 1:18 PM, Brendan Mannella
bmanne...@teraswitch.com wrote:
Nope, i actually dont see any deny statements at all. Does the system,
just deny everything thats not defined as allowed? Any other thing i should
look at?
Brendan Mannella
President and CEO
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Toll-Free: 866.583.6338
Mobile: 412-592-7848
Efax: 412.202.7094
- Original Message -
From: Scott T. Cameron routeh...@gmail.com
To: juniper-nsp juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 1:35:06 PM
Subject: Re: [j-nsp] SRX Config Question
Your rules actually seem fine at a glance. Are those the only rules in
your
system? No deny that might otherwise be blocking the traffic? I also
migrated from ScreenOS and ditched all the old catch-all denies that I had
at the bottom of zone policies because they don't work the same way in
JunOS
land.
You're right, you run the policies against the post-translated address,
not
the pre-translated. The NAT is separate entirely from policies.
scott
On Mon, Jun 21, 2010 at 12:54 PM, Brendan Mannella
bmanne...@teraswitch.com
wrote:
Yes that makes sense. And the policy pre srx was like this. But I am
almost
positive I read somewhere the srx was different in that the policy is
looked
at post NAT and so the private ip should be used.
I will give that a shot though.
Brendan Mannella
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Mobile: 412.592.7848
Efax: 412.202.7094
On Jun 21, 2010, at 12:50 PM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming
traffic
on
the ports i opened below on the policies. Anyone have any ideas what i
am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214:
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector off
into
the NAT policy which will translate from 111.111.111.214 to
192.168.1.214.
I think you might also need to use an address book entry whereby you
put
the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
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
___
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] SRX Config Question
I have to double check but i might have missed
set security nat static rule-set natting from zone untrust... I will double
check and update the list.
- Original Message -
From: ben b benboyd.li...@gmail.com
To: Brendan Mannella bmanne...@teraswitch.com
Cc: Scott T. Cameron routeh...@gmail.com, juniper-nsp
juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 4:10:43 PM
Subject: Re: [j-nsp] SRX Config Question
I noticed you didn't include all of the nat config.make sure you have the
from-zone configured for the static nat rule-set...
- Original Message -
From: ben b benboyd.li...@gmail.com
To: Brendan Mannella bmanne...@teraswitch.com
Cc: Scott T. Cameron routeh...@gmail.com, juniper-nsp
juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 4:10:43 PM
Subject: Re: [j-nsp] SRX Config Question
I noticed you didn't include all of the nat config.make sure you have the
from-zone configured for the static nat rule-set...
ex.
set security nat static rule-set natting from zone untrust
set security nat static rule-set natting rule 214 match destination-address
111.111.111.214/32
set security nat static rule-set natting rule 214 then static-nat prefix
192.168.1.214/32
I've also noticed strange things when using . inside of an address-book
address. I use _ instead.
-Ben
On Mon, Jun 21, 2010 at 2:57 PM, ben b benboyd.li...@gmail.com wrote:
The system does default deny if you haven't specified a default policy
action.
set security policies default-policy permit-all
As far as the policy is concerned, the policy is applied AFTER destination nat
is performed and BEFORE source nat is performed.
What is the output of 'show security policies' or 'show security policies
from-zone untrust to-zone trust'?
-Ben
On Mon, Jun 21, 2010 at 1:18 PM, Brendan Mannella bmanne...@teraswitch.com
wrote:
Nope, i actually dont see any deny statements at all. Does the system, just
deny everything thats not defined as allowed? Any other thing i should look at?
Brendan Mannella
President and CEO
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Toll-Free: 866.583.6338
Mobile: 412-592-7848
Efax: 412.202.7094
- Original Message -
From: Scott T. Cameron routeh...@gmail.com
To: juniper-nsp juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 1:35:06 PM
Subject: Re: [j-nsp] SRX Config Question
Your rules actually seem fine at a glance. Are those the only rules in your
system? No deny that might otherwise be blocking the traffic? I also
migrated from ScreenOS and ditched all the old catch-all denies that I had
at the bottom of zone policies because they don't work the same way in JunOS
land.
You're right, you run the policies against the post-translated address, not
the pre-translated. The NAT is separate entirely from policies.
scott
On Mon, Jun 21, 2010 at 12:54 PM, Brendan Mannella bmanne...@teraswitch.com
wrote:
Yes that makes sense. And the policy pre srx was like this. But I am almost
positive I read somewhere the srx was different in that the policy is looked
at post NAT and so the private ip should be used.
I will give that a shot though.
Brendan Mannella
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Mobile: 412.592.7848
Efax: 412.202.7094
On Jun 21, 2010, at 12:50 PM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto: juniper-nsp-
boun...@puck.nether.net ] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming traffic
on
the ports i opened below on the policies. Anyone have any ideas what i am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214 :
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector off
into
the NAT policy which will translate from 111.111.111.214 to 192.168.1.214.
I think you might also need to use an address book entry whereby you put
the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
Re: [j-nsp] SRX Config Question
the rule-set won't be natting, it'll be whatever rule-set rule 214
exists in
-Ben
On Mon, Jun 21, 2010 at 3:13 PM, Brendan Mannella
bmanne...@teraswitch.comwrote:
I have to double check but i might have missed
set security nat static rule-set natting from zone untrust... I will double
check and update the list.
- Original Message -
From: ben b benboyd.li...@gmail.com
To: Brendan Mannella bmanne...@teraswitch.com
Cc: Scott T. Cameron routeh...@gmail.com, juniper-nsp
juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 4:10:43 PM
Subject: Re: [j-nsp] SRX Config Question
I noticed you didn't include all of the nat config.make sure you have
the from-zone configured for the static nat rule-set...
ex.
set security nat static rule-set natting from zone untrust
set security nat static rule-set natting rule 214 match
destination-address 111.111.111.214/32
set security nat static rule-set natting rule 214 then static-nat prefix
192.168.1.214/32
I've also noticed strange things when using . inside of an address-book
address. I use _ instead.
-Ben
On Mon, Jun 21, 2010 at 2:57 PM, ben b benboyd.li...@gmail.com wrote:
The system does default deny if you haven't specified a default policy
action.
set security policies default-policy permit-all
As far as the policy is concerned, the policy is applied AFTER destination
nat is performed and BEFORE source nat is performed.
What is the output of 'show security policies' or 'show security policies
from-zone untrust to-zone trust'?
-Ben
On Mon, Jun 21, 2010 at 1:18 PM, Brendan Mannella
bmanne...@teraswitch.com wrote:
Nope, i actually dont see any deny statements at all. Does the system,
just deny everything thats not defined as allowed? Any other thing i should
look at?
Brendan Mannella
President and CEO
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Toll-Free: 866.583.6338
Mobile: 412-592-7848
Efax: 412.202.7094
- Original Message -
From: Scott T. Cameron routeh...@gmail.com
To: juniper-nsp juniper-nsp@puck.nether.net
Sent: Monday, June 21, 2010 1:35:06 PM
Subject: Re: [j-nsp] SRX Config Question
Your rules actually seem fine at a glance. Are those the only rules in
your
system? No deny that might otherwise be blocking the traffic? I also
migrated from ScreenOS and ditched all the old catch-all denies that I
had
at the bottom of zone policies because they don't work the same way in
JunOS
land.
You're right, you run the policies against the post-translated address,
not
the pre-translated. The NAT is separate entirely from policies.
scott
On Mon, Jun 21, 2010 at 12:54 PM, Brendan Mannella
bmanne...@teraswitch.com
wrote:
Yes that makes sense. And the policy pre srx was like this. But I am
almost
positive I read somewhere the srx was different in that the policy is
looked
at post NAT and so the private ip should be used.
I will give that a shot though.
Brendan Mannella
TeraSwitch Networks Inc.
Office: 412.224.4333 x303
Mobile: 412.592.7848
Efax: 412.202.7094
On Jun 21, 2010, at 12:50 PM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Brendan Mannella
Sent: Monday, June 21, 2010 11:20 AM
To: juniper-nsp
Subject: [j-nsp] SRX Config Question
So main issue is the firewall does not seem to allow any incoming
traffic
on
the ports i opened below on the policies. Anyone have any ideas what
i am
missing?
Hi Brendan,
How are things? I could be wrong, but I believe the issue is with the
untrust-to-trust policy where you are matching on destination-address
192.168.1.214:
from-zone untrust to-zone trust {
policy 240-51 {
match {
source-address any;
destination-address 192.168.1.214;
application [ rdp junos-dns-udp junos-ftp junos-http junos-https
junos-ms-sql ];
}
I believe in order for this to work you are going to need to make the
destination-address 111.111.111.214. This will cause it to vector off
into
the NAT policy which will translate from 111.111.111.214 to
192.168.1.214.
I think you might also need to use an address book entry whereby you
put
the
pre-natted address (111.111.111.214) into your trust zone as well.
Feel free to contact me offline if you'd like additional assistance.
HTHs.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
We leverage the EX3200 and 4200's extensively in our network, for edge, core, and access. As far as edge (ISP connectivity) we use EX3200's in pairs- each EX3200 has a separate peer session to each upstream provider, providing redundancy (high-availability) without merging the two units as one logical unit. This makes zero-downtime maintenance easier at your edge, as upgrading a stacked chassis involves rebooting all the devices at once. And they're cheaper than their 4200 counterparts. I'm elated at the 4200's performance in our core- I think what may be of use to you is a comparison to equivalent Cisco gear- in this light we just replaced a two-chassis 3750G stack with a two-chassis EX4200 stack (we stack them to take advantage of port densities with staggered growth in the core), and we are glad we did so. The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the Catalyst 3xxx series only actually supports 8 RVI's, and they don't publish this (you will find it when configuring the profile of the device). This created a problem with 10 OSPF interfaces (and 15 other non-OPSF interfaces) on the Cisco. Upon a link-state change on any of the Cisco's OSPF-configured interfaces, the CPU would crank up to 100% and the stacked device throughput was ground to a crawl (80%+ traffic loss). Changing the configuration in the OSPF subsection, elimination of the problem interface (flapping or not) from the configuration, or a complete reboot would solve the problem- none of which are attractive solutions to a problem we shouldn't have been having in the first place. Compare this to a two-chassis EX4200-48T stack we have in another part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and the stacked device hasn't given us any grief. They cost us 1/3 less than the Cisco solution, and doubled the port density (the Ciscos had 24 and the Junipers we got have 48 ports). There are platform limitations, like memory, which may cause you to be a little more exotic on BGP route selection, but the Catalyst 3750G's have even less memory as I recall. Overall they have been extremely good for our network, and have caused me to swear off Cisco completely. Hope this provides some insight. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent HENRY Sent: Monday, June 21, 2010 6:29 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? Regards ___ 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] AS Path regular expression for Null AS
Just a guess but try ^ $ to match beginning and end with nothing in
between. Or you can match against ^ 1234{0,1} $ which matches the
null as or a single occurrence of only AS 1234 (just insert any unused
AS).
-J Scott
On Mon, Jun 21, 2010 at 3:10 PM, Leah Lynch leah.ly...@clearwire.com wrote:
I cannot seem to get any of the regular expressions that I know of for null
AS to work. I have tried () and * and neither expression returns any
results. Does anyone out there have a known working expression for this on
M/MX routers?
Leah
This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.
___
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] EX 4200 stability with BGP and OSPF redistribution ?
From: Dan Farrell da...@appliedi.net Date: Mon, 21 Jun 2010 14:33:50 -0700 Sender: juniper-nsp-boun...@puck.nether.net With 10.0.S1.1 the only headaches we encounter with our loaded configuration on a 2-member 4200 stack (~850+ RVI's total, some on OSPF) is the time it takes for the configuration to be checked or implemented from the CLI. The wait times from commit to actually being returned to the command prompt can be up to twenty seconds sometimes. At first this scared me (making large changes in a production environment... then ... wait.) but now I'm accustomed to it. Guess you never had a heavily configured M10 or M20 if you think that 20 seconds is a long time to commit. I'll admit that I have gotten spoiled by the speed of the MX series, though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS Path regular expression for Null AS
Hi,
Everything in the junos doc works as expected and I have tried a lot
of combs, if you are using this procedure to select only local BGP
routes do not forget to reject everything else too, because the
default accept policy in the junos BGP, not sure if this is the
problem.
Below a Juniper example that worked fine for me:
[edit policy-options]
null-as ();
policy-statement only-my-routes {
term just-my-as {
from {
protocol bgp;
as-path null-as;
}
then accept;
}
term nothing-else {
then reject;
}
}
protocol {
bgp {
neighbor 10.2.2.6 {
export only-my-routes;
}
}
}
On Mon, Jun 21, 2010 at 7:39 PM, Judah Scott judah.scott@gmail.com wrote:
Just a guess but try ^ $ to match beginning and end with nothing in
between. Or you can match against ^ 1234{0,1} $ which matches the
null as or a single occurrence of only AS 1234 (just insert any unused
AS).
-J Scott
On Mon, Jun 21, 2010 at 3:10 PM, Leah Lynch leah.ly...@clearwire.com wrote:
I cannot seem to get any of the regular expressions that I know of for null
AS to work. I have tried () and * and neither expression returns any
results. Does anyone out there have a known working expression for this on
M/MX routers?
Leah
This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review, use, distribution or disclosure by
others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
email and delete all copies of this message.
___
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
--
Rio de Janeiro Ciclopata! Coração Brasiliense e Floripano!
Twitter: http://www.twitter.com/curupas
Orkut: http://www.orkut.com.br/Main#Profile?rl=mpuid=6915582353112941469
Vai Encarar? http://www.vaiencarar.com.br
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
