Cisco 7204VXR naar Nortel OM1400

[silvans]

In ons netwerk hebben we een tweetal WAN-verbindingen (KPN Epacity) over EVPN, 100 mbit op twee lokaties.

Op beide lokaties is het LAN aangesloten aan een Cisco 7204VXR en deze hangt aan de WAN-zijde aan de Nortel OM1400.

Op het eerste gezicht leken deze verbindingen prima te functioneren, totdat een gebruiker klaagde over matige FTP-performance.

Een trace met Wireshark toonde veel duplicate ack tcp packets, ten teken dat er onderweg pakketjes verloren raken. Ik ben verder gaan kijken en heb een aantal grote pings afgevuurd vanaf de 7204 richting Epacity en ook door Epacity heen naar eindstations. In alle gevallen had ik packet loss van de 7204 WAN interface (ethernet) naar het WAN. De LAN interface (ethernet) is prima.

CRC errors en andere problemen zijn niet zichtbaar op de Cisco.

FastEthernet0/1 is up, line protocol is up
Hardware is i82543 (Livengood), address is 0011.5c76.f906 (bia 0011.5c76.f906)
Description: Connection 100baseT to EVPN Epacity
Internet address is 10.169.1.9/30
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 15/255, rxload 18/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:07, output 00:00:00, output hang never
Last clearing of "show interface" counters 4d08h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1907
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 70000 kilobits/sec
5 minute input rate 7442000 bits/sec, 1641 packets/sec
5 minute output rate 6248000 bits/sec, 1631 packets/sec
504173339 packets input, 3048488948 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
406911129 packets output, 82641278 bytes, 0 underruns
11 output errors, 0 collisions, 4 interface resets
0 babbles, 0 late collision, 0 deferred
11 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Nu komt het interessante stuk.

Met de Cisco 7204 WAN ethernet interface met een UTP kabel rechstreeks op poort 1 van de OM1400 heb ik het packet loss probleem duidelijk in beeld.

Uit het magazijn een eenvoudige 3Com 4400 switch gehaald en deze tussen de Cisco 7204 WAN ethernet interface gezet en daarvandaan via een crosscable naar de OM1400, en het probleem is opgelost.

Uiteraard is het natuurlijk geen fraaie oplossing om een extra switch als single point of failure tussen de WAN router en de OM1400 te plaatsen.

Moet ik in de hoek zoeken van ethernet timing problemen die door het tussenvoegen van een ethernet switchje worden ondervangen (buffers oid) ??

[silvans]

Wellicht ten overvloede, de output drops in de statistieken zijn waarschijnlijk door mijzelf veroorzaakt (een aantal keren geschakeld tussen diverse service policies en kabels omgestoken tijdens het troubleshooten)

[jvanhambelgium]

Da's net het gekke, als er timing-problemen zouden zijn (of eenders welke ethernet problemen) zou je verwachten die wel te zien in de output op de Cisco.

Als je die switch ertussen zet, staan die poorten op deze 3COM richting OM1400 ook op "100 Full" (zoals op de Cisco?) of eerder "auto negotiate" oid ?

PS : "Totdat een gebruiker klaagde" -> Is het probleem voor *ALLE* gebruikers over deze link. Heb je bepaalde IP destinations waar het probleem zich voordoet ? Bepaalde source-ranges ?
Is nogal straf dat er dan slechts 1 gebruiker zou klagen ?

[silvans]

Zowel de Cisco als de OM1400 staan op 100-full. De 3Com switch heb ik dan ook op 100-full gezet voor beide poorten.

De problemen (en de loss) vinden plaats op alle verkeer over deze verbindingen, maar kwamen juist door deze transfertests pas aan het licht. TCP is zo slim genoeg om het te corrigeren. Alle applicaties die we via het WAN draaien werken allemaal wel.

Even een voorbeeld van de output bij de Cisco naar OM1400-constructie zonder tussenliggende switch:

rw-rt5#ping
Protocol [ip]:
Target IP address: 10.169.1.10
Repeat count [5]: 1000
Datagram size [100]: 18024
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1000, 18024-byte ICMP Echos to 10.169.1.10, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!.!!!!!!
Success rate is 99 percent (994/1000), round-trip min/avg/max = 20/22/116 ms
rw-rt5#

Bij de ping tests zonder switch ertussen zien de meeste tests eruit zoals hierboven.
Bij alle ping-tests die ik heb uitgevoerd mét de switch ertussen heb ik 100% succes rate.

[Verwijderd]

Aangezien het met die switch er tussen wél perfect werkt, zou ik logischerwijze toch echt denken aan duplex mismatches of een defecte kabel?

