[c-nsp] ATM CRC errors
Dean Penton
dean at northrock.bm
Wed Oct 27 16:16:44 EDT 2004
Hi,
I have the same issue with one of our DS3's. The telco has changed the
connectors, etc but still seeing them. I suspect a bad card or that the atm
is dropping cells on me but the Telco here cannot give me a straight answer.
There is an issue with certain DS3 ATM cards from Cisco and distance issues
with DS3.
Regards,
Dean
-----Original Message-----
From: cisco-nsp-request at puck.nether.net
[mailto:cisco-nsp-request at puck.nether.net]
Sent: Wednesday, October 27, 2004 4:35 PM
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 23, Issue 101
Send cisco-nsp mailing list submissions to
cisco-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of cisco-nsp digest..."
Today's Topics:
1. Re: how "fast" is L2TP "fast switching" under 12.3T?
(Krzysztof Adamski)
2. Re: What MTU for Bellsouth BBG / BRAS <-> LNS l2TP tunnel?
(Brian Feeny)
3. 6500 vs MG8 vs Force10 E600 (Eric)
4. Re: EIGRP Adversing Problem (Mark)
5. RE: EIGRP Adversing Problem (Oliver Boehmer (oboehmer))
6. ATM CRC errors (James Hamilton)
7. Cat5505 running CatOS 6.3(1) (Sorin CONSTANTINESCU)
8. Re: ATM CRC errors (Andy Dills)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Oct 2004 12:27:24 -0400 (EDT)
From: Krzysztof Adamski <k at adamski.org>
Subject: Re: [c-nsp] how "fast" is L2TP "fast switching" under 12.3T?
To: "Robert E.Seastrom" <rs at seastrom.com>
Cc: cisco-nsp at puck.nether.net
Message-ID:
<Pine.LNX.4.44.0410271223320.29631-100000 at carbon.netxsys.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 27 Oct 2004, Robert E.Seastrom wrote:
> > Your problem is fragmentation, since the L2TP tunnel is delivered
> > over Ethernet, the max MTU is 1500. Every customer frame that is
> > over 1452 causes fragmentation since 1452 + 8(PPPoE) + 12(L2TP) + 8(UDP)
+ 20(IP) = 1500.
> > You can add "ip tcp adjust-mss 1412" to eliminate fragmentation of
> > TCP packets, but you won't be able to do anything about UDP and IPSec
packets.
>
> Yup, the "ip tcp adjust-mss 1412" is already in place. Based on flow
> stats collected upstream, UDP is the biggest contributor; IPSec plays
> a bit role.
If you look inside the UDP packets you will probably discover that they
contain IPSec packets, that seems to be the preferred way of passing IPSec
through NAT boxes.
Here is something you can do to eliminate the UDP problem, set the MTU on
the PPPoE link to 1452, now you are going to guaranty that no fragmentation
is not happening. I have not been brave enough to try this, since I don't
know what will stop working :-) If you try this, let me know how it works.
K
------------------------------
Message: 2
Date: Wed, 27 Oct 2004 11:48:57 -0500
From: Brian Feeny <signal at shreve.net>
Subject: Re: [c-nsp] What MTU for Bellsouth BBG / BRAS <-> LNS l2TP
tunnel?
To: Jon Lewis <jlewis at lewis.org>
Cc: cisco-nsp <cisco-nsp at puck.nether.net>
Message-ID: <18309468-2838-11D9-A1C2-000A9592C292 at shreve.net>
Content-Type: text/plain; charset="us-ascii"
So you are running MTU 4470 on the PVC over which your L2TP session is
built, but I am using 1500, and thats probably the difference.
In the old days I use to think PPPoE was more ideal, because it could
terminate on the customer desktop (WinPoet, etc). But of course DSL is
almost always terminated into CPE, so maybe I should look more closely at
PPPoA vs. PPPoE.
I would still like to solve my MTU issues, which I probably should try to
just raise the MTU of my L2TP port. PPPoA or PPPoE you still have a
customer on ethernet somewhere negotiating an MTU with a distance end, and I
would think there is going to be alot of simularities in the problems you
find.
Brian
On Oct 27, 2004, at 7:59 AM, Jon Lewis wrote:
> On Wed, 27 Oct 2004, Brian Feeny wrote:
>
>> For those of you terminating DSL subscribers using PPPoE over an L2TP
>> tunnel, what MTU are you using for the L2TP tunnel between your LNS
>> and
>> the BRAS/LAC?
>
> ATM2/0 is up, line protocol is up
> Hardware is ENHANCED ATM PA
> Description: DS3 ATM HOST/BROADBAND GATEWAY BS CID#...
> MTU 4470 bytes, sub MTU 4470, BW 40704 Kbit, DLY 190 usec,
>
> Funny thing though is we were never told it would do PPPoE. We
> migrated
> several ATM T1's of PPPoA customers to the BBG DS3, and left them all
> as
> PPPoA. I only recently found out by accident while testing new CPE
> hardware that the BBG will do PPPoE as well.
>
>> What other MTU adjustments are you making for this functionality?
>
> None.
>
> Perhaps you should look into doing PPPoA on the CPE instead of PPPoE.
> I've got an MTU of 1500 on the both the CPE side and the virtual-access
> interface on the server end and no MTU issues. Since the PPPo[EA]
> session
> is handled by Bell's shastas and sent to you as a L2TP session, you
> don't
> even have to change anything on your end...just tell a CPE to do PPPoA
> instead of PPPoE and it should work.
>
> ----------------------------------------------------------------------
> Jon Lewis | I route
> Senior Network Engineer | therefore you are
> Atlantic Net |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>
------------------------------------------------------------------------
------
Brian Feeny, CCIE #8036, CISSP e: signal at shreve.net
Network Engineer p: 318.213.4709
ShreveNet Inc. f: 318.221.6612
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url :
https://puck.nether.net/pipermail/cisco-nsp/attachments/20041027/b7c5d875/PG
P-0001.bin
------------------------------
Message: 3
Date: Wed, 27 Oct 2004 09:54:24 -0700 (PDT)
From: Eric <jammersmurf at yahoo.com>
Subject: [c-nsp] 6500 vs MG8 vs Force10 E600
To: cisco-nsp at puck.nether.net
Message-ID: <20041027165424.5310.qmail at web52702.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
My company is looking at replacing it's core,
currently dual Cisco 4006's with L3 routing, and I was
wondering if anyone has any comments on the benefits
or drawbacks of the Foundry MG8, the 6500's with the
SUP720's (with or without the DFCs, do I need them, is
it worth it?), and the Force10 E600. I have to say
that the stuff I've been looking at with Force10 has
been really impressive.
Colin Hines
Tower Hill Insurance Group, Inc.
------------------------------
Message: 4
Date: Wed, 27 Oct 2004 19:15:07 +0200
From: Mark <mac at telvia.it>
Subject: Re: [c-nsp] EIGRP Adversing Problem
To: cisco-nsp <cisco-nsp at puck.nether.net>
Cc: "oboehmer <oboehmer at cisco.com>" <Oliver>
Message-ID: <C00138C9-283B-11D9-AC76-000A95791B10 at telvia.it>
Content-Type: text/plain; charset=US-ASCII; format=flowed
I tried,
but net 10.0.0.0/16 is always advertised.
MArk
On Oct 27, 2004, at 1:51 PM, Oliver Boehmer ((oboehmer)) wrote:
> mark,
>
> so you want to advertise everything *except* 10.0.0.0/16 (incl. subnets
> of this range)? Then the following config should do what you want
>
> ip prefix-list private_IP deny 10.0.0.0/16 le 32
> ip prefix-list private_IP permit 0.0.0.0/0 le 32
> !
> router eigrp 1
> distribute-list prefix private_IP out
>
> this should work..
>
> oli
>
> Mark <mailto:mac at telvia.it> wrote on Wednesday, October 27, 2004 1:42
> PM:
>
>> Thanks Oli,
>>
>> But I announce all my net and suppress 10.0.0.0/16 (and smaller in
>> the net).
>> Actually my prefix filter do the contrary. :-(
>>
>> Where am I wrong?
>>
>> Mark
>>
>>
>> On Oct 27, 2004, at 11:43 AM, Oliver Boehmer ((oboehmer)) wrote:
>>
>>> Mark <mailto:mac at telvia.it> wrote on Wednesday, October 27, 2004
>>> 11:29 AM:
>>>
>>>> I tried, without success, this config.
>>>>
>>>> ip prefix-list private_IP permit 10.0.0.0/16
>>>> router eigrp XXXX
>>>> distribute-list prefix private_IP out
>>>>
>>>> Now ALL my network are FILTERED.
>>>>
>>>> Where i'm wrong???
>>>
>>> what do you want to achieve exactly? announce only 10.0/16 networks
>>> and suppress the rest? Your prefix list matches only the 10.0.0.0/16
>>> network, more specfics are suppressed.. In case you want to announce
>>> the
>>> more specifics subnets as well, use
>>> ip prefix-list private_IP permit 10.0.0.0/16 le 32
>>>
>>> oli
>>>
>>>
>>>>
>>>> On Oct 27, 2004, at 1:33 AM, Mark wrote:
>>>>
>>>>> Oliver,
>>>>>
>>>>> can you write down an example of distribute-lists out for a
>>>>> specific network?
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> On Oct 26, 2004, at 7:59 PM, Oliver Boehmer ((oboehmer)) wrote:
>>>>>
>>>>>> Jason Lixfeld <> wrote on Tuesday, October 26, 2004 7:38 PM:
>>>>>>
>>>>>>> Use the eigrp router passive-interface command.
>>>>>>>
>>>>>>> http://www.cisco.com/en/US/tech/tk365/tk207/
>>>>>>> technologies_tech_note09186a0080093f0a.shtml
>>>>>>
>>>>>> passive-interface will only prevent an EIGRP adjacency being
>>>>>> formed over
>>>>>> this link, the link address will still be advertised.. the only
>>>>>> way to prevent this from happening was mentioned by Bruce earlier
>>>>>> :
>>>>>>
>>>>>>> Well, it depends. You could adjust your "network" statements in
>>>>>>> EIGRP
>>>>>> to
>>>>>>> not include that network or subnetwork. Or you could use
>>>>>> distribute-lists
>>>>>>> to filter it out.
>>>>>>
>>>>>> In halfway modern code (at least 12.2 and later, I think 12.1 as
>>>>>> well) you can use "network <network> <wildcard>" to exactly
>>>>>> specify the interfaces' addresses which you want to be covered by
>>>>>> EIGRP.. works similar to the way you setup OSPF..
>>>>>>
>>>>>> oli
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/
>
------------------------------
Message: 5
Date: Wed, 27 Oct 2004 19:28:05 +0200
From: "Oliver Boehmer \(oboehmer\)" <oboehmer at cisco.com>
Subject: RE: [c-nsp] EIGRP Adversing Problem
To: "Mark" <mac at telvia.it>, "cisco-nsp" <cisco-nsp at puck.nether.net>
Message-ID:
<70B7A1CCBFA5C649BD562B6D9F7ED7842AE30C at xmb-ams-333.emea.cisco.com>
Content-Type: text/plain; charset="us-ascii"
> but net 10.0.0.0/16 is always advertised.
>
strange.. just tried this in the lab (using 12.3(10)):
interface Loopback0
ip address 11.0.1.1 255.255.255.0 secondary
ip address 11.0.2.1 255.255.255.128 secondary
ip address 11.0.3.1 255.255.255.255 secondary
ip address 11.1.0.1 255.255.0.0 secondary
ip address 11.0.0.1 255.255.0.0
!
router eigrp 1
network 10.0.0.0
network 11.0.0.0
distribute-list prefix test out
no auto-summary
!
ip prefix-list test seq 5 deny 11.0.0.0/16 le 32
ip prefix-list test seq 10 permit 0.0.0.0/0 le 32
before the prefix list is applied, the neighbor sees
11.0.0.0/8 is variably subnetted, 5 subnets, 4 masks
D 11.0.3.1/32 [90/2297856] via 10.0.0.1, 00:00:26, Serial2
D 11.0.2.0/25 [90/2297856] via 10.0.0.1, 00:00:26, Serial2
D 11.1.0.0/16 [90/2297856] via 10.0.0.1, 00:00:26, Serial2
D 11.0.1.0/24 [90/2297856] via 10.0.0.1, 00:00:26, Serial2
D 11.0.0.0/16 [90/2297856] via 10.0.0.1, 00:00:26, Serial2
After I apply the above config list, I see
11.0.0.0/16 is subnetted, 1 subnets
D 11.1.0.0 [90/2297856] via 10.0.0.1, 00:00:06, Serial2
So we filter everything within 11.0.0.0/16, but let 11.1.0.0/16
through.. just what was intended..
oli
>
>
> On Oct 27, 2004, at 1:51 PM, Oliver Boehmer ((oboehmer)) wrote:
>
>> mark,
>>
>> so you want to advertise everything *except* 10.0.0.0/16 (incl.
>> subnets of this range)? Then the following config should do what you
>> want
>>
>> ip prefix-list private_IP deny 10.0.0.0/16 le 32
>> ip prefix-list private_IP permit 0.0.0.0/0 le 32
>> !
>> router eigrp 1
>> distribute-list prefix private_IP out
>>
>> this should work..
>>
>> oli
>>
>> Mark <mailto:mac at telvia.it> wrote on Wednesday, October 27, 2004 1:42
>> PM:
>>
>>> Thanks Oli,
>>>
>>> But I announce all my net and suppress 10.0.0.0/16 (and smaller in
>>> the net).
>>> Actually my prefix filter do the contrary. :-(
>>>
>>> Where am I wrong?
>>>
>>> Mark
>>>
>>>
>>> On Oct 27, 2004, at 11:43 AM, Oliver Boehmer ((oboehmer)) wrote:
>>>
>>>> Mark <mailto:mac at telvia.it> wrote on Wednesday, October 27, 2004
>>>> 11:29 AM:
>>>>
>>>>> I tried, without success, this config.
>>>>>
>>>>> ip prefix-list private_IP permit 10.0.0.0/16
>>>>> router eigrp XXXX
>>>>> distribute-list prefix private_IP out
>>>>>
>>>>> Now ALL my network are FILTERED.
>>>>>
>>>>> Where i'm wrong???
>>>>
>>>> what do you want to achieve exactly? announce only 10.0/16 networks
>>>> and suppress the rest? Your prefix list matches only the
>>>> 10.0.0.0/16 network, more specfics are suppressed.. In case you
>>>> want to announce the
>>>> more specifics subnets as well, use
>>>> ip prefix-list private_IP permit 10.0.0.0/16 le 32
>>>>
>>>> oli
>>>>
>>>>
>>>>>
>>>>> On Oct 27, 2004, at 1:33 AM, Mark wrote:
>>>>>
>>>>>> Oliver,
>>>>>>
>>>>>> can you write down an example of distribute-lists out for a
>>>>>> specific network?
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>> On Oct 26, 2004, at 7:59 PM, Oliver Boehmer ((oboehmer)) wrote:
>>>>>>
>>>>>>> Jason Lixfeld <> wrote on Tuesday, October 26, 2004 7:38 PM:
>>>>>>>
>>>>>>>> Use the eigrp router passive-interface command.
>>>>>>>>
>>>>>>>> http://www.cisco.com/en/US/tech/tk365/tk207/
>>>>>>>> technologies_tech_note09186a0080093f0a.shtml
>>>>>>>
>>>>>>> passive-interface will only prevent an EIGRP adjacency being
>>>>>>> formed over
>>>>>>> this link, the link address will still be advertised.. the only
>>>>>>> way to prevent this from happening was mentioned by Bruce
>>>>>>> earlier
>>>>>>>>
>>>>>>>
>>>>>>>> Well, it depends. You could adjust your "network" statements
>>>>>>>> in EIGRP
>>>>>>> to
>>>>>>>> not include that network or subnetwork. Or you could use
>>>>>>> distribute-lists
>>>>>>>> to filter it out.
>>>>>>>
>>>>>>> In halfway modern code (at least 12.2 and later, I think 12.1 as
>>>>>>> well) you can use "network <network> <wildcard>" to exactly
>>>>>>> specify the interfaces' addresses which you want to be covered
>>>>>>> by EIGRP.. works similar to the way you setup OSPF..
>>>>>>>
>>>>>>> oli
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/
------------------------------
Message: 6
Date: Wed, 27 Oct 2004 11:48:43 -0600
From: James Hamilton <jamesh at swcp.com>
Subject: [c-nsp] ATM CRC errors
To: cisco-nsp at puck.nether.net
Message-ID: <20041027174843.GA5642 at swcp.com>
Content-Type: text/plain; charset=us-ascii
Hi there, we've got an ATM DS3 to Qwest (our telco) for Qwest based T1s and
DSL. It's taken ~588 input CRC errors in the last 20 minutes. The count
for
the last week was ~140,000 CRC's. I've been unable to match these CRC
errors
to the counters for my interfaces. There were about 100,000 CRC's that I
couldn't match to any interface except the main atm1/0 interface.
We've checked the physical line, Qwest has monitored the port. They are
telling me that discarded cells are the cause. If that is the case
shouldn't
I be able to match the main interface CRC counter to the CRC counters for
all
my subinterfaces? Any insight would be appreciated.
Thanks
--
James Hamilton
Southwest Cyberport
http://www.swcp.com
505-232-7992
------------------------------
Message: 7
Date: Wed, 27 Oct 2004 21:46:00 +0300
From: Sorin CONSTANTINESCU <consta at gmail.com>
Subject: [c-nsp] Cat5505 running CatOS 6.3(1)
To: cisco-nsp at puck.nether.net
Message-ID: <411c5cf041027114636cc3aae at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII
Hi,
One of our Catalysts reloaded after i issued the "show banner"
command. After it booted, the "show log" said:
=== cut here ===
Last software reset by user: 11/1/2003,10:54:07
Last Exception occurred on Oct 27 2004 18:23:22 ...
Software version = 6.3(1)
Error Msg:
PID = 10 show_comma
PC: 10146DA2, Status: 2000, Vector: 7008
sp+00: 20001014 6DA27008 11FF4794 01050005
sp+10: 00050005 75726500 10624AEA 00000095
sp+20: 75726500 FFFFFFFF 75726500 FFFFFFFF
sp+30: 20427563 75726500 10146D96 10146D52
sp+40: 11FF53D0 10140CF8 00000000 10140B92
sp+50: 00000000 11FF53E8 104BCB78 00000014
sp+60: 00000000 00000000 00000700 11FF53E4
sp+70: 104BB524 104BB524 104BB524 104BB524
sp+80: 104BB524 104BB524 104BB524 104BB524
sp+90: 104BB524 104BB524 104BB524 104BB524
sp+A0: 104BB524 104BB524 104BB524 104BB524
sp+B0: 104BB524 104BB524 104BB524 104BB524
sp+C0: 104BB524 104BB524 104BB524 104BB524
sp+D0: 104BB524 104BB524 104BB524 104BB524
sp+E0: 104BB524 104BB524 104BB524 104BB524
sp+F0: 104BB524 104BB524 104BB524 104BB524
D0: 00000001, D1: 00000000, D2: 10661E2C, D3: 00000000
D4: 00000000, D5: 00000000, D6: 00000000, D7: 00000000
A0: 107B7D44, A1: 10786F45, A2: 0000012C, A3: 000000B4
A4: 00000000, A5: 00000000, A6: 75726500, sp: 11FF537C
=== and here ===
I tried using Output Interpreter, but it didn't show anything
interresting. I know the software version is quite old, but ...
I guess i should upgrade.
--
Sorin CONSTANTINESCU
consta at gmail.com
Linux Registered User #222086
------------------------------
Message: 8
Date: Wed, 27 Oct 2004 15:32:23 -0400 (EDT)
From: Andy Dills <andy at xecu.net>
Subject: Re: [c-nsp] ATM CRC errors
To: James Hamilton <jamesh at swcp.com>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20041027152738.V77702 at thunder.xecu.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 27 Oct 2004, James Hamilton wrote:
> Hi there, we've got an ATM DS3 to Qwest (our telco) for Qwest based T1s
and
> DSL. It's taken ~588 input CRC errors in the last 20 minutes. The count
for
> the last week was ~140,000 CRC's. I've been unable to match these CRC
errors
> to the counters for my interfaces. There were about 100,000 CRC's that I
> couldn't match to any interface except the main atm1/0 interface.
>
> We've checked the physical line, Qwest has monitored the port. They are
> telling me that discarded cells are the cause. If that is the case
shouldn't
> I be able to match the main interface CRC counter to the CRC counters for
all
> my subinterfaces? Any insight would be appreciated.
No, CRC errors are not associated with discarded cells. That's ridiculous.
CRC is a method of verifying the packets were transmitted properly by
verifying the supplied checksum against the calculated checksum. Demand
escalation if that's the nonsense you're being fed.
Chances are, it's running too hot. How long is the cable?
You may find, if it's a very short run, that the either you need to insert
some attentuators, or preferrably, get Qwest to adjust the LBO on their
equipment.
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
------------------------------
_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 23, Issue 101
******************************************
More information about the cisco-nsp
mailing list