[j-nsp] juniper-nsp Digest, Vol 67, Issue 3
Judd, Michael (Michael)
mjudd at alcatel-lucent.com
Tue Jun 3 06:11:34 EDT 2008
Hello,
Taking into account the architecture of JUNOS I would suspect that this
PR would affect all interfaces and would not be specific to a
media-type.
Regards
Mike
-------------------
Message: 3
From: gastontejia at osinet.com.ar
Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12
To: juniper-nsp at puck.nether.net
Message-ID: <20080602175815.510kbit9jj9c4wo0 at otto.l637.osinet.com.ar>
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Hi, just one question.. they have confirmed that it's broken for 8.3...
or for 8.x ?? and for a particular Media-type ?
BR
Gaston.
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
juniper-nsp-request at puck.nether.net
Sent: Tuesday, June 03, 2008 2:18 AM
To: juniper-nsp at puck.nether.net
Subject: juniper-nsp Digest, Vol 67, Issue 3
Send juniper-nsp mailing list submissions to
juniper-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/juniper-nsp
or, via email, send a message with subject or body 'help' to
juniper-nsp-request at puck.nether.net
You can reach the person managing the list at
juniper-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of juniper-nsp digest..."
Today's Topics:
1. Re: Juniper monitoring and syslog (Kevin Oberman)
2. Re: Juniper M40e - Junos 8.3 - coc12 (Judd, Michael (Michael))
3. Re: Juniper M40e - Junos 8.3 - coc12 (gastontejia at osinet.com.ar)
4. Re: Aggregated SONET: Incorrect load balancing (Erdem Sener)
5. Re: Aggregated SONET: Incorrect load balancing (Andrew Degtiariov)
----------------------------------------------------------------------
Message: 1
Date: Mon, 02 Jun 2008 09:45:15 -0700
From: "Kevin Oberman" <oberman at es.net>
Subject: Re: [j-nsp] Juniper monitoring and syslog
To: Shane Ronan <sronan at fattoc.com>
Cc: Juniper-Nsp <juniper-nsp at puck.nether.net>
Message-ID: <20080602164515.976944500F at ptavv.es.net>
Content-Type: text/plain; charset="us-ascii"
> From: Shane Ronan <sronan at fattoc.com>
> Date: Mon, 2 Jun 2008 08:02:42 -0700
> Sender: juniper-nsp-bounces at puck.nether.net
>
> Love Smokeing...
>
> So much in fact that my firm paid the OpenNMS group to add Smokeping
> like functionality to OpenNMS. Now you have the Smokeping like
> functionality with a full featured NMS.
Thank you! The community often forgets to thank the folks willing to
make such contributions.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL:
<https://puck.nether.net/pipermail/juniper-nsp/attachments/20080602/9222
6dc6/attachment-0001.bin>
------------------------------
Message: 2
Date: Mon, 2 Jun 2008 15:39:15 -0500
From: "Judd, Michael \(Michael\)" <mjudd at alcatel-lucent.com>
Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12
To: "Judd, Michael \(Michael\)" <mjudd at alcatel-lucent.com>, "Perry,
Andrew" <Andrew.Perry at qwest.com>
Cc: juniper-nsp at puck.nether.net
Message-ID:
<466DE5A5B3EF564CB354B201DD5ED30701988410 at ILEXC2U01.ndc.lucent.com>
Content-Type: text/plain; charset="US-ASCII"
Hello, Juniper confirmed that this feature is broken in 8.x JUNOS.
Existing PR.
Specifically, the interface down timer does not work.
Regards
Mike
-----Original Message-----
From: Judd, Michael (Michael)
Sent: Tuesday, May 27, 2008 10:29 AM
To: 'Perry, Andrew'
Subject: RE: [j-nsp] Juniper M40e - Junos 8.3 - coc12
Hi Andy,
I have not tested 8.3 on any other chassis. I am awaiting a response
from Juniper to tell me if it is a defect with 8.3.
Regards
Mike
-----Original Message-----
From: Perry, Andrew [mailto:Andrew.Perry at qwest.com]
Sent: Tuesday, May 27, 2008 10:24 AM
To: Judd, Michael (Michael)
Subject: RE: [j-nsp] Juniper M40e - Junos 8.3 - coc12
Are you saying it only applies to the M40e or to any M-Series with 8.3
code?
Andy
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net on behalf of Judd, Michael
(Michael)
Sent: Tue 5/27/2008 8:19 AM
To: Erdem Sener
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12
Erdem,
Thank you. I tested on another box, an M7i running 7.4. The hold-timer
worked as designed. I think there is a problem with the hold-timer in
JUNOS 8.3 for the M40e. I am addressing this with Juniper and asking
them to create a PR for this issue.
Thank you for the reply.
Regards
Mike
-----Original Message-----
From: Erdem Sener [mailto:erdems at gmail.com]
Sent: Friday, May 23, 2008 6:06 PM
To: Judd, Michael (Michael)
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12
Hi Mike,
hold-time does exactly what the documentation states; meaning that
instead of immediately bringing the interface down, it waits as much as
your hold time 'down' counter before making the interface down and as
much as your 'up'
counter before marking a down interface as up.
For example, the configuration below tells JUNOS to wait for 2 seconds
after an error (e.g. AIS) before bringing the interface down. If the AIS
took, say 5 seconds and the interface is down; JUNOS will wait for 2
seconds after the alarm is cleared before bringing the interface up.
e3-1/3/0 {
hold-time up 1000 down 2000;
unit 0 {
family mlppp {
bundle lsq-1/2/0.0;
}
}
}
Based on how your alarms are happening (e.g. sub-second, 1 second
etc.), you may use this feature safely I'd say.
HTH
Erdem
On Thu, May 22, 2008 at 8:31 PM, Judd, Michael (Michael)
<mjudd at alcatel-lucent.com> wrote:
> BACKGROUND:
>
> I am working with a customer who is using MLPPP. Whenever the directly
> connected DACS experiences any sort of redunancy switchover, separate
> from an APS switchover, a path AIS is generated which causes the M40's
> ct3's to bounce. When this happens, all MLPPP re-negotiation/restart
> occurs resulting in higher than desired recovery times for the network
> that this service is serving. I found the following parameter in the
> Juniper docs but have no easy way to test this in the lab.
> Cisco has a similar feature called carrier-delay.
>
> Question; does anyone have any experience or insight into the
> following interfaces hold-time parameter?
>
> http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-netw
> or k-interfaces/html/interfaces-physical-config31.html
>
> Damping Interface Transitions
>
> By default, when an interface changes from being up to being down, or
> from down to up, this transition is advertised immediately to the
> hardware and the JUNOS software. In some situations-for example, when
> an interface is connected to an add-drop multiplexer (ADM) or
> wavelength-division multiplexer (WDM), or to protect against SONET/SDH
> framer holes-you might want to damp interface transitions. This means
> not advertising the interface's transition until a certain period of
> time has passed, called the hold-time. When you have damped interface
> transitions and the interface goes from up to down, the interface is
> not advertised to the rest of the system as being down until it has
> remained down for the hold-time period. Similarly when an interface
> goes from down to up, it is not advertised as being up until it has
> remained up for the hold-time period.
>
> To damp interface transitions, include the hold-time statement at the
> [edit interfaces interface-name] hierarchy level:
>
> [edit interfaces interface-name]
>
> hold-time
> <http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-net
> wo rk-interfaces/html/interfaces-summary143.html#1015655> up
> milliseconds down milliseconds;
>
> The time can be a value from 0 through 65,534 milliseconds. The
> default value is 0, which means that interface transitions are not
> damped. The JUNOS software advertises the transition within 100
> milliseconds of the time value you specify.
> Thank you !
>
>
>
> ~~~~~~~~~~~~~~~
> Mike Judd
> Member of Technical Staff
> Alcatel-Lucent
> 4 Robbins Road
> Westford, MA 01886
> office: 978-392-6406
>
> Alcatel-Lucent Global TSS Contact Center
> ** 24x7x365 Customer Technical Support ** In the United States;
> 1-866-Lucent8, option 1 / 1-866-582-3688, option 1 Outside of the
> United States 1-630-224-4672 ~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
This communication is the property of Qwest and may contain confidential
or privileged information. Unauthorized use of this communication is
strictly prohibited and may be unlawful. If you have received this
communication in error, please immediately notify the sender by reply
e-mail and destroy all copies of the communication and any attachments.
------------------------------
Message: 3
Date: Mon, 02 Jun 2008 17:58:15 -0300
From: gastontejia at osinet.com.ar
Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12
To: juniper-nsp at puck.nether.net
Message-ID: <20080602175815.510kbit9jj9c4wo0 at otto.l637.osinet.com.ar>
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Hi, just one question.. they have confirmed that it's broken for 8.3...
or for 8.x ?? and for a particular Media-type ?
BR
Gaston.
Quoting "Judd, Michael \(Michael\)" <mjudd at alcatel-lucent.com>:
>
> Hello, Juniper confirmed that this feature is broken in 8.x JUNOS.
> Existing PR.
>
> Specifically, the interface down timer does not work.
>
> Regards
>
> Mike
>
> -----Original Message-----
> From: Judd, Michael (Michael)
> Sent: Tuesday, May 27, 2008 10:29 AM
> To: 'Perry, Andrew'
> Subject: RE: [j-nsp] Juniper M40e - Junos 8.3 - coc12
>
> Hi Andy,
>
> I have not tested 8.3 on any other chassis. I am awaiting a response
> from Juniper to tell me if it is a defect with 8.3.
>
> Regards
>
> Mike
>
> -----Original Message-----
> From: Perry, Andrew [mailto:Andrew.Perry at qwest.com]
> Sent: Tuesday, May 27, 2008 10:24 AM
> To: Judd, Michael (Michael)
> Subject: RE: [j-nsp] Juniper M40e - Junos 8.3 - coc12
>
> Are you saying it only applies to the M40e or to any M-Series with 8.3
> code?
>
> Andy
>
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net on behalf of Judd, Michael
> (Michael)
> Sent: Tue 5/27/2008 8:19 AM
> To: Erdem Sener
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12
>
> Erdem,
>
> Thank you. I tested on another box, an M7i running 7.4. The hold-timer
> worked as designed. I think there is a problem with the hold-timer in
> JUNOS 8.3 for the M40e. I am addressing this with Juniper and asking
> them to create a PR for this issue.
>
> Thank you for the reply.
>
> Regards
>
> Mike
>
> -----Original Message-----
> From: Erdem Sener [mailto:erdems at gmail.com]
> Sent: Friday, May 23, 2008 6:06 PM
> To: Judd, Michael (Michael)
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12
>
> Hi Mike,
>
> hold-time does exactly what the documentation states; meaning that
> instead of immediately bringing the interface down, it waits as much
> as your hold time 'down' counter before making the interface down and
> as much as your 'up'
> counter before marking a down interface as up.
>
> For example, the configuration below tells JUNOS to wait for 2 seconds
> after an error (e.g. AIS) before bringing the interface down. If the
> AIS took, say 5 seconds and the interface is down; JUNOS will wait for
> 2 seconds after the alarm is cleared before bringing the interface up.
>
> e3-1/3/0 {
> hold-time up 1000 down 2000;
> unit 0 {
> family mlppp {
> bundle lsq-1/2/0.0;
> }
> }
> }
>
> Based on how your alarms are happening (e.g. sub-second, 1 second
> etc.), you may use this feature safely I'd say.
>
> HTH
> Erdem
>
> On Thu, May 22, 2008 at 8:31 PM, Judd, Michael (Michael)
> <mjudd at alcatel-lucent.com> wrote:
>> BACKGROUND:
>>
>> I am working with a customer who is using MLPPP. Whenever the
>> directly
>
>> connected DACS experiences any sort of redunancy switchover, separate
>> from an APS switchover, a path AIS is generated which causes the
>> M40's
>
>> ct3's to bounce. When this happens, all MLPPP re-negotiation/restart
>> occurs resulting in higher than desired recovery times for the
>> network
>
>> that this service is serving. I found the following parameter in the
>> Juniper docs but have no easy way to test this in the lab.
>> Cisco has a similar feature called carrier-delay.
>>
>> Question; does anyone have any experience or insight into the
>> following interfaces hold-time parameter?
>>
>> http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-net
>> w or k-interfaces/html/interfaces-physical-config31.html
>>
>> Damping Interface Transitions
>>
>> By default, when an interface changes from being up to being down, or
>> from down to up, this transition is advertised immediately to the
>> hardware and the JUNOS software. In some situations-for example, when
>> an interface is connected to an add-drop multiplexer (ADM) or
>> wavelength-division multiplexer (WDM), or to protect against
>> SONET/SDH
>
>> framer holes-you might want to damp interface transitions. This means
>> not advertising the interface's transition until a certain period of
>> time has passed, called the hold-time. When you have damped interface
>> transitions and the interface goes from up to down, the interface is
>> not advertised to the rest of the system as being down until it has
>> remained down for the hold-time period. Similarly when an interface
>> goes from down to up, it is not advertised as being up until it has
>> remained up for the hold-time period.
>>
>> To damp interface transitions, include the hold-time statement at the
>> [edit interfaces interface-name] hierarchy level:
>>
>> [edit interfaces interface-name]
>>
>> hold-time
>> <http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-ne
>> t wo rk-interfaces/html/interfaces-summary143.html#1015655> up
>> milliseconds down milliseconds;
>>
>> The time can be a value from 0 through 65,534 milliseconds. The
>> default value is 0, which means that interface transitions are not
>> damped. The JUNOS software advertises the transition within 100
>> milliseconds of the time value you specify.
>> Thank you !
>>
>>
>>
>> ~~~~~~~~~~~~~~~
>> Mike Judd
>> Member of Technical Staff
>> Alcatel-Lucent
>> 4 Robbins Road
>> Westford, MA 01886
>> office: 978-392-6406
>>
>> Alcatel-Lucent Global TSS Contact Center
>> ** 24x7x365 Customer Technical Support ** In the United States;
>> 1-866-Lucent8, option 1 / 1-866-582-3688, option 1 Outside of the
>> United States 1-630-224-4672 ~~~~~~~~~~~~~~~~~
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> This communication is the property of Qwest and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the
> sender by reply e-mail and destroy all copies of the communication and
any attachments.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
------------------------------
Message: 4
Date: Tue, 3 Jun 2008 01:46:10 +0200
From: "Erdem Sener" <erdems at gmail.com>
Subject: Re: [j-nsp] Aggregated SONET: Incorrect load balancing
To: "Andrew Degtiariov" <andrew.degtiariov at gmail.com>
Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Message-ID:
<392c91050806021646w3cf95b2xf81e3779f81c659a at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Andrew,
If ever you upgrade to 9.0+, you could use 'indexed-next-hop' knob:
http://www.juniper.net/techpubs/software/junos/junos90/swconfig-policy/i
ndexed-next-hop.html
Following may also be interesting for you:
http://www.juniper.net/techpubs/software/junos/junos90/swconfig-policy/p
er-prefix.html#per-prefix-statement
Cheers,
Erdem
On Mon, Jun 2, 2008 at 3:38 PM, Andrew Degtiariov
<andrew.degtiariov at gmail.com> wrote:
> Hello!
> We have problems with incorrect balancing on asX interfaces: one of
> interfaces from bundle always full loaded but other have a free
> bandwidth.
>
> ad at host> show interfaces as0 detail
> Physical interface: as0, Enabled, Physical link is Up Interface
> index: 128, SNMP ifIndex: 38, Generation: 11
> Description: XXXXXX
> Link-level type: Cisco-HDLC, MTU: 4474, Speed: 311040kbps, Minimum
> links needed: 1
> Device flags : Present Running
> Interface flags: SNMP-Traps Internal: 0x4000
> Link flags : Keepalives
> Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
> Last flapped : Never
> Statistics last cleared: Never
> Traffic statistics:
> Input bytes : 88014189685409 100101256 bps
> Output bytes : 233504346126377 224426680 bps
> Input packets: 215881346509 39284 pps
> Output packets: 320492035869 36532 pps
>
> Logical interface as0.0 (Index 67) (SNMP ifIndex 42) (Generation 6)
> Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Cisco-HDLC
> Statistics Packets pps Bytes bps
> Bundle:
> Input : 215879698457 39284 88014153428265 100101256
> Output: 320490390799 36490 233504161135208 224369696
> Link:
> so-1/3/0:0.0
> Input : 15050048922 27106 6085042177400 66550112
> Output: 16070445975 12811 11743234420336 76498040
> so-1/3/0:1.0
> Input : 13382313 12178 4479819115 33551144
> Output: 26537823 23679 20157131134 147871656
> Protocol inet, MTU: 4470, Generation: 13, Route table: 0
> Flags: None
> Addresses, Flags: Is-Preferred Is-Primary
> ----cut-cut----
> Protocol mpls, MTU: 4458, Generation: 14, Route table: 0
> Flags: None
>
> ad at host> show configuration interfaces as0 description XXXX;
> encapsulation cisco-hdlc; aggregated-sonet-options {
> minimum-links 1;
> link-speed oc3;
> }
> unit 0 {
> family inet {
> address ---cut--cut---;
> }
> family mpls;
> }
>
> ad at host> show configuration interfaces so-1/3/0:0 clocking external;
> sonet-options {
> no-payload-scrambler;
> aggregate as0;
> }
> ad at host> show configuration interfaces so-1/3/0:1 clocking external;
> sonet-options {
> no-payload-scrambler;
> aggregate as0;
> }
>
> ad at host>
>
> Platform: Juniper M20, JUNOS 7.5R2.8
>
> Is there any ways to load interfaces in bundle as0 more fairly?
>
> --
> Andrew Degtiariov
> DA-RIPE
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
------------------------------
Message: 5
Date: Tue, 3 Jun 2008 09:14:26 +0300
From: "Andrew Degtiariov" <andrew.degtiariov at gmail.com>
Subject: Re: [j-nsp] Aggregated SONET: Incorrect load balancing
To: "Erdem Sener" <erdems at gmail.com>
Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Message-ID:
<5d1b76f60806022314u133decadg506d6de36d233e86 at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2008/6/3 Erdem Sener <erdems at gmail.com>:
> Hi Andrew,
>
> If ever you upgrade to 9.0+, you could use 'indexed-next-hop' knob:
>
> http://www.juniper.net/techpubs/software/junos/junos90/swconfig-policy
> /indexed-next-hop.html
>
> Following may also be interesting for you:
>
> http://www.juniper.net/techpubs/software/junos/junos90/swconfig-policy
> /per-prefix.html#per-prefix-statement
>
> Cheers,
> Erdem
So I need to dismantle as0 and doing load balancing on 2 L3 interfaces
so-1/3/0:0.0 and so-1/3/0:1.0?
> On Mon, Jun 2, 2008 at 3:38 PM, Andrew Degtiariov
> <andrew.degtiariov at gmail.com> wrote:
>> Hello!
>> We have problems with incorrect balancing on asX interfaces: one of
>> interfaces from bundle always full loaded but other have a free
>> bandwidth.
>>
>> ad at host> show interfaces as0 detail
>> Physical interface: as0, Enabled, Physical link is Up Interface
>> index: 128, SNMP ifIndex: 38, Generation: 11
>> Description: XXXXXX
>> Link-level type: Cisco-HDLC, MTU: 4474, Speed: 311040kbps, Minimum
>> links needed: 1
>> Device flags : Present Running
>> Interface flags: SNMP-Traps Internal: 0x4000
>> Link flags : Keepalives
>> Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
>> Last flapped : Never
>> Statistics last cleared: Never
>> Traffic statistics:
>> Input bytes : 88014189685409 100101256 bps
>> Output bytes : 233504346126377 224426680 bps
>> Input packets: 215881346509 39284 pps
>> Output packets: 320492035869 36532 pps
>>
>> Logical interface as0.0 (Index 67) (SNMP ifIndex 42) (Generation 6)
>> Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Cisco-HDLC
>> Statistics Packets pps Bytes bps
>> Bundle:
>> Input : 215879698457 39284 88014153428265 100101256
>> Output: 320490390799 36490 233504161135208 224369696
>> Link:
>> so-1/3/0:0.0
>> Input : 15050048922 27106 6085042177400 66550112
>> Output: 16070445975 12811 11743234420336 76498040
>> so-1/3/0:1.0
>> Input : 13382313 12178 4479819115 33551144
>> Output: 26537823 23679 20157131134 147871656
>> Protocol inet, MTU: 4470, Generation: 13, Route table: 0
>> Flags: None
>> Addresses, Flags: Is-Preferred Is-Primary
>> ----cut-cut----
>> Protocol mpls, MTU: 4458, Generation: 14, Route table: 0
>> Flags: None
>>
>> ad at host> show configuration interfaces as0 description XXXX;
>> encapsulation cisco-hdlc; aggregated-sonet-options {
>> minimum-links 1;
>> link-speed oc3;
>> }
>> unit 0 {
>> family inet {
>> address ---cut--cut---;
>> }
>> family mpls;
>> }
>>
>> ad at host> show configuration interfaces so-1/3/0:0 clocking external;
>> sonet-options {
>> no-payload-scrambler;
>> aggregate as0;
>> }
>> ad at host> show configuration interfaces so-1/3/0:1 clocking external;
>> sonet-options {
>> no-payload-scrambler;
>> aggregate as0;
>> }
>>
>> ad at host>
>>
>> Platform: Juniper M20, JUNOS 7.5R2.8
>>
>> Is there any ways to load interfaces in bundle as0 more fairly?
>>
>> --
>> Andrew Degtiariov
>> DA-RIPE
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
--
Andrew Degtiariov
DA-RIPE
------------------------------
_______________________________________________
juniper-nsp mailing list
juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
End of juniper-nsp Digest, Vol 67, Issue 3
******************************************
More information about the juniper-nsp
mailing list