Ik verkies zelf ook de situatie waarbij beide kanten fixed ingesteld staan, maar kan je beide kanten eens op auto zetten (Cisco en Nortel)? Ook andere kabel proberen.

[mph_rbi]

Hard instellen van interfaces is long gone. Zoals ook bij de IEEE tegenwoordig gerept wordt: er is geen enkele reden meer om tegenwoordig nog fixed instellingen aan te houden. Duplex mismatches komen zelden meer voor en wij merken zelfs meer problemen met autoneg als zonder. Wat voor NPE heb je in de 7200? En gebruik je de FE-I/O aan de voorzijde? Wel is het vreemd, daar een duplex mismatch normaal gezien zorgt voor CRC's op de Cisco. Kun je de OM ook uitlezen?

[silvans]

Aangezien het met die switch er tussen wél perfect werkt, zou ik logischerwijze toch echt denken aan duplex mismatches of een defecte kabel? Ik verkies zelf ook de situatie waarbij beide kanten fixed ingesteld staan, maar kan je beide kanten eens op auto zetten (Cisco en Nortel)? Ook andere kabel proberen.

Andere kabel reeds geprobeerd. Ook een exemplaar van 20 meter ertussen gehangen waar er normaalgesproken 2 meter tussenhangt, om op die manier timing issues veroorzaakt door te korte kabel uit te sluiten.

Hard instellen van interfaces is long gone. Zoals ook bij de IEEE tegenwoordig gerept wordt: er is geen enkele reden meer om tegenwoordig nog fixed instellingen aan te houden. Duplex mismatches komen zelden meer voor en wij merken zelfs meer problemen met autoneg als zonder. Wat voor NPE heb je in de 7200? En gebruik je de FE-I/O aan de voorzijde? Wel is het vreemd, daar een duplex mismatch normaal gezien zorgt voor CRC's op de Cisco. Kun je de OM ook uitlezen?

De fixed instelling komt van KPN. De OM1400 is namelijk van KPN EVPN, en de Cisco 7204VXR is van onszelf. Hardware bestaat uit Cisco 7204VXR met NPE400 en C7200-I/O-2FE/E waar zowel LAN als WAN aanhangen.

De duplex instelling heb ik uitgesloten. Kies ik hard voor half of auto dan zie ik direct CRC errors en een veelvoud van de packet loss in vergelijk tot de huidige situatie.

Typerend is dat het probleem zich op twee lokaties voordoet. Op beide lokaties staat dezelfde hardware, de IOS'en in de 7204VXR's is wel verschillend.

[Verwijderd]

Als ik zie dat er vanuit de cisco geen error's etc in de interface stats staan, lijkt het mij dat de echo reply's vanaf de OM1400.

Je zou eventueel een hub oid er tussen kunnen hangen en dan met je laptop en een sniffer kijken of je de "bron" van het probleem kan achterhalen.

Geen smartnet contract op de cisco?

[silvans]

De OM1400 is een soort van laag 2 doorgeefluik, de echo replies komen verder vanuit het KPN netwerk vanaf Epacity (ip vpn). Sniffer aan de buitenkant is als dat lukt inderdaad de volgende stap hoewel dat weer lastig is aangezien ik geconstateerd heb dat het probleem zich niet voordoet als ik er een extra switch tussenhang. Of een hub het verschil zou maken moet ik proberen.

[jvanhambelgium]

Ok, de OM1400 staat ertussen als ethernet-bridge dus...nu doe je de test met flinke ICMP datagram sizes. Heb je dit probleem ook met een conventioneel ICMP datagram size van vb 100 ?

[silvans]

Ook dan heb ik errors. Weliswaar minder, maar ze zijn er wel.

[jvanhambelgium]

Doe toch eens een "clear counters" op de betreffende FastEthernet en laat het eens een tijdje.
Als er echt geen noemenswaardige zaken op de counters bovenkomen heb je ofwel een IOS bug ofwel ook echt geen "ethernet" issues tussen Cisco <-> Nortel

Het is echt wel gek dat het opgelost is als je er een switch tussen steekt...

Vraag desnoods KPN ook voor een print-out van de ethernet stats op die OM1400

[Kabouterplop01]

Is het een IAS verbinding met 100MB?

[ Voor 70% gewijzigd door Kabouterplop01 op 26-10-2009 23:09 . Reden: onzin weggehaald ]

[silvans]

Clear Counters had ik een paar dagen geleden nog uitgevoerd, en je ziet echt geen rare dingen. Met of zonder tussenliggende switch maakt geen verschil.

