Re: [j-nsp] PPTP VPN through NAT on M10i
PPTP ALG is supported from JUNOS 11.2R1
GRE is not supported with "nat source dynamic"
HTH
Rgds
Alex
- Original Message -
From: "Jo Rhett"
To:
Sent: Tuesday, January 17, 2012 3:19 AM
Subject: [j-nsp] PPTP VPN through NAT on M10i
I've got a problem with NAT on an M10i with Junos 10.4. Simple PNAP
interface, works fine for TCP and UDP. Doesn't work for PPTP or IPSEC. Way
back in my mind I remember something about having to create a second nat
rule without port mapping, but its not working. I'm pretty sure I'm
forgetting something here. Can someone spare a 2x4 and clue me over the
head?
---yes, I know that the filters in the configuration below aren't active.
Here's the configuration now:
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/1/0 {
unit 0 {
family inet {
service {
input {
service-set NAT;
}
output {
service-set NAT;
}
}
address 192.168.2.1/24;
}
}
}
sp-0/3/0 {
unit 0 {
family inet;
}
}
….
firewall {
filter UNTRUST-IN {
term ICMP {
from {
destination-address {
192.168.2.1/4;
}
protocol icmp;
}
then accept;
}
term EVERYTHING-ELSE {
then {
discard;
}
}
}
filter TRUST-OUT {
term IPOUT {
from {
source-address {
192.168.1.0/24;
}
destination-address {
0.0.0.0/0;
}
}
then accept;
}
}
}
services {
service-set NAT {
nat-rules Outbound;
interface-service {
service-interface sp-0/3/0.0;
}
}
nat {
pool NATPOOL {
address 192.168.2.3/32
port {
automatic;
}
}
pool GRE-NATPOOL {
address 192.168.2.3/32
}
rule Outbound {
match-direction output;
term PPTP_VPNs {
from {
source-address {
192.168.1.0/24;
}
applications GRE-PPTP;
}
then {
translated {
source-pool GRE-NATPOOL;
translation-type {
source dynamic;
}
}
}
}
term Else {
from {
source-address {
192.168.1.0/24;
}
}
then {
translated {
source-pool NATPOOL;
translation-type {
source dynamic;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
}
applications {
application GRE-PPTP {
protocol gre;
}
}
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and
other randomness
___
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] tcp reset on srx
Yes it is "reject". Just found out that it is only over the IPSEC tunnel. Without IPSEC tunnel it seems to be working. On Tue, Jan 17, 2012 at 4:07 PM, Ben Dale wrote: > > Ashish, > > On 17/01/2012, at 1:19 PM, ashish verma wrote: > > > In our SRX deployment I am seeing an issue where client does not receive > a > > ICMP message back after getting denied by the policy. > > > > I can see that packet got dropped by the policy and SRX generates the > > tcp-rst but client does not receive anything. > > Can you confirm that your policy action is "reject" and not "deny"? > Otherwise the traffic will be dropped silently. > > Cheers, > > Ben > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] tcp reset on srx
Ashish, On 17/01/2012, at 1:19 PM, ashish verma wrote: > In our SRX deployment I am seeing an issue where client does not receive a > ICMP message back after getting denied by the policy. > > I can see that packet got dropped by the policy and SRX generates the > tcp-rst but client does not receive anything. Can you confirm that your policy action is "reject" and not "deny"? Otherwise the traffic will be dropped silently. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] PPTP VPN through NAT on M10i
I've got a problem with NAT on an M10i with Junos 10.4. Simple PNAP interface,
works fine for TCP and UDP. Doesn't work for PPTP or IPSEC. Way back in my
mind I remember something about having to create a second nat rule without port
mapping, but its not working. I'm pretty sure I'm forgetting something here.
Can someone spare a 2x4 and clue me over the head?
---yes, I know that the filters in the configuration below aren't active.
Here's the configuration now:
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/1/0 {
unit 0 {
family inet {
service {
input {
service-set NAT;
}
output {
service-set NAT;
}
}
address 192.168.2.1/24;
}
}
}
sp-0/3/0 {
unit 0 {
family inet;
}
}
….
firewall {
filter UNTRUST-IN {
term ICMP {
from {
destination-address {
192.168.2.1/4;
}
protocol icmp;
}
then accept;
}
term EVERYTHING-ELSE {
then {
discard;
}
}
}
filter TRUST-OUT {
term IPOUT {
from {
source-address {
192.168.1.0/24;
}
destination-address {
0.0.0.0/0;
}
}
then accept;
}
}
}
services {
service-set NAT {
nat-rules Outbound;
interface-service {
service-interface sp-0/3/0.0;
}
}
nat {
pool NATPOOL {
address 192.168.2.3/32
port {
automatic;
}
}
pool GRE-NATPOOL {
address 192.168.2.3/32
}
rule Outbound {
match-direction output;
term PPTP_VPNs {
from {
source-address {
192.168.1.0/24;
}
applications GRE-PPTP;
}
then {
translated {
source-pool GRE-NATPOOL;
translation-type {
source dynamic;
}
}
}
}
term Else {
from {
source-address {
192.168.1.0/24;
}
}
then {
translated {
source-pool NATPOOL;
translation-type {
source dynamic;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
}
applications {
application GRE-PPTP {
protocol gre;
}
}
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other
randomness
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] tcp reset on srx
Hi All, In our SRX deployment I am seeing an issue where client does not receive a ICMP message back after getting denied by the policy. I can see that packet got dropped by the policy and SRX generates the tcp-rst but client does not receive anything. Here is the traceoption log Jan 16 18:59:25 18:59:24.1596505:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT: pak processing end. Jan 16 18:59:25 18:59:24.1596527:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT:Denied by policy 150,*generating icmp/tcp-rst* Jan 16 18:59:25 18:59:24.1596538:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT: packet dropped, denied by policy Jan 16 18:59:25 18:59:24.1596549:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT: packet dropped, policy deny. Anyone else has seen this issue or have any suggestions? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] T320 mid mount frame
Hi, Where can you buy chassis mid-mount rails for T320 ? I need some 5 sets or more. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 cluster - ethernet switching issue
Are you suggesting something aong these lines?
Interfaces for
ge-2/0/4 {
description "*** Connected to XXX***";
gigether-options {
redundant-parent reth4;
ge-11/0/4 {
description "*** Connected to XXX***";
gigether-options {
redundant-parent reth4;
ge-2/0/5 {
description "*** Connected to XXX***";
gigether-options {
redundant-parent reth5;
ge-11/0/5 {
description "*** Connected to XXX***";
gigether-options {
redundant-parent reth5;
set interfaces reth4 vlan-tagging
set interfaces reth4 description "*** Connected to XXX TRUNK #1 ***";
set interfaces reth4 redundant-ether-options redundancy-group 4
set interfaces reth4 unit 200 vlan-id 200
set interfaces reth4 unit 200 family inet address 192.168.200.0/24
set interfaces reth4 unit 201 vlan-id 201
set interfaces reth4 unit 201 family inet address 192.168.201.0/24
set interfaces reth4 unit 202 vlan-id 202
set interfaces reth4 unit 202 family inet address 192.168.202.0/24
set interfaces reth5 vlan-tagging
set interfaces reth5 description "*** Connected to XXX TRUNK #2 ***";
set interfaces reth5 redundant-ether-options redundancy-group 5
set interfaces reth5 unit 205 vlan-id 205
set interfaces reth5 unit 205 family inet address 192.168.205.0/24
set interfaces reth5 unit 206 vlan-id 206
set interfaces reth5 unit 206 family inet address 192.168.206.0/24
set interfaces reth5 unit 207 vlan-id 207
set interfaces reth5 unit 207 family inet address 192.168.207.0/24
Then, on the EX side - just simple trunk configuration permitting said VLAN's
for those ports?
Thank you again.
From: Павел Лунин [plu...@senetsy.ru]
Sent: Monday, January 16, 2012 3:58 PM
To: Paulhamus, Jon
Cc: Ben Dale; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX650 cluster - ethernet switching issue
The case what not that I was connecting end points directly to the SRX, it's
that I wanted 2 trunk links between each SRX node and the switch stack (there
is only 1 switch stack), each of the 2 links supporting different VLAN's. So
- 2 links from the primary node to the switch stack, and 2 links from the
secondary node to the switch stack as well... this does not work with STP
enabled as 3 of the 4 links get blocked by STP. I needed a setup like this as
I'm pushing over 1Gb through each switch link.
My favorite design is to connect each SRX to its own (no cross-links) VC-member
using several physical links (as many as you need for performance) and to use
L3 on top of reth VLAN units, each of which includes two physical links
(primary and secondary). You can distribute VLANs across reths manually, just
as you would do for STP (if it worked). At the SRX side you have several reth
interfaces with units on them, at the VC side you use interface-range for
bundling ports connected to primary and secondary SRX into a single config
knob, which is really useful. Of course, on SRXes, when you move a VLAN X from,
say, reth0 to reth1, you also need to replace reth0.X to reth1.X in the rest of
config (zones, etc) but JUNOS allows you to do so with a single command.
You can either bound all the reths into a single RG1 (always active/passive) or
put each reth into a dedicated RG (partial active/active). You can even easily
make different nodes act as master for different RGs, though in most cases it
will give nothing except pain in the rear. I love the first approach (one RG1
for all reths) because it's much simpler. RG1/2/3/etc failover is quite fast
(sufficient for most applications) so failing over all the reths to backup node
in case only one of the primary node links fails is not a very high price for
the simplicity.
A small drawback of this design is h-shape switching, if you connect downlink
devices to the VC with LAGs. Traffic will come to the VC balanced between the
switches connected to active and backup SRXes. So the VC will first forward the
frames to the switch, connected to the active SRX via internal VC link. But if
we consider a VC of 2×EX4200 connected with two VC cables, this is not much of
a problem.
You can also add cross-links and bound four interfaces into a single LAG/reth
(a hybrid of the two) on SRX (two links on master are active, two on backup are
down), but JUNOS does not allow to bound two ae interfaces into an interface
range on the EX side. So for each reth on SRX you will have two ae's on EX.This
is hateful and prone to mistakes. On the other hand this approach will give you
the ability to balance traffic across two links (SRX1―EX1 and SRX1―EX2)
automatically with hashing (limited to two links only) and additional speed of
switching over LAG members in case of a failure. When switches are connected
not with 2×32G cables but something else (1G llinks or 10G and it's an SRX High
End cluster) this approach will also save some resources because of avoiding
interswitch forwarding
Re: [j-nsp] SRX650 cluster - ethernet switching issue
Hi Pavel - I believe that what you are describing is exactly what I'm looking for, but I did not realize this was the proper way to configure. Can you please provide a configuration example? Thanks again for all of the input. From: Павел Лунин [plu...@senetsy.ru] Sent: Monday, January 16, 2012 3:58 PM To: Paulhamus, Jon Cc: Ben Dale; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 cluster - ethernet switching issue The case what not that I was connecting end points directly to the SRX, it's that I wanted 2 trunk links between each SRX node and the switch stack (there is only 1 switch stack), each of the 2 links supporting different VLAN's. So - 2 links from the primary node to the switch stack, and 2 links from the secondary node to the switch stack as well... this does not work with STP enabled as 3 of the 4 links get blocked by STP. I needed a setup like this as I'm pushing over 1Gb through each switch link. My favorite design is to connect each SRX to its own (no cross-links) VC-member using several physical links (as many as you need for performance) and to use L3 on top of reth VLAN units, each of which includes two physical links (primary and secondary). You can distribute VLANs across reths manually, just as you would do for STP (if it worked). At the SRX side you have several reth interfaces with units on them, at the VC side you use interface-range for bundling ports connected to primary and secondary SRX into a single config knob, which is really useful. Of course, on SRXes, when you move a VLAN X from, say, reth0 to reth1, you also need to replace reth0.X to reth1.X in the rest of config (zones, etc) but JUNOS allows you to do so with a single command. You can either bound all the reths into a single RG1 (always active/passive) or put each reth into a dedicated RG (partial active/active). You can even easily make different nodes act as master for different RGs, though in most cases it will give nothing except pain in the rear. I love the first approach (one RG1 for all reths) because it's much simpler. RG1/2/3/etc failover is quite fast (sufficient for most applications) so failing over all the reths to backup node in case only one of the primary node links fails is not a very high price for the simplicity. A small drawback of this design is h-shape switching, if you connect downlink devices to the VC with LAGs. Traffic will come to the VC balanced between the switches connected to active and backup SRXes. So the VC will first forward the frames to the switch, connected to the active SRX via internal VC link. But if we consider a VC of 2×EX4200 connected with two VC cables, this is not much of a problem. You can also add cross-links and bound four interfaces into a single LAG/reth (a hybrid of the two) on SRX (two links on master are active, two on backup are down), but JUNOS does not allow to bound two ae interfaces into an interface range on the EX side. So for each reth on SRX you will have two ae's on EX.This is hateful and prone to mistakes. On the other hand this approach will give you the ability to balance traffic across two links (SRX1―EX1 and SRX1―EX2) automatically with hashing (limited to two links only) and additional speed of switching over LAG members in case of a failure. When switches are connected not with 2×32G cables but something else (1G llinks or 10G and it's an SRX High End cluster) this approach will also save some resources because of avoiding interswitch forwarding, as described above. Though in my experience it's not usually worth the 'two on EX ― one on SRX' interface matching headache. -- Regards, Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 cluster - ethernet switching issue
> The case what not that I was connecting end points directly to the SRX, > it's that I wanted 2 trunk links between each SRX node and the switch stack > (there is only 1 switch stack), each of the 2 links supporting different > VLAN's. So - 2 links from the primary node to the switch stack, and 2 > links from the secondary node to the switch stack as well... this does not > work with STP enabled as 3 of the 4 links get blocked by STP. I needed a > setup like this as I'm pushing over 1Gb through each switch link. > > My favorite design is to connect each SRX to its own (no cross-links) VC-member using several physical links (as many as you need for performance) and to use L3 on top of reth VLAN units, each of which includes two physical links (primary and secondary). You can distribute VLANs across reths manually, just as you would do for STP (if it worked). At the SRX side you have several reth interfaces with units on them, at the VC side you use interface-range for bundling ports connected to primary and secondary SRX into a single config knob, which is really useful. Of course, on SRXes, when you move a VLAN X from, say, reth0 to reth1, you also need to replace reth0.X to reth1.X in the rest of config (zones, etc) but JUNOS allows you to do so with a single command. You can either bound all the reths into a single RG1 (always active/passive) or put each reth into a dedicated RG (partial active/active). You can even easily make different nodes act as master for different RGs, though in most cases it will give nothing except pain in the rear. I love the first approach (one RG1 for all reths) because it's much simpler. RG1/2/3/etc failover is quite fast (sufficient for most applications) so failing over all the reths to backup node in case only one of the primary node links fails is not a very high price for the simplicity. A small drawback of this design is h-shape switching, if you connect downlink devices to the VC with LAGs. Traffic will come to the VC balanced between the switches connected to active and backup SRXes. So the VC will first forward the frames to the switch, connected to the active SRX via internal VC link. But if we consider a VC of 2×EX4200 connected with two VC cables, this is not much of a problem. You can also add cross-links and bound four interfaces into a single LAG/reth (a hybrid of the two) on SRX (two links on master are active, two on backup are down), but JUNOS does not allow to bound two ae interfaces into an interface range on the EX side. So for each reth on SRX you will have two ae's on EX.This is hateful and prone to mistakes. On the other hand this approach will give you the ability to balance traffic across two links (SRX1—EX1 and SRX1—EX2) automatically with hashing (limited to two links only) and additional speed of switching over LAG members in case of a failure. When switches are connected not with 2×32G cables but something else (1G llinks or 10G and it's an SRX High End cluster) this approach will also save some resources because of avoiding interswitch forwarding, as described above. Though in my experience it's not usually worth the 'two on EX — one on SRX' interface matching headache. -- Regards, Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] HDD Write Error
Isidoro, the SSD must be jumpered to SLAVE. The onboard CF is already master and thus you get this error message (PAGE FAULT). The other error message you have when you set it to SLAVE is probably because you have no active partition on the SSD (did you re-install junos on the SSD?). Please jumper the SSD to slave and re-install JunOS via a PCMCIA card. Best regards, Jonas Frey Am Montag, den 16.01.2012, 15:51 +0100 schrieb Juniper GOWEX: > Hi all, > > We have disk errors again. We bought a SSD ( TS8GSSD25-S ) to replace > the HDD with problems. If we connect the SSD the router does not boot, > the following error appears: > > - SSD as CS or Slave: > > Will try to boot from : > PCMCIA ATA Flash Card... > Compact Flash... > Hard Disk... > Ethernet... > > Trying to Boot from Hard Disk... > Not found any [active partition] in HDD > > Trying to Boot from Ethernet... > > Intel LANDesk (R) Service Agent II, version > 0.99k > Copyright (C) 1997,1998 Intel Corporation. > All rights reserved. > > PXE-E61: Media test failure, check cable. > PXE-M0F: Exiting LANDesk (R) Service Agent II > > Trying to Boot from PCMCIA ATA Flash Card... > Error: No Drive E... > > Trying to Boot from Compact Flash... > Boot error > > > - SSD as Master: > > > Trying to Boot from Compact Flash... > Loading /boot/loader > Console: serial port > BIOS drive A: is disk0 > BIOS drive C: is disk1 > BIOS 639kB/785344kB available memory > > FreeBSD/i386 bootstrap loader, Revision 0.8 > (buil...@xathanon.juniper.net, Sat Jul 2 > 01:44:10 GMT 2005) > Loading /boot/defaults/loader.conf > /kernel text=0x3fe2c1 data=0x34c08+0x53cd0 > syms=[0x4+0x49cf0+0x4+0x59681] > > > Hit [Enter] to boot immediately, or space bar > for command prompt. > Booting [kernel]... > Copyright (c) 1996-2001, Juniper Networks, > Inc. > All rights reserved. > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, > 1989, 1991, 1992, 1993, 1994 > The Regents of the University of > California. All rights reserved. > JUNOS 7.3R1.4 #0: 2005-07-02 02:23:12 UTC > > > buil...@xathanon.juniper.net:/build/xathanon-c/7.3R1.4/obj-i386/sys/compile/JUNIPER > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 331706449 Hz > CPU: Pentium II/Pentium II Xeon/Celeron > (331.71-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x66a > Stepping = 10 > > > Features=0x183f9ff > real memory = 805306368 (786432K bytes) > sio0: gdb debugging port > avail memory = 776638464 (758436K bytes) > Preloaded elf kernel "kernel" at 0xc062c000. > DEVFS: ready for devices > Pentium Pro MTRR support enabled > md0: Malloc disk > Using $PIR table, 14 entries at 0xc00fde70 > DRAM Data Integrity Mode: ECC Mode with h/w > scrubbing > npx0: on motherboard > npx0: INT 16 interface > pcib0: disabled)> on motherboard > pci0: on pcib0 > isab0: at > device 7.0 on pci0 > isa0: on isab0 >
Re: [j-nsp] SRX650 cluster - ethernet switching issue
Is there any reason you aren't using reth groups? You can do an AE with those. Morgan On Mon, Jan 16, 2012 at 10:44 AM, Paulhamus, Jon wrote: > Thanks for the reply. > > The case what not that I was connecting end points directly to the SRX, > it's that I wanted 2 trunk links between each SRX node and the switch stack > (there is only 1 switch stack), each of the 2 links supporting different > VLAN's. So - 2 links from the primary node to the switch stack, and 2 > links from the secondary node to the switch stack as well... this does not > work with STP enabled as 3 of the 4 links get blocked by STP. I needed a > setup like this as I'm pushing over 1Gb through each switch link. > > > > > > > > -Original Message- > From: Pavel Lunin [mailto:plu...@senetsy.ru] > Sent: Monday, January 16, 2012 9:32 AM > To: Paulhamus, Jon > Cc: Ben Dale; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] SRX650 cluster - ethernet switching issue > > > > Sorry, missed this reply because of the new year holidays. > > >> BTW, never could understand people running L2 on srx650 coupled with a > normal switch. Especially in srx-cluster + ex-vc. What for? > > Why not? If you have more devices that need access to specific vlan > zones on the SRX, and you're low on physical interfaces, why not use a > switch. This can be extremely handy when bringing trunks into a VMWare > server(s). > > > > When you build a FW cluster, you anyway must have a pair of supporting > switches in almost all sorts of design. Either each SRX connected to its > own switch (I prefer this) or full mesh (people like this but there is no > much sense, imho). So in terms of the number of physical ports, it seems > like this is not the SRX's job (in most cases). Although in case of port > deficit, this can be a kind of workaround, I agree. > > > I'm not sure what you're saying about especially in a cluster either - > clustering of the firewalls is soley for redundancy in my situation. > > If you physically connect something to SRX in cluster mode, not to the > supporting switches, it becomes complicated to teach the device to switch > traffic to a different SRX node in case of a failure. Say, you have SRX1 > and SRX2 in cluster. SRX1 connected to SW1 and SRX2 connected to SW2. SRX1 > is primary for RG0 and RG1. Say, SW1 and SW2 form a VC. You have some > devices connected to the VC (most probably using LAGs) and some devices > connected to the SRXes itself (LAG is not supported here, AFAIR). Let's say > SW1 fails and SRX1-SW1 link does so as well. RG1 switches to the backup > node SRX2. But how the directly connected device will know it should > forward traffic to the second node? In case it still send it to SRX1, this > will lead to h-shape forwarding through the swfab link (not good). xSTP can > help, but it moves the solution further from best (I don't even want to > think of what can happen with STP in case of SRX's RG0 switchover). You > anyway must run xSTP though, since you now have two switch nodes instead of > one. > > Add here operational expenses of managing and troubleshooting switching > stuff of SRXs instead of just on VC and lack of some switching features. > I think, it's cheaper overall to just add port-capacity to the switch > cluster. So, while it does work in principle, as a design for a new setup, > I'd say, it's a bit clumsy. > > ___ > 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 cluster - ethernet switching issue
Thanks for the reply. The case what not that I was connecting end points directly to the SRX, it's that I wanted 2 trunk links between each SRX node and the switch stack (there is only 1 switch stack), each of the 2 links supporting different VLAN's. So - 2 links from the primary node to the switch stack, and 2 links from the secondary node to the switch stack as well... this does not work with STP enabled as 3 of the 4 links get blocked by STP. I needed a setup like this as I'm pushing over 1Gb through each switch link. -Original Message- From: Pavel Lunin [mailto:plu...@senetsy.ru] Sent: Monday, January 16, 2012 9:32 AM To: Paulhamus, Jon Cc: Ben Dale; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 cluster - ethernet switching issue Sorry, missed this reply because of the new year holidays. >> BTW, never could understand people running L2 on srx650 coupled with a >> normal switch. Especially in srx-cluster + ex-vc. What for? > Why not? If you have more devices that need access to specific vlan zones on > the SRX, and you're low on physical interfaces, why not use a switch. This > can be extremely handy when bringing trunks into a VMWare server(s). > When you build a FW cluster, you anyway must have a pair of supporting switches in almost all sorts of design. Either each SRX connected to its own switch (I prefer this) or full mesh (people like this but there is no much sense, imho). So in terms of the number of physical ports, it seems like this is not the SRX's job (in most cases). Although in case of port deficit, this can be a kind of workaround, I agree. > I'm not sure what you're saying about especially in a cluster either - > clustering of the firewalls is soley for redundancy in my situation. If you physically connect something to SRX in cluster mode, not to the supporting switches, it becomes complicated to teach the device to switch traffic to a different SRX node in case of a failure. Say, you have SRX1 and SRX2 in cluster. SRX1 connected to SW1 and SRX2 connected to SW2. SRX1 is primary for RG0 and RG1. Say, SW1 and SW2 form a VC. You have some devices connected to the VC (most probably using LAGs) and some devices connected to the SRXes itself (LAG is not supported here, AFAIR). Let's say SW1 fails and SRX1-SW1 link does so as well. RG1 switches to the backup node SRX2. But how the directly connected device will know it should forward traffic to the second node? In case it still send it to SRX1, this will lead to h-shape forwarding through the swfab link (not good). xSTP can help, but it moves the solution further from best (I don't even want to think of what can happen with STP in case of SRX's RG0 switchover). You anyway must run xSTP though, since you now have two switch nodes instead of one. Add here operational expenses of managing and troubleshooting switching stuff of SRXs instead of just on VC and lack of some switching features. I think, it's cheaper overall to just add port-capacity to the switch cluster. So, while it does work in principle, as a design for a new setup, I'd say, it's a bit clumsy. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OP script to show descriptions
Thank you very much, Phil
On Sat, Jan 14, 2012 at 7:05 AM, Phil Shafer wrote:
> tim tiriche writes:
>>Would anyone have an op script that when executed shows the
>>description of the interface of 'show isis adjancency' or 'show ospf
>>neighbor'
>
> I don't run ISIS in my test lab, but here's a a script I whipped
> up for you that handles OSPF:
>
> user@cli> op test
> Neighbor Interface State Description
> 10.5.10.2 fe-0/0/1.0 Full Link to SJC (10.5.10.2)
> 10.5.13.2 fe-0/0/2.0 Full Link to LAX (10.5.13.2)
> 10.5.12.2 fe-0/3/1.0 Full Link to AUS (10.5.12.2)
>
> IIRC there's a sample script on junos.juniper.net that does "show
> interfaces" with "show interfaces descriptions" merged in, which
> but I did this one from scratch since it was simple enough.
>
> Thanks,
> Phil
>
>
> version 1.0;
>
> ns junos = "http://xml.juniper.net/junos/*/junos";;
> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;
>
> import "../import/junos.xsl";
>
> var $fmt = "%-16s %-20s %-8s %s";
>
> match / {
> {
> {
> var $conn = jcs:open();
> var $rpc = {
> ;
> }
> var $interfaces = jcs:execute($conn, $rpc);
> var $ospf = jcs:execute($conn, "get-ospf-neighbor-information");
>
> jcs:printf($fmt, "Neighbor", "Interface",
> "State", "Description");
>
> for-each ($ospf/ospf-neighbor) {
> var $ifname = interface-name;
> var $desc = {
> var $xdesc = $interfaces/*[name == $ifname]/description;
> if ($xdesc) {
> expr $xdesc;
> } else {
> var $ifd = substring-before($ifname, ".");
> expr $interfaces/*[name == $ifd]/description;
> }
> }
>
> jcs:printf($fmt, neighbor-address, $ifname,
> ospf-neighbor-state, $desc);
> }
> }
> }
> }
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] HDD Write Error
Hi all, We have disk errors again. We bought a SSD ( TS8GSSD25-S ) to replace the HDD with problems. If we connect the SSD the router does not boot, the following error appears: /_- SSD as CS or Slave:_ Will try to boot from : PCMCIA ATA Flash Card... Compact Flash... Hard Disk... Ethernet... Trying to Boot from Hard Disk... Not found any [active partition] in HDD Trying to Boot from Ethernet... Intel LANDesk (R) Service Agent II, version 0.99k Copyright (C) 1997,1998 Intel Corporation. All rights reserved. PXE-E61: Media test failure, check cable. PXE-M0F: Exiting LANDesk (R) Service Agent II Trying to Boot from PCMCIA ATA Flash Card... Error: No Drive E... Trying to Boot from Compact Flash... Boot error _- SSD as Master:_ Trying to Boot from Compact Flash... Loading /boot/loader Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/785344kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 (buil...@xathanon.juniper.net, Sat Jul 2 01:44:10 GMT 2005) Loading /boot/defaults/loader.conf /kernel text=0x3fe2c1 data=0x34c08+0x53cd0 syms=[0x4+0x49cf0+0x4+0x59681] Hit [Enter] to boot immediately, or space bar for command prompt. Booting [kernel]... Copyright (c) 1996-2001, Juniper Networks, Inc. All rights reserved. Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. JUNOS 7.3R1.4 #0: 2005-07-02 02:23:12 UTC buil...@xathanon.juniper.net:/build/xathanon-c/7.3R1.4/obj-i386/sys/compile/JUNIPER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 331706449 Hz CPU: Pentium II/Pentium II Xeon/Celeron (331.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x66a Stepping = 10 Features=0x183f9ff real memory = 805306368 (786432K bytes) sio0: gdb debugging port avail memory = 776638464 (758436K bytes) Preloaded elf kernel "kernel" at 0xc062c000. DEVFS: ready for devices Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 14 entries at 0xc00fde70 DRAM Data Integrity Mode: ECC Mode with h/w scrubbing npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: at 7.2 irq 11 smb0: port 0x5000-0x500f at device 7.3 on pci0 pcic0: mem 0xe6205000-0xe6205fff irq 15 at device 13.0 on pci0 pcic0: TI12XX PCI Config Reg: [pci only] pccard0: on pcic0 pcic1: mem 0xe620-0xe6200fff irq 7 at device 13.1 on pci0 pcic1: TI12XX PCI Config Reg: [pci only] pccard1: on pcic1 fxp0: port 0xdc00-0xdc3f mem 0xe610-0xe61f,0xe6204000-0xe6204fff irq 7 at device 16.0 on pci0 fxp1: port 0xe000-0xe03f mem 0xe600-0xe60f,0xe6207000-0xe6207fff irq 10 at device 19.0 on pci0 orm0: at iomem 0xc8000-0xc87ff,0xc9000-0xc97ff on isa0 ata2 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 vga0: at port 0x3b0-0x3bb iomem 0xb-0xb7fff on isa0 sc0: at flags 0x100 on isa0 sc0: MDA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16550A, console sio1 at port 0x3e8-0x3ef irq 5 on isa0 sio1: type 16550A sio2 at port 0x2f8-0x2ff irq 3 on isa0 sio2: type 16550A sio3: configured irq 7 not in bitmap of probed irqs 0 fxp0: Ethernet address 00:a0:a5:12:25:94 fxp1: Ethernet address 02:00:00:00:00:04 DEVFS: ready to run ad0: 248MB [994/16/32] at ata0-master PIO4 Mounting root from ufs:/dev/ad0s1a if_pfe_open: listener socket opened, listening... BAD_PAGE_FAULT: pid 1 (preinit), uid 0: pc 0x804cc83 got a read fault at 0xd, x86 fault flags = 0x4 Trapframe R
Re: [j-nsp] SRX650 cluster - ethernet switching issue
Sorry, missed this reply because of the new year holidays. BTW, never could understand people running L2 on srx650 coupled with a normal switch. Especially in srx-cluster + ex-vc. What for? Why not? If you have more devices that need access to specific vlan zones on the SRX, and you're low on physical interfaces, why not use a switch. This can be extremely handy when bringing trunks into a VMWare server(s). When you build a FW cluster, you anyway must have a pair of supporting switches in almost all sorts of design. Either each SRX connected to its own switch (I prefer this) or full mesh (people like this but there is no much sense, imho). So in terms of the number of physical ports, it seems like this is not the SRX's job (in most cases). Although in case of port deficit, this can be a kind of workaround, I agree. I'm not sure what you're saying about especially in a cluster either - clustering of the firewalls is soley for redundancy in my situation. If you physically connect something to SRX in cluster mode, not to the supporting switches, it becomes complicated to teach the device to switch traffic to a different SRX node in case of a failure. Say, you have SRX1 and SRX2 in cluster. SRX1 connected to SW1 and SRX2 connected to SW2. SRX1 is primary for RG0 and RG1. Say, SW1 and SW2 form a VC. You have some devices connected to the VC (most probably using LAGs) and some devices connected to the SRXes itself (LAG is not supported here, AFAIR). Let's say SW1 fails and SRX1-SW1 link does so as well. RG1 switches to the backup node SRX2. But how the directly connected device will know it should forward traffic to the second node? In case it still send it to SRX1, this will lead to h-shape forwarding through the swfab link (not good). xSTP can help, but it moves the solution further from best (I don't even want to think of what can happen with STP in case of SRX's RG0 switchover). You anyway must run xSTP though, since you now have two switch nodes instead of one. Add here operational expenses of managing and troubleshooting switching stuff of SRXs instead of just on VC and lack of some switching features. I think, it's cheaper overall to just add port-capacity to the switch cluster. So, while it does work in principle, as a design for a new setup, I'd say, it's a bit clumsy. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Load Balancing on 2x MSPIC 100 for NAT
> 5) Create the service-filters: > > set firewall family inet service-filter SS_PART1_FILTER term part1 from > source- > address 10.100.0.0/17 > set firewall family inet service-filter SS_PART1_FILTER term part1 then > service > set firewall family inet service-filter SS_PART1_FILTER term default then > skip > set firewall family inet service-filter SS_PART2_FILTER term part2 from > source- > address 10.100.128.0/17 > set firewall family inet service-filter SS_PART2_FILTER term part2 then > service > set firewall family inet service-filter SS_PART2_FILTER term default then > skip > > There's a trick to reach more accurate manual LB. Something like: set firewall family inet service-filter SS_PART1_FILTER term part1 from source-address 10.100.0.0/255.255.0.1 ... set firewall family inet service-filter SS_PART2_FILTER term part1 from source-address 10.100.0.1/255.255.0.1 Even addresses go left, odd ones go right. Does not matter how your 10.100/16 is divided into subnets, how many subscribers you have in each half or whatever. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
