[Cisco] Input queue probleem...

[Flyduck]

Ik heb een vraagje over een Cisco 1760 router / 12.2(11)YV.

Een klant van ons heeft 2 centrale locaties, en 5 kleinere sites.
De centrale locaties hebben een 1760 router, en zitten aangesloten op een 2mbit SDSL lijn van KPN.
Deze centrale routers hebben een IPSEC verbinding met elkaar, en vanaf allebei de routers moeten 5 IPSEC verbindingen lopen naar de verschillende kleinere locaties (op de locaties staan ook cisco routers)
Allebei de 1760's moeten dus 6 VPN's draaien in totaal, wat de 1760 makkelijk moet kunnen.

1 centrale router heeft hier ook geen problemen mee, .. de andere wel. Dit terwijl de hardware / IOS en config gelijk is.

De router die problemen heeft kan wel tot 4 ipsec's draaien, maar zodra er nog eentje bijkomt beginnen de problemen.
Na ongeveer 3 uur is er dan opeens geen verkeer meer mogelijk naar de externe interface van die router.
Je krijgt dus een time-out bij het pingen.
Verder vallen 1 voor 1 alle vpn's uit (niet tegelijk).
Echt heel vreemd, je kan niet meer internetten via de router op dat moment, maar sommige VPN's draaien gewoon nog door..

f_vrf/i_vrf dst src state conn-id slot

/ x.x.5.97 x.x.5.1 MM_NO_STATE 25 (deleted)
/ x.x.5.81 x.x.5.1 MM_NO_STATE 5 (deleted)
/ x.x.5.17 x.x.5.1 MM_NO_STATE 26
/ x.x.5.17 x.x.5.1 MM_NO_STATE 24 (deleted)
/ x.x.5.49 x.x.5.1 QM_IDLE 2
/ x.x.5.33 x.x.5.1 QM_IDLE 3

Hierboven is te zien hoe 4 VPN's al down zijn, internet niet meer werkt, en er toch 2 VPN's nog gewoon te gebruiken zijn.

Na ongeveer 4 uur is er helemaal geen verkeer meer mogelijk via die router, tenzij je hem reload.

Nadat de verbinding helemaal weg was heb ik een show tech gedraaid en daar zag ik dit in staan:

Dialer2 is up, line protocol is up (spoofing)
Hardware is Unknown
Internet address is x.x.5.1/28
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
DTR is pulsed for 1 seconds on reset
Interface is bound to Vi3
Last input never, output never, output hang never
Last clearing of "show interface" counters 10:22:47
Input queue: 76/75/10669/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)

Zoals te zien is de max size van de input queue overschreden, en worden alle packets gedropt.
Nu heb ik de input queue verhoogt naar 4096 (max). Ik moet nog testen of dit de boel oplost, of alleen uitstelt.

Mijn vraag is hoe het mogelijk is dat dit kan gebeuren?
De andere 1760 staat ook met een max input queue van 75 en heeft nergens last van, terwijl de configuratie / hardware / IOS / lijn etc allemaal gelijk is

De router en de sdsl module zijn allebei al vervangen, dus het is niet hardwarematig...

En zodra de router packets aan het droppen is, leegt deze niet tegelijk de input queue, wat toch eigenlijk wel zou moeten gebeuren
Zodra ik een reload doe werkt alles weer naar behoren totdat er weer meer dan 4 IPSEC's worden geconnect.
Dit gebeurd trouwens terwijl er alleen een paar pingloops draaien om de vpn's in de gaten te houden (max 2Kb/s).

[TrailBlazer]

Wij hebben redelijk slechte ervaring met 12.2 iossen icm met sdsl 12.3 zal je problems vermoedelijk oplossen alleen bij ons liep de atm que vol

[kell.nl]

Dat lijkt heel erg op een exploit die pas in versie 12.3 is opgelost. Alle andere IOS versies op alle routers/switches zijn vulnerable.
De info bij Cisco zelf:
http://www.cisco.com/en/U...ory09186a00801a34c2.shtml

Voor als je niet kunt upgraden naar een nieuwe versie, staat hier dan ook een workaround.
Veel succes

/edit

Hij was als eerste in de 12.3 versie opgelost.. Ze hebben voor andere versies ook updates uitgebracht...

[ Voor 14% gewijzigd door kell.nl op 28-11-2003 19:45 ]

[Predator]

Zie je diezelfde input (of output) drops ook op je ATM interface (ipv je dailer) ?

[Flyduck]

Ik ben op dit moment aan het het testen met een hold-queue in van 4096 packets.
Heb weer een aantal pingloops aangezet..
Op dit moment loopt de queue heel langzaam vol,.. zit nu pas op 12 packets.

