Download als PDF FileKürzlich eine „slow network“ Situation getroubleshooted…
The situation:
Kunde beklagte sich über massiv langsame Verbindung auf „gewisse Server“ aber nur von „gewissen Clients“. Von einem 100Mbit/s Port, kriegt er max. 4MB/s, egal ob FTP, Samba etc.. Zu bemerken noch, dass wenn zwei Clients etwas vom Server ziehen, beiden noch 2MB/s zur Verfügung stehen.
-> Challenge accepted! 😈
The Infrastructure:
Im Core ein 3750er Stack mit 2x-12S und einem -24E. Einer der 12S ist Master und hat eine Advanced Routing IOS drauf. Rudimentäres STP Setup mit 2960er im Access auf den Stack verkabelt, teils Daisy-chained.
The Configuration:
- Segmentiert in VLANs (Server, Printer, Cients, Voip, Management…. so wies sich gehört
- Core STP rootbridge mit prio 4096
- Rapid PVSTP, schön die redundanten Pfade geblocked
- InterVLAN Routing aber kein Dynamisches Routing, lediglich eine Default route auf die Firewall
- Kunde hat quasi zwei WAN… das Public WWW und ein PrivatWAN
MOMENT, was ist das…. PBR mit next hop change konfiguriert…. jetzt wirds spanned.
The detailed view:
ip route 0.0.0.0 0.0.0.0 172.16.126.170 1)access-list 100 deny Ip host 172.16.124.1 any 2)access-list 100 deny ip 172.16.124.0 0.0.0.127 host 172.16.124.1 3)access-list 100 deny ip 172.16.124.0 0.0.0.127 172.16.66.0 0.0.0.255 4)access-list 100 deny ip 172.16.124.0 0.0.0.127 172.16.4.0 0.0.1.255 5)access-list 100 deny ip 172.16.124.0 0.0.0.127 172.16.6.0 0.0.0.255 6)access-list 100 deny ip 172.16.124.0 0.0.0.127 192.168.50.0 0.0.0.255 7)access-list 100 permit ip 172.16.124.0 0.0.0.127 any route-map PBR_RM1 permit 10 match ip address 100 set ip next-hop 172.16.126.171
Was wurde hier versucht?
1) Markiert Traffic auf das SVI vom 3750 selber
2) Markiert Traffic von der unteren Hälfte eines Subnet auf das SVI vom 3750
3-6) Markiert Traffic von der unteren Hälfte eines Subnet in alle anderen Subnets
7) Implizite Rule für jeglichen weiteren Traffic
Es ist schon eine Zeit her seit dem letzten Mal PBR… aber da dämmert mir doch eine limitation:
When configuring match criteria in a route map, follow these guidelines:
– Do not match ACLs that permit packets destined for a local address. PBR would forward these packets, which could cause ping or Telnet failure or route protocol flapping.
– Do not match ACLs with deny ACEs. Packets that match a deny ACE are sent to the CPU, which could cause high CPU utilization.
-> show proc cpu history
100 * ** 90 * *** * * ** * 80 ****** ****** * ** ** ********* *** ** * * * ***** **** * 70 ********************************************************************** 60 ********************************************************************** 50 ********************************************************************** 40 ****##**************************************************************** 30 ****###***#******************#**************************************** 20 **#####**###***************####**###********************************** 10 ###################################################################### 0....5....1....1....2....2....3....3....4....4....5....5....6....6....7. 0 5 0 5 0 5 0 5 0 5 0 5 0 CPU% per hour (last 72 hours) * = maximum CPU% # = average CPU%
Moderater Avarage aber häufige 100% peaks.
Also http://sourceforge.net/projects/iperf/ ausgepackt. Verschiedene Szenarien durch gemessen. UDP/TCP spielte keine Rolle.
[ 3] local 172.16.124.199 port 33453 connected with 172.16.66.50 port 5001
[ 3] 0.0-10.2 sec 12.26 MBytes 12.05 Mbits/sec
[ 3] local 172.16.124.99 port 33453 connected with 172.16.66.50 port 5001
[ 3] 0.0-10.2 sec 4.26 MBytes 4.05 Mbits/sec
(Capture nachgestellt, hab die vor Ort nicht gesaved)
The Analysis:
Tatsächlich, der Kunde hatte recht. Hitted PBR, steigt die CPU, PEAKt sie auf 100%, fängt der Switch an zu droppen == Bandbreite sinkt massiv!
Ein Blick auf die CEF Tabelle, zeigte vorerst nichts ungewöhnliches:
SW1#show ip cef summary
IPv4 CEF is enabled for distributed and running
VRF Default:
452 prefixes (452/0 fwd/non-fwd)
Default network 0.0.0.0/0
Table id 0
Database epoch: 8 (452 entries at this epoch)
Die CEF Engine läuft und hat ein moderates Volumen an Einträgen.
Beim genaueren hinsehen, zeigte sich jedoch dass eine enorme Anzahl an Paketen von der CEF gedropped werden:
SW1#show ip cef switching statistics
Reason Drop Punt Punt2Host
RP LES Packet destined for us 0 187122 0
RP LES No adjacency 26642184 0 0
RP LES No adj, queued resolution 181442882 0 0
RP LES Incomplete adjacency 230 0 0
RP LES Incomp adj, queued resolu 122 0 0
RP LES TTL expired 0 0 597
RP LES Total 208085418 187122 597
All Total 208085418 187122 597
Der Grund dafür konnte auch gefunden werden. Der Switch teilt jedem Dienst eine beschränkte Anzahl Resourcen zu:
SW1#show proc memory
Processor Pool Total: 79719284 Used: 34869188 Free: 44850096
I/O Pool Total: 12574720 Used: 8572444 Free: 4002276
PID TTY Allocated Freed Holding Getbufs Retbufs Process
0 0 48784268 10604156 35264900 0 0 *Init*
0 0 14032 3953798148 14032 0 0 *Sched*
0 0 1771680428 87657724 844016 9717416 1229480 *Dead*
Bei der CEF Engine sieht man schön, dass diese ihren Memory komplett auslasstet. Im Detail siehts mans noch etwas besser:
SW1#show cef memory
Memory in use/allocated Count
——————————————————————
ADJ: NULL adjacency : 336/380 ( 88%) [1]
ADJ: adj sev context : 3844/3932 ( 97%) [2]
ADJ: adjacency : 264864/265216 ( 99%) [8]
ADJ: request resolve : 21760/21848 ( 99%) [2]
ADJ: sevs : 10684/10772 ( 99%) [2]
CEF: Brkr Consumer : 288/552 ( 52%) [6]
CEF: fib_rib_route_update : 65812/65900 ( 99%) [2]
CEF: fibhwidb table : 25496/25540 ( 99%) [1]
CEF: fibidb table : 25496/25540 ( 99%) [1]
CEF: hash table : 262144/262232 ( 99%) [2]
CEF: hwapi swobj walks : 67888/67976 ( 99%) [2]
The Assumption:
Dadurch, dass nicht mehr via Hardware reroutet werden kann, wird es via Software von der CPU abgehandelt, das würde die Peaks erklären. Wenn die CPU an den Anschlag kommt (ca. 80-90%, da sie noch reservierungen für critische Dienste hat), fängt sie an zu droppen.
Ich kann mir vorstellen, dass die von Kunden beschriebenen Probleme mit den Telefon Disconnects und den Citrixsessions die Abreisen, ebenfalls damit zusammen hängen.
Ich hab die Memory Table etwas beobachtet, es macht nicht den Anschein, als würde sie sich gross verändert, scheinbar leaked hier ein Prozess. Ebenfalls Suspect, dass er den Speicher nicht mehr freigibt.
Ich konnte jedoch leider in der Releasenote von eurem 12.2(44) IOS keinen Bugfinden der auf einen CEF Memory Leak hindeutet.
The Solution:
Die Lösungsansetze in sinnvoller Reihenfolge, jeweils in Abhängigkeit, sollte der Vorgänger kein Ergebnis bringen.
1) Coreswitch neustartet
2) Switch 2 (gleiches Model) zum Master
3) IOS Upgrade
4) TAC Case aufmachen und tiefer Troubleshooten.
5) Switch 3 (Enhanched Serie) mit einer Advance Routing Lizenz aufbohren und diesen zum Master machen.
6) Switche ersetzen oder Design überdenken.
1 + 2 brachte keinen Erfolg
3-4 wird nicht weiter verfolgt
5) bedeutet Kosten für den Kunden, mit ungewisser Erfolgsaussicht
6) PBR ohne Deny Konfigurieren.
—Konfig Changes—
ip route 0.0.0.0 0.0.0.0 172.16.126.170
no ip route 172.16.126.224 255.255.255.248 172.16.126.170
no ip route 20.20.20.0 255.255.255.248 172.16.126.170
no ip route 129.132.2.21 255.255.255.255 172.16.126.170
ip route 10.0.0.0 255.0.0.0 172.16.126.171
ip route 172.16.0.0 255.255.0.0 172.16.126.171
access-list 105 permit ip 172.16.124.0 0.0.0.127 10.0.0.0 0.255.255.255
access-list 105 permit ip 172.16.124.0 0.0.0.127 172.16.0.0 0.0.255.255
route-map PBR-NEXHOP-to-PRIVATWAN permit 10
match ip address 105
set ip next-hop 172.16.126.171
Somit keine Deny Statements mehr und kein Traffic von oder auf Router der ins PBR Matched!
Lösung noch nicht implementiert. Update folgt…
Quellen Angaben:
