MPLS L3VPN -labra ei pingaa? Tarkista nämä viisi hyppyä

Kaksi asiakasreititintä, pari provider edge -laitetta ja ping, joka kuolee ilman virheilmoitusta. Pienessä MPLS L3VPN -labrassa vika on lähes aina yhdessä viidestä tarkistuspisteestä, ja jokaisella niistä on komento, joka näyttää joko riippuvuuden toimivan tai sen puuttuvan. Virhe on käynnistää BGP uudelleen joka kerta, kun ping epäonnistuu, sen sijaan että riippuvuudet testattaisiin järjestyksessä. Jos hyppäät suoraan VRF-konfiguraatioon, voit viettää tunnin ongelmassa, joka alkoi ratkaisemattomasta seuraavasta hypystä kahden laitteen päässä.

Käy lista läpi alhaalta ylöspäin. Tarkistuspiste, joka menee läpi, pysyy hyväksyttynä, ja ensimmäinen vika on se, jota kannattaa debugata.

Tarkistuspiste yksi: PE-laitteet tavoittavat toisensa

Jokainen PE tarvitsee reitin toisen PE:n loopbackiin, ja sen reitin on ratkettava jotain todellista kautta. Interior gateway protocol on tavallinen tapa sinne, mutta staattinen reitti toimii myös, kunhan rekursiivinen haku päätyy elävään adjacencyyn. IOS-tyylisillä laitteilla show ip route 10.0.0.2 ja sen perässä show ip cef 10.0.0.2 näyttävät, onko prefiksi olemassa ja onko sen takana ratkaistu adjacency. Reitti taulussa ilman adjacencyä sen takana ei ole tavoitettavuutta.

Tarkista molemmat suunnat. Epäsymmetriset IGP-kustannukset, väärällä puolella oleva passive interface tai loopbackin suodattava distribute list rikkovat kukin vain yhden suunnan, ja yksi suunta riittää tappamaan istunnon. Jos loopbackit pingaavat mutta BGP-istunto seisoo Active-tilassa, katso update source ennen kuin kosket mitään muuta.

Tarkistuspiste kaksi: leimapolku on olemassa

IP-reitti etäiseen loopbackiin ei todista, että kuljetus painaa leiman päälle. Varmista LDP-ratkaisussa, että etäisellä loopbackilla on sekä paikallinen että etäinen sidonta ja että lähtevä leima näkyy forwarding-taulussa. show mpls ldp bindings 10.0.0.2 32 näyttää leimaparit ja show mpls forwarding-table 10.0.0.2 näyttää, mitä line card todella asettaa päälle. Kun toinen komento ei näytä leimaa tai putoaa takaisin IP:hen, kuljetus ei kanna VPN-liikennettä niin kuin suunnitelma olettaa.

Ero tulee siitä, miten MPLS erottaa forwarding staten kohdeprefiksistä, malli, joka on kuvattu dokumentissa RFC 3031. Jos labrasi käyttää LDP:n sijaan RSVP-TE:tä tai BGP:n viereisiä leimoja, tarkista sen mekanismin oma tila; olettaa, että LDP jakaa jokaisen alikerroksen leiman, on tavallinen tapa jahdata kummitusbugia. Rikkinäinen leimapolku näkyy myöhemmin yleensä VPN-reittinä, joka on olemassa mutta käyttökelvoton.

Tarkistuspiste kolme: VPN-reitti saapui ehjänä

Katso täsmällisen asiakasprefiksin VPNv4- tai VPNv6-reittiä, älä istunnon yhteenvetoa. show bgp vpnv4 unicast all 10.10.1.0/24 näyttää route distinguisherin, etäiseen PE-loopbackiin asetetun next hopin ja leiman. Jos prefiksi puuttuu, ensimmäinen epäilty on lähettävän PE:n vientikäytäntö tai vastaanottavan PE:n tuontikäytäntö, ja route targetit ovat tavallinen syyllinen.

Lue route target -tarkistus erillään BGP-vastaanotosta. Reitti voi saapua oikealla next hopilla ja silti jäädä laskeutumatta VRF:ään, koska importtarget ei täsmää. Vastaanottavalla PE:llä show ip route vrf CUSTOMER 10.10.1.0 on se testi, jolla on merkitystä; BGP-taulu todistaa vain, että reitti ylitti ohjaustason.

Tarkistuspiste neljä: interface on VRF:ssä

VRF-määritelmä route distinguisherilla ja route targeteilla ei siirrä yhtään interfacea sinne. CE:tä kohti oleva interface tarvitsee VRF-määrityksen, ja show ip vrf interfaces tai show ip interface brief näyttää sen oikean instanssin alla. Tämä on se tarkistuspiste, jossa kopioitu konfiguraatio useimmin menee pieleen, koska VRF-lohko näyttää valmiilta samalla kun interface istuu yhä globaalissa taulussa.

Vahvista sitten, että PE on oppinut paikallisen asiakasprefiksin siihen VRF:ään ja että CE:llä on reitti takaisin liitännän kautta. Staattinen default CE:llä kohti PE:tä riittää labraan, edellyttäen että PE:n VRF:ssä on reitti CE-LANiin. Jos jompikumpi puolisko puuttuu, ping epäonnistuu ennen kuin yhtään leimaa asetetaan.

Tarkistuspiste viisi: vastaus löytää tien kotiin

Jäljitä eteenpäin menevä paketti ja sitten paluupaketti, koska ne käyttävät eri tauluja. Tulevan PE:n pitäisi ratkaista asiakkaan lähde VRF:n sisällä etäiseen prefiksiin etäisellä leimalla. Lähtevän PE:n pitäisi ratkaista kohde saman VRF:n sisällä CE:tä kohti olevaan interfaceen. PE:stä itsestään lähtevä ping ei ole todiste: se voi poistua globaalin taulun tai toisen lähdeosoitteen kautta, ja siksi ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 on se testi, joka pitää ajaa.

Isäntien palomuurit, reverse-path filtering ja CE:n access-listat pätevät edelleen. Jos meno toimii ja vastaus kuolee, ongelma on paluupuolen reitissä tai suodattimessa, ei MPLS-kuljetuksessa.

Pidä tarkistuspistettä kohden yksi rivi, johon kirjaat ensimmäisen pettäneen riippuvuuden. Se rivi muuttaa väitteen, ettei asiakas voi pingata, konkreettiseksi kysymykseksi tavoitettavuudesta, leiman tilasta, reitin tuonnista, interfacen jäsenyydestä tai paluupolusta, ja se estää seuraavaa debug-kertaa toistamasta samoja viittä komentoa samassa järjestyksessä.