[j-nsp] juniper-nsp Digest, Vol 119, Issue 45

Fri Oct 26 18:19:46 EDT 2012

Any Ideas on using a USB 3/4G modem with the SRX 100 ? 

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of juniper-nsp-request at puck.nether.net
Sent: Friday, October 26, 2012 4:44 PM
To: juniper-nsp at puck.nether.net
Subject: juniper-nsp Digest, Vol 119, Issue 45

Send juniper-nsp mailing list submissions to
	juniper-nsp at puck.nether.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://puck.nether.net/mailman/listinfo/juniper-nsp
or, via email, send a message with subject or body 'help' to
	juniper-nsp-request at puck.nether.net

You can reach the person managing the list at
	juniper-nsp-owner at puck.nether.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of juniper-nsp digest..."

Today's Topics:

   1. Re: Juniper Services Question ? (Alex Arseniev)
   2. Re: L2L SRX - Linux (Michael Loftis)
   3. Re: L2L SRX - Linux (Nick Kritsky)
   4. How reliable is EX multichassis? 3300 and 8200 switches
      (Morgan McLean)
   5. Re: How reliable is EX multichassis? 3300 and 8200 switches
      (Giuliano Medalha)
   6. Re: How reliable is EX multichassis? 3300 and 8200 switches
      (Jeff Wheeler)
   7. Re: How reliable is EX multichassis? 3300 and 8200 switches
      (Morgan McLean)
   8. Re: How reliable is EX multichassis? 3300 and 8200 switches
      (Giuliano Medalha)

----------------------------------------------------------------------

Message: 1
Date: Fri, 26 Oct 2012 18:05:25 +0100
From: "Alex Arseniev" <alex.arseniev at gmail.com>
To: "Vasanth R S" <rsvasantheee at gmail.com>,
	<juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] Juniper Services Question ?
Message-ID: <3A360C4CD5D643EEB9EBFE400DE23A92 at jnpr.net>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original

The service-filter directs matching packets to a particular service-set.
So in a sense, service-filter is executed first because match happens on ingress interface, and service-set execution happens inside AS|MS-PIC|DPC when matching packets have entered the ingress interface+crossed the forwarding plane.
HTH
Rgds
Alex

----- Original Message -----
From: "Vasanth R S" <rsvasantheee at gmail.com>
To: <juniper-nsp at puck.nether.net>
Sent: Friday, October 26, 2012 12:22 PM
Subject: [j-nsp] Juniper Services Question ?

> If you have service-set and service-filter, which one will get serviced
> first ?
>
> set interfaces ge-1/0/0 unit 1 family inet service input service-set 
> ss-nat
> service-filter nat-exclude-input
> set interfaces ge-1/1/0 unit 2 family inet service input service-set 
> ss-nat
> service-filter nat-exclude-input
>
> set firewall family inet service-filter nat-exclude-input term rfc1918 
> from
> destination-address 10.0.0.0/8
> set firewall family inet service-filter nat-exclude-input term rfc1918 
> from
> destination-address 172.16.0.0/12
> set firewall family inet service-filter nat-exclude-input term rfc1918 
> from
> destination-address 192.168.0.0/16
> set firewall family inet service-filter nat-exclude-input term rfc1918 
> then
> skip
> set firewall family inet service-filter nat-exclude-input term public from
> destination-prefix-list -public-nat-exclude
> set firewall family inet service-filter nat-exclude-input term public then
> skip
> set firewall family inet service-filter nat-exclude-input term default 
> then
> service
>
>
> -- 
> Regards,
> Vasanth R S
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

------------------------------

Message: 2
Date: Fri, 26 Oct 2012 10:38:15 -0700
From: Michael Loftis <mloftis at wgops.com>
To: bizza <bizzam at gmail.com>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] L2L SRX - Linux
Message-ID:
	<CAHDg04u1ekXrDKPyaDPfscvz3A5+ZPO0TmWH9pGofARwwaiJRQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Lookup route-based VPN's at Juniper's site, that will give you
everything you need for that side.  For the Linux side the details
depend on your distro, but in general it's simple and straight
forward, just remember to turn on ip_forward and setup firewall rules
appropriately (by default f/ex you'll be able to route packets into
the VPN from anywhere...source routed packets = bad in this case)

On Fri, Oct 26, 2012 at 6:35 AM, bizza <bizzam at gmail.com> wrote:
> Hi,
> I need to configure a lan 2 lan vpn between a srx and a rhel server.
> There is anything I need to know before starting?
> Does anyone has a production l2l and could share the config snippet?
>
> Regards
> Marco
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

------------------------------

