BGP Configuratie IP backbone

[bonza]

BGP freaks onder ons... HELP,

Ons ISP netwerk is zojuist 15 minuten deels down geweest, terwijl we volledig redudant via meerdere uplinks met meerdere upstream providers via een eigen AS nummer via BGP4 met internet verbonden zijn.

Het probleem ontstond doordat een BGP tabelen op een router van een van de upstream providers niet direct geupdated werd terwijl links verder in hun netwerk down waren.

We waren genoodzaakt om onze BGP link naar deze Provider handmatig down te brengen.

15 minuten minder bereikbaar zijn is voor ons een eeuwigheid, laten we zeggen dat dit voor ons bedrijf een duur incidentje was

Ik weet dat het BGP4 protocol dit zelf niet kan opvangen, maar bestaan er tools (in hardware en/of software) welke in z'n geval onze eigen BGP tabellen kunnen beinvloeden?
Dit zodat indien er een groot aantal routes van een upstream provider down zijn deze een lagere prefix krijgen of zelfs de hele BGP sessie naar deze provider verbroken wordt. Het detecteren van een groot aantal dode routings zou dan dus bijna realtime moeten gebeuren. Een gedeeltelijke downtime van 120 seconden ofzo zou in z'n situatie geen probleem zijn, maar 15 minuten agghh (sneller kunnen z'n storing rond 2:30 snachts niet oplossen).

Wakker worden van een pager en dan remote gaan debugen op BGP nivo kost nu helaas eenmaal tijd...

[Coen Rosdorff]

Ik zou een andere vraag stellen: Wil je wel door met zo'n provider als het goed functioneren (schijnbaar) zo kritisch is?

Je kan vast wat scripts maken die wat tests doen met ping, en bij het niet functioneren wat in de bgp gaan vroeten. Maar dan ben je wel met symptoon bestrijding bezig.

[Verwijderd]

Euh.... 2 upstream providers nemen, je blokken goed bij RIPE registeren, en peeren op loopback?

[Verwijderd]

sorry, te snel gelezen, je hebt al meerdere upstream providers... tja, tegen dit soort dingen kun je je heel lastig beschermen, ik denk zelfs niet

[Maarten @klet.st]

Verwijderd schreef op 08 September 2003 @ 07:31:
sorry, te snel gelezen, je hebt al meerdere upstream providers... tja, tegen dit soort dingen kun je je heel lastig beschermen, ik denk zelfs niet

Als ik het zo lees heb je je configuratie goed in elkaar zitten (eigen AS, ge-announced via meerdere upstream providers). Als een van die upstream providers je wel announced, maar het verkeer niet naar je doorstuurt kun je weinig meer doen dan zorgen dat ze daar SNEL mee stoppen. De vraag is nog maar of het 'verbreken' van de propagatie van jouw AS (door jou) aan de betreffence upstream provider zin heeft, zij hebben kennelijk toch al ergens een fout zitten. Veel invloed op het announcen door hen zul je dus wel niet hebben.

Veel meer dan het nummer van de juiste technische personen (NOC ofzo) in je telefoon hebben en goed opletten (of een monitoring tool aan de buitenkant dat je tijdig waarschuwt) kun je niet doen. Uiteraard kun je wel een mooi script maken dat op basis van extern monitoren de configuratie van je routers aanpast, maar zoals gezegd, de vraag is of je upstream provider zich er veel van aantrekt als er geen link tussen hun borderrouters en de router waarmee jij communiceert is.
Bellen en klagen is vaak de enige oplossing, alhoewel ik ook wel weet dat bellen niet altijd even efficient is (figuren aan de lijn die je niet snappen enzo).

[Verwijderd]

van BGP weet ik niet extreem veel, maar kan je de schade niet verhalen op je uplink provider (welke is het als ik vragen mag?) Ik neem aan dat je een goed SLA hebt die je connectivity garandeert, dus wanneer het bij hun in de soep loopt (ook al is het verderop in het netwerk) waardoor jij de buitenwereld niet meer kan bereiken dan mag ik aannemen dat het onder je SLA valt.

[bonza]

Update: Het probleem is met bijna 100% zekerheid gevonden. Het betrof trouwens een Upstream via het glas netwerk van Colt telecom gelink op een Versatel pop in Zwolle. Een van de router reflectors functioneerd waarschijnlijk niet naar behoren. Aangezien er geen default route voor onze IP ranges was binnen hun IBGP setup ondervonden alleen wij hier hinder van en merkten ze zelf niets van de storing.

Als je onze upstreams los bekijkt hebben deze een beschikbaarheid van 99.9 of 99.8% (afhankelijk van de uitvoering van de glas verbinding). Dus iemand aansprakelijk stellen is in dit geval zowiezo moeilijk en gezien onze relaties met onze upstreams ook niet wenselijk.

