09 September 2013

RFC 5185, please!

Nattens hyggelige fejlsøgning...

Redundans for OSPF-ringe virkede ikke ordentligt: Når det direkte link mellem to distributions-routere var nede, og trafikken skulle flyde via en af de mange, vidunderlige holde-OSPF-areas-sammen GRE-tunnels, røg trafikken i bitspanden.

Fejlsøgning viste, at problemet skyldtes, at tunnel destination (7600) modtog pakken som IP-i-GRE-i-MPLS, og det kan en 7600 ikke terminere / route til et rent IP-interface. Tunnel source / destination er separate loopbacks, da tunnel-trafik ellers software-forwardes på den platform, og loopbacks er så som normalt passivt inkluderet i IGP'en (i dette tilfælde ISIS).

Det viste sig, at nogle core-routere genererede labels for disse ISIS-lærte loopback routes. LDP outbound filter blev rettet på de pågældende routere, og så kørte det.

Nå ja, og så var der lige hyggen med en hardware-fejlbesked på et modul, der ikke gik væk ved at skifte modulet, men først da vi skiftede RSP'en.

Så gik der en nat med det.

-A

PS: OSPF er (naturligvis, stadig) noget skrammel i en SP backbone, men det kunne være lidt bedre, hvis man havde support af RFC 5185 i IOS. Det er supporteret i XR og XE 3.10, men Sjovt(tm) nok ikke i 15 S.

07 September 2013

500K

Har du en fuld Internet-tabel på 6500/7600 (på XL-kort, selvfølgelig)?

Hvis du kører default-config, er du nu faretruende tæt på 100%:

Aktuel fra en tilfældig router:

router#sh mls cef summ

Total routes:                 504884
     IPv4 unicast routes:     502873
     IPv4 Multicast routes:      940     
     MPLS routes:                708     
     IPv6 unicast routes:        254     
     IPv6 multicast routes:        3       
     EoM routes:                 109     


Default fordeling:

router#sh mls cef max
FIB TCAM maximum routes :
=======================
Current :-
-------
IPv4 + MPLS         - 512k (default)
IPv6 + IP Multicast - 256k (default)


Man kan justere fordelingen (mls cef max), og det kan kun gå for langsomt.

-A

02 September 2013

Shared buffer, global drop

Dagens sjove fejlsøgning...

Nogle bestemte web-sites virkede ikke for klienter på bestemte typer af access-switche (de gamle 3560 fejlede, men de endnu ældre 3550 virkede fint). Man kunne se en TCP SYN (eller ICMP ECHO) blive sendt, men ikke noget svar.

Når man så lavede en SVI på samme switch med en adresse i samme VLAN, kunne man godt pinge serveren derfra.

Var der tale om noget filtrering / blacklisting af specifikke adresser fra hosting-provideren? (Checket via meatspace-netværket[1]). Næh, det var der ikke.

(En hel del) yderligere fejlsøgning viste, at når man slog 'mls qos' fra, så virkede det fint[2].

Et 'tcpdump' af trafikken viste, at den var mærket med ToS=0x20 (CS1). Hvem Fanden bruger også Scavenger til noget som helst?

Der var på switchen ikke reserveret noget buffer-space til CS1 -- "Vi bruger ikke Scavenger"[3] -- og på en shared buffer-arkitetur, gælder at ingen (nul) buffer = drop pakke, uanset hvad belastningen er.

Derfor.

-A

[1] Tak, Michal!

[2] Men vi elsker jo QoS. Det gør vi. Næsten lige så meget som tunnels og NAT.

[3] Men hvis vi ikke bruger Scavenger, kan vi med fordel nedmærke al transit-trafik til BE.

-A