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