Re: [j-nsp] SRX IPSEC performance
Hi Ashish: I recently tested the SRX3400 for IPsec tunnel setup rates and was able to setup 3600 tunnels using IxVPN testing tool. I only sent traffic across the tunnels for 1 minute but the testing was successful. We were running 4x SPC and 2xNPC in our configuration. We were using one GE WAN interface as well. Our primary purpose was just to test that number of IPsec tunnels that we needed for a future implementation. Devin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ashish verma Sent: Thursday, September 13, 2012 5:35 PM To: juniper-nsp Subject: [j-nsp] SRX IPSEC performance Hi All, Has anyone here done IPSEC performance tests for SRX3k and share your results? Juniper claims that with 1400bytes of packet with 2SPC and 1NPC VPN throughput is 3Gbps. How much have you achieved? Ashish ___ 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] nssa default route
Hi Ryan:
Have you already tried adding the 'type-7' knob to the NSSA area?
[edit]
Devin@MX10-1# set protocols ospf area 1 nssa default-lsa ?
Possible completions:
<[Enter]>Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
default-metric Metric for the default route in this area
(1..16777215)
metric-type External metric type for the default type 7 LSA
(1..2)
type-7 Flood type 7 default LSA if no-summaries is
configured << This knob
|Pipe through a command
Since you are configuring 'no-summaries' and the default route comes through
as such I believe you need to allow it as a type-7 instead.
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ryanL
Sent: Thursday, August 16, 2012 1:48 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] nssa default route
tl;dr - when i kill one of my mx's, the default route disappears on my ex's.
and, the remaining ospf database entry is for the router that died, not the
router that remains active.
i might be a little slow on the uptick here, but this seems pretty straight
forward to me. i can't figure out what's up. i'm pretty new to junos, so
bear with me.
m = mx
e = ex
standard physical full mesh
mx1 lo0 = 1.1.1.1
mx2 lo0 = 1.1.1.2
m - m
| x |
e - e
my mx are ospf area 0 and area 1 nssa. the ex are area 1 nssa only.
mx's inject default into nssa.
config on mx:
//
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
area 0.0.0.1 {
nssa {
default-lsa default-metric 10;
no-summaries;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//
config on ex:
//
area 0.0.0.1 {
nssa;
interface lo0.0 {
passive;
}
interface ae1.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae2.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
interface ae0.0 {
interface-type p2p;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
full-neighbors-only;
}
}
}
//
routes before killing mx2:
>show route 0.0.0.0
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/10] 00:08:40, metric 15
> to 10.254.1.2 via ae1.0
to 10.254.1.4 via ae2.0
ospf database before killing mx2:
> show ospf database
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x848e 2283 0x20 0x7c36 168
Router 10.255.1.2 10.255.1.2 0x8486 2284 0x20 0x1e89 168
Router 1.1.1.1 1.1.1.2 0x83e2 513 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x83e8 1082 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.1 0x8001 513 0x20 0xeaa8 28
Summary 0.0.0.0 1.1.1.2 0x80b4 1082 0x20 0x7d61 28
routes after killing mx2:
> show route 0.0.0.0
# show ospf database
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.255.1.1 10.255.1.1 0x849041 0x20 0x286f 144
Router 10.255.1.2 10.255.1.2 0x848842 0x20 0x6030 144
Router 1.1.1.1 1.1.1.2 0x83e2 612 0x20 0x7006 72
Router 1.1.1.2 1.1.1.2 0x83e8 1181 0x20 0x7bf2 72
Summary 0.0.0.0 1.1.1.2 0x80b4 1181 0x20 0x7d61
28 #<---dead router!
so, what happened to my remaining router's ospf database entry, and that
secondary default route?
thanks for any insight. i'm going to open a case with jtac as well.
ryanL
___
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
Re: [j-nsp] Best practice MTU?
Sent from my Samsung Galaxy Note™, an AT&T LTE smartphone
Original message
Subject: Re: [j-nsp] Best practice MTU?
From: Jack Bates
To: Chris Kawchuk
CC: Re: [j-nsp] Best practice MTU?
I agree, as long as the transport between devices supports the MTU. This
is especially important with device interoperability. Cisco, for
example, apparently pads out ISO hello packets to MTU (Juniper limits it
to maximum ISO packet size). If the packet is discarded by transport
medium, the ISIS session will not come up. Found this one out increasing
MTU by 4 to support a single MPLS tag. lol
Jack
On 4/26/2012 6:33 PM, Chris Kawchuk wrote:
> I usually set the interface physical MTU as high as it goes (per device), but
> manually set protocol inet to MTU 1500 (for things like OSPF to work). This
> allows for as-large-as-MTU-as-MPLS-can-do. Other address families aren't that
> picky about MTU matching.
>
>
> ge-1/0/5 {
> description "LINK to another IP/OSPF/MPLS device - May or May not
>support MTU 9192 on the physical but inet4/OSPF is 1500 so it works";
> mtu 9192;
> unit 0 {
> family inet {
> mtu 1500;
> address 10.102.10.1/24;
> }
> family mpls;
> }
> }
>
> - CK.
>
>
>
> On 2012-04-27, at 7:32 AM, OBrien, Will wrote:
>
>> We've been pushing out jumbo frames across our new core lately. Right now
>> I've got multiple boxes from multiple vendors that all support different
>> maximum MTUs.
>>
>> Example: Juniper MX960/480, Nexus 7009, Nexus 5k/2k, Catalyst 4900,
>> Nortel/Avaya 8600 All different maximums.
>>
>> Anyone have suggestions for a best practice MTU? (That is over 9000?!)
>>
>>
>> Thanks!
>>
>> Will
>> ___
>> 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
Hi Stefan: Do you also have a recommendation for study materials for the JNCIP-SP (taking to renew JNCIE-M) and also for study towards the JNCIE-SEC exams? Best Regards, Devin J Kennedy Juniper Engineer - AT&T Labs dk5...@att.com -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stefan Fouant Sent: Tuesday, April 24, 2012 10:57 AM To: bruno.juniper Cc: juniper-nsp Subject: Re: [j-nsp] looking for jncie-sp study follow On 4/23/2012 11:26 PM, bruno.juniper wrote: > Looking for study folks; My exam is in 2 moths.skype: brunojuniper Your best bet is to go through all the labs in JIR, AJSPR, JMV, JMR, and JCOS. Mock these up and go through as many different scenarios as possible. Also, the labs in Harry Reynolds' JNCIP and JNCIE Study Guides are still good to go through as they are somewhat representative of the type of stuff you will seen on the exam. In addition, have you taken our JNCIE-SP bootcamp? You can order these materials from our OnFullfillment website. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ 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] Dual Stack Aggregate Policing via Firewall Filter
Hi Stefan:
Thanks again for your input. It looks like it won't take this command
either on the SRX... See below when configuring the
physical-interface-policer:
juniper@SRX210-1-ipv6# edit firewall policer cos1_drop_80_out_small
[edit firewall policer cos1_drop_80_out_small]
juniper@SRX210-1-ipv6# show
filter-specific;
##
## Warning: statement ignored: unsupported platform (srx210he)
##
physical-interface-policer; <<<<<<<<<<<<<<<<<<<<
if-exceeding {
bandwidth-limit 800k;
burst-size-limit 100k;
}
then discard;
We are running Junos 10.4R9.5 as well.
Thanks,
Devin
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Devin Kennedy
Sent: Friday, March 02, 2012 1:17 PM
To: 'Stefan Fouant'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
Thanks Stefan! I'll try that out and see if that will work for us.
-Original Message-
From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net]
Sent: Friday, March 02, 2012 12:55 PM
To: 'Devin Kennedy'; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
Hi Devin,
Have you tried using a Physical Interface Policer? A Physical Interface
Policer will allow you to apply your policers across different terms across
different firewall filters, that are applied to different protocol families
on a single physical interface, and then it will merge all the filters which
call that policer on the same physical interface. The cool thing is you can
use this across different logical interfaces that might even be in different
routing instances!
Try something along the following:
[edit firewall]
policer cos1_drop_8000K_out_medium {
physical-interface-policer; < This is required
if-exceeding {
bandwidth-limit 8m;
burst-size-limit 1m;
}
then discard;
}
family inet {
filter filter-ipv4 {
physical-interface-filter; < This is required
term 1 {
from {
protocol tcp;
port 80;
}
then {
policer cos1_drop_8000K_out_medium;
accept;
}
}
}
}
family inet6 {
filter filter-ipv6 {
physical-interface-filter; < This is required
term 1 {
from {
protocol tcp;
port 80;
}
then {
policer cos1_drop_8000K_out_medium;
accept;
}
}
}
}
HTHs.
Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
Technical Trainer, Juniper Networks
> -Original Message-
> From: Devin Kennedy [mailto:devinkennedy...@hotmail.com]
> Sent: Thursday, March 01, 2012 9:08 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
>
> Hello:
>
>
>
> We are currently testing dual stack CoS on the Juniper platform and
> we're not seeing any way to aggregate the policing applied to IPv4 and
> IPv6. We want to allocate a customer a specific amount of bandwidth,
> say 10m (including both IPv4 and IPv6 traffic in any proportional
> amount), and have the traffic policed to 10m regardless of the amount
> of IPv4 or IPv6 traffic.
>
>
>
>
> I see there is an option to use a logical-interface-policer at the
> unit
> level:
>
>
>
> firewall policer 10M-policing
>
> {
>
> logical-interface-policer;
>
> if-exceeding {
>
> bandwidth-limit 10m;
>
> burst-size-limit 100k;
>
> }
>
> then discard;
>
> }
>
>
>
>
>
> interfaces {
>
> fe-2/0/3 {
>
> vlan-tagging;
>
>unit 200 {
>
>vlan-id 200;
>
> policer {
>
> input 10M-policing;
>
> output 10M-policing;
>
> }
>
>
>
> However, we are policing differently for each CoS queue so we need to
> call policers via MF and BA filters. The problem is that there has to
> be a different filter for each family (inet and inet6), so the two are
> not able to use an aggregate amount. So if we apply the same 10m
> policer to each family it won't aggregate and instead applies an
> instance of the policer for each family (so a total of 20m).
>
>
>
> Does anyone know if it's possible to configure an aggregate policer
> across two different firewall filters? Below is an example of what we
> are currently doing:
>
>
>
> ge-0/0/1 {
>
> per-unit-scheduler;
>
> vlan-tagging;
>
> speed 100m;
>
> link-mode full-duplex;
>
> gigether-options {
>
>
Re: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
Thanks Stefan! I'll try that out and see if that will work for us.
-Original Message-
From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net]
Sent: Friday, March 02, 2012 12:55 PM
To: 'Devin Kennedy'; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
Hi Devin,
Have you tried using a Physical Interface Policer? A Physical Interface
Policer will allow you to apply your policers across different terms across
different firewall filters, that are applied to different protocol families
on a single physical interface, and then it will merge all the filters which
call that policer on the same physical interface. The cool thing is you can
use this across different logical interfaces that might even be in different
routing instances!
Try something along the following:
[edit firewall]
policer cos1_drop_8000K_out_medium {
physical-interface-policer; < This is required
if-exceeding {
bandwidth-limit 8m;
burst-size-limit 1m;
}
then discard;
}
family inet {
filter filter-ipv4 {
physical-interface-filter; < This is required
term 1 {
from {
protocol tcp;
port 80;
}
then {
policer cos1_drop_8000K_out_medium;
accept;
}
}
}
}
family inet6 {
filter filter-ipv6 {
physical-interface-filter; < This is required
term 1 {
from {
protocol tcp;
port 80;
}
then {
policer cos1_drop_8000K_out_medium;
accept;
}
}
}
}
HTHs.
Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
Technical Trainer, Juniper Networks
> -Original Message-
> From: Devin Kennedy [mailto:devinkennedy...@hotmail.com]
> Sent: Thursday, March 01, 2012 9:08 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
>
> Hello:
>
>
>
> We are currently testing dual stack CoS on the Juniper platform and
> we're not seeing any way to aggregate the policing applied to IPv4 and
> IPv6. We want to allocate a customer a specific amount of bandwidth,
> say 10m (including both IPv4 and IPv6 traffic in any proportional
> amount), and have the traffic policed to 10m regardless of the amount
> of IPv4 or IPv6 traffic.
>
>
>
>
> I see there is an option to use a logical-interface-policer at the
> unit
> level:
>
>
>
> firewall policer 10M-policing
>
> {
>
> logical-interface-policer;
>
> if-exceeding {
>
> bandwidth-limit 10m;
>
> burst-size-limit 100k;
>
> }
>
> then discard;
>
> }
>
>
>
>
>
> interfaces {
>
> fe-2/0/3 {
>
> vlan-tagging;
>
>unit 200 {
>
>vlan-id 200;
>
> policer {
>
> input 10M-policing;
>
> output 10M-policing;
>
> }
>
>
>
> However, we are policing differently for each CoS queue so we need to
> call policers via MF and BA filters. The problem is that there has to
> be a different filter for each family (inet and inet6), so the two are
> not able to use an aggregate amount. So if we apply the same 10m
> policer to each family it won't aggregate and instead applies an
> instance of the policer for each family (so a total of 20m).
>
>
>
> Does anyone know if it's possible to configure an aggregate policer
> across two different firewall filters? Below is an example of what we
> are currently doing:
>
>
>
> ge-0/0/1 {
>
> per-unit-scheduler;
>
> vlan-tagging;
>
> speed 100m;
>
> link-mode full-duplex;
>
> gigether-options {
>
> no-auto-negotiation;
>
> }
>
> unit 2001 {
>
> vlan-id 2001;
>
> family inet {
>
> filter {
>
> output cos_filter;
>
> }
>
> address x.x.x.x/30;
>
> }
>
> family inet6 {
>
> filter {
>
> output cos_filter-v6;
>
> }
>
> address x::x/64;
>
> }
>
> }
>
> }
>
>
>
> The cos_filter then calls BA and MF filters such as:
>
>
>
> [edit]
>
> juniper@SRX210-2-IPV6# show firewall family inet filter cos1_MF
>
> term 1 {
>
> from {
>
> protocol [ udp tcp ];
>
> port 2081;
>
> }
>
> then {
>
> policer cos1_drop_8000K_out_medium;
>
> count COS1_MF_counter;
>
Re: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
Thanks for your response Krasi. Unfortunately it appears it's not supported
on the SRX/J series in that way. It won't commit stating that it's the
wrong platform for using the logical-interface-policer statement in that
manner.
From: Krasimir Avramski [mailto:kr...@smartcom.bg]
Sent: Thursday, March 01, 2012 11:16 AM
To: Devin Kennedy
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
Hi,
It is possible to reference logical-interface-policer in interface-specific
filters for inet and inet6 families.
Krasi
On 1 Mar 2012 16:11, "Devin Kennedy" wrote:
Hello:
We are currently testing dual stack CoS on the Juniper platform and we're
not seeing any way to aggregate the policing applied to IPv4 and IPv6. We
want to allocate a customer a specific amount of bandwidth, say 10m
(including both IPv4 and IPv6 traffic in any proportional amount), and have
the traffic policed to 10m regardless of the amount of IPv4 or IPv6 traffic.
I see there is an option to use a logical-interface-policer at the unit
level:
firewall policer 10M-policing
{
logical-interface-policer;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 100k;
}
then discard;
}
interfaces {
fe-2/0/3 {
vlan-tagging;
unit 200 {
vlan-id 200;
policer {
input 10M-policing;
output 10M-policing;
}
However, we are policing differently for each CoS queue so we need to call
policers via MF and BA filters. The problem is that there has to be a
different filter for each family (inet and inet6), so the two are not able
to use an aggregate amount. So if we apply the same 10m policer to each
family it won't aggregate and instead applies an instance of the policer for
each family (so a total of 20m).
Does anyone know if it's possible to configure an aggregate policer across
two different firewall filters? Below is an example of what we are
currently doing:
ge-0/0/1 {
per-unit-scheduler;
vlan-tagging;
speed 100m;
link-mode full-duplex;
gigether-options {
no-auto-negotiation;
}
unit 2001 {
vlan-id 2001;
family inet {
filter {
output cos_filter;
}
address x.x.x.x/30;
}
family inet6 {
filter {
output cos_filter-v6;
}
address x::x/64;
}
}
}
The cos_filter then calls BA and MF filters such as:
[edit]
juniper@SRX210-2-IPV6# show firewall family inet filter cos1_MF
term 1 {
from {
protocol [ udp tcp ];
port 2081;
}
then {
policer cos1_drop_8000K_out_medium;
count COS1_MF_counter;
forwarding-class cos1;
accept;
}
}
[edit]
juniper@SRX210-2-IPV6# show firewall family inet filter cos1_ba
term 1 {
from {
dscp [ 46 40 ];
}
then {
policer cos1_drop_8000K_out_medium;
count cos1_BA_PLP_Low_counter;
forwarding-class cos1;
accept;
}
}
And here is the common policer called by both the inet and inet6 filters (MF
and BA for each family):
[edit]
juniper@SRX210-2-IPV6# show firewall policer cos1_drop_8000K_out_medium
filter-specific;
if-exceeding {
bandwidth-limit 8m;
burst-size-limit 1m;
}
then discard;
We need that 8m to apply to both families together. Any pointers?
Thanks,
Devin
___
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] Dual Stack Aggregate Policing via Firewall Filter
Hello:
We are currently testing dual stack CoS on the Juniper platform and we're
not seeing any way to aggregate the policing applied to IPv4 and IPv6. We
want to allocate a customer a specific amount of bandwidth, say 10m
(including both IPv4 and IPv6 traffic in any proportional amount), and have
the traffic policed to 10m regardless of the amount of IPv4 or IPv6 traffic.
I see there is an option to use a logical-interface-policer at the unit
level:
firewall policer 10M-policing
{
logical-interface-policer;
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 100k;
}
then discard;
}
interfaces {
fe-2/0/3 {
vlan-tagging;
unit 200 {
vlan-id 200;
policer {
input 10M-policing;
output 10M-policing;
}
However, we are policing differently for each CoS queue so we need to call
policers via MF and BA filters. The problem is that there has to be a
different filter for each family (inet and inet6), so the two are not able
to use an aggregate amount. So if we apply the same 10m policer to each
family it won't aggregate and instead applies an instance of the policer for
each family (so a total of 20m).
Does anyone know if it's possible to configure an aggregate policer across
two different firewall filters? Below is an example of what we are
currently doing:
ge-0/0/1 {
per-unit-scheduler;
vlan-tagging;
speed 100m;
link-mode full-duplex;
gigether-options {
no-auto-negotiation;
}
unit 2001 {
vlan-id 2001;
family inet {
filter {
output cos_filter;
}
address x.x.x.x/30;
}
family inet6 {
filter {
output cos_filter-v6;
}
address x::x/64;
}
}
}
The cos_filter then calls BA and MF filters such as:
[edit]
juniper@SRX210-2-IPV6# show firewall family inet filter cos1_MF
term 1 {
from {
protocol [ udp tcp ];
port 2081;
}
then {
policer cos1_drop_8000K_out_medium;
count COS1_MF_counter;
forwarding-class cos1;
accept;
}
}
[edit]
juniper@SRX210-2-IPV6# show firewall family inet filter cos1_ba
term 1 {
from {
dscp [ 46 40 ];
}
then {
policer cos1_drop_8000K_out_medium;
count cos1_BA_PLP_Low_counter;
forwarding-class cos1;
accept;
}
}
And here is the common policer called by both the inet and inet6 filters (MF
and BA for each family):
[edit]
juniper@SRX210-2-IPV6# show firewall policer cos1_drop_8000K_out_medium
filter-specific;
if-exceeding {
bandwidth-limit 8m;
burst-size-limit 1m;
}
then discard;
We need that 8m to apply to both families together. Any pointers?
Thanks,
Devin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos Load Balancing Behavior
Hello: I'm looking for some insight on the load balancing behavior that Junos uses by default. We are certifying our Junos platform CE routers (SRX, MX10, M7i) and not seeing what we expected given the documentation we have. According to the Juniper docs and the old JNCIP study guide, OSPF will automatically load balance if there are two equal cost routes. And indeed in the routing table we have default route advertised via OSPF to a CE router which shows two next hops (one to each of two PE's). juniper@SRX240-5> show route 0/0 exact inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[OSPF/150] 20:45:21, metric 112, tag 13979 to 10.7.122.1 via ge-0/0/6.0 > to 10.7.122.2 via ge-0/0/6.0 However in the forwarding table there is only one next-hop shown and when testing traffic flows we don't see any load balancing by default. juniper@SRX240-5> show route forwarding-table destination 0/0 Routing table: default.inet Internet: DestinationType RtRef Next hop Type Index NhRef Netif defaultuser 0ulst 262142 2 80:71:1f:c0:3c:81 ucst 584 4 ge-0/0/6.0 defaultperm 0rjct36 4 0.0.0.0/32 perm 0dscd34 2 Routing table: __master.anon__.inet Internet: DestinationType RtRef Next hop Type Index NhRef Netif defaultperm 0rjct 517 1 0.0.0.0/32 perm 0dscd 515 1 Everything goes across the one next hop only (the one with the > in front of it). We have to add an export policy to the routing-options forwarding-table stanza to get it to work. This is from the Junos documentation for OSPF for version 10.4: "When several equal-cost routes to a destination exist, traffic is distributed equally among them." http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/ospf-routing- overview.html Shouldn't the load balancing work by default as the documentation would lead one to believe? Does anyone have any insight into this? Is the documentation incorrect and you actually are required to always add a load-balancing export policy in order to get the desired load-balancing behavior? Best Regards, Devin J Kennedy Juniper Engineer - AT&T Labs ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M160 SFM BOGUS ERRORS
Due to the shared memory architecture of the M160, the bogus cells could be coming from any of the FPCs or the problem could be the SFM itself. Usually the problem is caused by an FPC in my experience. To isolate the offending FPC, you can do the following steps: 1) reboot each FPC one at a time 2) look for any bchip (or bogus cell) errors reported in syslog during bootup This should expose the FPC that is introducing the bogus cells. But JTAC may have more commands they can run that may not require you to reboot the FPC's one by one if this router is a critical router. So I would recommend opening a case with them. -Original Message- From: Mario Andres Rueda Jaimes [mailto:maeve2...@gmail.com] Sent: Thursday, June 09, 2011 11:22 AM To: Devin Kennedy Cc: juniper-nsp@puck.nether.net Subject: RE: [j-nsp] M160 SFM BOGUS ERRORS Devin We are running junos 9,6R3.8 the messages seen once the SFM goes up, are like this Jun 9 13:58:16fpc0 DCHIP(0/3): H/S link Tx12(0) overflow Jun 9 13:58:16 fpc0 DCHIP(0/3): H/S link Tx12(1) overflow Jun 9 13:58:16 fpc6 DCHIP(6/0): H/S link Tx12(1) overflow Jun 9 13:58:16 fpc6 DCHIP(6/0): H/S link Tx12(2) overflow Jun 9 13:58:19 fpc7 DCHIP(7/1): H/S link Tx12(0) overflow Jun 9 13:58:19 fpc0 DCHIP(0/3): H/S link Tx12(1) overflow Jun 9 13:58:20 fpc0 DCHIP(0/3): H/S link Tx12(0) overflow Jun 9 13:59:15 fpc6 DCHIP(6/0): H/S link Tx12(1) overflow right now only bogus errors are seen Regards -Mensaje original- De: Devin Kennedy Para: 'Mario Andres Rueda Jaimes' , juniper-nsp@puck.nether.net Asunto: RE: [j-nsp] M160 SFM BOGUS ERRORS Fecha: Thu, 9 Jun 2011 10:34:18 -0400 In my experience, these can be caused by either the SFM or one of the FPCs. In the messages log, do you see any B chip errors? What version of Junos? Usually this indicates a hardware issue and often requires an RMA of the faulty SFM or FPC. You should open a case with JTAC for this. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mario Andres Rueda Jaimes Sent: Thursday, June 09, 2011 10:12 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] M160 SFM BOGUS ERRORS Hi All, We are getting following error messages on our M160 Router, there is no traffic impact, anyone can help with this ? Jun 9 14:03:57 sfm2 Bogus Cell incremented since last reported.3 Jun 9 14:05:27 sfm2 Bogus Cell incremented since last reported. Thanks and Regards ___ 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] M160 SFM BOGUS ERRORS
In my experience, these can be caused by either the SFM or one of the FPCs. In the messages log, do you see any B chip errors? What version of Junos? Usually this indicates a hardware issue and often requires an RMA of the faulty SFM or FPC. You should open a case with JTAC for this. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mario Andres Rueda Jaimes Sent: Thursday, June 09, 2011 10:12 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] M160 SFM BOGUS ERRORS Hi All, We are getting following error messages on our M160 Router, there is no traffic impact, anyone can help with this ? Jun 9 14:03:57 sfm2 Bogus Cell incremented since last reported.3 Jun 9 14:05:27 sfm2 Bogus Cell incremented since last reported. Thanks and Regards ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper Equivalent to Cisco's qos pre-classify?
Thanks Jon. Actually we need this to work on the SRX210, SRX240, J4350 and M7i. We did find that we were able to add a input/output filter in order to classify on the sp- interface, but the SRX/J boxes don't allow application of a filter at all for the st0 interface it seems. Thanks for the input in regards to the M-series, however; this will help us with the M7i for sure. From: Jonathan Looney [mailto:jonloo...@gmail.com] Sent: Tuesday, June 07, 2011 2:16 PM To: Devin Kennedy Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper Equivalent to Cisco's qos pre-classify? You didn't specify the platform. If you're speaking of something with an AS or MS card/module of some kind, then you can do this by classifying the pre-encrypted packet anytime between input and encryption. If you want to classify it on output to the encryption module, you would apply the classifier to the appropriate (inside) unit on the sp-* interface. I believe you can even apply a re-write rule on that interface that will change the original (unencrypted) packet's ToS bits as it transmitted to the AS/MS card/module for encryption. The ToS bits should get copied to the ESP (encrypted) packet's IP header, and I believe the router should maintain the previously-assigned forwarding class and loss priority for the packet. You'll just need to make sure you don't accidentally change the forwarding class/loss priority as the encrypted packet makes its way through the router a second time. Then, if desired, you can apply a custom rewrite rule on output. (Keep in mind that - if I recall correctly - the default IP precedence output rule may cause packets from other forwarding classes to be marked as best effort.) If you're speaking of an SRX device, then I can't help you definitively. However, I suspect it may work in a similar way if you substitute st interface for sp-* interface in the above. Hope that helps. -Jon On Tue, Jun 7, 2011 at 11:19 AM, Devin Kennedy wrote: Hello: I'm trying to get our current CoS configurations to work with IPsec. I know that the ToS bits are copied to the IP header that ESP places on the encrypted payload. However, we are currently utilizing MF classifiers, so we are classifying based on dest/source addresses and ports. The problem is that the classification happens after encryption so all of our packets are being sent to the BE queue (since the TCP header is no longer visible after encryption). Is anyone aware of a command or a method of accomplishing the same thing as Cisco's "qos pre-classify" command so that the classification is done before the encryption process? Thanks for any help on this. Best Regards, Devin J Kennedy ___ 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] Juniper Equivalent to Cisco's qos pre-classify?
Hello: I'm trying to get our current CoS configurations to work with IPsec. I know that the ToS bits are copied to the IP header that ESP places on the encrypted payload. However, we are currently utilizing MF classifiers, so we are classifying based on dest/source addresses and ports. The problem is that the classification happens after encryption so all of our packets are being sent to the BE queue (since the TCP header is no longer visible after encryption). Is anyone aware of a command or a method of accomplishing the same thing as Cisco's "qos pre-classify" command so that the classification is done before the encryption process? Thanks for any help on this. Best Regards, Devin J Kennedy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IKE Key Life-times on J-series vs. SRX
Thanks Stefan. This is what I was thinking should be the case as well. -Original Message- From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] Sent: Thursday, June 02, 2011 4:29 PM To: 'Devin Kennedy'; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] IKE Key Life-times on J-series vs. SRX > -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of Devin Kennedy > Sent: Thursday, June 02, 2011 3:59 PM > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] IKE Key Life-times on J-series vs. SRX > > Does anyone know if the lifetime value used for the IKE session is > determined by the initiator? It appears from the behavior I've > observed that the lifetime value is always determined by whichever > peer is in the initiator role. That shouldn't be the case, but will need to do some digging. It should always be that the peers use the lesser of the two lifetime settings as their negotiated IKE SA lifetime. Stefan Fouant JNCIE-M #513, JNCIE-ER #70, JNCI GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IKE Key Life-times on J-series vs. SRX
Does anyone know if the lifetime value used for the IKE session is determined by the initiator? It appears from the behavior I've observed that the lifetime value is always determined by whichever peer is in the initiator role. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Devin Kennedy Sent: Thursday, June 02, 2011 11:37 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] IKE Key Life-times on J-series vs. SRX Hello All: I am seeing a difference in behavior on the J4350 vs. the SRX240 for the IKE key lifetime negotiation for IPsec phase 1. In both cases the peer is a Cisco 1841. Please see outputs below. Has anyone else run into this? I would expect that it ought to take the lower lifetime value as it does on the SRX240. BTW, Im running Junos 10.4R4.5 on both Juniper routers. On the SRX I saw what I expected to see, which is that the negotiated value is the lesser of the two if they do not match: SRX240 [edit] Devin@SRX240-1# show security ike proposal testikeprop authentication-method pre-shared-keys; dh-group group2; authentication-algorithm sha1; encryption-algorithm aes-256-cbc; [edit] Devin@SRX240-1# run show security ike security-associations detail IKE peer 10.10.3.89, Index 7707821, Role: Initiator, State: UP Initiator cookie: ed10b684f40a71d2, Responder cookie: 3c2a1fb09e701c34 Exchange type: Main, Authentication method: Pre-shared-keys Local: 10.10.3.93:500, Remote: 10.10.3.89:500 Lifetime: Expires in 28795 seconds Peer ike-id: 10.10.3.89 Xauth assigned IP: 0.0.0.0 Algorithms: Authentication: sha1 Encryption: aes-cbc (256 bits) Pseudo random function: hmac-sha1 Traffic statistics: Input bytes : 688 Output bytes : 880 Input packets:4 Output packets:5 Flags: Caller notification sent IPSec security associations: 1 created, 0 deleted Phase 2 negotiations in progress: 1 Negotiation type: Quick mode, Role: Initiator, Message ID: 1851437682 Local: 10.10.3.93:500, Remote: 10.10.3.89:500 Local identity: ipv4_subnet(any:0,[0..7]=10.100.9.0/24) Remote identity: ipv4_subnet(any:0,[0..7]=10.100.7.0/24) Flags: Caller notification sent, Waiting for done Cisco 1841 crypto isakmp policy 1 encr aes 256 authentication pre-share group 2 C1841-2#show crypto isakmp policy Global IKE policy Protection suite of priority 1 encryption algorithm: AES - Advanced Encryption Standard (256 bit keys). hash algorithm:Secure Hash Standard authentication method: Pre-Shared Key Diffie-Hellman group: #2 (1024 bit) lifetime:86400 seconds, no volume limit Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm:Secure Hash Standard authentication method: Rivest-Shamir-Adleman Signature Diffie-Hellman group: #1 (768 bit) lifetime:86400 seconds, no volume limit C1841-2#show crypto isakmp sa detail Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal X - IKE Extended Authentication psk - Preshared key, rsig - RSA signature renc - RSA encryption IPv4 Crypto ISAKMP SA C-id Local Remote I-VRFStatus Encr Hash Auth DH Lifetime Cap. 1156 10.10.3.89 10.10.3.93 ACTIVE aes sha psk 2 0 D Engine-id:Conn-id = ??? (deleted) 1155 10.10.3.89 10.10.3.93 ACTIVE aes sha psk 2 07:59:34 D Engine-id:Conn-id = SW:155 With the J4350 in place of the SRX240 with the same configuration as shown for the SRX240 and same configuration as shown for the Cisco 1841, I see: J4350 [edit] Devin@J4350-1# show security ike proposal testikeprop ß No lifetime configured so should use default of 28800 authentication-method pre-shared-keys; dh-group group2; authentication-algorithm sha1; encryption-algorithm aes-256-cbc; [edit] Devin@J4350-1# Devin@J4350-1> show security ike security-associations detail IKE peer 10.10.3.89, Index 4833153, Role: Responder, State: UP Initiator cookie: b4443ecf19364ac2, Responder cookie: 7c741a4fcb0f5558 Exchange type: Main, Authentication method: Pre-shared-keys Local: 10.10.3.85:500, Remote: 10.10.3.89:500 Lifetime: Expires in 86321 seconds Peer ike-id: 10.10.3.89 Xauth assigned IP: 0.0.0.0 Algorithms: Authentication: sha1 Encryption: aes-cbc (256 bits) Pseudo random function: hmac-sha1 Traffic statistics: Input bytes : 864 Output bytes : 1092 Input packets:
[j-nsp] IKE Key Life-times on J-series vs. SRX
Hello All: I am seeing a difference in behavior on the J4350 vs. the SRX240 for the IKE key lifetime negotiation for IPsec phase 1. In both cases the peer is a Cisco 1841. Please see outputs below. Has anyone else run into this? I would expect that it ought to take the lower lifetime value as it does on the SRX240. BTW, Im running Junos 10.4R4.5 on both Juniper routers. On the SRX I saw what I expected to see, which is that the negotiated value is the lesser of the two if they do not match: SRX240 [edit] Devin@SRX240-1# show security ike proposal testikeprop authentication-method pre-shared-keys; dh-group group2; authentication-algorithm sha1; encryption-algorithm aes-256-cbc; [edit] Devin@SRX240-1# run show security ike security-associations detail IKE peer 10.10.3.89, Index 7707821, Role: Initiator, State: UP Initiator cookie: ed10b684f40a71d2, Responder cookie: 3c2a1fb09e701c34 Exchange type: Main, Authentication method: Pre-shared-keys Local: 10.10.3.93:500, Remote: 10.10.3.89:500 Lifetime: Expires in 28795 seconds Peer ike-id: 10.10.3.89 Xauth assigned IP: 0.0.0.0 Algorithms: Authentication: sha1 Encryption: aes-cbc (256 bits) Pseudo random function: hmac-sha1 Traffic statistics: Input bytes : 688 Output bytes : 880 Input packets:4 Output packets:5 Flags: Caller notification sent IPSec security associations: 1 created, 0 deleted Phase 2 negotiations in progress: 1 Negotiation type: Quick mode, Role: Initiator, Message ID: 1851437682 Local: 10.10.3.93:500, Remote: 10.10.3.89:500 Local identity: ipv4_subnet(any:0,[0..7]=10.100.9.0/24) Remote identity: ipv4_subnet(any:0,[0..7]=10.100.7.0/24) Flags: Caller notification sent, Waiting for done Cisco 1841 crypto isakmp policy 1 encr aes 256 authentication pre-share group 2 C1841-2#show crypto isakmp policy Global IKE policy Protection suite of priority 1 encryption algorithm: AES - Advanced Encryption Standard (256 bit keys). hash algorithm:Secure Hash Standard authentication method: Pre-Shared Key Diffie-Hellman group: #2 (1024 bit) lifetime:86400 seconds, no volume limit Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm:Secure Hash Standard authentication method: Rivest-Shamir-Adleman Signature Diffie-Hellman group: #1 (768 bit) lifetime:86400 seconds, no volume limit C1841-2#show crypto isakmp sa detail Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal X - IKE Extended Authentication psk - Preshared key, rsig - RSA signature renc - RSA encryption IPv4 Crypto ISAKMP SA C-id Local Remote I-VRFStatus Encr Hash Auth DH Lifetime Cap. 1156 10.10.3.89 10.10.3.93 ACTIVE aes sha psk 2 0 D Engine-id:Conn-id = ??? (deleted) 1155 10.10.3.89 10.10.3.93 ACTIVE aes sha psk 2 07:59:34 D Engine-id:Conn-id = SW:155 With the J4350 in place of the SRX240 with the same configuration as shown for the SRX240 and same configuration as shown for the Cisco 1841, I see: J4350 [edit] Devin@J4350-1# show security ike proposal testikeprop ß No lifetime configured so should use default of 28800 authentication-method pre-shared-keys; dh-group group2; authentication-algorithm sha1; encryption-algorithm aes-256-cbc; [edit] Devin@J4350-1# Devin@J4350-1> show security ike security-associations detail IKE peer 10.10.3.89, Index 4833153, Role: Responder, State: UP Initiator cookie: b4443ecf19364ac2, Responder cookie: 7c741a4fcb0f5558 Exchange type: Main, Authentication method: Pre-shared-keys Local: 10.10.3.85:500, Remote: 10.10.3.89:500 Lifetime: Expires in 86321 seconds Peer ike-id: 10.10.3.89 Xauth assigned IP: 0.0.0.0 Algorithms: Authentication: sha1 Encryption: aes-cbc (256 bits) Pseudo random function: hmac-sha1 Traffic statistics: Input bytes : 864 Output bytes : 1092 Input packets:5 Output packets:5 Flags: Caller notification sent IPSec security associations: 1 created, 0 deleted Phase 2 negotiations in progress: 1 Negotiation type: Quick mode, Role: Responder, Message ID: 931695683 Local: 10.10.3.85:500, Remote: 10.10.3.89:500 Local identity: ipv4_subnet(any:0,[0..7]=10.100.11.0/24) Remote identity: ipv4_subnet(any:0,[0..7]=10.100.7.0/24) Flags: Caller notification sent, Waiting for done Cisco 1841 C184
Re: [j-nsp] Trying to get OSPF to work across IPsec for Redundancy
I was finally able to get this working. I had to set the MTU's explicitly on each sub unit (I just set them to 1500). I guess the default MTU that the st0 and sp- interfaces use doesn't work well with OSPF. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of OBrien, Will Sent: Friday, April 29, 2011 10:08 AM To: Dale Shaw Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Trying to get OSPF to work across IPsec for Redundancy We were using two tunnels to separate peers. 1 to a pci network and another for office workers to be on our normal user network. I will see if I can dig up details later today Will Sent from my iPad On Apr 29, 2011, at 9:05 AM, "Dale Shaw" wrote: > Hi Stefan, > > On Friday, April 29, 2011, Stefan Fouant > wrote: >> I have successfully built IPsec tunnels using a Secure Tunnel >> interface terminating in both 'virtual-router' and 'forwarding' >> Routing Instances using Junos 10.4R4.3. I also had no problems >> getting OSPF up and running using both Multipoint or Point-to-Point configurations. >> > > Interesting! > > Like Will, I've been bitten by the "OSPF over st0.x in a routing > instance" problem. For us it seems to pop up when there are multiple > tunnels (in discrete instances) established between the same peers. > > Did your testing happen to include the multiple tunnels scenario? > > Will, do you happen to have a PR # for the problem? We've experienced > it on 10.0R3 and R4. It's not widely supported in those releases but > Juniper initially told us it should work. It's the #1 reason we're > looking at 10.4. > > Cheers, > Dale ___ 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] Trying to get OSPF to work across IPsec for Redundancy
Hello All:
I'm trying to get OSPF up over IPsec. We have two IPsec tunnels, a primary and
a secondary that our spoke router can use. We want to have the spoke router
run OSPF across both and then in case of a failure of the primary hub router
(where the primary IPsec tunnel terminates) OSPF will direct traffic over the
backup tunnel to the backup hub.
So far I have seen OSPF on the spoke router come up just a couple of times but
only to one or the other peer. It never has come up to both peers. Here are
my configurations for OSPF and the services interfaces below. Also BGP is up
on all routers and all routers are reachable via BGP.
If anyeone can guide me in the right direction to get OSPF working over IPsec
that would be most apprectiated!
Spoke router:
[edit]
Devin@SRX210-2# show protocols ospf
area 0.0.0.2 {
interface st0.0 {
interface-type p2p;
neighbor 10.10.10.1;
}
interface st0.1 {
interface-type p2p;
neighbor 10.10.11.1;
}
}
[edit]
Devin@SRX210-2# show interfaces st0
unit 0 {
point-to-point;
family inet {
address 10.10.10.2/30;
}
}
unit 1 {
point-to-point;
family inet {
address 10.10.11.2/30;
}
}
Primary Hub router:
[edit]
Devin@M7i-1# show protocols ospf
area 0.0.0.2 {
interface sp-1/2/0.1 {
interface-type p2p;
neighbor 10.10.10.2;
}
}
[edit]
Devin@M7i-1# show interfaces sp-1/2/0
unit 1 {
point-to-point;
family inet {
address 10.10.10.1/30;
}
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
Backup hub router:
[edit]
Devin@J4350-1# show protocols ospf
area 0.0.0.2 {
interface st0.0 {
interface-type p2p;
neighbor 10.10.11.2;
}
}
[edit]
Devin@J4350-1# show interfaces st0
unit 0 {
point-to-point;
family inet {
address 10.10.11.1/30;
}
}
DJ
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