Inmiddels ook een 'show tech' door de Output Interpreter gehaald en die geeft ook geen spannende dingen, buffer problemen of andere ernstige zaken.

Dat geeft me ook het gevoel dat ik aan de Cisco zijde wel zo'n beetje klaar ben.

Het is een 100 mb EVPN naar Epacity. Dus geen IAS (ik neem aan Internet Access Service).

[jvanhambelgium]

Het zal 'em in de wolk zitten ;-)
Serieus, heb je geen reporting optie voor de KPN dienst waar je alle zaken als drops,latency,average responses etc mee kan consulteren op verschillende punten ?

Die duplicate ack's duiden inderdaad op congestie (net als timeouts) "ergens onderweg" maar met zo'n mpls wolk is het niet altijd evident zulke dingen te vinden zonder de nodige statistics...

Het blijft toch wel iets raar. Zeker als het altijd reproduceerbaar is en je vb altijd dezelfde "ondermaatse" ftp performance zou halen.
Het blijft me intrigeren dat het fenomeen precies "weg" zou zijn bij het tussenschakelen van een additioneel switchje en dat je niets op de de Cisco counters ziet...zoiets zou toch een lokaal gegeven moeten zijn.

[mph_rbi]

Ok, heb je al met je hold queue 'gespeeld'? Als je er een 3com tussen knoopt is het probleem opgelost. Dat lijkt op een buffer/queue die overloopt.

Probeer eens je hold-queue op te krikken :

interface fa0/0
hold-queue 1024 in
hold-queue 1024 out

Je geeft aan dat je dit probleem al hebt bij het pingen, dus flow-control zou niet mogen bijten. Wellicht dat je er toch even naar kunt kijken. Je weet het nooit op de 2FE . NPE400 zou in ieder geval voldoende moeten zijn voor je 100Mbps.

[Uberprutser]

Verwijderd schreef op maandag 26 oktober 2009 @ 17:02:
Ik verkies zelf ook de situatie waarbij beide kanten fixed ingesteld staan, maar kan je beide kanten eens op auto zetten (Cisco en Nortel)? Ook andere kabel proberen.

mph_rbi schreef op maandag 26 oktober 2009 @ 17:28:
Hard instellen van interfaces is long gone.

In het geval van een OM1400 en randapparatuur niet; de meest performance problemen komen voor omdat de auto setting op 1 van de 2 niet goed gaat. Lekker op Full 100 laten staan, dat zal ook het eerste zijn wat je te horen krijgt wanneer je een performance probleem op EVPN niveau aanmeldt.

silvans schreef op dinsdag 27 oktober 2009 @ 07:54:
Het is een 100 mb EVPN naar Epacity. Dus geen IAS (ik neem aan Internet Access Service).

IAS gaat over EVPN

Als ik jou was zou ik een ticket laten aanmaken bij KPN Epacity.
Zij kunnen je OM1400 uitlezen (is een soort van managed switch waar glas via GBIC in gaat) en zien wat er allemaal niet goed gaat.

Even nog een vraagje tussendoor: Hoeveel verkeer neem je af en op welke waarde staat je shaper ingesteld? Mocht daar iets niet goed tussen zijn ga je ook droppen tussen OM1400 en Cisco.
Want de volgende zin doet mij namelijk vermoeden dat je hier je probleem moet zoeken.

Moet ik in de hoek zoeken van ethernet timing problemen die door het tussenvoegen van een ethernet switchje worden ondervangen (buffers oid) ??

[ Voor 21% gewijzigd door Uberprutser op 02-11-2009 14:29 ]

[silvans]

Queues zou een optie kunnen zijn, hier kijk ik naar.

Het ticket bij KPN staat al een tijdje open. Ook vanaf die kant wordt gezocht, maar wil er natuurlijk zelf ook wijzer van worden

We nemen 100 mbit af en het koppelvlak is ook 100 mbit. Als het goed is is er dan ook geen shaper nodig. Zo staat het ook beschreven in de 'Handleiding Epacity'. Ook een traffic shaper test is overigens al geprobeerd, als ik shape naar 50 of 70 mbit blijft het probleem bestaan.

[silvans]

Ok, heb je al met je hold queue 'gespeeld'? Als je er een 3com tussen knoopt is het probleem opgelost. Dat lijkt op een buffer/queue die overloopt.

Geen effect helaas.

[Verwijderd]

mph_rbi schreef op maandag 26 oktober 2009 @ 17:28:
Hard instellen van interfaces is long gone. Zoals ook bij de IEEE tegenwoordig gerept wordt: er is geen enkele reden meer om tegenwoordig nog fixed instellingen aan te houden.

