Re: [j-nsp] Netconf for VCP - EX4550
Correct. I confused with MX-VC that supports it. By the way, the way you get that info on CLI is using "show virtual-chassis vc-port statistics vcp-x/y/z extensive" which is translated into the RPC call used in the script of the KB article you posted. On Monday, 19 August 2013, Giuliano Medalha wrote: > There is no option for: > > > show interface queue vcp-x/y/z > > > It does not support it. > > > I think that the following KB solved the problem for EX8208 and > EX4200/4500/4550: > > > http://kb.juniper.net/InfoCenter/index?page=content&id=KB27711&actp=RSS > > > Thanks a lot, > > Giuliano > > > > > WZTECH is registered trademark of WZTECH NETWORKS. > Copyright © 2013 WZTECH NETWORKS. All Rights Reserved. > > The information transmitted in this email message and any attachments are > solely for the intended recipient and may contain confidential or > privileged information. If you are not the intended recipient, any review, > transmission, dissemination or other use of this information is > prohibited. If you have received this communication in error, please notify > the sender immediately and delete the material from any computer, including > any copies. > > > On Fri, Aug 16, 2013 at 8:32 PM, Diogo Montagner < > diogo.montag...@gmail.com 'diogo.montag...@gmail.com');>> wrote: > >> The problem of this approach is that you are assuming all packets will >> have the same size. >> >> You could use the timestamp of each collection to calculate how many >> packets traversed the interface in that period. It doesn't have a good >> accuracy but will give something very close. >> >> What about getting the pps and bps from the show interface queue >> vcp-x/y/z ? >> >> Thanks >> >> On Saturday, 17 August 2013, Giuliano Medalha wrote: >> >>> People, >>> >>> We are doing a custom management system for VCP interfaces monitoring >>> using >>> NETCONF in JUNOS. >>> >>> The following stats are the only one reported to us: >>> >>> T2 >>> 3966099 >>> 3985901 >>> >>> T1 >>> 3966000 >>> 3985850 >>> >>> >>> How is possible to calculate the input rate and the ouput rate ? >>> >>> The MTU for the interface is 1514. >>> >>> Can we consider something like: >>> >>> 1514 x 8 x (3966099-3966000) / (T2 - T1) >>> >>> It can be considering a goog mean value ? Or we will have so much >>> variations for packet size ? >>> >>> packet size for JUNOS (VCP interface) is the same as ethernet frame-size >>> ? >>> >>> Thanks a lot, >>> >>> Giuliano >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> >> >> -- >> ./diogo -montagner >> JNCIE-SP 0x41A >> > > -- ./diogo -montagner JNCIE-SP 0x41A ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netconf for VCP - EX4550
There is no option for: show interface queue vcp-x/y/z It does not support it. I think that the following KB solved the problem for EX8208 and EX4200/4500/4550: http://kb.juniper.net/InfoCenter/index?page=content&id=KB27711&actp=RSS Thanks a lot, Giuliano WZTECH is registered trademark of WZTECH NETWORKS. Copyright © 2013 WZTECH NETWORKS. All Rights Reserved. The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies. On Fri, Aug 16, 2013 at 8:32 PM, Diogo Montagner wrote: > The problem of this approach is that you are assuming all packets will > have the same size. > > You could use the timestamp of each collection to calculate how many > packets traversed the interface in that period. It doesn't have a good > accuracy but will give something very close. > > What about getting the pps and bps from the show interface queue vcp-x/y/z > ? > > Thanks > > On Saturday, 17 August 2013, Giuliano Medalha wrote: > >> People, >> >> We are doing a custom management system for VCP interfaces monitoring >> using >> NETCONF in JUNOS. >> >> The following stats are the only one reported to us: >> >> T2 >> 3966099 >> 3985901 >> >> T1 >> 3966000 >> 3985850 >> >> >> How is possible to calculate the input rate and the ouput rate ? >> >> The MTU for the interface is 1514. >> >> Can we consider something like: >> >> 1514 x 8 x (3966099-3966000) / (T2 - T1) >> >> It can be considering a goog mean value ? Or we will have so much >> variations for packet size ? >> >> packet size for JUNOS (VCP interface) is the same as ethernet frame-size ? >> >> Thanks a lot, >> >> Giuliano >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > -- > ./diogo -montagner > JNCIE-SP 0x41A > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mx5 traffic generator
Hi Rodrigo, some suggestions can be found here: http://www.juniper.net/us/en/community/junos/training-certification/day-one/networking-technologies-series/a-packet-walkthrough/ HTH ./diogo -montagner JNCIE-SP 0x41A On Mon, Aug 19, 2013 at 6:31 AM, Rodrigo Augusto wrote: > Hi folks! > Does anyone knows if can i generate traffic from mx to mx?! Like iperf or > ostinato... > > > Enviado via iPhone > Grupo Connectoway > > Em 18/08/2013, às 16:56, Giuliano Medalha > escreveu: > > > People, > > > > Someone on the list have implemented virtual chassis using EX8208 before > ? > > > > We are looking for some sample of configuration related to a firewall > > filter (Ex. PROTECT-RE) for EX8208 in a Virtual Chassis Environment ? > > > > Is it possible to use the same loopback address ? It will protect the > > external XRE200 at the same way ? Is it correct ? > > > > I am looking for some reference inside JUNIPER web site without sucess. > > > > The VCP ports must be configured with any kind of filter ? > > > > The input policer is not permited in loopback 0 ... how is possible to > > policer ICMP packets for example ? > > > > Does anyone on list has some experience with that ? > > > > 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] VPN tunnel between OpenSwan and SRX220
Hi Laurent. Is your ultimate goal to get the GRE running over IPSEC, or just a vanilla IPSEC tunnel? Your configuration will need to change either way: If you want GRE over IPSEC: You need to remove the /32 on the st0.0 interface and the Openswan rightsourceip and make them a contiguous subnet eg: 172.31.254.41/30 on the Juniper side 172.31.254.42/30 on the Openswan side Now adjust your GRE configuration to use these addresses for source and destination on both ends Now adjust your remote proxy-id on the SRX and leftsubnet on Openswan to match (just the IPs, leave the mask as /32). The logic behind this is that you will only encrypt traffic between 172.31.254.41/32 and 172.31.254.42/32 which will be your GRE tunnelled traffic (all other traffic will be wrapped up inside this GRE). As an aside - the last time I checked, the SRX seemed to only use the Proxy-ID to negotiate the tunnel and then promptly ignored it and allowed you to send and receive whatever traffic your routes and policy allowed. If you're just trying to do vanilla IPSEC tunnels: Again, change the /32s on the st0.0 and Openswan rightsourceip: 172.31.254.41/30 on the Juniper side (or leave it unnumbered) 172.31.254.42/30 on the Openswan side Now on the SRX change your proxy-id local to 192.168.123.0/24 and remote to whatever is sitting behind the Openswan box (eg: leftsubnet) On Openswan, change the right-subnet to 192.168.123.0/24 and left-subnet to whatever you're trying to tunnel across (or leave it as-is if it's just this host, or you're source-natting) Once you've got this in place and st0.0 comes up, you'll just need to point static routes on the SRX side to st0.0 or the Openswan next-hop (172.31.254.42) and vice-versa. If it's still not working, send through the output of: show security ipsec security-associations Cheers, Ben On 07/08/2013, at 1:55 AM, Laurent CARON wrote: > Hi, > > I'm trying to establish a VPN tunnel between a SRX220 and an OpenSwan box. > > SRX is: > Model: srx220h > JUNOS Software Release [12.1X44-D20.3] > > OpenSwan: 2.6.37 > > Both are currently hooked on a test LAN. > > 192.168.0.18 = openswan box on lan > 192.168.0.120 = juniper box on lan > > 172.31.254.41 = ipsec on juniper box > 172.31.254.27 = ipsec on openswan box > > 172.31.255.27 = loopback on juniper box > > Not relevant for now: > 10.254.2.33 = gre tunnel on openswan side > 10.254.2.34 = gre tunnel on juniper side > > Here is the config on the Juniper side: > > set interfaces ge-0/0/0 mtu 1514 > set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.120/24 > > set interfaces gr-0/0/0 unit 0 tunnel source 172.31.254.41 > set interfaces gr-0/0/0 unit 0 tunnel destination 172.31.254.27 > set interfaces gr-0/0/0 unit 0 family inet address 10.254.2.34/32 > > set interfaces lo0 unit 0 family inet address 172.31.255.41/32 > > set interfaces st0 unit 0 family inet address 172.31.254.41/32 > > set interfaces vlan unit 0 family inet address 192.168.123.1/24 > > set routing-options static route 172.31.254.27/32 next-hop st0.0 > > set security ike traceoptions file vpn-debug-ike > set security ike traceoptions flag all > > set security ike proposal ike_aes_128 authentication-method pre-shared-keys > > set security ike proposal ike_aes_128 dh-group group2 > set security ike proposal ike_aes_128 authentication-algorithm sha1 > set security ike proposal ike_aes_128 encryption-algorithm 3des-cbc > set security ike proposal ike_aes_128 lifetime-seconds 3600 > > set security ike policy phase1_aes_128 mode main > set security ike policy phase1_aes_128 proposals ike_aes_128 > set security ike policy phase1_aes_128 pre-shared-key ascii-text "pwd" > > set security ike gateway RTR-SIEGE-001 ike-policy phase1_aes_128 > set security ike gateway RTR-SIEGE-001 address 192.168.0.18 > set security ike gateway RTR-SIEGE-001 no-nat-traversal > set security ike gateway RTR-SIEGE-001 external-interface ge-0/0/0.0 > > set security ipsec proposal ipsec_aes_128 protocol esp > set security ipsec proposal ipsec_aes_128 authentication-algorithm > hmac-sha1-96 > > set security ipsec proposal ipsec_aes_128 encryption-algorithm 3des-cbc > set security ipsec proposal ipsec_aes_128 lifetime-seconds 3600 > > set security ipsec policy phase2_aes_128 proposals ipsec_aes_128 > > set security ipsec vpn VPN_TO_SIEGE-001 bind-interface st0.0 > set security ipsec vpn VPN_TO_SIEGE-001 ike gateway RTR-SIEGE-001 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity local > 172.31.254.41/32 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity remote > 172.31.254.27/32 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity service any > set security ipsec vpn VPN_TO_SIEGE-001 ike ipsec-policy phase2_aes_128 > set security ipsec vpn VPN_TO_SIEGE-001 establish-tunnels immediately > > set security flow traceoptions file vpn-debug > set security flow traceoptions flag basic-datapath > set security flow traceoptions flag packe
[j-nsp] Mx5 traffic generator
Hi folks! Does anyone knows if can i generate traffic from mx to mx?! Like iperf or ostinato... Enviado via iPhone Grupo Connectoway Em 18/08/2013, às 16:56, Giuliano Medalha escreveu: > People, > > Someone on the list have implemented virtual chassis using EX8208 before ? > > We are looking for some sample of configuration related to a firewall > filter (Ex. PROTECT-RE) for EX8208 in a Virtual Chassis Environment ? > > Is it possible to use the same loopback address ? It will protect the > external XRE200 at the same way ? Is it correct ? > > I am looking for some reference inside JUNIPER web site without sucess. > > The VCP ports must be configured with any kind of filter ? > > The input policer is not permited in loopback 0 ... how is possible to > policer ICMP packets for example ? > > Does anyone on list has some experience with that ? > > 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] EX8208 Virtual Chassis Protection
People, Someone on the list have implemented virtual chassis using EX8208 before ? We are looking for some sample of configuration related to a firewall filter (Ex. PROTECT-RE) for EX8208 in a Virtual Chassis Environment ? Is it possible to use the same loopback address ? It will protect the external XRE200 at the same way ? Is it correct ? I am looking for some reference inside JUNIPER web site without sucess. The VCP ports must be configured with any kind of filter ? The input policer is not permited in loopback 0 ... how is possible to policer ICMP packets for example ? Does anyone on list has some experience with that ? Thanks a lot, Giuliano ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPN tunnel between OpenSwan and SRX220
Any resolve? On Aug 6, 2013 10:34 AM, "Laurent CARON" wrote: > Hi, > > I'm trying to establish a VPN tunnel between a SRX220 and an OpenSwan box. > > SRX is: > Model: srx220h > JUNOS Software Release [12.1X44-D20.3] > > OpenSwan: 2.6.37 > > Both are currently hooked on a test LAN. > > 192.168.0.18 = openswan box on lan > 192.168.0.120 = juniper box on lan > > 172.31.254.41 = ipsec on juniper box > 172.31.254.27 = ipsec on openswan box > > 172.31.255.27 = loopback on juniper box > > Not relevant for now: > 10.254.2.33 = gre tunnel on openswan side > 10.254.2.34 = gre tunnel on juniper side > > Here is the config on the Juniper side: > > set interfaces ge-0/0/0 mtu 1514 > set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.120/24 > > set interfaces gr-0/0/0 unit 0 tunnel source 172.31.254.41 > set interfaces gr-0/0/0 unit 0 tunnel destination 172.31.254.27 > set interfaces gr-0/0/0 unit 0 family inet address 10.254.2.34/32 > > set interfaces lo0 unit 0 family inet address 172.31.255.41/32 > > set interfaces st0 unit 0 family inet address 172.31.254.41/32 > > set interfaces vlan unit 0 family inet address 192.168.123.1/24 > > set routing-options static route 172.31.254.27/32 next-hop st0.0 > > set security ike traceoptions file vpn-debug-ike > set security ike traceoptions flag all > > set security ike proposal ike_aes_128 authentication-method pre-shared-keys > > set security ike proposal ike_aes_128 dh-group group2 > set security ike proposal ike_aes_128 authentication-algorithm sha1 > set security ike proposal ike_aes_128 encryption-algorithm 3des-cbc > set security ike proposal ike_aes_128 lifetime-seconds 3600 > > set security ike policy phase1_aes_128 mode main > set security ike policy phase1_aes_128 proposals ike_aes_128 > set security ike policy phase1_aes_128 pre-shared-key ascii-text "pwd" > > set security ike gateway RTR-SIEGE-001 ike-policy phase1_aes_128 > set security ike gateway RTR-SIEGE-001 address 192.168.0.18 > set security ike gateway RTR-SIEGE-001 no-nat-traversal > set security ike gateway RTR-SIEGE-001 external-interface ge-0/0/0.0 > > set security ipsec proposal ipsec_aes_128 protocol esp > set security ipsec proposal ipsec_aes_128 authentication-algorithm > hmac-sha1-96 > > set security ipsec proposal ipsec_aes_128 encryption-algorithm 3des-cbc > set security ipsec proposal ipsec_aes_128 lifetime-seconds 3600 > > set security ipsec policy phase2_aes_128 proposals ipsec_aes_128 > > set security ipsec vpn VPN_TO_SIEGE-001 bind-interface st0.0 > set security ipsec vpn VPN_TO_SIEGE-001 ike gateway RTR-SIEGE-001 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity local > 172.31.254.41/32 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity remote > 172.31.254.27/32 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity service any > set security ipsec vpn VPN_TO_SIEGE-001 ike ipsec-policy phase2_aes_128 > set security ipsec vpn VPN_TO_SIEGE-001 establish-tunnels immediately > > set security flow traceoptions file vpn-debug > set security flow traceoptions flag basic-datapath > set security flow traceoptions flag packet-drops > > set security flow tcp-mss ipsec-vpn mss 1412 > > > Here is the config on the OpenSwan side: > > conn rtr-siege-001_TO_jun-noi-001 > left=192.168.0.18 > leftsubnet=172.31.254.27/32 > leftsourceip=172.31.254.27 > right=192.168.0.120 > rightsubnet=172.31.254.41/32 > rightsourceip=172.31.254.41 > ike=3des-sha1 > auth=esp > keyingtries=0 > keyexchange=ike > authby=secret > compress=no > auto=start > pfs=no > mtu=1412 > > The connection establishes fine but drops 10 seconds after and is > renegociated, then drops again, endlessly. > > I do have those logs on the openswan side): > Aug 6 17:42:42 rtr-siege-001 pluto[28569]: added connection description > "rtr-siege-001_TO_jun-noi-001" > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: initiating Main Mode > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: received Vendor ID payload [Dead Peer Detection] > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: ignoring unknown Vendor ID payload [**699369228741c6d4ca094c93e242c9** > de19e7b7c600050500] > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: STATE_MAIN_I2: sent MI2, expecting MR2 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: STATE_MAIN_I3: sent MI3, expecting MR3 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.120' > Aug 6 17:42:43 rtr-siege-001 p
Re: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX
I guess technically any protocol would help in this case...regardless of default advertisement. I'm guessing no protocols are possible? On Sun, Aug 18, 2013 at 2:46 AM, Morgan McLean wrote: > Could you ask them to use a routing protocol and implement some logic on > their side dictating when they advertise a default to you? > > Morgan > > > On Sat, Aug 17, 2013 at 2:40 PM, Ahmad Hasan wrote: > >> BFD is not a valid option because the other end is cisco and the customer >> is >> using PBR, so based on their feedback they can't implement BFD along with >> PBR on cisco side >> >> BR, >> A.Hasan >> >> -Original Message- >> From: Chris Kawchuk [mailto:juniperd...@gmail.com] >> Sent: Friday, August 16, 2013 3:47 AM >> To: Ahmad Hasan >> Cc: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX >> >> How about a default 0.0.0.0/0 with a bfd-liveliness detection. >> >> We use this for conditionally routing statics every now and then. >> >> Works well assuming the next-hop supports BFD; and no dynamic routing >> protocol needed. >> >> - CK. >> >> >> On 16/08/2013, at 7:15 AM, Darren O'Connor wrote: >> >> > You could run VRRP on R1 and R2 giving R1 the higher priority. Have >> > the static default on the SRX3600 pointing to the VRRP IP >> > >> > Darren >> > http://www.mellowd.co.uk/ccie >> > >> > >> >> From: barakat-ah...@hotmail.com >> >> To: juniper-nsp@puck.nether.net >> >> Date: Tue, 13 Aug 2013 13:16:49 +0300 >> >> Subject: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX >> >> >> >> Dear All >> >> >> >> >> >> >> >> We have high end SRX3600 connected to layer2 switch and then to two >> >> gateway routers, and we have a static default route to R1 with >> >> default preference >> >> (5) and to R2 with preference 10, we need to track the IP of R1 so >> >> that in case we couldn't ping R1 the route to prefer R2 i.e. in case >> >> the link between R1 and the layer2 switch went down the route to prefer >> R2. >> >> >> >> Noting that we were able to accomplish the above requirements with >> >> branch SRX using either two options (set services ip-monitoring) or >> >> (set services >> >> rpm) >> >> >> >> Unfortunately the mentioned commands are not supported on high end >> >> SRX >> >> >> >> Any ideas. >> >> >> >> >> >> >> >> Regards >> >> >> >> A.Hasan >> >> >> >> >> >> >> >> >> >> >> >> ___ >> >> 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 >> > > > > -- > Thanks, > Morgan > -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX
Could you ask them to use a routing protocol and implement some logic on their side dictating when they advertise a default to you? Morgan On Sat, Aug 17, 2013 at 2:40 PM, Ahmad Hasan wrote: > BFD is not a valid option because the other end is cisco and the customer > is > using PBR, so based on their feedback they can't implement BFD along with > PBR on cisco side > > BR, > A.Hasan > > -Original Message- > From: Chris Kawchuk [mailto:juniperd...@gmail.com] > Sent: Friday, August 16, 2013 3:47 AM > To: Ahmad Hasan > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX > > How about a default 0.0.0.0/0 with a bfd-liveliness detection. > > We use this for conditionally routing statics every now and then. > > Works well assuming the next-hop supports BFD; and no dynamic routing > protocol needed. > > - CK. > > > On 16/08/2013, at 7:15 AM, Darren O'Connor wrote: > > > You could run VRRP on R1 and R2 giving R1 the higher priority. Have > > the static default on the SRX3600 pointing to the VRRP IP > > > > Darren > > http://www.mellowd.co.uk/ccie > > > > > >> From: barakat-ah...@hotmail.com > >> To: juniper-nsp@puck.nether.net > >> Date: Tue, 13 Aug 2013 13:16:49 +0300 > >> Subject: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX > >> > >> Dear All > >> > >> > >> > >> We have high end SRX3600 connected to layer2 switch and then to two > >> gateway routers, and we have a static default route to R1 with > >> default preference > >> (5) and to R2 with preference 10, we need to track the IP of R1 so > >> that in case we couldn't ping R1 the route to prefer R2 i.e. in case > >> the link between R1 and the layer2 switch went down the route to prefer > R2. > >> > >> Noting that we were able to accomplish the above requirements with > >> branch SRX using either two options (set services ip-monitoring) or > >> (set services > >> rpm) > >> > >> Unfortunately the mentioned commands are not supported on high end > >> SRX > >> > >> Any ideas. > >> > >> > >> > >> Regards > >> > >> A.Hasan > >> > >> > >> > >> > >> > >> ___ > >> 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 > -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