Message: 3
Date: Fri, 26 Oct 2012 21:57:55 +0400
From: Nick Kritsky <nick.kritsky at gmail.com>
To: Michael Loftis <mloftis at wgops.com>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] L2L SRX - Linux
Message-ID:
	<CAJ8_BxoshwBhA8HtFWFXYAiXDenjjSUXNL9ESVK=YPF5oqK2yA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

By the way, does anybody know if SRX/Netscreen route-based VPNs use
any sort of transport encapsulation like GRE or IPIP? Or is it just
plain tunnel with 0.0.0.0/0 encryption domain and policy-based
routing?

thanks
Nick

------------------------------

Message: 4
Date: Fri, 26 Oct 2012 11:46:31 -0700
From: Morgan McLean <wrx230 at gmail.com>
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] How reliable is EX multichassis? 3300 and 8200
	switches
Message-ID:
	<CAPiLEQeaZ9SoKXk-tf3-FgfMtxf07mccqCvPwcibp6AsXWoGRQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hey guys,

So I run SRX as my core firewalls, with EX8200's doing core switching and
EX3300's doing access switching. I have two SRX's, two 8208's, and two
3300's at every cabinet. Spanning tree is a pain in my ass, especially
since I have other environments setup the same way, just with smaller
switches. Right now the SRX reth interfaces only come down as legs, not
full mesh. The top of rack switches have only one link active at a time,
legs. The interconnects between the core switches of different environments
are legs, not full mesh due to spanning tree constraints (it closes the lag
center trunk between the core switches).

It would be a lot easier if I could just VC the core and VC the access
switch pairs so that multi-chassis lags can be run everywhere and I can for
the most part cut spanning tree out of the picture and have greater link
fault tolerance. How reliable is VC? I've really done my best to avoid it
up to this point as I try to keep redundant systems as separate as possible
so one doesn't take down the other. Then again, when it comes down to it my
edge and core firewalls are all SRX clusters, so... :) lol

I'm not really sure what kind of information I'm looking for here. I would
just run 20G lags eveywhere instead of having 10G forward/blocking STP
pairs. I don't really know how things work when a device fails, how fast
convergence is, split brain scenarios etc.

Any major lessons learned with this technology? I am aware that with the
8200's I would need the external SRE.

Thanks,
Morgan

------------------------------

Message: 5
Date: Fri, 26 Oct 2012 19:19:05 -0200
From: Giuliano Medalha <giuliano at wztech.com.br>
To: Morgan McLean <wrx230 at gmail.com>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200
	switches
Message-ID:
	<CAMw=8hSgu068fB==xAJ3PDhkp7wfqZ=Tyo136vC_e_yFnZeEFg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Morgan,

We have some cases running EX8200 as a Virtual Chassis, but you will need
the XRE200 External Routing Engines:

http://www.juniper.net/in/en/products-services/switching/ex-series/options/xre200/

Don't forget that you will need the 8 ports (10 gig)  for chassis inter x
connections - EX8200-8XS

It is a very good topology and we have very good performance with not bad
uptime (196 days) right now.

Without STP problems.

We have used a lot of EX4200 pairs (48 port) connected by Virtual Chassis
for Client Access.

2 x 10 giga fiber (1 for each EX4200) connect using Aggregated Ethernet
Interfaces to both EX8200 (10 gig modules)

I really recommend it for you.

Att,

Giuliano

On Fri, Oct 26, 2012 at 4:46 PM, Morgan McLean <wrx230 at gmail.com> wrote:

> Hey guys,
>
> So I run SRX as my core firewalls, with EX8200's doing core switching and
> EX3300's doing access switching. I have two SRX's, two 8208's, and two
> 3300's at every cabinet. Spanning tree is a pain in my ass, especially
> since I have other environments setup the same way, just with smaller
> switches. Right now the SRX reth interfaces only come down as legs, not
> full mesh. The top of rack switches have only one link active at a time,
> legs. The interconnects between the core switches of different environments
> are legs, not full mesh due to spanning tree constraints (it closes the lag
> center trunk between the core switches).
>
> It would be a lot easier if I could just VC the core and VC the access
> switch pairs so that multi-chassis lags can be run everywhere and I can for
> the most part cut spanning tree out of the picture and have greater link
> fault tolerance. How reliable is VC? I've really done my best to avoid it
> up to this point as I try to keep redundant systems as separate as possible
> so one doesn't take down the other. Then again, when it comes down to it my
> edge and core firewalls are all SRX clusters, so... :) lol
>
> I'm not really sure what kind of information I'm looking for here. I would
> just run 20G lags eveywhere instead of having 10G forward/blocking STP
> pairs. I don't really know how things work when a device fails, how fast
> convergence is, split brain scenarios etc.
>
> Any major lessons learned with this technology? I am aware that with the
> 8200's I would need the external SRE.
>
> Thanks,
> Morgan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

