[c-nsp] ATM Issues

[Clayton Zekelman]

I did an interesting experiment.  I have a couple of PVC's between the 2 sites, so I used one of the spare ones, and have determined that the packet loss is directly related to using RBE or Bridging.

There appears to be no packet loss when I do plain IP over ATM.

I set up a test IP address on the ATM subinterface on each end, plus put them into a bridge group and placed IP addresses on the BVI's on each end.

When pinging with 5000 pings at 4000 bytes, I get no packet loss between the 2 IP over ATM addresses, but get packet loss when I ping between the 2 BVI IP addresses with 5000 pings at 1500 bytes.  Yep, packet loss on the SAME subinterface and PVC at the same time as I'm getting no packet loss on the same interface (I tried both at the same time, and both separately).

I get similar results with RBE, which also appears to have issues under heavy load (works fine when only the PING traffic is on the PVC).


Next step is to convert completely to IP over ATM, but I'll have to get some fiber run and an extra PA-A3-OC3.




----- Original Message ---------------

Subject: Re: [c-nsp] ATM Issues
   From: Mark Rogaski <wendigo at pobox.com>
   Date: Sun, 21 Aug 2005 14:35:28 -0400
     To: clayton at mnsi.net
     Cc: cisco-nsp at puck.nether.net

>
>--nFreZHaLTZJo0R7j
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>An entity claiming to be clayton at mnsi.net (clayton at mnsi.net) wrote:
>:=20
>: Both routers are acting as bridges (ATM Subinterface sits in the same bri=
>dge group as a
>: GigE Sub Interface).
>:=20
>: For some strange reason, I get occasional packet loss, particularly durin=
>g periods of
>: higher (30 meg or so) activity.  The PVC is set in the carrier's network =
>for 100 Meg
>: UBR service.
>
>
>The first thing to ask is how many links the are in the path ... are you
>sure the packet loss is on the ATM link?
>
>
>:=20
>: I understand that the carrier may drop cells due to the class of service =
>we're using,
>: but the funny part is that I can't see any AAL5 errors on the PVC.
>
>The carrier may drop cells regardless of what class of service is used, the
>class of service just specifies how to determine what is considered
>compliant or non-compliant traffic. =20
>
>
>:=20
>: I would expect that if the carrier is dropping cells, we'd see the AAL5 e=
>rror counters
>: increment.
>:=20
>
>Not necessarily, if the carrier is doing early packet discard (EPD) all
>cells in the AAL5 PDU will be discarded and no AAL5 errors will occur.  If
>the carrier is doing partial packet discard (PPD or tail discard),
>non-compiance can be tagged for any cell in the frame ... all cells except
>the last one will be dropped.  The last one is left to prevent the next
>frame from looking like an oversized frame.
>
>EPD makes sense for a UBR service, when the ingress queues build up to a
>certain threshold entire frames are discarded and oversubscribed bandwidth
>isn't wasted transporting partial frames that the customer will discard
>anyway.
>
>Mark
>
>--=20
>[]                           |
>[] Mark Rogaski              |         Computers save time like kudzu
>[] wendigo at pobox.com         |         prevents soil erosion.
>[] mrogaski at cpan.org         |                      -- Al Castanoli
>[]                           |
>
>--nFreZHaLTZJo0R7j
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: Digital signature
>Content-Disposition: inline
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>
>iD8DBQFDCMlwutYv6C+bLmgRAtZpAJ9i3ToOI2vr94Hl0x/6m8ibbkVO0wCgpkhp
>7lAZjs9wlD5/duOfEQd0gsQ=
>=GvM5
>-----END PGP SIGNATURE-----
>
>--nFreZHaLTZJo0R7j--