Az OSPF designated router (DR) illetve backup DR (BDR) választás a broadcast/multicast képes interfészeken RouterOS alatt sem mindig úgy történik, ahogy az ember előre elképzeli, elég egy kis figyelmetlenség, az eszközök rossz sorrendben való konfigurálása, vagy egy kimaradt prioritás paraméter, és máris olyan eszközre kerülhet a DR funkció, ahol nem szeretnénk látni. A Cisco IOS-es megoldásokat, vagy éppen furcsaságokat több helyen el lehet olvasni, a Mikrotik RouterOS doksikban, fórumokon viszont nincs bő lére eresztve az ezzel kapcsolatos tudnivaló.
Mivel az OSPF interfészeken kézzel beállítható prioritás nem preemptív, és a routerek az éppen beállított prioritástól függetlenül elfogadják a már élő DR-t, alapvetően RouterOS alatt sincs más dolgunk, mint valahogy elérni, hogy az OSPF neigborship megszakadjon, és ezzel kierőszakoljuk a DR/BDR választást.
Talán a legegyszerűbb, és egyben a legrondább megoldás a megfelelő sorrendben újraindítgatni a Mikrotik eszközeinket. Egy modern RouterBoard, amin gigaherzes processzorok vannak, szó szerint másodpercek alatt újra tud bootolni. Nyilván ez nem minden környezetben kivitelezhető, ennél sokkal elegánsabb megoldás az, ami nagyjából a "clear ip ospf process" IOS parancsnak feleltethető meg (feltételezve, hogy csak egyetlen OSPF példányunk fut):
/routing ospf instance
/routing ospf instance> disable default; enable default
Amennyiben még ez is túlságosan destruktív parancs lenne, lehetséges az OSPF interfész reset (a fizikai interfész konfigurációjának piszkálása nélkül):
/routing ospf interface
print (az interfészek listájához)
disable 0; enable 0
Ugyanezek a dolgok hasonló útvonalon elérhetőek a grafikus felületen, WinBoxban is, azonban a kattintgatásoknál jó, ha tisztában vagyunk vele, hogy amennyiben a management IP-hez is OSPF route-okon férünk hozzá, akkor esetleg megszakadhat az admin sessionünk mielőtt visszaengedélyezzük az adott interfészt. A legjobban persze akkor járunk, ha még az OSPF neighborship kialakulása előtt bevéssük a konfigba a prioritást (1-255), és a "jó" sorrendben konfiguráljuk az OSPF-et az eszközeinken :)
/routing ospf interface
add interface=ether2 priority=255 disabled=no
2013-11-15
BGPlay: mikor és mi történt a UPC hálózatával?
Biztos többen emlékeznek, hogy UPC hálózatával nemzetközi irányokban komoly problémák voltak november első két napjában. Nemrég bukkantam rá a BGPlay nevű Java utilra, amivel a BGP AS prefix hirdetéseket, path változásokat és visszavonásokat lehet a RouteViews projekt naplói alapján historikusan nyomon követni egy megadott prefixre. Általában nem szeretem a grafikus eszközöket, de ez tényleg klassz. Nézzük meg, hogy mi történt a UPC ASN6830-ból eredő 89.134.0.0/15 prefixszel a BGPlay-ben elérhető összes adatforrás szerint:
Felül az információs sávban látszik az időpont, az AS path változás, illetve annak a BGP peernek az IP-je, ahonnan az adott információ be lett gyűjtve. A grafikonon minden egyes AS path-t egy-egy vonal jelöl, ami áthalad az érintett AS-eken. A szaggatott vonalak azt jelzik, hogy az adott időintervallum alatt az adott AS path nem változott, míg színes, folyamatos vonalak a változásokat mutatják.
A HUP.hu fórum vonatkozó témájában azonban egy ennél is jobb eszközt linkeltek be. A RIPE májusban adott ki közleményt arról, hogy az eredeti BGPlay-t továbbfejlesztett formában elérhetővé teszi. A szervezet által működtetett BGPplay változat nagyobb adatforrásból dolgozik, a felület is tovább finomodott, így az előzőnél is látványosabb, ahogy a 34655-ös DoclerWeb AS eltéríti a 89.134.0.0/15 prefixet.
Előtte:
Utána:
Felül az információs sávban látszik az időpont, az AS path változás, illetve annak a BGP peernek az IP-je, ahonnan az adott információ be lett gyűjtve. A grafikonon minden egyes AS path-t egy-egy vonal jelöl, ami áthalad az érintett AS-eken. A szaggatott vonalak azt jelzik, hogy az adott időintervallum alatt az adott AS path nem változott, míg színes, folyamatos vonalak a változásokat mutatják.
A HUP.hu fórum vonatkozó témájában azonban egy ennél is jobb eszközt linkeltek be. A RIPE májusban adott ki közleményt arról, hogy az eredeti BGPlay-t továbbfejlesztett formában elérhetővé teszi. A szervezet által működtetett BGPplay változat nagyobb adatforrásból dolgozik, a felület is tovább finomodott, így az előzőnél is látványosabb, ahogy a 34655-ös DoclerWeb AS eltéríti a 89.134.0.0/15 prefixet.
Előtte:
Utána:
2013-11-14
SDM template-ek Cisco switcheken
Meglehetősen könnyű olyan esetekbe belefutni Cisco switcheken, amelyek az SDM template módosítását igénylik, tipikusan ilyenek:
A CAM vagyis Content Addressable Memory olyan jószág, amely a neki átadott adatot (switchnél MAC címet) keresi meg a memóriaterületen és visszatér azzal a címmel (switch esetén portindex) ahol egyezést talált. A RAM-ok épp fordítva működnek: az általunk megadott címről olvasunk ki adatot, és nem az adattal keressük ki a címet. A switchek a CAM memória segítségével tudják villámgyorsan, hardveresen megállapítani, hogy mely portjukra kell az adott cél MAC című keretet továbbítani.
A TCAM-ok, azaz ternary, hármas CAM-ok a bináris CAM-októl eltérően, amelyek csak nullákat vagy egyeseket képesek tárolt adatként elfogadni, használnak egy harmadik, "nem számít" állapotot is az adat tárolása során. A TCAM ideális memóriatípus a például a route táblákban való keresések hardveres gyorsítására. Ha CPU-val végezzük a route táblában való keresést, akkor a cél IP-t össze kell ÉS-elgetni a route tábla minden egyes bejegyzéséhez tartozó maszkkal, majd az így megkapott hálózatcímet összehasonlítani az adott route bejegyzéssel, amíg egyezést nem találunk. A TCAM esetén a megfelelő biteket (a route tábla bejegyzéseinek host bitjeit) "nem számít" állapotban tárolva a továbbítandó csomag cél IP-je azonnal illeszkedik a megfelelő bejegyzésre, így nem kell minden egyes route tábla bejegyzéshez ÉS műveleteket majd egy összehasonlítást is elvégeztetni a CPU-val.
Ha a CAM megtelik egy switchben, akkor az eszköz nem tud új MAC címeket betanulni, így a még nem ismert eszközök MAC címeivel érkező kereteket minden portján továbbítani fogja, azaz floodolja. Ha a TCAM telik meg, akkor az újabb, a TCAM-be már nem férő route bejegyzések feldolgozása CPU-ból történik meg, ami jelentős terhelést ró az általában nem túl izmos switch CPU-ra. Minkét esetet érdemes elkerülni, ebben segít a Cisco switcheken az SDM template, hogy a rendelkezésre álló CAM és TCAM erőforrásokat az igényeinknek megfelelően, hatékonyan tudjuk a felhasználási területek közt szétosztani. Az ezzel kapcsolatos két legfontosabb parancs a "sh sdm prefer" enable módban, illetve az "sdm prefer" konfig módban. A template módosítás után mindig újra kell indítani az eszközt a beállítások érvényre jutásához.
DEVICE#show sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 3K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 11K
number of directly-connected IPv4 hosts: 3K
number of indirect IPv4 routes: 8K
number of IPv4 policy based routing aces: 512
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
DEVICE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
DEVICE(config)#sdm prefer ?
access Access bias
default Default bias
dual-ipv4-and-ipv6 Support both IPv4 and IPv6
routing Unicast bias
vlan VLAN bias
A poszt elején említettem, hogy az SDM template módosításával a Cisco 2960-asok is Layer3-as képességekkel ruházhatók fel, egy volt kollégám mutatta ezt kb. másfél éve. Csodákra azért ne számítsunk, a 2960-ason nem lesz se PBR, se dinamikus routeolás, statikus route-okból is csak max. 16 darab, kizárólag SVI interfésszel. Szoftverigény: legalább LANBASE 12.2.55 IOS.
- 2960-ason statikus routolás (igen!)
- 3560-ason PBR
- 3560/3750-esen IPv6 routeolás
A CAM vagyis Content Addressable Memory olyan jószág, amely a neki átadott adatot (switchnél MAC címet) keresi meg a memóriaterületen és visszatér azzal a címmel (switch esetén portindex) ahol egyezést talált. A RAM-ok épp fordítva működnek: az általunk megadott címről olvasunk ki adatot, és nem az adattal keressük ki a címet. A switchek a CAM memória segítségével tudják villámgyorsan, hardveresen megállapítani, hogy mely portjukra kell az adott cél MAC című keretet továbbítani.
A TCAM-ok, azaz ternary, hármas CAM-ok a bináris CAM-októl eltérően, amelyek csak nullákat vagy egyeseket képesek tárolt adatként elfogadni, használnak egy harmadik, "nem számít" állapotot is az adat tárolása során. A TCAM ideális memóriatípus a például a route táblákban való keresések hardveres gyorsítására. Ha CPU-val végezzük a route táblában való keresést, akkor a cél IP-t össze kell ÉS-elgetni a route tábla minden egyes bejegyzéséhez tartozó maszkkal, majd az így megkapott hálózatcímet összehasonlítani az adott route bejegyzéssel, amíg egyezést nem találunk. A TCAM esetén a megfelelő biteket (a route tábla bejegyzéseinek host bitjeit) "nem számít" állapotban tárolva a továbbítandó csomag cél IP-je azonnal illeszkedik a megfelelő bejegyzésre, így nem kell minden egyes route tábla bejegyzéshez ÉS műveleteket majd egy összehasonlítást is elvégeztetni a CPU-val.
Ha a CAM megtelik egy switchben, akkor az eszköz nem tud új MAC címeket betanulni, így a még nem ismert eszközök MAC címeivel érkező kereteket minden portján továbbítani fogja, azaz floodolja. Ha a TCAM telik meg, akkor az újabb, a TCAM-be már nem férő route bejegyzések feldolgozása CPU-ból történik meg, ami jelentős terhelést ró az általában nem túl izmos switch CPU-ra. Minkét esetet érdemes elkerülni, ebben segít a Cisco switcheken az SDM template, hogy a rendelkezésre álló CAM és TCAM erőforrásokat az igényeinknek megfelelően, hatékonyan tudjuk a felhasználási területek közt szétosztani. Az ezzel kapcsolatos két legfontosabb parancs a "sh sdm prefer" enable módban, illetve az "sdm prefer" konfig módban. A template módosítás után mindig újra kell indítani az eszközt a beállítások érvényre jutásához.
DEVICE#show sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 3K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 11K
number of directly-connected IPv4 hosts: 3K
number of indirect IPv4 routes: 8K
number of IPv4 policy based routing aces: 512
number of IPv4/MAC qos aces: 512
number of IPv4/MAC security aces: 1K
DEVICE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
DEVICE(config)#sdm prefer ?
access Access bias
default Default bias
dual-ipv4-and-ipv6 Support both IPv4 and IPv6
routing Unicast bias
vlan VLAN bias
A poszt elején említettem, hogy az SDM template módosításával a Cisco 2960-asok is Layer3-as képességekkel ruházhatók fel, egy volt kollégám mutatta ezt kb. másfél éve. Csodákra azért ne számítsunk, a 2960-ason nem lesz se PBR, se dinamikus routeolás, statikus route-okból is csak max. 16 darab, kizárólag SVI interfésszel. Szoftverigény: legalább LANBASE 12.2.55 IOS.
Feliratkozás:
Bejegyzések (Atom)