[c-nsp] Turning PVCs into VLANs

[Alastair Johnson]

This bug also strikes on the early 12.1 releases for the ATM module
for the 2924M-XL.  We ran into this a few months ago (I posted here
about it).

The very weird thing was if we used 12.2 and RBE on the ATM side,
the problem didn't occur.  But with 12.0 and BPVCs, it did.

It's very peculiar and if you haven't read about the bug, can leave
you and the telco looking for faults for a long long time.  In our
case, we had only one circuit going through a 2900 which didn't
work, and all the others did as they were going through 6500s.

In the end, the telco replaced the 2900 with a Martini tunnel
via Vendor J.

aj

On Fri, 19 Nov 2004, Clinton Work wrote:

>
> The ws-x5158 (ATM OC3) works well, but throughput maxes out around
> 80Mbps bi-directional traffic and 50,000 pps with 64-byte frames (RFC
> 2684). I would run a IOS version on the ATM module of
> c5atm-wt-mz.120-28.W5.30.bin or later to avoid a bug with Ethernet
> frames not being padded to 64-bytes. If the far end device is a Cisco
> router using 1483 bridged PVCs over ATM with CEF enabled you'll
> encounter the problem.
>
> CSCdp82703  - Packets less than 64 bytes should be padded on 1483 PVCs
> http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdp82703&Submit=Search
>
>
>
> Dan Armstrong wrote:
> > A 5505 with a x5158 or x5161 LANE card and an Ethernet blade will do 1483.
> >
> >
> _______________________________________________
> 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/
>

-- 
Network Operations		||	noc. +64.9.915.1825
Maxnet				||	cell. +64.21.639.706