------------------------------

Message: 6
Date: Fri, 26 Oct 2012 17:35:42 -0400
From: Jeff Wheeler <jsw at inconcepts.biz>
To: Morgan McLean <wrx230 at gmail.com>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200
	switches
Message-ID:
	<CAPWAtbJ-tEJmqUcGY5iDWF=0FGAh0Jrvt1eKDi2AxUpYBs0T0g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 26, 2012 at 2:46 PM, Morgan McLean <wrx230 at gmail.com> wrote:
> fault tolerance. How reliable is VC? I've really done my best to avoid it

I can't speak to EX3300 specifically, but on EX4200 the VC works very
well.  I have many stacks running for many years, and have had no
stacking-related problems since before Junos 10.4R.

We configure no-split-detection on VCs of two units (like TOR) based
on our guess that it is much more likely one unit will fail
completely, than the likelihood of split-brain happening where both
switches are still working.  If it did happen we would have a fast
time-to-repair, and we think good MTTR is too often overlooked.

-- 
Jeff S Wheeler <jsw at inconcepts.biz> +1 502-523-6989 Mobile
Sr Network Operator  /  Innovative Network Concepts

------------------------------

Message: 7
Date: Fri, 26 Oct 2012 14:36:23 -0700
From: Morgan McLean <wrx230 at gmail.com>
To: Giuliano Medalha <giuliano at wztech.com.br>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200
	switches
Message-ID:
	<CAPiLEQd99Q0e0dJQxcneFi3Q6Wc3FOZOHWUot0iYo31rd8PhUQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I know I need the XRE200, but my question would be why? Why is this the
only EX product requiring external RE's? And also, it looks like you need
two local RE's to be able to connect to two external RE's? Seems
unnecessarily expensive.

Also, are the 8XS required for inter connects? Right now I only have two
8208's each with an 8XS and the 40 port 10g card, but I plan on adding
another 40 port and in the future two additional EX8208's at another site
with two 40 port 10gig cards each, no more 8XS cards. I would like to
spread the interconnections across two cards to protect against a module
failure.

Morgan

On Fri, Oct 26, 2012 at 2:19 PM, Giuliano Medalha <giuliano at wztech.com.br>wrote:

> Morgan,
>
> We have some cases running EX8200 as a Virtual Chassis, but you will need
> the XRE200 External Routing Engines:
>
>
> http://www.juniper.net/in/en/products-services/switching/ex-series/options/xre200/
>
> Don't forget that you will need the 8 ports (10 gig)  for chassis inter x
> connections - EX8200-8XS
>
> It is a very good topology and we have very good performance with not bad
> uptime (196 days) right now.
>
> Without STP problems.
>
> We have used a lot of EX4200 pairs (48 port) connected by Virtual Chassis
> for Client Access.
>
> 2 x 10 giga fiber (1 for each EX4200) connect using Aggregated Ethernet
> Interfaces to both EX8200 (10 gig modules)
>
> I really recommend it for you.
>
> Att,
>
> Giuliano
>
>
>
>
> On Fri, Oct 26, 2012 at 4:46 PM, Morgan McLean <wrx230 at gmail.com> wrote:
>
>> Hey guys,
>>
>> So I run SRX as my core firewalls, with EX8200's doing core switching and
>> EX3300's doing access switching. I have two SRX's, two 8208's, and two
>> 3300's at every cabinet. Spanning tree is a pain in my ass, especially
>> since I have other environments setup the same way, just with smaller
>> switches. Right now the SRX reth interfaces only come down as legs, not
>> full mesh. The top of rack switches have only one link active at a time,
>> legs. The interconnects between the core switches of different
>> environments
>> are legs, not full mesh due to spanning tree constraints (it closes the
>> lag
>> center trunk between the core switches).
>>
>> It would be a lot easier if I could just VC the core and VC the access
>> switch pairs so that multi-chassis lags can be run everywhere and I can
>> for
>> the most part cut spanning tree out of the picture and have greater link
>> fault tolerance. How reliable is VC? I've really done my best to avoid it
>> up to this point as I try to keep redundant systems as separate as
>> possible
>> so one doesn't take down the other. Then again, when it comes down to it
>> my
>> edge and core firewalls are all SRX clusters, so... :) lol
>>
>> I'm not really sure what kind of information I'm looking for here. I would
>> just run 20G lags eveywhere instead of having 10G forward/blocking STP
>> pairs. I don't really know how things work when a device fails, how fast
>> convergence is, split brain scenarios etc.
>>
>> Any major lessons learned with this technology? I am aware that with the
>> 8200's I would need the external SRE.
>>
>> Thanks,
>> Morgan
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>