Behalve op de dialer interface heb ik op geen enkele andere interface output of input queue problemen (allemaal op 0)

Ik heb ook een case open staan bij Cisco maar die reageren op de meest vreemde tijden (half twee 's nachts etc)

Als ik kijk wat er nu in de queue voor packets zitten:

Buffer information for Big buffer at 0x8199CC8C
data_area 0x3787004, refcount 1, next 0x0, flags 0x280
linktype 7 (IP), enctype 33 (ATM), encsize 0, rxtype 1
if_input 0x81DE25F0 (Dialer2), if_output 0x0 (None)
inputtime 0x0, outputtime 0x0, oqnumber 65535
datagramstart 0x378707C, datagramsize 660, maximum size 1692
mac_start 0x3787056, addr_start 0x3787056, info_start 0x0
network_start 0x378707C, transport_start 0x0, caller_pc 0x80DAC3BC

source: 192.168.19.3, destination: 192.168.0.1, id: 0x8E1C, ttl: 126, prot: 1

(en dat 12x, zelfde packet)

Protocol 1 is volgens mij ICMP. Echter dit is niet van een ping loop die ik heb lopen maar behoort tot de communicatie tussen 2 active directory controllers die via de VPN syncen.

Ben benieuwd wat er strax gaat gebeuren...

Ik zal ff checken of dit idd te maken heeft met de IOS versie.
(echter is er van de 12.3 nog geen IOS versie die de functionaliteit heeft die ik nodig heb...)

*Edit*
Ik heb dat document gelezen. Het is inderdaad precies het probleem wat ik heb, echter heb ik geen last van protocol 103 packets, maar protocol 1. Ik denk dat het dus geen attack is (vooral ook omdat ik precies weet wanneer het gaat gebeuren, namelijk bij het opzetten van meer dan 4 ipsec vpn's)

[ Voor 10% gewijzigd door Flyduck op 28-11-2003 21:17 ]

[Flyduck]

Nou hij heeft de nacht overleeft. maar........

Dialer2 is up, line protocol is up (spoofing)
Hardware is Unknown
Hardware is Unknown
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, loopback not set
DTR is pulsed for 1 seconds on reset
Interface is bound to Vi3
Last input never, output never, output hang never
Last clearing of "show interface" counters 1d10h
Input queue: 518/4096/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/16 (active/max active/max total)

De input queue staat na 14 uur met 5 ipsec's up al op 518.
Alle packets in de queue zijn ping packets tussen AD controllers.
En nou moet er eigenlijk nog een VPN bij met ook nog een AD controller op locatie, waardoor de input queue nog sneller zal oplopen...

[kell.nl]

Queueing staat nou op weighted fair queueing. Misschien dat daar iets fout gaat.
Je zou eens gewoon fifo (first in, first out) kunnen proberen:

Op de interface:

code:

no fair-queue

Dan krijgt geen enkel pakketje voorrang op andere pakketjes.
Met wfq is dat wel het geval, waardoor protocol 1 misschien verdrongen wordt

[Flyduck]

kell.nl schreef op 29 november 2003 @ 14:20:
Queueing staat nou op weighted fair queueing. Misschien dat daar iets fout gaat.
Je zou eens gewoon fifo (first in, first out) kunnen proberen:

Op de interface:

code:

no fair-queue

Dan krijgt geen enkel pakketje voorrang op andere pakketjes.
Met wfq is dat wel het geval, waardoor protocol 1 misschien verdrongen wordt

Ik heb "no fair-queue" op de dialer interface geactiveerd, echter meteen daarna viel de verbinding uit. Gelukkig kon ik er nog bij via de interne interface.
Moest de router reloaden om verbinding weer up te krijgen.. Helaas dus niet gewenste resultaat...

[kell.nl]

Hmmm.. Ik had niet verwacht dat dat de verbinding zou plat gooien....
Heb je ook kunnen achterhalen waarom de verbinding plat ging?

Ik heb toch nog steeds het vermoeden dat de queueing fout gaat...
Je kan proberen om queueing zelf te regelen, en dan protocol 1 iets meer prioriteit of bandbreedte toewijzen.

http://www.cisco.com/en/U...6a0080087f36.html#1017499

Hier staat hoe je dat op meerdere manieren kunt regelen.
Ik denk dat custom queueing het makkelijkst is.

[ Voor 6% gewijzigd door kell.nl op 29-11-2003 15:29 ]

[Flyduck]

Ben het aan het bestuderen.
Echter blijft het toch vreemd dat het precies de ICMP packets zijn tussen de AD controllers... Van de overige ICMP packets (ik heb 6 ping loops lopen) zie ik niets terug in de buffers.

Op de cisco zijn staat dit:
"Traffic passing through the device cannot block the input queue."

En dat is dus precies wat er bij mij wel gebeurd, het verkeer is namelijk niet gericht aan de router, maar aan een Active Dir. controller.
Of is het omdat ik VPN's gebruik dat het toch weer anders werkt...

[kell.nl]

Even wat vraagjes, om het eea duidelijk te krijgen:

- Maakt het nog wat uit in welke volgorde je de VPN's opzet?
- Of gebeurt het probleem altijd zogauw je de vijfde VPN opzet?
- Of gebeurt altijd als je 1 specifieke VPN opzet?
- Wat is de inputrate op de interfaces als het pobleem zich begint voor te doen?
- Zijn er meer AD controllers op de andere sites, of alleen op die twee (192.168.19.0 en 192.168.0.0)
- Je andere centrale locatie heeft dezelfde hardware e.d., maar daar komt het probleem niet voor. Zijn daar wel twee lokaties bij met AD controllers die met elkaar babbelen? (om te kijken of dat verkeer altijd problemen veroorzaakt)
- Is het mogelijk om de twee centrale routers fysiek om te wisselen, om uit te sluiten dat het toch een hardware probleem is.

Het zijn misschien wat veel vragen, maar dan heb ik (en anderen die dit topic lezen) een duidelijker beeld waar we het moeten zoeken, al denk ik nog steeds dat het een queueing probleem is, met misschien een hoge input rate.

Wat je misschien als quick and dirty workaround kan gebruiken, is het blokken van die pakketjes al op de remote router op z'n ethernet interface.
Ik weet niet of dat kwaad kan voor de AD controllers, maar ze krijgen die pakketjes nu ook niet, dus waarschijnlijk valt dat dan wel mee.

[Flyduck]

Ok ik zal proberen een beetje uit te leggen wat de situatie is.

De kleinere locaties hebben nu ook verbinding met de centrale locaties via een huurlijn. De routers op de locaties zijn dus uitgerust met een serial interface en een adsl interface.

De huurlijnen zijn opgezegt, en worden volgende week opgeheven.
Vanaf dat moment moet alles dus draaien over de IPSEC verbindingen. Aangezien de boel nog niet stabiel draait ben ik nu dus in het weekend bezig...

Om even op je vragen te komen;

- Maakt het nog wat uit in welke volgorde je de VPN's opzet?

Ja, de VPN naar de andere centrale locatie gaat meestal als eerst up aangezien die al actief gebruikt wordt. Echter over die lijn vind nog geen AD replicatie plaats. Dan komen er nog 3 extra VPN's bij waar idd ook geen replicatie over plaats vind. De vijfde IPSEC die zet ik handmatig op, aangezien daar de problemen beginnen. Dat is de verbinding (192.168.3.0 - 192.168.0.0), waarbij 192.168.0.0 de centrale locatie is. Over deze VPN komen de ICMP packets binnen van de AD controllers op die site. (192.168.3.20 en 192.168.3.254). Dan is er nog een VPN nodig die ik nu nog niet eens opgezet heb, maar waarover ook gerepliceerd moet worden.

- Wat is de inputrate op de interfaces als het pobleem zich begint voor te doen?

5 minute input rate 23000 bits/sec, 2 packets/sec
Het enigste verkeer is de AD replicatie, en een eigen pingloop.

- Je andere centrale locatie heeft dezelfde hardware e.d., maar daar komt het probleem niet voor. Zijn daar wel twee lokaties bij met AD controllers die met elkaar babbelen? (om te kijken of dat verkeer altijd problemen veroorzaakt)

Op die locatie vind idd ook replicatie plaats naar 1 andere site via een VPN.
Daar blijft de input queue echter netjes op 0.
Dat is nu ook nog een ander AD domain dan wordt gebruikt op de andere centrale locatie. (we zijn bezig 2 verschillende netwerken aan het migreren naar 1, daarom vind er ook nog geen replicatie plaats tussen de 2 centrale locaties)

- Is het mogelijk om de twee centrale routers fysiek om te wisselen, om uit te sluiten dat het toch een hardware probleem is.

Zou kunnen, maar zoals aangegeven is de hardware al allemaal vervangen. Dat zou eventueel een optie kunnen zijn, maar het lijkt toch meer op een softwarematig probleem.

Ik was idd al bezig om uit te zoeken wat het gevolg is als er Active Directory controllers elkaar niet meer via ICMP packets kunnen benaderen. Ik zou daarmee idd het probleem van de queue oplossen, maar strax syncen de server opeens niet meer....

[kell.nl]

Flyduck schreef op 29 november 2003 @ 16:32:
Ik was idd al bezig om uit te zoeken wat het gevolg is als er Active Directory controllers elkaar niet meer via ICMP packets kunnen benaderen. Ik zou daarmee idd het probleem van de queue oplossen, maar strax syncen de server opeens niet meer....

Ik heb even gekeken op de MS site.
Daar staat ICMP niet bij als vereiste voor replicatie.
Check het volgende document:

http://www.microsoft.com/...s/config_ipsec_P63623.asp

Gaat over replicatie door firewalls.
Daar wordt iig geen ICMP genoemd als vereiste.

Dus ik denk als je protocol 1 blokt, dat dat geen problemen oplevert.
Al is het natuurlijk veel interessanter om te weten waarom de router problemen geeft.

PS. Heb je al een nieuwe IOS versie geprobeert?

[Flyduck]

thx, das wel interessant idd. Kon zelf zo snel nix vinden.
Wat ik wel vond was tevens op GOT, dit draadje

MTU problemen bij Cisco IPsec i.c.m. NAT traversal

Daar komt naar voren dat het een MTU probleem zou kunnen zijn.
Ik heb icmp debugging aangezet en ik krijg af en toe
ICMP: dst (192.168.19.3) frag. needed and DF set unreachable sent to 192.168.0.5

Maar dat zijn niet de packets die de input queue verstoppen helaas.

Ik zal een access-list op de ethernet interfaces gooien die alleen het icmp verkeer tussen AD controllers tegenhoudt,.. ben benieuwd.
Bedankt voor je hulp iig.

*edit*
Ik kan van de 12.3 IOS geen IPSEC56 versie vinden, alleen 3DES versies, en die mag ik niet downloaden...

[ Voor 9% gewijzigd door Flyduck op 29-11-2003 18:37 ]

[Flyduck]

Cisco TAC antwoord nadat ze een halve dag op de router bezig zijn geweest;


I think I found the bug which affect your router:

CSCea28206
Externally found severe defect: Resolved (R) Router outside NAT interface wedged upon receiving ip fragments

Fixed releases: 12.2(16)B02 12.2(13)ZF02 12.3(00.05)BW03 12.2(15)ZK 12.3(00.01)B 12.2(15)T 012.003(000.001)


This bug has been introduced by the fix of another bug:

CSCdz05512
Externally found severe defect: Resolved (R) PAT does not handle out-of-order fragments on the outside

So the images before CSCdz05512 are not affected. As 12.2(11)YV is in the integrated releases, it IS affected.

You can verify that the packets stucked in the input queue are fragments by decoding the hex header of sh buff input-interface...

hbruyere@sweet-brew-4% hex2ipheader 45000254 06C000B9 7E01AEBF C0A8031E C0A80002
IP: VER 4 HDRLEN 5 TOS 0 (prec 0 (Routine) del 0 rel 0 thr 0 = DSCP 0) LEN 596
IP: ID 1728 Z2 0 DF 0 MF 0 Frag Offset 185 <========
IP: TTL 126 PROTO 1 (icmp) HEAD_CHECK aebf (correct 0)
IP: src 192.168.3.30
IP: dst 192.168.0.2


Regards,
Herve


En mijn dank voor de 12.3 IOS die ik heb gehad van Relaxteb.. kon hem zelf niet downloaden. Ga nu kijken of daarmee de problemen opgelost zijn..

[Maarten @klet.st]

Vreemd genoeg zie ik hier geen reactie op Kell.nl's post dat je wellicht te maken hebt met een vulnerability in Cisco routers (zie bijvoorbeeld http://securecomputing.st.../cisco-ios-17jul2003.html), of ik lees er overheen .

Op http://www.cisco.com/warp...blocked.shtml#workarounds staat een voorbeeld ACL die dit soort vulnerable verkeer blocked, het kan geen kwaad om die regels eens aan je (van Internet) inkomende ACL toe te voegen, wellicht dat het zo simpel is

Edit: ZUCHT, ik lees net je laatste post, waar in staat dat de ene fix de fix hiervoor vernaggelt heeft. Anyway, de voorbeeld ACL op de link hierboven zou het probleem dus wel eens op kunnen lossen..

[ Voor 17% gewijzigd door Maarten @klet.st op 01-12-2003 21:52 . Reden: Best moeilijk, ff een thread doorlezen ]

[Flyduck]

Maarten.O schreef op 01 december 2003 @ 21:50:
Vreemd genoeg zie ik hier geen reactie op Kell.nl's post dat je wellicht te maken hebt met een vulnerability in Cisco routers (zie bijvoorbeeld http://securecomputing.st.../cisco-ios-17jul2003.html), of ik lees er overheen .

Ik had er op gereageerd, onderaan in me 2e post.
Het bleek niet om protocol 103 packets te gaan, maar protocol 1 en 17.