[nsp] Packet loss on MLPPP

[Vincent De Keyzer]

No, it's MLPPP that takes care of (exact) load balancing as far as I
understand? Or I don't get your question?...

Vincent


> -----Original Message-----
> From: Johnson, Michael [mailto:michael.johnson at digex.com] 
> Sent: vendredi 21 novembre 2003 15:27
> To: 'Vincent De Keyzer'; 'cisco-nsp at puck.nether.net'
> Subject: RE: [nsp] Packet loss on MLPPP
> 
> 
> Are you doing per packet load balancing across the MLPPP link?
> 
> Mike j
> 
> -----Original Message-----
> From: Vincent De Keyzer [mailto:vincent at dekeyzer.net] 
> Sent: Friday, November 21, 2003 6:53 AM
> To: cisco-nsp at puck.nether.net
> Subject: [nsp] Packet loss on MLPPP
> 
> 
> Hi,
>  
> I have some packet loss on a PPP multilink, and I am 
> wondering what it could be caused by. I get 0.4% packet loss, 
> with no errors at the E1 level.
>  
> Could it be a software problem? When a ping packet fails, 
> 'debug ppp multilink fragments' produces:
>  
> Nov 21 12:39:40.111 CET: Mu1 MLP: Lost fragment DF0835 in 
> 'EBIC00101r' (all links have rcvd higher seq#) Nov 21 
> 12:39:43.091 CET: Mu1 MLP: Lost fragment DF0BE1 in 
> 'EBIC00101r' (all links have rcvd higher seq#) Nov 21 12:39:46.095
> CET: Mu1 MLP: Lost fragment DF0F1B in 'EBIC00101r' (all links 
> have rcvd higher seq#) Nov 21 12:40:47.373 CET: Mu1 MLP: Lost 
> fragment DF2FF1 in 'EBIC00101r' (all links have rcvd higher 
> seq#) Nov 21 12:40:59.281 CET: Mu1
> MLP: Lost fragment DF383F in 'EBIC00101r' (all links have 
> rcvd higher seq#) Nov 21 12:43:33.136 CET: Mu1 MLP: Lost 
> fragment DF706D in 'EBIC00101r' (all links have rcvd higher 
> seq#) Nov 21 12:44:22.437 CET: Mu1 MLP: Lost fragment DF83FB 
> in 'EBIC00101r' (all links have rcvd higher seq#) Nov 21 12:44:50.877
> CET: Mu1 MLP: Lost fragment DF9185 in 'EBIC00101r' (all links 
> have rcvd higher seq#) Nov 21 12:45:17.702 CET: Mu1 MLP: Lost 
> fragment DFA15D in 'EBIC00101r' (all links have rcvd higher 
> seq#) Nov 21 12:47:29.148 CET: Mu1
> MLP: Lost fragment DFDD1B in 'EBIC00101r' (all links have 
> rcvd higher seq#)
> 
> Any idea what this means?
>  
> Thanks for any help (details below if required)
>  
> Vincent
>  
> ______
>  
> The setup is as follows:
>  
> PoP side, a 2621 running "IOS (tm) C2600 Software 
> (C2600-JS-M), Version 12.2(5), RELEASE SOFTWARE (fc1)" 
> Customer side, a 2610 running "IOS (tm) C2600 Software 
> (C2600-I-M), Version 12.1(5)T5,  RELEASE SOFTWARE (fc1)"
>  
> Both are equipped with VWIC-2MFT-E1, and the config looks like this:
>  
> interface Serial0/1:0
>  description First E1
>  no ip address
>  encapsulation ppp
>  load-interval 30
>  ppp multilink
>  multilink-group 1
> 
> interface Serial1/2:0
>  description Second E1
>  no ip address
>  encapsulation ppp
>  load-interval 30
>  ppp multilink
>  multilink-group 1
> 
> interface Multilink1
>  description #customer: XXXX
>  ip address a.b.c.d 255.255.255.252
>  no ip redirects
>  no ip proxy-arp
>  load-interval 30
>  ntp broadcast
>  ppp multilink
>  multilink-group 1
>  
> The controllers are perfect for the last 24 hours 
> (specifically, no slips, so not a clocking problem?): 
>  
> E1 1/2 is up.
>   Applique type is Channelized E1 - balanced
>   No alarms detected.
>   alarm-trigger is not set
>   Version info Firmware: 20010805, FPGA: 15
>   Framing is CRC4, Line Code is HDB3, Clock Source is Internal.
>    Current port master clock: recovered from controller 1/1
>   Total Data (last 24 hours)
>      0 Line Code Violations, 0 Path Code Violations,
>      0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
>      0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 
> 0 Unavail Secs
> 
> E1 0/1 is up.
>   Applique type is Channelized E1 - balanced
>   No alarms detected.
>   alarm-trigger is not set
>   Version info Firmware: 20010805, FPGA: 15
>   Framing is CRC4, Line Code is HDB3, Clock Source is Line.
>   Total Data (last 24 hours)
>      0 Line Code Violations, 0 Path Code Violations,
>      0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
>      0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 
> 0 Unavail Secs
> 
> pedro#ping ip
> Target IP address: ebic02
> Repeat count [5]: 1000
> Datagram size [100]: 1500
> Timeout in seconds [2]:
> Extended commands [n]:
> Sweep range of sizes [n]:
> Type escape sequence to abort.
> Sending 1000, 1500-byte ICMP Echos to 217.64.241.42, timeout 
> is 2 seconds: 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Nov 21 12:54:27.444 CET: Mu1 MLP: Lost fragment E055B9 in 
> 'EBIC00101r' (all links have rcvd higher 
> seq#).!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!
> !!!!!!!!!!!!!!!!!!!!
> Success rate is 99 percent (996/1000), round-trip min/avg/max 
> = 8/12/80 ms pedro#
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco> -nsp
> archive at 
> http://puck.nether.net/pipermail/cisco-nsp/
>