BGP oppi etuliitteen, mutta liikenne väistää tunnelia yhä

Haarakonttorin yhdyskäytävä näyttää pilven etuliitteen BGP-taulukossaan, istunto palveluntarjoajaan on muodostettu, ja silti käyttäjän pyyntö tuohon etuliitteeseen lähtee väärästä rajapinnasta. Mikään ei ole rikki niin kuin valvonta antaa ymmärtää, sillä “BGP oppi sen” on väite ohjaustasosta. Tuon taulukon ja paketin välissä on neljä erillistä siirtymää, ja virta pysähtyy täsmälleen yhteen niistä. Käy portit järjestyksessä läpi ja pysähdy ensimmäiseen, joka epäonnistuu.

Ensimmäinen portti: mitä naapuri todella lähetti

Aloita etuliitteestä sellaisena kuin se vastaanotettiin, ei tiivistettynä. Etsi tarkka verkko ja peite BGP-taulukosta ja kirjaa seuraava hyppy, AS-polku ja kaikki yhteisöt, joihin tuontikäytäntö voisi osua. Koontireitti hallintapaneelissa voi piilottaa sen, ettei kyseistä etuliitettä koskaan hyväksytty.

Tuontikäytäntö on tavallinen paikka, jossa reitti katoaa ilman virhettä. Etuliiteluettelo, yhteisösuodatin tai saapuva reittikartta voi pudottaa päivityksen, kun istunto pysyy pystyssä ja terveenä, ja siksi vihreä naapurivalo todistaa niin vähän. Lokirivin puuttuminen ei tarkoita päätöksen puuttumista. Se tarkoittaa yleensä, että päätös tehtiin hiljaa, täsmälleen kuten on määritetty.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Lue tuloste siinä järjestyksessä. Kaksi ensimmäistä komentoa kertovat, saapuiko tieto ja mitä naapuri väittää lähettäneensä; kaksi viimeistä, pääsikö mikään reititys- ja edelleenlähetystaulukoihin. Ensimmäisessä komennossa oleva ja kolmannessa puuttuva etuliite on valinta- tai asennusongelma, ei yhteyksien ongelma.

Toinen portti: valinta ja sitten asennus

BGP valitsee parhaan polun, eikä valittua polkua asenneta automaattisesti. Seuraava hyppy on ratkaistava, ja toisella reittilähteellä voi jo olla tämä etuliite paremmalla hallinnollisella etäisyydellä. Migraatiosta jäänyt staattinen reitti voittaa helposti kelvollisen BGP-polun ja lähettää liikenteen muualle.

RFC 4271 pitää kolme ajatusta erillään: mitä naapuri lähetti, minkä tämä puhuja valitsi parhaaksi ja mitä se ilmoittaa eteenpäin. Ne ovat käsitteellisiä rooleja, eivät kolme fyysistä tietokantaa, jotka toimittajan on paljastettava, mutta juuri tämä erottelu tekee “se on BGP:ssä” puutteelliseksi vastaukseksi.

Tarkista myös, mitä reitityskontekstia luet. VRF:ään asennettu reitti, johon käyttäjän rajapinta ei kuulu, on näkymätön kyseisen käyttäjän paketeille, ja taulukko näyttää koko ajan oikealta.

Kolmas portti: haku, joka koskee tätä virtaa

Lopeta nyt reitistä kysyminen ja ala kysyä paketista. Kirjaa käyttäjän lähdeosoite, kohde, protokolla, portti ja saapuva rajapinta, sillä jokainen niistä voi valita eri käytännön. Katso sitten hakua, joka koskee tuota yhdistelmää, yleisen reititystaulukon sijaan.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Tarkempi etuliite on täällä yleisin yllätys ja käytäntöreitti toinen. Molemmat ohittavat sen koontireitin, jota katsoit, eikä kumpikaan näy BGP-taulukon yhteenvedossa.

Yhdyskäytävästä itsestään lähtevä ping ei ole todiste käyttäjän istunnosta. Eri lähdeosoite, eri käytäntöpolku ja usein eri tulos. Testaa samalla lähteellä, jota sovellus käyttää, tai hyväksy, että testi vastaa eri kysymykseen.

Neljäs portti: polun kaukainen puolisko

Jos paikallinen haku valitsee tunnelin, paketti on silti hyväksyttävä suojakäytännössä, sallittava edelleenlähetyssäännössä ja vastattava jostakin toiselta puolelta. Krypto-ACL, joka ei sisällä osoiteparia, pudottaa liikenteen samalla kun tunneli ilmoittaa olevansa pystyssä, mikä tuottaa aikakatkaisun, jota ei voi erottaa reititysvirheestä.

Paluupolku on yhtä tärkeä kuin lähtevä. Pilven puolen on tiedettävä, miten haaran lähteeseen päästään, joko reitin tai tarkoituksella määrittämäsi käännöksen kautta. Epäsymmetriset paluupolut ovat yleisiä suunnitelmissa, joita on testattu vain yhdestä suunnasta.

Yhdistä tuore valtuutettu yhteys kolmeen havaintoon: paikallinen käytäntö, joka osui, liikkuneet tunnelilaskurit ja vastaanotto kaukaisella puolella, missä se on näkyvissä. Jos laskurit eivät liiku, paketti ei koskaan mennyt tunneliin, mitä reititystaulukko sanoo tahansa. Jos ne liikkuvat eikä mitään saavu, kaukainen puoli pudottaa tai reitittää sen väärin. Nämä kaksi tulosta johtavat täysin eri tiimeihin.

Nimeä siirtymä, joka epäonnistui

Kirjoita tulos yhtenä viidestä tilasta: ei vastaanotettu, käytäntö ei hyväksynyt, ei valittu, ei asennettu tai tämä virta ei osunut. Lisää kuudes tapaukseen, jossa paikallinen polku on oikea eikä kaukainen pää voi vastata. Tuo lause on toimitettava tulos, ja se on paljon hyödyllisempi kuin kuvakaappaus muodostetusta naapurista.

Pidä hyväksymissuunnitelmassa myös negatiivinen testi: kohde, jonka ei pidä kulkea tunnelin läpi, varmistettuna muutoksen jälkeen. Tarkistuslista, joka todistaa vain onnellisen polun, ei nappaa laajaa käytäntösääntöä, jonka joku lisää seuraavassa huoltoikkunassa.