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: [EMAIL PROTECTED] Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12 To: [email protected] Message-ID: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 2:18 AM To: [email protected] Subject: juniper-nsp Digest, Vol 67, Issue 3 Send juniper-nsp mailing list submissions to [email protected] 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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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" <[EMAIL PROTECTED]> Subject: Re: [j-nsp] Juniper monitoring and syslog To: Shane Ronan <[EMAIL PROTECTED]> Cc: Juniper-Nsp <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" > From: Shane Ronan <[EMAIL PROTECTED]> > Date: Mon, 2 Jun 2008 08:02:42 -0700 > Sender: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] 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\)" <[EMAIL PROTECTED]> Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12 To: "Judd, Michael \(Michael\)" <[EMAIL PROTECTED]>, "Perry, Andrew" <[EMAIL PROTECTED]> Cc: [email protected] Message-ID: <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] on behalf of Judd, Michael (Michael) Sent: Tue 5/27/2008 8:19 AM To: Erdem Sener Cc: [email protected] 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:[EMAIL PROTECTED] Sent: Friday, May 23, 2008 6:06 PM To: Judd, Michael (Michael) Cc: [email protected] 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) <[EMAIL PROTECTED]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] 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: [EMAIL PROTECTED] Subject: Re: [j-nsp] Juniper M40e - Junos 8.3 - coc12 To: [email protected] Message-ID: <[EMAIL PROTECTED]> 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\)" <[EMAIL PROTECTED]>: > > 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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] on behalf of Judd, Michael > (Michael) > Sent: Tue 5/27/2008 8:19 AM > To: Erdem Sener > Cc: [email protected] > 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:[EMAIL PROTECTED] > Sent: Friday, May 23, 2008 6:06 PM > To: Judd, Michael (Michael) > Cc: [email protected] > 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) > <[EMAIL PROTECTED]> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ > juniper-nsp mailing list [email protected] > 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > ------------------------------ Message: 4 Date: Tue, 3 Jun 2008 01:46:10 +0200 From: "Erdem Sener" <[EMAIL PROTECTED]> Subject: Re: [j-nsp] Aggregated SONET: Incorrect load balancing To: "Andrew Degtiariov" <[EMAIL PROTECTED]> Cc: "[email protected]" <[email protected]> Message-ID: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. > > [EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED]> 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; > } > > [EMAIL PROTECTED]> show configuration interfaces so-1/3/0:0 clocking > external; > sonet-options { > no-payload-scrambler; > aggregate as0; > } > [EMAIL PROTECTED]> show configuration interfaces so-1/3/0:1 clocking > external; > sonet-options { > no-payload-scrambler; > aggregate as0; > } > > [EMAIL PROTECTED]> > > 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > ------------------------------ Message: 5 Date: Tue, 3 Jun 2008 09:14:26 +0300 From: "Andrew Degtiariov" <[EMAIL PROTECTED]> Subject: Re: [j-nsp] Aggregated SONET: Incorrect load balancing To: "Erdem Sener" <[EMAIL PROTECTED]> Cc: "[email protected]" <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=UTF-8 2008/6/3 Erdem Sener <[EMAIL PROTECTED]>: > 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 > <[EMAIL PROTECTED]> 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. >> >> [EMAIL PROTECTED]> 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 >> >> [EMAIL PROTECTED]> 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; >> } >> >> [EMAIL PROTECTED]> show configuration interfaces so-1/3/0:0 clocking >> external; >> sonet-options { >> no-payload-scrambler; >> aggregate as0; >> } >> [EMAIL PROTECTED]> show configuration interfaces so-1/3/0:1 clocking >> external; >> sonet-options { >> no-payload-scrambler; >> aggregate as0; >> } >> >> [EMAIL PROTECTED]> >> >> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > -- Andrew Degtiariov DA-RIPE ------------------------------ _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp End of juniper-nsp Digest, Vol 67, Issue 3 ****************************************** _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