------------------------------

Message: 8
Date: Fri, 26 Oct 2012 19:44:27 -0200
From: Giuliano Medalha <giuliano at wztech.com.br>
To: Morgan McLean <wrx230 at gmail.com>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200
	switches
Message-ID:
	<CAMw=8hTZ0JtQk=Z=-zQHSD0xGu9VF2GiM8MpAqVaw02QeB-NDQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Morgan,

I really dont know why JUNIPER did this kind of crazy environment with
EX8200.

Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L
I think you do not need the external routing engines for virtual chassis.

About the line card ... the information I have is that you need 8 port line
card to interconnect chassis.

Take a look:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/line-cards-ex8200.html

You cannot use 40 port 10 gig to interconnect.. maybe in future with a new
JUNOS code you could use it.

I will try to check it.

Att,

Giuliano

On Fri, Oct 26, 2012 at 7:36 PM, Morgan McLean <wrx230 at gmail.com> wrote:

> I know I need the XRE200, but my question would be why? Why is this the
> only EX product requiring external RE's? And also, it looks like you need
> two local RE's to be able to connect to two external RE's? Seems
> unnecessarily expensive.
>
> Also, are the 8XS required for inter connects? Right now I only have two
> 8208's each with an 8XS and the 40 port 10g card, but I plan on adding
> another 40 port and in the future two additional EX8208's at another site
> with two 40 port 10gig cards each, no more 8XS cards. I would like to
> spread the interconnections across two cards to protect against a module
> failure.
>
> Morgan
>
> On Fri, Oct 26, 2012 at 2:19 PM, Giuliano Medalha <giuliano at wztech.com.br>wrote:
>
>> Morgan,
>>
>> We have some cases running EX8200 as a Virtual Chassis, but you will need
>> the XRE200 External Routing Engines:
>>
>>
>> http://www.juniper.net/in/en/products-services/switching/ex-series/options/xre200/
>>
>> Don't forget that you will need the 8 ports (10 gig)  for chassis inter x
>> connections - EX8200-8XS
>>
>> It is a very good topology and we have very good performance with not bad
>> uptime (196 days) right now.
>>
>> Without STP problems.
>>
>> We have used a lot of EX4200 pairs (48 port) connected by Virtual Chassis
>> for Client Access.
>>
>> 2 x 10 giga fiber (1 for each EX4200) connect using Aggregated Ethernet
>> Interfaces to both EX8200 (10 gig modules)
>>
>> I really recommend it for you.
>>
>> Att,
>>
>> Giuliano
>>
>>
>>
>>
>> On Fri, Oct 26, 2012 at 4:46 PM, Morgan McLean <wrx230 at gmail.com> wrote:
>>
>>> Hey guys,
>>>
>>> So I run SRX as my core firewalls, with EX8200's doing core switching and
>>> EX3300's doing access switching. I have two SRX's, two 8208's, and two
>>> 3300's at every cabinet. Spanning tree is a pain in my ass, especially
>>> since I have other environments setup the same way, just with smaller
>>> switches. Right now the SRX reth interfaces only come down as legs, not
>>> full mesh. The top of rack switches have only one link active at a time,
>>> legs. The interconnects between the core switches of different
>>> environments
>>> are legs, not full mesh due to spanning tree constraints (it closes the
>>> lag
>>> center trunk between the core switches).
>>>
>>> It would be a lot easier if I could just VC the core and VC the access
>>> switch pairs so that multi-chassis lags can be run everywhere and I can
>>> for
>>> the most part cut spanning tree out of the picture and have greater link
>>> fault tolerance. How reliable is VC? I've really done my best to avoid it
>>> up to this point as I try to keep redundant systems as separate as
>>> possible
>>> so one doesn't take down the other. Then again, when it comes down to it
>>> my
>>> edge and core firewalls are all SRX clusters, so... :) lol
>>>
>>> I'm not really sure what kind of information I'm looking for here. I
>>> would
>>> just run 20G lags eveywhere instead of having 10G forward/blocking STP
>>> pairs. I don't really know how things work when a device fails, how fast
>>> convergence is, split brain scenarios etc.
>>>
>>> Any major lessons learned with this technology? I am aware that with the
>>> 8200's I would need the external SRE.
>>>
>>> Thanks,
>>> Morgan
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>

------------------------------

_______________________________________________
juniper-nsp mailing list
juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

End of juniper-nsp Digest, Vol 119, Issue 45
********************************************

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________