Ik ga denk ik maar eens kijken of ik via een paar aanpassigen in ons BGP bandbreedte managment systeem (Linux doos met Zebra en stapeltje scripts gelinkt op onze Core routers) dit soort situaties veilig kan detecteren en de downtime dan wat kan verminderen door ongunstige local prefs en wat AS prepends te injecteren op de verdachte upstreams totdat een engineer besluit om de lijn geheel down te brengen.

Mocht het script dan door een bug of een beperking ooit domme dingen doen dan belanden we teminste ook niet in een situatie waarin meerdere upstreams geheel worden afgesloten

[Verwijderd]

Heeft COLT.NET toevallig gisteren om 17:00 instellingen veranderd? Er zijn via de access providers KPN en UPC namelijk een heel aantal domeinen bijvoorbeeld www.photoways.com www.casino.com niet bereikbaar. (BBNED heeft geen problemen hiermee) Hier de routings, er zijn op dit moment dus nog steeds problemen, maar waar moet ik aankloppen?

XSALL
Tracing route to casino.com [217.73.2.78]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 37 ms 44 ms 41 ms 11.ge-0-2-0.xr1.s340.xs4all.net [194.109.30.1]
4 40 ms 38 ms 38 ms 0.ge-1-3-0.xr2.pbw.xs4all.net [194.109.5.21]
5 39 ms 42 ms 44 ms 0.ge-1-3-0.xr1.tc2.xs4all.net [194.109.5.6]
6 41 ms 38 ms 38 ms gladys.router.colt.net [193.148.15.236]
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.


UPC
Tracing route to casino.com [217.73.2.78]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 7 ms 3 ms 3 ms h7rtr1.a2000.nl [24.132.52.1]
3 7 ms 9 ms 3 ms pos12-3.am00rt03.brain.upc.nl [62.108.0.61]
4 11 ms 5 ms 15 ms srp8-0.am00rt01.brain.upc.nl [212.142.32.33]
5 14 ms 9 ms 3 ms srp0-0.am00rt06.brain.upc.nl [212.142.32.44]
6 3 ms 8 ms 11 ms nl-ams01a-rd1-pos-3-0.aorta.net[213.46.161.53]
7 6 ms 5 ms 9 ms nl-ams04a-ri-gige5-2-4.aorta.net[213.46.161.193]
8 * 4 ms 3 ms nl-ams02a-rd1-10gige-7-0.aorta.net[213.46.161.58]
9 7 ms 10 ms 4 ms nl-ams04a-ri1-pos-6-0.aorta.net[213.46.161.62]
10 4 ms 4 ms 122 ms gladys.router.colt.net [193.148.15.236]
11 * * * Request timed out.
12 *


BBNED
Bezig met het traceren van de route naar www.casino.com [217.73.2.78]
via maximaal 30 hops:
1 10 ms <10 ms <10 ms 192.168.0.1
2 <10 ms <10 ms 10 ms 62-177-208-57.bbeyond.nl [62.177.208.57]
3 30 ms 10 ms 30 ms asdhem1nrp04.bbned.nl [62.177.131.9]
4 20 ms 20 ms 30 ms asdhem1rip01.bbned.nl [62.177.131.1]
5 20 ms 30 ms 20 ms asdhem1rtr01.bbned.nl [62.177.131.74]
6 20 ms 10 ms 20 ms asdtel1rtr01.bbned.nl [62.177.143.254]
7 10 ms 20 ms 20 ms 212.72.45.245
8 10 ms 30 ms 10 ms gige1-2.core2.amsterdam1.level3.net [213.244.165.102]
9 10 ms 20 ms 20 ms pos3-3.br1.ams3.alter.net [146.188.67.201]
10 20 ms 20 ms 20 ms so-0-2-0.tr1.ams2.alter.net [146.188.3.213]
11 60 ms 50 ms 60 ms so-6-0-0.tr1.stk2.alter.net [146.188.7.30]
12 50 ms 61 ms 50 ms ge-7-3-0.xr1.stk3.alter.net [146.188.11.229]
13 60 ms 60 ms 50 ms pos1-0.gw7.stk3.alter.net [146.188.5.34]
14 50 ms 60 ms 60 ms om-gw.customer.alter.net [146.188.60.6]
15 50 ms 60 ms 50 ms sesma202cs02-s1l3vlan14.lundaidc.net [217.73.0.34]

[Verwijderd]

Het probleem bij COLT is nu opgelost, bijna 24 uur waren die netwerken onbereikbaar. Als je nou casino.com bent en je hebt 3 onafhankelijke ISPs en een lullige storing als deze kan je zomaar duizenden bezoekers kosten. (Ook hun 25 online casino's waren onbereikbaar) waar kan je dan aankloppen?