Allereerst onze excusses dat we zo laat reageren, maar we zijn net terug van
de colocatie.
Probleem:
De router ( cisco 12012 ) en de routing switch ( Extreme 7i ) konden elkaar
niet bereiken, en aangezien alle machine achter de Extreme hangen waren deze
totaal onbereikbaar.
Oplossing:
We dachten direct aan een kabelbreuk, dus hebben we er een nieuw stuk glas
tussen de routers gezet, maar dat was het probleem niet. Beide interfaces
konden elkaar niet bereiken via de Gbit verbinding. Toen dachten we aan een
IP conflict op het interne netwerk, maar dat kon het ook niet wezen. Toen
dachten we een ARP probleem, dus op de 12012 en de 7i de ARP-Cache
gecleared, maar binnen een seconde stond de oude ARP weer op de 12012 (?!).
Toen hebben we alle verbindingen op de 7 weggehaald op de Gbit verbinding
naar de 12012 na ( om te kijken waar die ARP-tabel vandaan kwam ), maar dat
bleek dus niet intern te komen, want direct na de ''clear arp'' op de 12012
stond de ARP-table weer gevuld op de 12012. conclusie: de ARP-table moest
van buiten het netwerk komen. Op het moment dat we Carrier1 uplink en de
AMSIX link down brachten was het probleem over. na een paar seconden de
uplinks weer terug gezet, daarna alle clients weer op de 7i aangesloten.
Conclusie:
Op een 1 of andere manier zit er ARP reflector op het netwerk, deze kan
alleen afkomstig zijn van Carrier1 ( omdat deze op basis van Ethernet
gekoppeld is, de andere uplinks zijn op basis van ATM ( daar is geen ARP op
mogelijk )), dus morgen vroeg direct contact opnemen met Carrier1 om te
kijken wat we hier aan kunnen doen.
Op dit moment werkt het weer, maar er bestaat een mogelijkheid dat het terug
komt.
Conclusie 2:
Dit hele ARP probleem bestond al veel langer ( daar weten BaseSoft en
NLHosting over mee te praten ), alleen konden we toen niet vermoeden, dat
het deze uitwerking kon hebben.
Conclusie 3:
(te) lang leve ARP-cache
Met vriendelijke groet,
Maurice Sienema
CyberComm