Re: [j-nsp] MX80 and MIC-3D-4XGE-XFP
It's only supported on MPC2 cards, so officially it will not work (MX80 is closer to MPC1 for its MIC slots.) The 2XGE is almost half the price of the 4XGE list, so you may want to talk to your reseller if the 4 is coming in cheaper. On May 20, 2013, at 4:41 PM, Chris Rogers wrote: > Hello everyone, > > Little curious, has anyone ever tried to use a MIC-3D-4XGE-XFP in a MX80? > > The MIC-3D-2XGE-XFP is listed as the compatible part, but is significantly > more expensive... > > Thanks! > -Chris > ___ > 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] QFX vs EX4550 as collapsed core
The QFX3500 does support IPv6 as of 12.3X50-D10. Just FYI. -PD -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tore Anderson Sent: Friday, April 26, 2013 1:44 AM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] QFX vs EX4550 as collapsed core * Andy Litzinger > Hi, we're deploying to a new environment where there will be about > 500 virtual servers hosted completely on Cisco UCS. The Core would > mostly be hosting uplinks to the UCS Fabric Interconnects (End Host > Mode), inter-vlan routing and links to service appliances (FW/LB) and > the Internet edge routers. Nearly all of our traffic is North/South > from server to LB to internet or server to LB to another server. The > core would mostly be routing a few (dozens at most) routes so RIB/FIB > size shouldn't be a great concern. Most links will be 10G, but there > are a handful of 1G management links. > > We're considering either the QFX3500 ( x2) or the EX4450 (x2 as a VC) > to fill this role (or potentially Cisco Nexus 6001) > > * are there any L3 benefits of one over the other? I haven't found > clear numbers in the datasheets We're using 2-node EX4500 VCs in much the same way as you describe as core switches in a couple of our data centres. We're quite happy with them - they've been trouble free so far (knock on wood). We briefly considered using the QFX3500s instead for a recent deployment but quickly disqualified them when we realised they do not support IPv6 at all. The EXes support IPv6 fairly well, although according to the specs they have an upper limit of 1000 IPv6 neighbour entries, which is disconcertingly small - at least if they're handling server LANs and not just router-to-router links. Due to hosts having both a link-local address in addition to the global one, 1000 entries will only handle 500 hosts. Tore ___ 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] Problem with EX-UM-2X4SFPs in EX4200-48Ts running version 12.1R2.9
On that switch stack, try a "show interfaces diagnostics optics
xe-blah/blah/blah" and see if the optic is recognized or ? when its plugged
into port 0. What does a "show interface extensive xe-blah/blah/blah" show
when its plugged in?
One other note, I've had to reboot an EX4200 after switching the UM mode to
10G before it would come up. Can't imagine that it would come up half way
though.
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dave Peters -
Terabit Systems
Sent: Wednesday, March 27, 2013 5:18 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Problem with EX-UM-2X4SFPs in EX4200-48Ts running version
12.1R2.9
Hi all--
I've got two EX4200s where each port 0 on the 2x4SFPs doesn't work. Port 2
sends 10G traffic fine, but when I swing the same cable to port 0, it just
doesn't come up at all. I've attached the config below, if that helps.
Hoping someone here will scan it and tell me why I'm stupid. I'm running
12.1R2.9 on a VC. Everything works but port 0 on each switch.
Thanks in advance. Here's the config. :
{master:2}
jding@SJOSWT-R10X-BOTTOM> show chassis hardware detail Hardware inventory:
Item Version Part number Serial number Description
ChassisBP0208377099 Virtual Chassis
Routing Engine 2 REV 11 750-021254 BP0208377099 EX4200-48T, 8 POE
Routing Engine 2 BP0208377099 EX4200-48T, 8 POE
Routing Engine 5 REV 11 750-021254 BP0208369164 EX4200-48T, 8 POE
Routing Engine 5 BP0208369164 EX4200-48T, 8 POE
FPC 2REV 11 750-021254 BP0208377099 EX4200-48T, 8 POE
CPU BUILTIN BUILTIN FPC CPU
PIC 0 BUILTIN BUILTIN 48x 10/100/1000
Base-T
PIC 1 REV 07 711-026017 CH0212417011 2x 10GE SFP+
Xcvr 2 REV 01 740-030077 APF11290025T0JSFP+-10G-CU3M
Power Supply 0 REV 03 740-020957 AT0508274033 PS 320W AC
Power Supply 1 REV 05 740-020957 AT0512293104 PS 320W AC
Fan Tray Fan Tray
FPC 5REV 11 750-021254 BP0208369164 EX4200-48T, 8 POE
CPU BUILTIN BUILTIN FPC CPU
PIC 0 BUILTIN BUILTIN 48x 10/100/1000
Base-T
PIC 1 REV 07 711-026017 CH0212417019 2x 10GE SFP+
Xcvr 2 REV 01 740-030077 APF11290025T9DSFP+-10G-CU3M
Power Supply 0 REV 03 740-020957 AT0508328564 PS 320W AC
Power Supply 1 REV 05 740-020957 AT0512293966 PS 320W AC
Fan Tray Fan Tray
{master:2}
jding@SJOSWT-R10X-BOTTOM> show configuration | no-more ## Last commit:
2013-03-22 15:57:32 PDT by jding version 12.1R2.9; system {
host-name __;
time-zone America/Los_Angeles;
authentication-order [ radius password ];
root-authentication {
encrypted-password "$1$zG2TUiCT$oRAiEUYXgWXeHtIzcHP7c/"; ##
SECRET-DATA
}
radius-server {
10.101.21.41 {
secret "$9$DFkfQF39O1h8XJDkqzFCtu"; ## SECRET-DATA
source-address 10.101.254.4;
}
}
radius-options {
password-protocol mschap-v2;
}
login {
user admin {
uid 2000;
class super-user;
authentication {
encrypted-password "$1$RFVvT28N$.2qN9/TVJYUZ39WHDjd0e/"; ##
SECRET-DATA
}
}
user remote {
full-name "All Radius users";
uid 2001;
class super-user;
}
}
services {
ssh {
root-login allow;
protocol-version v2;
}
}
syslog {
user * {
any emergency;
}
file messages {
any info;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
commit synchronize;
ntp {
server 10.101.0.1;
server 10.101.0.2;
}
}
chassis {
redundancy {
graceful-switchover;
}
aggregated-devices {
ethernet {
device-count 4;
}
}
fpc 2 {
pic 1 {
sfpplus {
pic-mode 10g;
}
}
}
fpc 5 {
pic 1 {
sfpplus {
pic-mode 10g;
}
}
}
}
interfaces {
ge-2/0/0 {
unit 0 {
family ethernet-switching {
vlan {
members Management;
}
}
}
}
ge-2/0/1 {
unit 0 {
family ethernet-switching {
vlan {
members CorpInside;
}
}
}
}
ge-2/0/2 {
unit 0 {
family ethernet-switching;
Re: [j-nsp] Help needed with IPSEC VPN on J-Series
I'd start to suspect the other side of the tunnel. What is your peer device?
On Mar 20, 2013, at 11:55 AM, Bill Sandiford
wrote:
> So I added the following configuration in. The syntax was a little
> different than what you sent, but basically the same thing (I think).
>
>> show configuration security policies
> from-zone trust to-zone trust {
>policy policy1 {
>match {
>source-address any;
>destination-address any;
>application any;
>}
>then {
>permit;
>}
>}
> }
> default-policy {
>permit-all;
> }
>
>
>
> Šbut still not working :(
>
>
>
>
> On 2013-03-20 12:29 PM, "Aaron Dewell" wrote:
>
>>
>> You'll also need a policy which allows traffic from trust to trust, i.e.:
>>
>> set security policies from-zone trust to-zone trust match source-address
>> any
>> set security policies from-zone trust to-zone trust match
>> destination-address any
>> set security policies from-zone trust to-zone trust match protocol any
>> set security policies from-zone trust to-zone trust then permit
>>
>> Cross-interface traffic is not allowed by default even within the same
>> zone.
>>
>> On Mar 20, 2013, at 10:16 AM, Bill Sandiford wrote:
>>> For the most part this J-series has always just acted as a router
>>> without
>>> any tunnels per se. As such, I have always had all interfaces in the
>>> trust zone, as follows
>>>
>>> zones {
>>> security-zone trust {
>>> tcp-rst;
>>> host-inbound-traffic {
>>> system-services {
>>> any-service;
>>> }
>>> protocols {
>>> all;
>>> }
>>> }
>>> interfaces {
>>> all;
>>> }
>>> }
>>> }
>>>
>>> Will this accomplish what you are suggesting?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2013-03-20 11:52 AM, "Patrick Dickey" wrote:
>>>
>>>> I don't remember if the J series behaves exactly like the SRXs when it
>>>> comes
>>>> to IPSec, but if it is make sure to put the st0.x interface into a
>>>> security
>>>> zone and have a security policy allowing the traffic.
>>>>
>>>> I believe that's only a requirement if you're running the enhanced
>>>> services/security code on the J, but I think you have to be to get
>>>> IPSec.
>>>>
>>>> HTH
>>>>
>>>>
>>>> -Original Message-
>>>> From: juniper-nsp-boun...@puck.nether.net
>>>> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Bill
>>>> Sandiford
>>>> Sent: Wednesday, March 20, 2013 8:47 AM
>>>> To: juniper-nsp@puck.nether.net
>>>> Subject: [j-nsp] Help needed with IPSEC VPN on J-Series
>>>>
>>>> Hi All,
>>>>
>>>> I need some help with an IPSEC tunnel that I just can't seem to get
>>>> working
>>>> on a J-6350. I have been able to get the tunnels to come up, but can't
>>>> seem
>>>> to pass traffic over the tunnels
>>>>
>>>> I've done the usual things. I've created an st0.0 interface and bound
>>>> it
>>>> to
>>>> the tunnel using the bind-interface command. I've created a static
>>>> route
>>>> and pointed it at the st0.0 interface. I just can't seem to get
>>>> traffic
>>>> to
>>>> pass over the tunnel.
>>>>
>>>> Any help or suggestions would be appreciated. I'm also willing to put
>>>> a
>>>> $$$
>>>> bounty on this for anyone that is willing to help me get it working via
>>>> teamviewer.
>>>>
>>>> Regards,
>>>> Bill
>>>>
>>>>
>>>> ___
>>>> 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] Help needed with IPSEC VPN on J-Series
I don't remember if the J series behaves exactly like the SRXs when it comes to IPSec, but if it is make sure to put the st0.x interface into a security zone and have a security policy allowing the traffic. I believe that's only a requirement if you're running the enhanced services/security code on the J, but I think you have to be to get IPSec. HTH -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Bill Sandiford Sent: Wednesday, March 20, 2013 8:47 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Help needed with IPSEC VPN on J-Series Hi All, I need some help with an IPSEC tunnel that I just can't seem to get working on a J-6350. I have been able to get the tunnels to come up, but can't seem to pass traffic over the tunnels I've done the usual things. I've created an st0.0 interface and bound it to the tunnel using the bind-interface command. I've created a static route and pointed it at the st0.0 interface. I just can't seem to get traffic to pass over the tunnel. Any help or suggestions would be appreciated. I'm also willing to put a $$$ bounty on this for anyone that is willing to help me get it working via teamviewer. Regards, Bill ___ 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] juniper cisco switch interconnection
Hi Dale- As far as I know, it's a Cisco interop issue. Cisco only sends certain info to the standard multicast address on VLAN 1. On all other VLANs, it sends info only to the Cisco multicast address (not the standard RFC address). At least that's how I remember the problem could be wrong. Patrick -Original Message- From: dale.s...@gmail.com [mailto:dale.s...@gmail.com] On Behalf Of Dale Shaw Sent: Monday, December 10, 2012 2:50 PM To: Patrick Dickey Cc: Juniper List Subject: Re: [j-nsp] juniper cisco switch interconnection Hi Patrick, On Tue, Dec 11, 2012 at 8:20 AM, Patrick Dickey wrote: > Just a quick note: if you need multiple vlan STP (like what PVST+ > has...), use VSTP on the Juniper. Ensure that VLAN 1 is on any trunk > line between the Cisco and the Juniper. You don't need to have traffic > there, but PVST+ uses VLAN 1 and VSTP will listen on VLAN 1 for STP > information. If it's not configured, all kinds of strangeness occurs. Your comment reminded me of some VSTP "strangeness" I'd seen previously. Do you know if VSTP "wants" VLAN 1 even in a pure Juniper environment? Or is this only required for Cisco PVST+ interop? Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper cisco switch interconnection
Just a quick note: if you need multiple vlan STP (like what PVST+ has...), use VSTP on the Juniper. Ensure that VLAN 1 is on any trunk line between the Cisco and the Juniper. You don't need to have traffic there, but PVST+ uses VLAN 1 and VSTP will listen on VLAN 1 for STP information. If it's not configured, all kinds of strangeness occurs. YMMV -Patrick -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Benny Amorsen Sent: Monday, December 10, 2012 2:16 PM To: harbor235 Cc: Juniper List Subject: Re: [j-nsp] juniper cisco switch interconnection harbor235 writes: > Has anyone connected a Juniper EX series switch with a Cisco switch (I > have a 3550)? Yes > Do you use a standard crossover cable? MDIX? I have only attempted 1Gbps, that just worked with a straight cable. > Any Layer 2 issues with RSTP and PVST+? It seems to work so far... > Any specific configuration required to make it work? Avoid VLAN 1. You can probably make VLAN 1 work if you try, but for me it was easier to simply not use it. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Static NAT - Not working in both directions
I'm a little confused here. Where does the 192.168.17.16 network reside?
The static NAT will only NAT the 192.168.35.200 IP when its initiating
traffic to the FROM zone in the static NAT configuration, not just
generally.
What does a flow from the 192.168.32.x/24 network look like when trying to
get to the 192.168.35.200 (or 192.168.32.5). How about in the reverse?
Patrick
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Oliver Garraux
Sent: Friday, September 07, 2012 5:08 PM
To: Brent Jones
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX Static NAT - Not working in both directions
Brent, Patrick,
Thanks for the replies.
When I change the rule-set to apply to traffic from the user zone, I'm
seeing the same behavior. The source address on traffic from the desktop
(192.168.35.200) out to the rest of the network isn't being NAT'ed. I also
can't initiate connections to 192.168.32.5 from the rest of my network.
I've also tried putting both the user and trust zones in the rule-set.
In that scenario, I can connect to 192.168.32.5 from outside, but the
outgoing traffic from 192.168.35.200 still isn't NAT'ed.
Thanks,
Oliver
-
Oliver Garraux
Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter:
twitter.com/olivergarraux
On Fri, Sep 7, 2012 at 5:34 PM, Brent Jones wrote:
> Try to apply the static NAT policy to zone 'user' and see how that goes.
>
> On Fri, Sep 7, 2012 at 12:22 PM, Oliver Garraux
wrote:
>> Hey,
>>
>> I recently bought an SRX and have been trying the different NAT
>> configuration options to become more familar with JunOS.
>>
>> Static NAT isn't operating quite as I'd expect from the documentation.
>> My understanding is that static NAT should be bidirectional, in that
>> it should translate connections going in both directions.
>>
>> I'm using 192.168.32.0/24 on the interface connected to the rest of
>> my network (ge-0/0/0.100), and 192.168.35.0/24 on vlan.200 on my SRX.
>> ge-0/0/0.100 is in the "trust" zone, and vlan.200 is in the "user"
>> zone.
>>
>> static {
>> rule-set user_to_trust {
>> from zone trust;
>> rule desktop1 {
>> match {
>> destination-address 192.168.32.5/32;
>> }
>> then {
>> static-nat prefix 192.168.35.200/32;
>> }
>> }
>> }
>> }
>> proxy-arp {
>> interface ge-0/0/0.100 {
>> address {
>> 192.168.32.5/32;
>> }
>> }
>> }
>>
>>
>> I'm only seeing it translate connections coming in to the destination
>> address (192.168.32.5). The source address on connections initiated
>> by the "static-nat" address (192.168.35.200 - the address on the
>> desktop sitting behind my SRX) are not being translated to
>> 192.168.32.5. Am I misunderstanding how static NAT works?
>>
>> I've tried using an IP that is routed to the SRX (where no proxy-arp
>> should have been required in that situation). I also don't see the
>> address being translated when I look at these flows in "show security
>> flow session", so I don't think this is an issue with proxy-arp. I'm
>> permitting all traffic between the "user" and "trust" zones (in both
>> directions) in my security policies.
>>
>> Here's one of the flow entries when I try to ping from 192.168.35.200
>> to 192.168.17.16
>>
>> Session ID: 21626, Policy name: permit-all/5, Timeout: 16, Valid
>> In: 192.168.35.200/25622 --> 192.168.17.16/1280;icmp, If: vlan.200,
>> Pkts: 1, Bytes: 60
>> Out: 192.168.17.16/1280 --> 192.168.35.200/25622;icmp, If:
>> ge-0/0/0.100, Pkts: 0, Bytes: 0
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Oliver
>>
>> -
>>
>> Oliver Garraux
>> Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter:
>> twitter.com/olivergarraux
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> Brent Jones
> br...@brentrjones.com
___
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] Multi-proxy IDS on route based VPN (SRX)
I can think of two options: Use GRE so you don't have to worry about the multiple proxy IDs. Not sure this would work for you with multi-site though. You can create multiple proxy-ids using different/several phase 2 tunnels with the same/single phase 1 gateway. This is a bit tedious, but I'd think it could work for you. Patrick -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of mahmoud yasin Sent: Wednesday, August 29, 2012 2:34 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Multi-proxy IDS on route based VPN (SRX) Hi I have SRX and want to setup Site-Site VPN with another vendor (Cisco), but i have the following conditions; - I have more than one site to create VPN with it. - There are multible subnets on each VPN tunnel. - The private Subnets are overlapping (so i have to use NAT over the VPN). based on this i think that i have to go with route based VPN (due to the required NATing), am i right? if so then i have to create multi proxy IDs for each tunnel, but its not supported. is there ane idea about this case?? Regards Mahmoud ___ 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] MX960 AC power strip
Just FYI: The Juniper SKU for the MX c19/c20 power cord is CBL-MX-PWR-C19-C20 if anyone needed it. Patrick From: joel jaeggli To: JA Cc: juniper-nsp@puck.nether.net Sent: Thursday, August 23, 2012 9:08 AM Subject: Re: [j-nsp] MX960 AC power strip On 8/23/12 6:59 AM, 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. we use c19-c20 cables. we have a standard supplier for those so I don't believe we're using a juniper p/n the device (well the whole rack) is fed off two PDUs with a 30a 3 phase service for each > 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 > ___ 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] EX4200 Virtual chassis ??
I'd strongly suggest using virtual chassis (as long as your somewhat current on your Junos version). Virtual Chassis is now a mature technology, and it's much easier to administer than the STP route, (faster, better, stronger) Patrick -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Rachid DHOU Sent: Wednesday, August 22, 2012 11:48 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX4200 Virtual chassis ?? Dear experts, We have two EX4200 switches, mainly used for L2 functionalities. We want to add two new EX4200 Switches and we want to connect them with the old switches. i have two possibilities : * Either, interconnect them and control everything with STP. * or use Virtual chassis. Please advise, what is the best way ? did you try Virtual chassis in EX ? Do you have other options ? *Kind regards,* *Rachid DHOU* ___ 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] Configuring policies on SRX Cluster
You may look at "global policies" on the SRX. It may simplify your configuration (if I'm understanding you correctly.) Patrick From: Shombra Shombra To: juniper-nsp@puck.nether.net Sent: Thursday, August 9, 2012 8:40 AM Subject: [j-nsp] Configuring policies on SRX Cluster Hello, First sorry for my english. I have many clients, one client and services per VLAN. On SRX I try to configure 7 clients and 3 services and 1 WAN, who some client and service has one VLAN and one ZONE. eg: Clients: Client 1 - VLAN 10 - Zone v10-Client-1 Client 2 - VLAN 20 - Zone v20-Client-2 Client 3 - VLAN 30 - Zone v30-Client-3 Client 6 - VLAN 60 - Zone v60-Client-6 Client 7 - VLAN 70 - Zone v70-Client-7 and Services: E-mail - VLAN 100 zone v100-EMAIL DNS - VLAN 200 - zone v200-DNS WEB - VLAN 300 - zone v300-WEB and WAN - reth1.0 - zone WAN if some client need access my e-mail i have to create a policy from v10-Client-1 to v100-EMAIL , if Client-2 need share the e-mail port to the word, I need open 25 for WAN, but if Client-3 have to send a e-mail for Client-2 i need create a policy from zone v30-Client-3 to zone v20-Client-2. if I have 1000 clients, this policies had became a mess. Someone has a solution for my policies to do not get messy? Best regards Carlos A. Bernardi F. ___ 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] Firewall best practices
Morgan- I would take a good hard look at Junos Space's Security Design package. Its has centralized address books, tier'd policy management, config management, and VPN tools (among a ton of other features), all from a single pane of glass. Ask your reseller for a demo or check it out online. The information Juniper is publishing on the website may be a little out of date, but there is more info available to your Juniper sales team. HTH Patrick From: Morgan McLean To: juniper-nsp@puck.nether.net Sent: Monday, June 11, 2012 5:18 PM Subject: [j-nsp] Firewall best practices Hi everyone, I have a question regarding managing policies among multiple sets of firewalls. I don't know what industry standard / best practice is for managing rules among multiple devices. Currently our office has an srx cluster, site A has an edge srx cluster and core srx cluster, and site B has an edge srx cluster and core srx cluster. The edge srx clusters generally interface with border routers or providers directly, IPSEC, DMZ and any outbound 3rd party web filter redirects etc. The core srx clusters handle firewalling between our different environments. Separating search engines, databases, web servers, etc etc. I don't know what the best way to manage the firewall rules is between these sites. I don't think its sustainable to write the same rule on site A core, site A edge, site B edge, site B core. And then managing the address book entries on every device also becomes a hassle, making sure its all synchronized etc. Is there a better method of doing this? I don't even want to think about what happens if I want traffic from the office to route through site A in order to reach site B in the event of a VPN issue between the office and site B directly. Is there a good method for keeping these things managed, like only having the edge firewall for site A manage incoming connections, and let the other sites edge firewall deal with site A's outgoing connections, etc? I'm a mess. If we add two more sites my head might explode. Morgan ___ 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] Rack mounting a EX4200-48PX, concerned about weight
James- I would suggest using the 4 post rack mounts for the EX4200. Juniper has them on the price list. They do sag a little too much for my taste as well, and with the bigger PSUs... yikes! I've seen them after a year on a 2 post stock mount and they were fine physically, though. HTH Patrick -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of James Baker Sent: Tuesday, March 20, 2012 4:20 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Rack mounting a EX4200-48PX, concerned about weight I've got a couple of new EX4200-48PX with dual 930W power supply which have just arrived and I'm quite concerned about the weight of the units in relation to the rack ears. It is the same ears for the EX4200/3200 family. Has anyone racked these before, if so how much sag do you get and do you suggest a shelve underneath? I've seen what a Cisco2811 does and how much it sags and this will be a lot worse. Thanks James ___ 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