Jij hebt zeker nog nooit een cisco aan een nortel gekoppeld?
Geloof me, die evpn dozen van KPN kan je beter fixed mee werken

[silvans]

Inmiddels hebben we CEF, route-caching en NAT al uitgeschakeld gehad om alles uit te sluiten maar dit heeft (nog) niet geholpen. KPN heeft inmiddels de bug tracker van Cisco bekeken en (dank!) een TAC geopend. Deze interessante case wordt vervolgd!

[joopv]

silvans schreef op maandag 26 oktober 2009 @ 20:35:
De OM1400 is een soort van laag 2 doorgeefluik, de echo replies komen verder vanuit het KPN netwerk vanaf Epacity (ip vpn). Sniffer aan de buitenkant is als dat lukt inderdaad de volgende stap hoewel dat weer lastig is aangezien ik geconstateerd heb dat het probleem zich niet voordoet als ik er een extra switch tussenhang. Of een hub het verschil zou maken moet ik proberen.

Een sniffer zoals wireshark heeft weinig zin, want dat laat - tenzij je een speciaal apparaat hebt - alleen problemen op laag 2 en hoger zien. Problemen op laag 0 en 1 zoals bekabelings issues en ethernet duplex mismatches / ethernet collisions worden niet zichtbaar gemaakt, of alleen indirect aan de hand van het gedrag op hogere lagen.

[Verwijderd]

Exact dezelfde problemen gehad, gelukkig wel een slimme KPNer aan de lijn gekregen en het was 100% half duplex full duplex mismatches, ook uit jouw ping is het voor 100% zeker full/half duplex mismatch. KPN bellen dat het even 100 full fixed moet worden ingesteld.

[silvans]

Truly believe me, dat is in het beginstadium al uitgesloten

[Kabouterplop01]

Je zou bijna zeggen om alles uit te sluiten andere cisco's gebruiken voor die test. Of alleen de 3com's om te testen.

Hopelijk komt er iets uit die TAC

zijn die ports trouwens routed ports of zijn het switched ports? (de ports die directly connected zijn)

yuk had het ip adres niet gezien.

[ Voor 46% gewijzigd door Kabouterplop01 op 01-11-2009 20:14 ]

[FatalError]

Verwijderd schreef op zondag 01 november 2009 @ 13:07:
Exact dezelfde problemen gehad, gelukkig wel een slimme KPNer aan de lijn gekregen en het was 100% half duplex full duplex mismatches, ook uit jouw ping is het voor 100% zeker full/half duplex mismatch. KPN bellen dat het even 100 full fixed moet worden ingesteld.

Bij duplex problemen verlies je veel meer dan 99 v/d 100 pakketjes.

[joopv]

Post de output van het "show controllers fastethernet 0/1" commando eens.

Daar staat veel meer info in dan in een show int fa0/1.

[silvans]

Duplex problemen zijn het niet zou ik zeggen. Is uitgezocht, beide zijden is 100 mbit full duplex. En het probleem heb ik niet op 1, maar op 2 lokaties.

Het moet haast interoperability zijn tussen de 7204VXR en de OM1400. Ik heb namelijk op de betreffende OM1400-poort ook een Cisco 2691 gehangen waarbij ik géén problemen had. Dus óf een switch ertussen óf een andere router neerhangen. Het laatste is eigenlijk geen optie.

Op verzoek de controller output van 1 van de lokaties:

