Re: [j-nsp] Static Routing - SRX
I did this once on an SRX240, and (as someone mentioned earlier) the fact that the SRX only sees the packets in one direction will mean that TCP sessions establish and work for a little while, but as soon as the flow record on the SRX expires, it will stop passing the traffic mid-stream. I ended up terminating the second subnet (172.30.200.0/24 in your example) on a separate interface on the SRX. -Jonesy On Wed, 3 Nov 2010 16:52:48 -0400, "Paul Stewart" wrote: > Thanks very much we had no policy between private and private ;) > > Appreciate everyone's replies... take care.. > > Paul > > > -Original Message- > From: Ben Dale [mailto:bd...@comlinx.com.au] > Sent: Wednesday, November 03, 2010 4:31 PM > To: Paul Stewart > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Static Routing - SRX > > Hi Paul, > > Router-on-a-stick with SRX will break unless you have the following: > > set security policy from-zone Private to-zone Private policy 1ARM match > source-address n192.168.20.0/24 > set security policy from-zone Private to-zone Private policy 1ARM match > destination-address n172.30.200.0/24 > set security policy from-zone Private to-zone Private policy 1ARM match > application any > set security policy from-zone Private to-zone Private policy 1ARM then > permit > > > Cheers, > > Ben > > On 04/11/2010, at 1:48 AM, Paul Stewart wrote: > >> Hi there. >> >> >> >> Can anyone give any suggestion/guidance on the following. >> >> >> >> I'm trying to do a static route *out* the same interface that the traffic >> came *in* on. This is on an SRX-240 >> >> >> >> Here are the details: >> >> "Private": 192.168.20.0/24 >> >> "Public": 216.168.x.x/32 >> >> >> >> Static route: 172.30.200.0/24 to to >> 192.168.20.121 >> >> >> >> 192.168.20.121 is the IP on a VPN appliance. >> >> >> >> Traffic from a client computer never gets routed to the VPN appliance. > This >> works on a Cisco 2800 without a problem, but I can't get it working on >> the >> SRX. >> >> >> >> So, to walk this through a bit more - a computer sitting on the > 192.168.20.0 >> subnet has a default gateway of 192.168.20.224. We want a route on the > SRX >> that routes any traffic coming into 192.168.20.224 that is destined to >> 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a >> static route. >> >> >> >> Ran across this challenge in the Cisco PIX world as well.. >> >> >> >> Thanks for any input.. >> >> >> >> Paul >> >> ___ >> 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] Static Routing - SRX
Thanks very much we had no policy between private and private ;) Appreciate everyone's replies... take care.. Paul -Original Message- From: Ben Dale [mailto:bd...@comlinx.com.au] Sent: Wednesday, November 03, 2010 4:31 PM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Static Routing - SRX Hi Paul, Router-on-a-stick with SRX will break unless you have the following: set security policy from-zone Private to-zone Private policy 1ARM match source-address n192.168.20.0/24 set security policy from-zone Private to-zone Private policy 1ARM match destination-address n172.30.200.0/24 set security policy from-zone Private to-zone Private policy 1ARM match application any set security policy from-zone Private to-zone Private policy 1ARM then permit Cheers, Ben On 04/11/2010, at 1:48 AM, Paul Stewart wrote: > Hi there. > > > > Can anyone give any suggestion/guidance on the following. > > > > I'm trying to do a static route *out* the same interface that the traffic > came *in* on. This is on an SRX-240 > > > > Here are the details: > > "Private": 192.168.20.0/24 > > "Public": 216.168.x.x/32 > > > > Static route: 172.30.200.0/24 to to > 192.168.20.121 > > > > 192.168.20.121 is the IP on a VPN appliance. > > > > Traffic from a client computer never gets routed to the VPN appliance. This > works on a Cisco 2800 without a problem, but I can't get it working on the > SRX. > > > > So, to walk this through a bit more - a computer sitting on the 192.168.20.0 > subnet has a default gateway of 192.168.20.224. We want a route on the SRX > that routes any traffic coming into 192.168.20.224 that is destined to > 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a > static route. > > > > Ran across this challenge in the Cisco PIX world as well.. > > > > Thanks for any input.. > > > > Paul > > ___ > 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] Block Skype and Ultrasurf using ScreenOS
Hi Giuliano, I haven't really tried such things myselft for ages but AFAIK it's not even possible with IDP since at least skype goes into encrypted mode when it detect itself blocked and simulates something https quite well. Please correct me, if someone knows I'm not right. In this case some too much clever gear might detect it using fancy heuristic methods but it's not Juniper. Sort of a workarond approach (has been introduced by Juniper few years ago for standalone IDP) is to use DiffSerf marking (don't know whether SRX IDP also supports it) to mark detected packets (signature-based), then an upstream router is used to police marked packets to something 64k in order to give illusion of reachability but make it unusable. Pretty sure any plain stateful firewall like SSG can't do it. 2010/11/3 Giuliano Cardozo Medalha > People, > > Does anyone knows how to block ultrasurf and skype applications using only > a SSG140 Box with DI license ? > > Or it is only possible to block it using SRX650 with IDP license ? > > > Is it possible to configure ? > > Where can I find the detailed signatures of this both applications ? > > Thanks a lot, > > Giuliano > > ___ > 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] GRE Tunnel bet JUNIPER and CISCO
As others have mentioned, on the Cisco side you can use ip tcp adjust-mss 1436. On the Juniper side, I'm not sure how widely the reassmble-packets know is supported across platforms, but the alternative is: set security flow all-tcp mss 1436 The only downside is that this will adjust MSS on all traffic, not just GRE. Cheers, Ben On 03/11/2010, at 11:04 PM, Giuliano Cardozo Medalha wrote: > People, > > We are trying to close a GRE tunnel between juniper and Cisco routers without > success. > > We have tried a lot of MTU configurations but the traffic is suffering a lot > ... sometimes slow, sometimes do not open some pages. > > Have you ever configured something like this before ? > > Any tip ou configuration related to best practices ? > > Thanks a lot, > > Giuliano > ___ > 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] Static Routing - SRX
Hi Paul, Router-on-a-stick with SRX will break unless you have the following: set security policy from-zone Private to-zone Private policy 1ARM match source-address n192.168.20.0/24 set security policy from-zone Private to-zone Private policy 1ARM match destination-address n172.30.200.0/24 set security policy from-zone Private to-zone Private policy 1ARM match application any set security policy from-zone Private to-zone Private policy 1ARM then permit Cheers, Ben On 04/11/2010, at 1:48 AM, Paul Stewart wrote: > Hi there. > > > > Can anyone give any suggestion/guidance on the following. > > > > I'm trying to do a static route *out* the same interface that the traffic > came *in* on. This is on an SRX-240 > > > > Here are the details: > > "Private": 192.168.20.0/24 > > "Public": 216.168.x.x/32 > > > > Static route: 172.30.200.0/24 to to > 192.168.20.121 > > > > 192.168.20.121 is the IP on a VPN appliance. > > > > Traffic from a client computer never gets routed to the VPN appliance. This > works on a Cisco 2800 without a problem, but I can't get it working on the > SRX. > > > > So, to walk this through a bit more - a computer sitting on the 192.168.20.0 > subnet has a default gateway of 192.168.20.224. We want a route on the SRX > that routes any traffic coming into 192.168.20.224 that is destined to > 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a > static route. > > > > Ran across this challenge in the Cisco PIX world as well.. > > > > Thanks for any input.. > > > > Paul > > ___ > 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] JFlow configuration with logical systems
Dear community member,
We are producing a rotator with 02 MX480-logical systems (LS1 and LS2) and
routing-instance-virtual routers (ls1 and ls2), I need to set up
collection JFLOW
(samping).
logical-systems {
LS1 {
interfaces {
ge-0/0/0 {
unit 0 {
description "Link - IG";
lo0 {
unit 501 {
description "Lo0.501";
routing-instances {
ls1 {
instance-type virtual-router;
interface ge-0/0/0.0;
interface lo0.501;
protocols {
bgp {
log-updown;
group PEER-1
How we set it in logical systems, or it is done globally?
Gabriel Farias
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] routing updates between PFEs and Kernal
On Wed, Nov 03, 2010 at 11:34:59PM +0500, Good One wrote: > > Thanks for an useful information, Richard. Well, a DPC has a 1G ram > inside and if each PFE has a complete copy of the routing table (even > the best route) and you are receiving a full feed of internet and a > thousands of your own routes, then all the 4 PFEs should occupy the 1G > RAM (I assume all 4 PFEs are using/sharing the DPC 1G ram to store > routing table) ... not sure how to connect to a PFE individually, all > I can do is 'start shell pfe network fpc0' which connects you to a DPC > and not the PFEs sitting somewhere on the DPC :) Not quite. There are 3 different types of memory on the DPC: Slot 0 information: State Online Temperature29 degrees C / 84 degrees F Total CPU DRAM 1024 MB <--- 1 Total RLDRAM 256 MB <--- 2 Total DDR DRAM 4096 MB <--- 3 The CPU DRAM is just general purpose RAM like you'd find on any PC. This is where the microkernel runs (which is what you're talking to when you do a "start shell pfe network fpc#"), on a 1.2GHz PowerPC embedded processor. It also handles things like IP options, TTL expiration, ICMP generation from the data plane, and the like. The RLDRAM (reduced latency DRAM) is the "lookup memory", this is where the final copy of the routing table used for forwarding (called the FIB) is stored, along with information about firewall rules, etc. This memory is directly accessed by the forwarding ASICs, and needs to be low latency in order to keep up with the number of lookups/sec required on a high speed router. On older platforms this would typically have been done with SRAM, which is very fast but also very expensive. On an old M/T box you might have seen 8MB or 16MB of SRAM per PFE, which could do 20Gbps PFEs handling 2xOC192 (50Mpps+ lookups/sec), but with a capacity of well under 500k routes in the FIB. The MX (and M120) introduced a new model for doing routing lookups using RLDRAM, which is much cheaper, and thus you can put a lot more of it on the PFE. Each DPC PFE actually has 4x32MB RLDRAM chips, but they run as 2 banks of 2x32MB mirrored blocks. The first bank holds your routing information, the second bank holds your firewall information. The mirroring of 2x32MB is necessary to meet the performance requirements using the slower RLDRAM, since you can do twice as many lookups/sec if you have 2 banks to query from. The MX architecture also makes this easier, since it uses a larger number of relatively low speed PFEs (4 PFEs of 10G/ea), and is ethernet only. To support 10GE or 10x1GE you only need to do 14.8Mpps per PFE, which is a lot easier than the older 20G PFEs on T-series which needed to do 50Mpps+ to support 2xOC192. This is how the MX is implemented economically, and still manages to deliver support for well over 1 million FIB entries. The 256MB being reported in the show chassis fpc output is your 4 PFEs * 64MB worth of available memory, which is really mirrored banks of 2x32MB each. Finally, the DDR DRAM is the "packet buffering" memory, which holds the copy of the packet as it moves through the system. When you receive a packet, its contents are stored in the packet buffer memory while the headers of the packet are sent to the I-chip for routing/firewall lookups. After the result is returned, the egress interface actually goes out and gathers up all the fragments of the packet necessary to reassemble and transmit it. So, your kernel pushes the selected FIB down to the DPC CPU, which in turn programs all 4 PFEs on the DPC, and then each PFE has its own copy of the routing table (in a highly optimized form that is directly accessed by the ASICs) to make decisions from. Also this is completely different from how the new MX (Trio/3D) cards work. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] routing updates between PFEs and Kernal
Thanks for an useful information, Richard. Well, a DPC has a 1G ram inside and if each PFE has a complete copy of the routing table (even the best route) and you are receiving a full feed of internet and a thousands of your own routes, then all the 4 PFEs should occupy the 1G RAM (I assume all 4 PFEs are using/sharing the DPC 1G ram to store routing table) ... not sure how to connect to a PFE individually, all I can do is 'start shell pfe network fpc0' which connects you to a DPC and not the PFEs sitting somewhere on the DPC :) Regards,Andrew > Date: Wed, 3 Nov 2010 12:20:06 -0500 > From: r...@e-gerbil.net > To: go...@live.com > CC: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] routing updates between PFEs and Kernal > > On Wed, Nov 03, 2010 at 02:00:11PM +0500, Good One wrote: > > > > We started using MX-480 and I came to know that each DPC has four > > PFEs. Now a question comes to mind that how the chemistry of routing > > updates in between PFEs and RE(kernel) is being done. If kernel routes > > are being exported to PFEs, does it means that each PFE contains a > > full routing table? So if you have five DPCs than you have 20 PFEs and > > you are exporting kernel routes to all 20 PFEs and each PFEs is having > > a best route in the forwarding table. > > Yes each PFE has a complete copy of the routing table and makes the > routing decision for ingress packets, this is how distributed forwarding > works. I suspect what actually happens is the kernel sends it's routing > table (krt) to the CPU on the DPC, which then programs the individual > PFEs on the card (4 per DPC), but I don't work for Juniper or anything > so I have no special knowledge about their implementation. > > There is also a fair amount of work that goes into locking and > verification of the routes, to ensure that every PFE has a consistent > view. Otherwise, you risk creating micro forwarding loops with every > route update, or worse macro forwarding loops aka Cisco Customer > Enragement Feature. :) > > -- > Richard A Steenbergenhttp://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static Routing - SRX
Does an SRX get confused when you have asymetric routing like
that on a single zone? Does it confuse the stream processing?
The SRX will only ever see the one way traffic from the host
on your local network to the remote network. The return traffic
(I assume) will go straight from the VPN gateway back to the
host on the same LAN.
Have you turned on some trace options to see what's going on?
security {
flow {
traceoptions {
file vpn_problem;
flag basic-datapath;
packet-filter vpn_traffic {
destination-prefix 172.30.200.0/24;
}
}
}
On 11/3/2010 at 11:02 AM, "Paul Stewart" wrote:
> Thanks... yeah, pretty much.
>
> We installed the static route and were unable to reach anything on the
> 172.30.200.0/24 network from a machine in the 192.168.20.0/24 subnet. On
> that actual machine (Windows 7) we installed a route in Windows and were
> able to communicate no problem (bypassing the route statement on the SRX).
>
> This seems to imply that by using a default route you can't take traffic
> into an interface and route it back out the SAME interface - an issue we
> used to face on the Cisco PIX boxes at one time.
>
> Looking for a workaround to this - our solution at this point is to bring
> the 192.168.20.121 device (which is a VPN appliance that connects us to our
> billing platforms) in via a subnet on a directly connected interface. The
> downside to this is that it involves some routing changes on the VPN portion
> which we're trying to avoid as it involves a third party.
>
> Literally on the Cisco 2800 in place it's "ip route 172.30.200.0
> 255.255.255.0 192.168.20.121". On the SRX we have "set routing-options
> static route 172.30.200.0/24 next-hop 192.168.20.121".
>
> Thanks,
>
> Paul
>
>
>
> -Original Message-
> From: Michael Damkot [mailto:mdamkot...@gmail.com]
> Sent: Wednesday, November 03, 2010 1:55 PM
> To: Paul Stewart
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Static Routing - SRX
>
> Paul-
>
> Just to make sure I'm tracking correctly, you've tried installing a static
> route and it didn't work?
>
>
> On Nov 3, 2010, at 11:48 , Paul Stewart wrote:
>
>> Hi there.
>>
>>
>>
>> Can anyone give any suggestion/guidance on the following.
>>
>>
>>
>> I'm trying to do a static route *out* the same interface that the traffic
>> came *in* on. This is on an SRX-240
>>
>>
>>
>> Here are the details:
>>
>> "Private": 192.168.20.0/24
>>
>> "Public": 216.168.x.x/32
>>
>>
>>
>> Static route: 172.30.200.0/24 to to
>> 192.168.20.121
>>
>>
>>
>> 192.168.20.121 is the IP on a VPN appliance.
>>
>>
>>
>> Traffic from a client computer never gets routed to the VPN appliance.
> This
>> works on a Cisco 2800 without a problem, but I can't get it working on the
>> SRX.
>>
>>
>>
>> So, to walk this through a bit more - a computer sitting on the
> 192.168.20.0
>> subnet has a default gateway of 192.168.20.224. We want a route on the
> SRX
>> that routes any traffic coming into 192.168.20.224 that is destined to
>> 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a
>> static route.
>>
>>
>>
>> Ran across this challenge in the Cisco PIX world as well..
>>
>>
>>
>> Thanks for any input..
>>
>>
>>
>> Paul
>>
>> ___
>> 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
--
Crist Clark
Network Security Specialist, Information Systems
Globalstar
408 933 4387
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE Tunnel bet JUNIPER and CISCO
Is this an encrypted GRE tunnel over the internet? The "recommended" MTU is 1400 bytes on both ends. Use the clear-dont-fragment-bit knob on the juniper side, and do "ip tcp mss-adjust 1360" on the Cisco side. Also on the Cisco side, ingress interfaces should have a route-map applied to clear the df bit of the packets similar to the following: route-map clear-df-bit permit 10 set ip df 0 interface fa0/0 ip policy route-map clear-df-bit Note that "crypto ipsec clear df" on the Cisco side does not work for traffic passing through GRE tunnels, and you should not have this command enabled if you are doing encrypted GRE tunnels. Similarly on the Juniper side, under the ipsec-vpn rule you should not configure the clear-dont-fragment-bit option (I forget the exact knob name, but its there). The reason for this is that if you configure path-mtu-discovery these options will break it. As noted below, you may have to lower the MTU or the tcp-adjust depending on the ciphers you are using. As much as possible, you want to avoid fragmenting and reassembling GRE or IPsec packets. I would lower the MTU and tcp mss-adjust until you stop seeing GRE and IPSec fragmentation. There are some odd bugs related to the clear-dont-fragment-bit option on the Juniper end. If you are doing packet classification ingress on the router, all packets must be classified with a loss-priority of "low." Otherwise packets will get blackholed if the next-hop is over the GRE tunnel. I think this is fixed in 10.0S8, but not in 10.0R4. Probably is fixed in 10.2R3, but I haven't tested. From: "Linder, Todd" To: giulian...@uol.com.br; juniper-nsp@puck.nether.net Sent: Wed, November 3, 2010 9:15:02 AM Subject: Re: [j-nsp] GRE Tunnel bet JUNIPER and CISCO I recently had and a similar issue between a Juniper and a Cisco router, I resolved some of those symptoms by adjusting the tcp maximum segment size. You may have to play with this setting until it yields the best result. I use the "ip tcp adjust-mss 1300" and applied it to the interfaces used. This size seemed to yeild the best results for my scenario. Todd Linder Network Support Engineer OneNet Oklahoma's Telecommunications Network -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Giuliano Cardozo Medalha Sent: Wednesday, November 03, 2010 8:04 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] GRE Tunnel bet JUNIPER and CISCO People, We are trying to close a GRE tunnel between juniper and Cisco routers without success. We have tried a lot of MTU configurations but the traffic is suffering a lot ... sometimes slow, sometimes do not open some pages. Have you ever configured something like this before ? Any tip ou configuration related to best practices ? Thanks a lot, Giuliano ___ 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] Static Routing - SRX
That's going to be required too, I forgot about that On Nov 3, 2010, at 14:07 , OBrien, Will wrote: > Do you have an intrazone policy? Trust to trust, allow all for example. > > Sent from my iPad > > On Nov 3, 2010, at 1:04 PM, "Paul Stewart" wrote: > >> Thanks... yeah, pretty much. >> >> We installed the static route and were unable to reach anything on the >> 172.30.200.0/24 network from a machine in the 192.168.20.0/24 subnet. On >> that actual machine (Windows 7) we installed a route in Windows and were >> able to communicate no problem (bypassing the route statement on the SRX). >> >> This seems to imply that by using a default route you can't take traffic >> into an interface and route it back out the SAME interface - an issue we >> used to face on the Cisco PIX boxes at one time. >> >> Looking for a workaround to this - our solution at this point is to bring >> the 192.168.20.121 device (which is a VPN appliance that connects us to our >> billing platforms) in via a subnet on a directly connected interface. The >> downside to this is that it involves some routing changes on the VPN portion >> which we're trying to avoid as it involves a third party. >> >> Literally on the Cisco 2800 in place it's "ip route 172.30.200.0 >> 255.255.255.0 192.168.20.121". On the SRX we have "set routing-options >> static route 172.30.200.0/24 next-hop 192.168.20.121". >> >> Thanks, >> >> Paul >> >> >> >> -Original Message- >> From: Michael Damkot [mailto:mdamkot...@gmail.com] >> Sent: Wednesday, November 03, 2010 1:55 PM >> To: Paul Stewart >> Cc: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] Static Routing - SRX >> >> Paul- >> >> Just to make sure I'm tracking correctly, you've tried installing a static >> route and it didn't work? >> >> >> On Nov 3, 2010, at 11:48 , Paul Stewart wrote: >> >>> Hi there. >>> >>> >>> >>> Can anyone give any suggestion/guidance on the following. >>> >>> >>> >>> I'm trying to do a static route *out* the same interface that the traffic >>> came *in* on. This is on an SRX-240 >>> >>> >>> >>> Here are the details: >>> >>> "Private": 192.168.20.0/24 >>> >>> "Public": 216.168.x.x/32 >>> >>> >>> >>> Static route: 172.30.200.0/24 to to >>> 192.168.20.121 >>> >>> >>> >>> 192.168.20.121 is the IP on a VPN appliance. >>> >>> >>> >>> Traffic from a client computer never gets routed to the VPN appliance. >> This >>> works on a Cisco 2800 without a problem, but I can't get it working on the >>> SRX. >>> >>> >>> >>> So, to walk this through a bit more - a computer sitting on the >> 192.168.20.0 >>> subnet has a default gateway of 192.168.20.224. We want a route on the >> SRX >>> that routes any traffic coming into 192.168.20.224 that is destined to >>> 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a >>> static route. >>> >>> >>> >>> Ran across this challenge in the Cisco PIX world as well.. >>> >>> >>> >>> Thanks for any input.. >>> >>> >>> >>> Paul >>> >>> ___ >>> 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] Static Routing - SRX
Do you have an intrazone policy? Trust to trust, allow all for example. Sent from my iPad On Nov 3, 2010, at 1:04 PM, "Paul Stewart" wrote: > Thanks... yeah, pretty much. > > We installed the static route and were unable to reach anything on the > 172.30.200.0/24 network from a machine in the 192.168.20.0/24 subnet. On > that actual machine (Windows 7) we installed a route in Windows and were > able to communicate no problem (bypassing the route statement on the SRX). > > This seems to imply that by using a default route you can't take traffic > into an interface and route it back out the SAME interface - an issue we > used to face on the Cisco PIX boxes at one time. > > Looking for a workaround to this - our solution at this point is to bring > the 192.168.20.121 device (which is a VPN appliance that connects us to our > billing platforms) in via a subnet on a directly connected interface. The > downside to this is that it involves some routing changes on the VPN portion > which we're trying to avoid as it involves a third party. > > Literally on the Cisco 2800 in place it's "ip route 172.30.200.0 > 255.255.255.0 192.168.20.121". On the SRX we have "set routing-options > static route 172.30.200.0/24 next-hop 192.168.20.121". > > Thanks, > > Paul > > > > -Original Message- > From: Michael Damkot [mailto:mdamkot...@gmail.com] > Sent: Wednesday, November 03, 2010 1:55 PM > To: Paul Stewart > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Static Routing - SRX > > Paul- > > Just to make sure I'm tracking correctly, you've tried installing a static > route and it didn't work? > > > On Nov 3, 2010, at 11:48 , Paul Stewart wrote: > >> Hi there. >> >> >> >> Can anyone give any suggestion/guidance on the following. >> >> >> >> I'm trying to do a static route *out* the same interface that the traffic >> came *in* on. This is on an SRX-240 >> >> >> >> Here are the details: >> >> "Private": 192.168.20.0/24 >> >> "Public": 216.168.x.x/32 >> >> >> >> Static route: 172.30.200.0/24 to to >> 192.168.20.121 >> >> >> >> 192.168.20.121 is the IP on a VPN appliance. >> >> >> >> Traffic from a client computer never gets routed to the VPN appliance. > This >> works on a Cisco 2800 without a problem, but I can't get it working on the >> SRX. >> >> >> >> So, to walk this through a bit more - a computer sitting on the > 192.168.20.0 >> subnet has a default gateway of 192.168.20.224. We want a route on the > SRX >> that routes any traffic coming into 192.168.20.224 that is destined to >> 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a >> static route. >> >> >> >> Ran across this challenge in the Cisco PIX world as well.. >> >> >> >> Thanks for any input.. >> >> >> >> Paul >> >> ___ >> 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] Static Routing - SRX
Well you're right that one of the old school fundamental rules of IP Packet forwarding does not allow a packet to exit the same interface it entered on... I think you can use Policy based Routing in JUNOS to engage that functionality, but A) it's been so long I forget how to do it off the top of my head, and B) I'm not sure if it's supported on the SRX. On Nov 3, 2010, at 14:02 , Paul Stewart wrote: > Thanks... yeah, pretty much. > > We installed the static route and were unable to reach anything on the > 172.30.200.0/24 network from a machine in the 192.168.20.0/24 subnet. On > that actual machine (Windows 7) we installed a route in Windows and were > able to communicate no problem (bypassing the route statement on the SRX). > > This seems to imply that by using a default route you can't take traffic > into an interface and route it back out the SAME interface - an issue we > used to face on the Cisco PIX boxes at one time. > > Looking for a workaround to this - our solution at this point is to bring > the 192.168.20.121 device (which is a VPN appliance that connects us to our > billing platforms) in via a subnet on a directly connected interface. The > downside to this is that it involves some routing changes on the VPN portion > which we're trying to avoid as it involves a third party. > > Literally on the Cisco 2800 in place it's "ip route 172.30.200.0 > 255.255.255.0 192.168.20.121". On the SRX we have "set routing-options > static route 172.30.200.0/24 next-hop 192.168.20.121". > > Thanks, > > Paul > > > > -Original Message- > From: Michael Damkot [mailto:mdamkot...@gmail.com] > Sent: Wednesday, November 03, 2010 1:55 PM > To: Paul Stewart > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Static Routing - SRX > > Paul- > > Just to make sure I'm tracking correctly, you've tried installing a static > route and it didn't work? > > > On Nov 3, 2010, at 11:48 , Paul Stewart wrote: > >> Hi there. >> >> >> >> Can anyone give any suggestion/guidance on the following. >> >> >> >> I'm trying to do a static route *out* the same interface that the traffic >> came *in* on. This is on an SRX-240 >> >> >> >> Here are the details: >> >> "Private": 192.168.20.0/24 >> >> "Public": 216.168.x.x/32 >> >> >> >> Static route: 172.30.200.0/24 to to >> 192.168.20.121 >> >> >> >> 192.168.20.121 is the IP on a VPN appliance. >> >> >> >> Traffic from a client computer never gets routed to the VPN appliance. > This >> works on a Cisco 2800 without a problem, but I can't get it working on the >> SRX. >> >> >> >> So, to walk this through a bit more - a computer sitting on the > 192.168.20.0 >> subnet has a default gateway of 192.168.20.224. We want a route on the > SRX >> that routes any traffic coming into 192.168.20.224 that is destined to >> 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a >> static route. >> >> >> >> Ran across this challenge in the Cisco PIX world as well.. >> >> >> >> Thanks for any input.. >> >> >> >> Paul >> >> ___ >> 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] Static Routing - SRX
Thanks... yeah, pretty much. We installed the static route and were unable to reach anything on the 172.30.200.0/24 network from a machine in the 192.168.20.0/24 subnet. On that actual machine (Windows 7) we installed a route in Windows and were able to communicate no problem (bypassing the route statement on the SRX). This seems to imply that by using a default route you can't take traffic into an interface and route it back out the SAME interface - an issue we used to face on the Cisco PIX boxes at one time. Looking for a workaround to this - our solution at this point is to bring the 192.168.20.121 device (which is a VPN appliance that connects us to our billing platforms) in via a subnet on a directly connected interface. The downside to this is that it involves some routing changes on the VPN portion which we're trying to avoid as it involves a third party. Literally on the Cisco 2800 in place it's "ip route 172.30.200.0 255.255.255.0 192.168.20.121". On the SRX we have "set routing-options static route 172.30.200.0/24 next-hop 192.168.20.121". Thanks, Paul -Original Message- From: Michael Damkot [mailto:mdamkot...@gmail.com] Sent: Wednesday, November 03, 2010 1:55 PM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Static Routing - SRX Paul- Just to make sure I'm tracking correctly, you've tried installing a static route and it didn't work? On Nov 3, 2010, at 11:48 , Paul Stewart wrote: > Hi there. > > > > Can anyone give any suggestion/guidance on the following. > > > > I'm trying to do a static route *out* the same interface that the traffic > came *in* on. This is on an SRX-240 > > > > Here are the details: > > "Private": 192.168.20.0/24 > > "Public": 216.168.x.x/32 > > > > Static route: 172.30.200.0/24 to to > 192.168.20.121 > > > > 192.168.20.121 is the IP on a VPN appliance. > > > > Traffic from a client computer never gets routed to the VPN appliance. This > works on a Cisco 2800 without a problem, but I can't get it working on the > SRX. > > > > So, to walk this through a bit more - a computer sitting on the 192.168.20.0 > subnet has a default gateway of 192.168.20.224. We want a route on the SRX > that routes any traffic coming into 192.168.20.224 that is destined to > 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a > static route. > > > > Ran across this challenge in the Cisco PIX world as well.. > > > > Thanks for any input.. > > > > Paul > > ___ > 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] Static Routing - SRX
Paul- Just to make sure I'm tracking correctly, you've tried installing a static route and it didn't work? On Nov 3, 2010, at 11:48 , Paul Stewart wrote: > Hi there. > > > > Can anyone give any suggestion/guidance on the following. > > > > I'm trying to do a static route *out* the same interface that the traffic > came *in* on. This is on an SRX-240 > > > > Here are the details: > > "Private": 192.168.20.0/24 > > "Public": 216.168.x.x/32 > > > > Static route: 172.30.200.0/24 to to > 192.168.20.121 > > > > 192.168.20.121 is the IP on a VPN appliance. > > > > Traffic from a client computer never gets routed to the VPN appliance. This > works on a Cisco 2800 without a problem, but I can't get it working on the > SRX. > > > > So, to walk this through a bit more - a computer sitting on the 192.168.20.0 > subnet has a default gateway of 192.168.20.224. We want a route on the SRX > that routes any traffic coming into 192.168.20.224 that is destined to > 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a > static route. > > > > Ran across this challenge in the Cisco PIX world as well.. > > > > Thanks for any input.. > > > > Paul > > ___ > 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] RSTP over logical-system.
Hi Nilesh,
Sorry for don't put the release, I am working with JunOS 10.0R4.7 and the
chassis is a MX960.
I was thinking the same about the bridge-id I noted it but I wasn't sure if
it was possible to implement on logical-system with the same system MAC.
Do you know if there are any limit with protocols of Layer2 and
logical-systems?
I will try with MSTP, I will comment the result of my tests.
Best regards,
On Tue, Nov 2, 2010 at 9:38 PM, Nilesh Khambal wrote:
> David,
>
> I don't think you can run RSTP in logical routers. As you can see from your
> outputs below, RSTP instances in all the LRs are using same system MAC. You
> can probably try MSTP but don't think RSTP will work in LRs.
>
> BTW, what JUNOS version is this?
>
> Thanks,
> Nilesh.
>
> > n...@mx960-lab-re0> ...ge logical-system SW1 routing-instance 11
> > STP bridge parameters
> > Routing instance name : SW1/11
> > Context ID : 1
> > Enabled protocol: STP
> > Root ID : 0.80:71:1f:8c:7f:d0
> > Hello time: 2 seconds
> > Maximum age : 20 seconds
> > Forward delay : 15 seconds
> > Message age : 0
> > Number of topology changes: 2
> > Time since last topology change : 388 seconds
> > Local parameters
> > Bridge ID : 0.80:71:1f:8c:7f:d0 <<<
> > Extended system ID : 0
> >
> > {master}
> > n...@mx960-lab-re0> ...tree bridge logical-system SW2 routing-instance 12
> > STP bridge parameters
> > Routing instance name : SW2/12
> > Context ID : 2
> > Enabled protocol: STP
> > Root ID : 8192.80:71:1f:8c:7f:d0
> > Hello time: 2 seconds
> > Maximum age : 20 seconds
> > Forward delay : 15 seconds
> > Message age : 0
> > Number of topology changes: 1
> > Time since last topology change : 396 seconds
> > Local parameters
> > Bridge ID : 8192.80:71:1f:8c:7f:d0 <<<
> > Extended system ID : 0
>
>
>
> On 11/2/10 7:08 PM, "David Lockuan" wrote:
>
> > Hi guys,
> >
> > I'm testing the protocols rstp over logical-systems, but when I set the
> > priority over one interface for it work as root, it is not change the
> status
> > in the protocols rstp and the other interface don't change to Blocking.
> > theirs always keep on Forwarding state.
> >
> > The topology that I am using it is the next:
> >
> > SW1 (logical)---ge-3/0/2loop
> > fisicoge-3/0/3--SW2(logical)
> > SW1 (logical)---ge-3/0/4loop
> > fisicoge-3/0/5--SW2(logical)
> >
> > I want to put the interface ge-3/0/2 as root interface.
> >
> > These are configuration of both logical-systems:
> >
>
> **>
> *
> > {master}
> > n...@mx960-lab-re0> show configuration interfaces
> > ge-3/0/2 {
> > encapsulation ethernet-bridge;
> > }
> > ge-3/0/3 {
> > encapsulation ethernet-bridge;
> > }
> > ge-3/0/4 {
> > encapsulation ethernet-bridge;
> > }
> > ge-3/0/5 {
> > encapsulation ethernet-bridge;
> > }
> >
> > {master}
> > n...@mx960-lab-re0> show configuration logical-systems SW1
> > interfaces {
> > ge-3/0/2 {
> > unit 0 {
> > family bridge;
> > }
> > }
> > ge-3/0/4 {
> > unit 0 {
> > family bridge;
> > }
> > }
> > }
> > routing-instances {
> > 11 {
> > instance-type virtual-switch;
> > protocols {
> > rstp {
> > bridge-priority 0;
> > interface ge-3/0/2 {
> > priority 0;
> > mode point-to-point;
> > }
> > interface ge-3/0/4 {
> > mode point-to-point;
> > }
> > force-version stp;
> > }
> > }
> > bridge-domains {
> > br1 {
> > interface ge-3/0/2.0;
> > interface ge-3/0/4.0;
> > }
> > }
> > }
> > }
> >
> > {master}
> > n...@mx960-lab-re0> show configuration logical-systems SW2
> > interfaces {
> > ge-3/0/3 {
> > unit 0 {
> > family bridge;
> > }
> > }
> > ge-3/0/5 {
> > unit 0 {
> > family bridge;
> > }
> > }
> > }
> > routing-instances {
> > 12 {
> > instance-type virtual-switch;
> > protocols {
> > rstp {
> > bridge-priority 8k;
> > interface ge-3/0/3 {
> > mode point-to-point;
> > }
> > interface ge-3/0/5 {
> >
Re: [j-nsp] routing updates between PFEs and Kernal
On Wed, Nov 03, 2010 at 02:00:11PM +0500, Good One wrote: > > We started using MX-480 and I came to know that each DPC has four > PFEs. Now a question comes to mind that how the chemistry of routing > updates in between PFEs and RE(kernel) is being done. If kernel routes > are being exported to PFEs, does it means that each PFE contains a > full routing table? So if you have five DPCs than you have 20 PFEs and > you are exporting kernel routes to all 20 PFEs and each PFEs is having > a best route in the forwarding table. Yes each PFE has a complete copy of the routing table and makes the routing decision for ingress packets, this is how distributed forwarding works. I suspect what actually happens is the kernel sends it's routing table (krt) to the CPU on the DPC, which then programs the individual PFEs on the card (4 per DPC), but I don't work for Juniper or anything so I have no special knowledge about their implementation. There is also a fair amount of work that goes into locking and verification of the routes, to ensure that every PFE has a consistent view. Otherwise, you risk creating micro forwarding loops with every route update, or worse macro forwarding loops aka Cisco Customer Enragement Feature. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Static Routing - SRX
Hi there. Can anyone give any suggestion/guidance on the following. I'm trying to do a static route *out* the same interface that the traffic came *in* on. This is on an SRX-240 Here are the details: "Private": 192.168.20.0/24 "Public": 216.168.x.x/32 Static route: 172.30.200.0/24 to to 192.168.20.121 192.168.20.121 is the IP on a VPN appliance. Traffic from a client computer never gets routed to the VPN appliance. This works on a Cisco 2800 without a problem, but I can't get it working on the SRX. So, to walk this through a bit more - a computer sitting on the 192.168.20.0 subnet has a default gateway of 192.168.20.224. We want a route on the SRX that routes any traffic coming into 192.168.20.224 that is destined to 172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a static route. Ran across this challenge in the Cisco PIX world as well.. Thanks for any input.. Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Block Skype and Ultrasurf using ScreenOS
People, Does anyone knows how to block ultrasurf and skype applications using only a SSG140 Box with DI license ? Or it is only possible to block it using SRX650 with IDP license ? Is it possible to configure ? Where can I find the detailed signatures of this both applications ? Thanks a lot, Giuliano ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE Tunnel bet JUNIPER and CISCO
I recently had and a similar issue between a Juniper and a Cisco router, I resolved some of those symptoms by adjusting the tcp maximum segment size. You may have to play with this setting until it yields the best result. I use the "ip tcp adjust-mss 1300" and applied it to the interfaces used. This size seemed to yeild the best results for my scenario. Todd Linder Network Support Engineer OneNet Oklahoma's Telecommunications Network -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Giuliano Cardozo Medalha Sent: Wednesday, November 03, 2010 8:04 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] GRE Tunnel bet JUNIPER and CISCO People, We are trying to close a GRE tunnel between juniper and Cisco routers without success. We have tried a lot of MTU configurations but the traffic is suffering a lot ... sometimes slow, sometimes do not open some pages. Have you ever configured something like this before ? Any tip ou configuration related to best practices ? Thanks a lot, Giuliano ___ 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] Block Skype and Ultrasurf using ScreenOS
People, Does anyone knows how to block ultrasurf and skype applications using only a SSG140 Box with DI license ? Is it possible to configure ? Where can I find the detailed signatures of this both applications ? Thanks a lot, Giuliano ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE Tunnel bet JUNIPER and CISCO
Hi Giuliano,
We have configured that like:
CISCO:
-
interface Tunnel0
ip address 172.20.1.1 255.255.255.252
keepalive 10 3
tunnel source FastEthernet0/0
tunnel destination 192.168.1.2
tunnel path-mtu-discovery ---IMPORTANT
interface FastEthernet0/1
description LAN INTERFACE
ip address 10.0.0.254 255.255.255.0
ip nat inside
duplex auto
speed auto
!
!
interface FastEthernet0/0
description Internet Interface
ip address 192.168.1.1 255.255.255.0
ip access-group allow-gre in
ip nat inside
duplex auto
speed auto
!
!
ip access-list extended allow-gre
permit gre any any
JUNIPER
---
gr-0/2/0 {
unit 0 {
description "Tunnel GRE Cisco-Juniper";
tunnel {
source 192.168.1.2;
destination 192.168.1.1;
}
family inet {
mtu 1514;
address 172.20.1.2/30;
}
El 03/11/2010 13:04, Giuliano Cardozo Medalha escribió:
People,
We are trying to close a GRE tunnel between juniper and Cisco routers
without success.
We have tried a lot of MTU configurations but the traffic is suffering
a lot ... sometimes slow, sometimes do not open some pages.
Have you ever configured something like this before ?
Any tip ou configuration related to best practices ?
Thanks a lot,
Giuliano
___
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] GRE Tunnel bet JUNIPER and CISCO
Generally, this issue is related to MTU and fragmentation. If you have a
problem with loading web-pages and slow tcp response, you better try
adjusting tcp-mss settings on your cisco router. You can use the following
command under tunnel interface, most of the time it works for me :)
interface tunnelX
ip tcp adjust-mss 1436
On juniper side you can add the following knobs under the gr interface conf
gr-x/x/x {
unit x {
clear-dont-fragment-bit
reassemble-packets
tunnel {
path-mtu-discovery
Thanks
BR//
Masood
> People,
>
> We are trying to close a GRE tunnel between juniper and Cisco routers
> without success.
>
> We have tried a lot of MTU configurations but the traffic is suffering a
> lot ... sometimes slow, sometimes do not open some pages.
>
> Have you ever configured something like this before ?
>
> Any tip ou configuration related to best practices ?
>
> Thanks a lot,
>
> Giuliano
> ___
> 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] GRE Tunnel bet JUNIPER and CISCO
People, We are trying to close a GRE tunnel between juniper and Cisco routers without success. We have tried a lot of MTU configurations but the traffic is suffering a lot ... sometimes slow, sometimes do not open some pages. Have you ever configured something like this before ? Any tip ou configuration related to best practices ? Thanks a lot, Giuliano ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Air Flow
Hi, How much air the PSU fan moves has absolutely no impact on switch cooling, it's only cooling the PSU (at least on 3200, haven't pulled a 4200 apart yet). Also take into account that the fan assembly is moving a larger volume at a lower speed, so a measurement with a piece of paper wouldn't necessarily give you the right impression. --- Martin Levin IT-strategy & planning Mölndals stad >>> Från:Bjørn Skovlund Till:Bill Blackford Kopia:"juniper-nsp@puck.nether.net" Datum:2010-11-03 10:40 Ärende:Re: [j-nsp] EX4200 Air Flow Hi Bill, We have around 80 EX-3200 (24 port RJ-45, with SFP module) and 30 EX-4200 (24 port SFP, with XFP module) in production. They're all located at telco pops, an environment with cooling, but not from the floor and also quite densely populated locations. Not ideal environment, so to say. I've run some quick stats and on the CPU, the temperature is of the same average. On the PFEs, the 4200s are in avarage 5 degrees celcius warmer than the 3200s. If it's possible to make any conclussions about airflow from this, I'm not so sure. As you can guess with the uplink modules, our 4200s are running a much higher packet-load than our 3200s. We've not found any problems with heating so far - and most of our EXs have been running for around 10 months now. Cheers, Bjørn On Tue, Nov 2, 2010 at 9:22 PM, Bill Blackford wrote: > I have several EX3200's and EX4200's installed in my Data Center. In comparing the two, they both intake from the sides and exhaust out the back. Actually, the EX3200 has intakes on both sides, the EX4200 only on one side. Using a very low-tech method for measuring air flow (my hand and a small strip of paper), it really seems like the EX3200 has better air flow than it's big brother. The removable fan assembly on the 4200 is barely moving any air. The Power supply fan on the 4200 has higher air flow, but the overall flow seems to be much less than the 3200. > > Has anyone experienced heat issues with these? > > Thanks, > > -b > > -- > Bill Blackford > Senior Network Engineer > Technology Systems Group > Northwest Regional ESD > > Logged into reality and abusing my sudo priviledges > > > ___ > 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] SRX650 Clustering - IPv6
I have it deployed in "enterprise-style" deployment (dual-stack for the office users), on a SRX240-H cluster running 10.2R3. It works just as expected so far. On Tue, Nov 2, 2010 at 21:39, Paul Stewart wrote: > Hmmm.. interesting - I thought I had reviewed 10.2 for this support... will > dig deeper. So then comes the question - anyone actually *using* IPv6 on > clustered SRX? Any real-world feedback? > > I have an SRX210H at home and recently discovered an annoying "bug" that IPv6 > isn't supported on VLAN interfaces... that was kind of a shock to be blunt.. > > Thanks, > Paul > > > -Original Message- > From: Crist Clark [mailto:crist.cl...@globalstar.com] > Sent: Tuesday, November 02, 2010 3:22 PM > To: Paul Stewart; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] SRX650 Clustering - IPv6 > > I just happened to be looking at the 10.2 release notes after > seeing your email. > > "IPv6 Support > [snip] > > * Chassis cluster—In JUNOS Release 10.2, we support chassis > cluster in an active-passive (failover) deployment. [Junos OS Security > Configuration Guide]" > > You may want to have a closer look at the 10.2 documentation > (the current recommended release for SRXs). I am not using > this feature so I have no personal experience whether it actually > works. > > > On 11/2/2010 at 10:43 AM, "Paul Stewart" wrote: >> Hi there. >> >> >> >> We are looking to bring on an additional SRX650 at a site by > clustering. >> One of the requirements though is IPv6 traffic and it appears it's > not >> supported? >> >> >> >> From >> > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-c > >> ollections/release-notes/10/topic-39007.html : >> >> >> >> Chassis Cluster >> >> On SRX Series and J Series devices, the following features are not > supported >> when chassis clustering is enabled on the device: >> >> * All packet-based protocols, such as MPLS, Connectionless > Network >> Service (CLNS), and IP version 6 (IPv6) >> >> >> >> >> >> >> >> Do any of the SRX boxes support clustering with IPv6? Is there any > timeline >> on this being fixed that anyone knows of? >> >> >> >> Our goal is redundant routing engines should something happen - makes > more >> $$$ sense to add an additional SRX650 when there is one existing.. >> >> >> >> Thanks in advance, >> >> >> >> Paul >> >> >> >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > -- > > Crist Clark > Network Security Specialist, Information Systems > Globalstar > 408 933 4387 > > > > ___ > 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 for MPLS
Interesting/ disappointing to read that the top end SRXs don't support MPLS as it is clearly the intention to deploy MPLS to the edge with the smaller SRXs. So what is Juniper's solution for concentration points in the network e.g. head offices etc? Do the large SRXs have no support for "Family mpls" in any fashion? Is it on the roadmap (the statement below would suggest it is)? And if so when can it be expected? Thanks, Tim. -Original Message- Message: 1 Date: Fri, 22 Oct 2010 08:54:36 +0530 From: Jai Chandra Gundapaneni To: "EXT - xmi...@gmail.com" Cc: "'juniper-nsp@puck.nether.net'" Subject: Re: [j-nsp] SRX for MPLS Message-ID: <33e45efc4b29ee4195b9440b22f885ea584a8...@embx02-bng.jnpr.net> Content-Type: text/plain; charset="iso-8859-1" Sorry for the confusion. The top end SRX don't yet support the MPLS feature as yet. The top end SRX don't work in packet mode. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Air Flow
Hi Bill, We have around 80 EX-3200 (24 port RJ-45, with SFP module) and 30 EX-4200 (24 port SFP, with XFP module) in production. They're all located at telco pops, an environment with cooling, but not from the floor and also quite densely populated locations. Not ideal environment, so to say. I've run some quick stats and on the CPU, the temperature is of the same average. On the PFEs, the 4200s are in avarage 5 degrees celcius warmer than the 3200s. If it's possible to make any conclussions about airflow from this, I'm not so sure. As you can guess with the uplink modules, our 4200s are running a much higher packet-load than our 3200s. We've not found any problems with heating so far - and most of our EXs have been running for around 10 months now. Cheers, Bjørn On Tue, Nov 2, 2010 at 9:22 PM, Bill Blackford wrote: > I have several EX3200's and EX4200's installed in my Data Center. In > comparing the two, they both intake from the sides and exhaust out the back. > Actually, the EX3200 has intakes on both sides, the EX4200 only on one side. > Using a very low-tech method for measuring air flow (my hand and a small > strip of paper), it really seems like the EX3200 has better air flow than > it's big brother. The removable fan assembly on the 4200 is barely moving any > air. The Power supply fan on the 4200 has higher air flow, but the overall > flow seems to be much less than the 3200. > > Has anyone experienced heat issues with these? > > Thanks, > > -b > > -- > Bill Blackford > Senior Network Engineer > Technology Systems Group > Northwest Regional ESD > > Logged into reality and abusing my sudo priviledges > > > ___ > 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] routing updates between PFEs and Kernal
We started using MX-480 and I came to know that each DPC has four PFEs. Now a question comes to mind that how the chemistry of routing updates in between PFEs and RE(kernel) is being done. If kernel routes are being exported to PFEs, does it means that each PFE contains a full routing table? So if you have five DPCs than you have 20 PFEs and you are exporting kernel routes to all 20 PFEs and each PFEs is having a best route in the forwarding table. BR//Andrew ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSTP over logical-system.
MSTP does work, well at least when i tried it on 10.3
On Wed, Nov 3, 2010 at 3:38 AM, Nilesh Khambal wrote:
> David,
>
> I don't think you can run RSTP in logical routers. As you can see from your
> outputs below, RSTP instances in all the LRs are using same system MAC. You
> can probably try MSTP but don't think RSTP will work in LRs.
>
> BTW, what JUNOS version is this?
>
> Thanks,
> Nilesh.
>
>> n...@mx960-lab-re0> ...ge logical-system SW1 routing-instance 11
>> STP bridge parameters
>> Routing instance name : SW1/11
>> Context ID : 1
>> Enabled protocol : STP
>> Root ID : 0.80:71:1f:8c:7f:d0
>> Hello time : 2 seconds
>> Maximum age : 20 seconds
>> Forward delay : 15 seconds
>> Message age : 0
>> Number of topology changes : 2
>> Time since last topology change : 388 seconds
>> Local parameters
>> Bridge ID : 0.80:71:1f:8c:7f:d0 <<<
>> Extended system ID : 0
>>
>> {master}
>> n...@mx960-lab-re0> ...tree bridge logical-system SW2 routing-instance 12
>> STP bridge parameters
>> Routing instance name : SW2/12
>> Context ID : 2
>> Enabled protocol : STP
>> Root ID : 8192.80:71:1f:8c:7f:d0
>> Hello time : 2 seconds
>> Maximum age : 20 seconds
>> Forward delay : 15 seconds
>> Message age : 0
>> Number of topology changes : 1
>> Time since last topology change : 396 seconds
>> Local parameters
>> Bridge ID : 8192.80:71:1f:8c:7f:d0 <<<
>> Extended system ID : 0
>
>
>
> On 11/2/10 7:08 PM, "David Lockuan" wrote:
>
>> Hi guys,
>>
>> I'm testing the protocols rstp over logical-systems, but when I set the
>> priority over one interface for it work as root, it is not change the status
>> in the protocols rstp and the other interface don't change to Blocking.
>> theirs always keep on Forwarding state.
>>
>> The topology that I am using it is the next:
>>
>> SW1 (logical)---ge-3/0/2loop
>> fisicoge-3/0/3--SW2(logical)
>> SW1 (logical)---ge-3/0/4loop
>> fisicoge-3/0/5--SW2(logical)
>>
>> I want to put the interface ge-3/0/2 as root interface.
>>
>> These are configuration of both logical-systems:
>>
> **>
> *
>> {master}
>> n...@mx960-lab-re0> show configuration interfaces
>> ge-3/0/2 {
>> encapsulation ethernet-bridge;
>> }
>> ge-3/0/3 {
>> encapsulation ethernet-bridge;
>> }
>> ge-3/0/4 {
>> encapsulation ethernet-bridge;
>> }
>> ge-3/0/5 {
>> encapsulation ethernet-bridge;
>> }
>>
>> {master}
>> n...@mx960-lab-re0> show configuration logical-systems SW1
>> interfaces {
>> ge-3/0/2 {
>> unit 0 {
>> family bridge;
>> }
>> }
>> ge-3/0/4 {
>> unit 0 {
>> family bridge;
>> }
>> }
>> }
>> routing-instances {
>> 11 {
>> instance-type virtual-switch;
>> protocols {
>> rstp {
>> bridge-priority 0;
>> interface ge-3/0/2 {
>> priority 0;
>> mode point-to-point;
>> }
>> interface ge-3/0/4 {
>> mode point-to-point;
>> }
>> force-version stp;
>> }
>> }
>> bridge-domains {
>> br1 {
>> interface ge-3/0/2.0;
>> interface ge-3/0/4.0;
>> }
>> }
>> }
>> }
>>
>> {master}
>> n...@mx960-lab-re0> show configuration logical-systems SW2
>> interfaces {
>> ge-3/0/3 {
>> unit 0 {
>> family bridge;
>> }
>> }
>> ge-3/0/5 {
>> unit 0 {
>> family bridge;
>> }
>> }
>> }
>> routing-instances {
>> 12 {
>> instance-type virtual-switch;
>> protocols {
>> rstp {
>> bridge-priority 8k;
>> interface ge-3/0/3 {
>> mode point-to-point;
>> }
>> interface ge-3/0/5 {
>> mode point-to-point;
>> }
>> force-version stp;
>> }
>> }
>> bridge-domains {
>> br1 {
>> interface ge-3/0/3.0;
>> interface ge-3/0/5.0;
>> }
>> }
>> }
>> }
>>
>> {master}
>> n...@mx960-lab-re0>
>>
> **>
> *
>>
>> The output of the show spanning-tree commands:
>>
>>
> ***
