Wêrom't ien EVPN-hierder ferskate route distinguishers sjen kin
Twa RD's yn ien hierder binne gjin konflikt. Kuierje fan de CLI-útprint nei it MAC-VRF of IP-VRF dat de rûte makke hat, en kontrolearje dan RT-ymport en VNI.
Jo filterje de EVPN-tabel foar ien hierder, en de rûtes drage twa ferskate route distinguishers. De earste reaksje is in konfiguraasjekonflikt, en dy reaksje is meastentiids ferkeard. In hierdernamme is in bedriuwslabel, net ien inkeld objekt fan 'e kontrôleflakte, sadat de brêgekontekst en de rûtekontekst derfan ûnder aparte identifikaasjes ferkundigje meie. Kuierje ien rûte tagelyk fan de útprint werom nei it lokale tsjinstobjekt dat it makke hat, en it twadde RD hâldt op as in flater te lykjen.
Begjin by de útprint dy't jo yn betizing brocht
Kies ien rûte ynstee fan 'e hiele tabel. Skriuw it rûtetype, it RD, de eksportearre route targets en de folgjende hop op. Dy fjouwer fjilden binne genôch om te bepalen hokker lokaal objekt it ferkundige hat en hokker polityk op ôfstân it ymportearje moat.
Op in apparaat yn NX-OS-styl wurdt de detailwerjefte berikt mei show bgp l2vpn evpn route-type 2 detail of show bgp l2vpn evpn route-type 5 detail. Op Junos stiet deselde ynformaasje yn show route table bgp.evpn.0 detail. Oare syntaksis, deselde fjilden.
Begjin net mei alle toande sifers gelyk te meitsjen. RD's gelyk meitsje is de feroaring dy't it ymportbelied op in wurkjend fabric brekt.
Jou elk identifikaasje syn wurk
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
In MAC-VRF hâldt MAC-trochstjoerynformaasje foar in brêgetsjinst. In IP-VRF leveret in IP-rûtekontekst foar in rûte tsjinst. In hierder kin beide omfetsje, dêrom kin ien hierder mear as ien RD produsearje sûnder hokker konfiguraasjeflater dan ek.
RFC 7432 jout it RD fan 'e ferkundigjende MAC-VRF oan syn EVPN NLRI en easket ferskate RD's oer MAC-VRF's op deselde PE. Route-target-prosedueres binne apart: se tastean ien of mear RT-attributen en fertrouwe op it ymportbelied foar lidmaatskip. RD-gelykheid is net wat mienskiplik lidmaatskip skept, en it sa behannelje is de woartel fan dizze betizing.
Kuierje ien rûte fan ferkundiging nei ymport
Folgje de rûte yn ien rjochting. Befêstigje it rûtetype, de tsjinst dy't it makke hat, it RD, de eksportearre RT's en dan it ymportbelied op 'e PE dy't it ûntfangt. Eltse stap beantwurdet in oare fraach, en in fout by hokker stap dan ek liket as deselde ûntbrekkende prefiks oan 'e oare kant.
As de rûte oanwêzich is, ûndersykje dan de ynstallearre trochstjoerkontekst en de VNI-mapping. In oerienkommende VNI oan beide kanten bewissiget dat de dataflakte it iens is; it bewissiget net dat de kontrôleflakte de rûte fia it bedoelde belied ymportearre hat.
As de rûte op 'e PE op ôfstân ferskynt mar der gjin ferkear rint, is it probleem foarby EVPN gien. Kontrolearje de VNI-nei-VLAN- of VNI-nei-VRF-bining en it underlay-paad foardat jo route targets wer bewurkje. Begjin by de mapping, dan it underlay en pas dan de kontrôleflakte. In route-target-wiziging weromdraaie om in dataflakteflater te efterfolgjen is in betroubere manier om in wurkjende ymport te brekken.
Prefiksen fan laach 3 binne noch altyd EVPN-rûtes
In IP-prefiks yn 'e EVPN-tabel is gjin gewoane IPv4-unicast BGP. De EVPN IP Prefix-rûte is in eigen rûtetype, en MAC/IP- en IP-prefiksferkundigings reizgje yn 'e EVPN-adresfamylje, dy't RFC 7432 as AFI 25 en SAFI 70 identifisearret.
Dat ûnderskie is fan belang as jo in rûte yn 'e EVPN-tabel fergelykje mei ien yn 'e unicast-tabel. Se kinne deselde bestimming beskriuwe en dochs troch ferskate belied makke, filtere en ymportearre wurde. Ien as bewiis oer de oare lêze is hoe't in krekte fabric by in migraasje brutsen liket.
Kontrolearje de ôflieding fan 'e leveransier foardat jo sifers fergelykje
RFC 9136 wreidet EVPN út mei IP Prefix-rûtes en spesifisearret oft it jildende RD út 'e MAC-VRF- of IP-VRF-kontekst komt. Dêrom moat in L2-tsjinstlabel en in label fan in rûte tsjinst yn deselde útprint lêzen wurde tsjin 'e objekten dêr't se by hearre, net werombrocht wurde ta ien RD per hierder.
Automatyske ôflieding fan RD en RT is leveransierspesifyk. Lês de referinsje fan 'e ynsette leveransier foar de brûkte formule; in automatysk generearre wearde sjoen op ien switch is gjin universele kodearring, en it fergelykjen fan sifers fan twa leveransiers bewissiget selden wat.
Einigje mei in skriftlik spoar foar de rûte dêr't jo mei begûn binne: type, oarsprongobjekt, RD, eksportearre RT, ymportbelied, ynstallearre VNI. Seis fjilden ferklearje de ferkundiging foar elkenien dy't it ticket dêrnei lêst, en net ien fan harren easket dat de sifers fan 'e hierder oerienkomme.