Interface FastEthernet0/1 (idb 0x64708E50)
Hardware is i82543 (Livengood) A2
network link is up
Config is 100MB, Full Duplex
loopback type is none
10/100 PHY is enabled (MII mode)
i82543 (Livengood) MAC registers:
CTRL =0x02F41945, STATUS=0x00000B43, CTRL_X=0x00004C20, IMS =0x00000096
RCTL =0x00428022, RDBAL =0x071FA000, RDBAH =0x00000000, RDLEN =0x00000800
RDH =0x0000002F, RDT =0x0000002E, RDTR =0x00000000
TCTL =0x000400FA, TDBAL =0x071FB000, TDBAH =0x00000000, TDLEN =0x00001000
TDH =0x00000085, TDT =0x00000085, TIPG =0x00600806
ETT =0x00000000, TXDMAC=0x00000001
TXCW =0x00000000, RXCW =0x0C000000, FCRTH =0x00000000, FCRTL =0x00000000
FCAH =0x00000100, FCAL =0x00C28001, FCT =0x00008808, FCTTV =0x00000000
RDFH =0x00000A17, RDFT =0x00000A17, RDFPC =0x00000000
TDFH =0x00001984, TDFT =0x00001A0A, TDFPC =0x00000001
RX is normal, enabled TX is normal, enabled
Device status = full-duplex, link up
Device Speed = 100Mbps
PHY registers:
PHY is LXT970A
Register 0x00: 2100 780D 7810 0003 0000 0000 0000
Register 0x10: 0100 0000 4000 0000 38C8
PHY says Link is UP, Speed 100Mbps, Full-Duplex
PCI configuration registers:
bus_no=0, device_no=6
DeviceID=0x1001, VendorID=0x8086, Command=0x0156, Status=0x0220
Class=0x02/0x00/0x00, Revision=0x02, LatencyTimer=0xFC, CacheLineSize=0x10
BaseAddr0=0x480C0000, BaseAddr1=0x00000000, MaxLat=0x00, MinGnt=0xFF
SubsysDeviceID=0x1001, SubsysVendorID=0x8086
Cap_Ptr=0x00000000 Retry/TRDY Timeout=0x00000000
PMC=0x00220001 PMCSR=0x00000000
i82543 (Livengood) Internal Driver Information:
lc_ip_turbo_fs=0x606D803C, ip_routecache=0x11(dfs=0/mdfs=0)
i82543_ds=0x64709F10, registers=0x3C0C0000
rx cache size=400, rx cache end=272, rx_nobuffer=0
max_mtu=1524
Software MAC address filter(hash:length/addr/mask/hits):
need_af_check = 0
0x00: 0 ffff.ffff.ffff 0000.0000.0000 0
0x5A: 0 0011.5c76.f906 0000.0000.0000 0
ring sizes: RX=128, TX=256
rxring=0x771FA000, shadow=0x6470A438, head=47, rx_buf_size=512
txring=0x071FB000, shadow=0x6470A66C, head=130, tail=130
chip_state=2, pci_rev=2
tx_count=0, tx_limited=1 (64)
rx_overrun=0, rx_seq=0, rx_no_enp=0, rx_discard=0, filtered_pak=0
throttled=0, enabled=0, disabled=0, bypassed=0
reset=19(init=1, check=0, restart=18, pci=0), auto_restart=52
link_reset=0, tx_carrier_loss=33, fatal_tx_err=0
isl_err=0, wait_for_last_tdt=0, rx_stuck=0
tx_stuck=0, rx_max_spin=1 rx_bad_particle=0
HW addr filter: 0x6470AEA0, ISL disabled, Promiscuous mode disabled
Entry= 0: Addr=0011.5C76.F906
(All other entries are empty)
i82543 (Livengood) Statistics
CRC error 1 Symbol error 0
Missed Packets 594 Single Collision 0
Excessive Coll 0 Multiple Coll 0
Late Coll 0 Collision 0
Defer 0 Receive Length 0
Alignment Error 0 XON RX 0
XON TX 0 XOFF RX 0
XOFF TX 0 FC RX Unsupport 0
Packet RX (64) 38177994 Packet RX (127) 31458886
Packet RX (255) 16109127 Packet RX (511) 4163818
Packet RX (1023) 12290445 Packet RX (1522) 179187360
Good Packet RX 281387630 Broadcast RX 18
Multicast RX 0 Good Packet TX 227632357
Good Octets RX.H 64 Good Octets RX.L 1711960736
Good Octets TX.H 31 Good Octets TX.L 581669796
RX No Buff 0 RX Undersize 0
RX Fragment 0 RX Oversize 0
RX Octets High 64 RX Octets Low 1711960736
TX Octets High 31 TX Octets Low 581669796
TX Packet 227632357 RX Packet 281387630
TX Broadcast 0 TX Multicast 0
Packet TX (64) 96734152 Packet TX (127) 22997424
Packet TX (255) 18280277 Packet TX (511) 4225791
Packet TX (1023) 4041247 Packet TX (1522) 81353466
TX Underruns 0 TX No CRS 157215513
RX Error Count 0 RX DMA Underruns 0
RX Carrier Ext 0
TCP Segmentation 0 TCP Seg Failed 0

[silvans]

Om maar even de voortgang te posten: Maandag komt KPN bij ons meten tussen de router en de OM1400. Hopelijk levert het iets op.

[silvans]

Om het draadje maar even af te ronden: een meting op laag 1-3 tussen Cisco en Nortel heeft laten zien dat er talloze interframe gap violations plaatsvinden. Het lijkt op een bug in de Cisco die daar inmiddels is opgepakt. Kennelijk kunnen niet alle upstream apparaten hier fatsoenlijk mee overweg. Het probleem is dus gezien, bekend en kan worden opgelost door hetzij een andere router, ander apparaat ipv de Nortel, of wachten tot een IOS fix.