dropwatch - pouzitelnost
Dalibor Toman
dtoman na fortech.cz
Středa Září 16 17:46:49 CEST 2015
DD,
tak ten problem jsem zrejme vyresil a zdroj potizi nebyl nezajimavy.
Nakonec se mi podarilo chytit dropwatchem okamzik, kdy dochazelo k tem
dropum a dropwatch ukazal na
qdisc_dequeue_head+93 (0xffffffff81494053)
, coz se nakonec ukazalo byt kfree_skb() ve funkci qdisc_reshape_fail().
To me nasmerovalo k shaperum (ktere na tom routeru jsou). Statistika
dropu qdiscu na bondovanem interface (bon0) vykazovala stejne prirustky
jako pocet dropu na tom vlankovem interface nad tim bondem (ip -s link
show dev bon0.vlanID). Shapery jsou nad bon0 ackoliv routing soupe
packety do bon0.vlanID (funguje to a resi to problem se shapovanim
odchoziho toku, kdyz ma router OSPF pres vice vlanek nad zakladnim
rozhranim).
Pak uz stacilo jen identifikovatv shaperu IPcko, ktere ma stejne
prirustky dropu ve sve class. Tcpdump odhalil, ze zakaznikovo IPcko
chvilemi primo chrli ICMP redirecty. Nacez se zjistilo, ze zakaznik je
pripojen pres router (mikrotik) ve kterem nefunguje spravne bridge -
MACky pro zakaznicka IPcka z ARP tabulky se nevyskytovaly v bridgeovaci
tabulce, takze bridge posilal packety pro konkretni IP vsemi porty v
bridge ven. Jednomu domacimu wifi routeru se to nelibilo tolik, ze obcas
vygeneroval par tisic ICMP redirektu (kdyz se k nemu dostal packet s
nespravnym IP).
Jediny drobny problem je, ze qdisc_reshape_fail() se vola jen v par
zdrojovych souborech a nami pouzite HTB k nim nepatri :-). Mozna se vola
neprimo pres jinou funkci.
A navic nejsem zvykly na to, ze dropy z HTBcka se propaguji jako dropy
na interface (jine rozhrani v tom samem routeru nic takoveho neindikuje
ani jine routery to nedelaji). Ale nikde jinde nemame vlan interface nad
bondem...
D. Toman
Další informace o konferenci Linux