MPLS L3VPN (VPRN) - Huawei

Daha önce Nokia SR OS’ta VPRN kurmuştum. Bu yazıda aynı servisi Huawei VRP‘de eNSP üzerinde AR2200 Router’ında kuruyorum. Mantık aynı: omurgada OSPF + LDP, PE’lerde müşteriye özel routing tablosu, PE’ler arasında MP-BGP. Değişen şey komutların dili. Bu yüzden önce iki vendor’ın karşılığını tek tabloda topladım, sonra kurulumu adım adım yazdım.

Nokia ve Huawei komut karşılaştırması

İki fark en çok dikkatimi çekti. Nokia’da servis bir bütün olarak vprn bloğunda toplanıyor, arayüz de SAP’le o bloğun içine giriyor. Huawei’de ise VRF ayrı bir nesne ve fiziksel arayüzü ona ip binding ile bağlıyorsun. İkincisi, Huawei’de transport tünelini açıkça seçmiyorsun, LDP LSP varsa kendiliğinden kullanıyor.

1. Amaç ve VPRN’in mantığı

Hedef şu: iki müşteri router’ı (CE1 ve CE2), operatörün MPLS omurgasının üstünden birbirine ulaşsın, ama omurgadaki P router’lar müşteri rotalarını hiç görmesin.

Parçalar:

• VPN instance (VRF): PE üzerinde müşteriye özel routing tablosu.
• RD (Route Distinguisher): Aynı prefix’i iki müşteri kullansa bile BGP’de çakışmasın diye rotanın başına eklenen etiket. Sadece benzersizlik içindir.
• RT (Route Target): Bir rotayı hangi VRF’lerin alacağını belirler. Export eden PE rotaya RT’yi yapıştırır, import eden PE kendi VRF’ine yalnızca eşleşenleri alır.
• MP-BGP (VPNv4): PE’ler arasında müşteri rotalarını taşıyan protokol.
• İki katmanlı etiket: Dış etiket LDP’den gelir (karşı PE’ye giden yol), iç etiket BGP’den gelir (hangi VRF’e girecek).

2. Topoloji ve IP planı

Altı router var:

Linkler:

AS numarası 65000, iki PE aynı AS’te. Yani PE’ler arasındaki oturum iBGP.

CE tarafında gerçek bir LAN yerine birer loopback kullandım (/32). Test için yeterli ve eNSP’yi yormuyor.

3. Adım adım kurulum

Adım 1: Omurgada OSPF

Önce PE’lerin loopback’leri (1.1.1.1 ve 4.4.4.4) birbirine ulaşabilmeli, çünkü hem LDP hem BGP bu adresler üzerinden kurulacak. Omurgada üç farklı area kullandım (R2–R3 Area 0, R1–R2 Area 1, R3–R4 Area 2), R2 ve R3 ABR oldu. Tek area da yeterdi, ama çoklu area’nın VPRN’i bozmadığını da görmek istedim. Area mantığını OSPF çoklu area yazısında anlattım.

Örnek olarak R2 (iki area’ya bacağı olan ABR):

ospf 1 router-id 2.2.2.2
 area 0
  network 2.2.2.2 0.0.0.0
  network 10.1.23.0 0.0.0.255
  quit
 area 1
  network 10.1.12.0 0.0.0.255
  quit
 quit

Her router’ın loopback’i kendi bulunduğu area’ya yazıldı, area’lar arası aktarımı ABR yapıyor. R1’de kontrol:

<R1>display ip routing-table protocol ospf
        2.2.2.2/32  OSPF    10   1           D   10.1.12.2       GigabitEthernet0/0/1
        3.3.3.3/32  OSPF    10   2           D   10.1.12.2       GigabitEthernet0/0/1
        4.4.4.4/32  OSPF    10   3           D   10.1.12.2       GigabitEthernet0/0/1
      10.1.23.0/24  OSPF    10   2           D   10.1.12.2       GigabitEthernet0/0/1
      10.1.34.0/24  OSPF    10   3           D   10.1.12.2       GigabitEthernet0/0/1

3.3.3.3 ve 4.4.4.4 başka area’lardan geldiği için inter-area, ama R1’in umurunda değil. LDP ve BGP sadece loopback’e ulaşılabilir olmasını ister. ping -a 1.1.1.1 4.4.4.4 gidiyor.

Adım 2: MPLS ve LDP

PE’lerde ve P’lerde (R1–R4) yapıldı, CE’lerde (R5, R6) yapılmadı. R1:

system-view
mpls lsr-id 1.1.1.1
mpls
 quit
mpls ldp
 quit
interface GigabitEthernet0/0/1
 mpls
 mpls ldp
 quit
return

Satırların anlamı:

• mpls lsr-id 1.1.1.1: Router’ın MPLS kimliği. Loopback’i veriyorum, çünkü loopback düşmez.
• mpls: Router genelinde MPLS’i açar.
• mpls ldp: LDP’yi global olarak açar.
• Arayüzde mpls + mpls ldp: O kabloda etiketli paket geçsin ve komşu aransın.

Etiketler sadece omurga arayüzlerinde açılıyor. Müşteriye bakan arayüze yazılmıyor, çünkü müşteri düz IP paketi gönderir, etiketi PE ekler.

Kontrol (R2’den):

<R2>display mpls ldp session

 PeerID             Status      LAM  SsnRole  SsnAge      KASent/Rcv
 ------------------------------------------------------------------------------
 1.1.1.1:0          Operational DU   Active   0000:00:04  18/18
 3.3.3.3:0          Operational DU   Passive  0000:00:02  9/9

Operational olması önemli. Active/Passive sağlık göstergesi değil: LSR ID’si büyük olan TCP bağlantısını başlatır (Active), küçük olan kabul eder (Passive). R2 (2.2.2.2), R1’e (1.1.1.1) göre büyük olduğu için Active, R3’e (3.3.3.3) göre küçük olduğu için Passive.

LAM: DU Downstream Unsolicited demek: komşular etiketi sormadan kendiliğinden duyuruyor.

LSP’nin uçtan uca kurulduğunu R1’den test ettim:

<R1>tracert lsp ip 4.4.4.4 32
  LSP Trace Route FEC: IPV4 PREFIX 4.4.4.4/32 , press CTRL_C to break.
  TTL   Replier            Time    Type      Downstream
  0                                Ingress   10.1.12.2/[1026 ]
  1     10.1.12.2          20 ms   Transit   10.1.23.3/[1026 ]
  2     10.1.23.3          30 ms   Transit   10.1.34.4/[3 ]
  3     4.4.4.4            20 ms   Egress

Normal tracert IP katmanını sınar. tracert lsp ise MPLS katmanını sınar: “4.4.4.4/32 için kurulmuş etiket yolu boyunca git” der. Etiketlerin görünmesi LSP’nin gerçekten var olduğunun kanıtı. Etiket yerel anlam taşır: R1 paketi 1026 ile R2’ye verir, R2 yine 1026 ile R3’e verir (tesadüf, numaralar router’a göre değişir), R3 etiketi 3’e çevirir. 3 özel bir değerdir, implicit-null: R4 “son atlama öncesi etiketi at” diyor (PHP, penultimate hop popping), R3 etiketi sökerek R4’e düz IP olarak veriyor.

Adım 3: VPN instance ve PE–CE linkleri

Burası VPRN’in kendisi. R1 (PE1):

system-view
ip vpn-instance VPRN_SERVICE
 ipv4-family
  route-distinguisher 65000:100
  vpn-target 65000:100 both
  quit
 quit
interface GigabitEthernet0/0/0
 ip binding vpn-instance VPRN_SERVICE
 ip address 172.16.10.1 24
 quit
ip route-static vpn-instance VPRN_SERVICE 10.100.1.1 32 172.16.10.2
return

• ip vpn-instance VPRN_SERVICE: Müşteriye özel ayrı routing tablosunu (VRF) oluşturur.
• route-distinguisher 65000:100: Bu VRF’in rotalarını BGP’de benzersiz yapar.
• vpn-target 65000:100 both: both hem export hem import demek. İki PE’de aynı RT olduğu için birbirinin rotalarını alırlar.
• ip binding vpn-instance: Müşteriye bakan arayüzü o VRF’e bağlar. Bağlama IP’yi siler, bu yüzden IP’den önce yazılır.
• ip route-static vpn-instance ...: PE’nin VRF’ine “CE1’in loopback’ine şu next-hop’tan gidilir” der.

R4 (PE2) aynı mantık, kendi CE’sine bakan arayüz ve rota farklı: 172.16.20.1/24 ve 10.200.2.1/32 → 172.16.20.2.

CE’lerde VPN instance yok. R5 ve R6 normal birer router: arayüze IP, bir loopback, bir de PE’ye giden varsayılan rota:

interface GigabitEthernet0/0/0
 ip address 172.16.10.2 24
 quit
interface LoopBack1
 ip address 10.100.1.1 32
 quit
ip route-static 0.0.0.0 0 172.16.10.1

Müşteri VPN’in varlığından haberdar bile değil, bildiği tek şey “dışarısı = PE”.

Adım 4: PE’ler arasında MP-BGP

P router’larına (R2, R3) hiç BGP yazmıyorum. Sadece iki PE:

R1:

bgp 65000
 router-id 1.1.1.1
 peer 4.4.4.4 as-number 65000
 peer 4.4.4.4 connect-interface LoopBack0
 ipv4-family unicast
  undo peer 4.4.4.4 enable
  quit
 ipv4-family vpnv4
  peer 4.4.4.4 enable
  quit
 ipv4-family vpn-instance VPRN_SERVICE
  import-route static
  quit
 quit

R4 aynısı, komşu 1.1.1.1.

• peer 4.4.4.4 as-number 65000: Aynı AS, yani iBGP.
• connect-interface LoopBack0: Oturum loopback’ten kurulur, fiziksel link düşse de OSPF başka yol bulursa oturum yaşar.
• undo peer ... enable (unicast): Normal IPv4 rota alışverişini kapatıyorum, bu komşuluk sadece VPN için.
• ipv4-family vpnv4 + peer ... enable: VPN rotalarını (RD + RT + etiket) taşıyan adres ailesi.
• ipv4-family vpn-instance + import-route static: VRF’teki statik rotayı BGP’ye alır, karşı PE böylece öğrenir.

Adım 5: Doğrulama

BGP oturumu (R4):

<R4>display bgp vpnv4 all peer

 BGP local router ID : 4.4.4.4
 Local AS number : 65000
 Total number of peers : 1		  Peers in established state : 1

  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
  1.1.1.1         4       65000        3        3     0 00:00:38 Established       2

VPN rotaları:

<R4>display ip routing-table vpn-instance VPRN_SERVICE
Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

     10.100.1.1/32  IBGP    255  0          RD   1.1.1.1         GigabitEthernet0/0/0
     10.200.2.1/32  Static  60   0          RD   172.16.20.2     GigabitEthernet0/0/1
    172.16.20.0/24  Direct  0    0           D   172.16.20.1     GigabitEthernet0/0/1

10.100.1.1/32, R4’ün VRF tablosuna IBGP olarak gelmiş ve next-hop R1’in loopback’i (1.1.1.1). RD flag’i rotanın next-hop’a recursive ulaştığını gösteriyor, yani 1.1.1.1’e giden LDP LSP üzerinden. Çıkış arayüzü R3’e bakan omurga portu (GigabitEthernet0/0/0). Müşteri trafiği yola etiketle çıkıyor.

Asıl test: CE1’den CE2’nin loopback’ine, kaynak olarak kendi loopback’imi vererek:

<R5>ping -a 10.100.1.1 10.200.2.1
  PING 10.200.2.1: 56  data bytes, press CTRL_C to break
    Reply from 10.200.2.1: bytes=56 Sequence=1 ttl=251 time=40 ms
    Reply from 10.200.2.1: bytes=56 Sequence=2 ttl=251 time=50 ms
    Reply from 10.200.2.1: bytes=56 Sequence=3 ttl=251 time=60 ms
    Reply from 10.200.2.1: bytes=56 Sequence=4 ttl=251 time=50 ms
    Reply from 10.200.2.1: bytes=56 Sequence=5 ttl=251 time=50 ms

  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss

-a önemli: kaynak adres loopback olsun ki R6’nın dönüş rotası (10.100.1.1) VPN’den geçsin.

<R5>tracert -a 10.100.1.1 10.200.2.1
 1 172.16.10.1 20 ms  1 ms  20 ms
 2 10.1.12.2 30 ms  40 ms  40 ms
 3 10.1.23.3 40 ms  40 ms  30 ms
 4 172.16.20.1 40 ms  30 ms  40 ms
 5 172.16.20.2 40 ms  40 ms  50 ms

Yol: R5 → R1 (PE1) → R2 (P) → R3 (P) → R4 (PE2) → R6. Burada ilginç bir şey var: müşteri tarafından yapılan tracert’te omurgadaki P router’ların adresleri görünüyor (10.1.12.2, 10.1.23.3). MPLS’te TTL varsayılan olarak etikete kopyalanır, bu yüzden P router’lar TTL dolunca ICMP cevabı verir. Operatörler genelde müşteriye omurgayı göstermek istemez, bunu undo ttl-propagate ile kapatırlar ve tracert tek atlamada görünür. Bu laboratuvarda kapatmadım, yolu görmek işime yaradı.

Son olarak VPRN’in asıl iddiasını doğruluyorum: P router müşteri rotalarını görmüyor. R2’nin global routing tablosu:

<R2>display ip routing-table
Routing Tables: Public
         Destinations : 15       Routes : 15

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

        1.1.1.1/32  OSPF    10   1           D   10.1.12.1       GigabitEthernet0/0/0
        2.2.2.2/32  Direct  0    0           D   127.0.0.1       LoopBack0
        3.3.3.3/32  OSPF    10   1           D   10.1.23.3       GigabitEthernet0/0/1
        4.4.4.4/32  OSPF    10   2           D   10.1.23.3       GigabitEthernet0/0/1
      10.1.12.0/24  Direct  0    0           D   10.1.12.2       GigabitEthernet0/0/0
      10.1.23.0/24  Direct  0    0           D   10.1.23.2       GigabitEthernet0/0/1
      10.1.34.0/24  OSPF    10   2           D   10.1.23.3       GigabitEthernet0/0/1
      (127.x ve diğer Direct satırları kısaltıldı)

Tabloda sadece omurga var: loopback’ler ve P’nin kendi linkleri. 10.100.1.1 ve 10.200.2.1 yok, 172.16.x.x yok. Üstelik R2 BGP de çalıştırmıyor. Yani CE1’den CE2’ye giden paket R2’den geçti (tracert’te gördük), ama R2 bunu IP’ye bakarak değil, sadece üstteki LDP etiketine bakarak yönlendirdi. Müşteri rotaları PE’lerin VRF tablosunda ve MP-BGP içinde yaşıyor. Bu, VPRN’in P router’ı müşteriden izole etme garantisi.

4. Nerede takıldım

1. Arayüzde IP yoktu, ping gitmedi. ping -vpn-instance VPRN_SERVICE 172.16.10.2 %100 kayıpla düştü. IP’ye baktığımı düşünüyordum ama display interface GigabitEthernet0/0/0 çıktısında şu iki satır her şeyi anlattı:

Line protocol current state : DOWN
Internet protocol processing : disabled

Internet protocol processing : disabled, arayüzde IP adresi yok demek. Fiziksel olarak UP ama IP olmadığı için protokol DOWN. Sebep: ip binding vpn-instance komutu arayüzdeki IP’yi siliyor. Sıra bağlamak, sonra IP yazmak olmalı.

2. undo ospf 1 çalışmadı. Omurgayı yeniden kurarken her router’a undo ospf 1 ile başlayan bir blok yapıştırdım. Huawei bu komutta “Continue? [Y/N]” diye onay soruyor ve yapıştırdığım bir sonraki satır (interface ...) bu soruya cevap oldu, silme iptal edildi. Sonuç: eski network satırları yeni olanların altında kaldı ve loopback’ler yanlış area’da durdu. ospf 1 içeriğine display current-configuration configuration ospf ile bakınca fark ettim. Çözüm: undo ospf 1 komutunu tek başına yazıp y demek, sonra bloğu yapıştırmak.

3. Loopback’e ping gitmedi. Router-id’yi elle verdim, loopback arayüzü ise tanımlı değildi. Router-id sadece OSPF’in kendine verdiği bir isim, ping atılabilecek bir adres değil. Loopback’e IP ve network x.x.x.x 0.0.0.0 satırı gerekiyor.

4. CE’lere de VPN instance yazmak. Bir an CE’lerde de ip binding gerekir sandım. Gerekmiyor: VRF, PE’nin birden fazla müşteriye ayrı tablo tutma aracı. Müşterinin kendi router’ı düz bir router, tek müşterisi olduğu için ayrı tabloya ihtiyacı yok.

5. Özet

• Omurgada OSPF loopback’leri ulaşılabilir yapar, LDP her loopback için etiket üretir.
• PE’lerde VPN instance müşteriye ayrı tablo verir, RD rotayı benzersiz, RT rotayı doğru VRF’e yönlendirir.
• PE’ler arasında MP-BGP (VPNv4) müşteri rotalarını taşır, P router’lar bu işe hiç karışmaz.
• Müşteri paketi PE1’de iki etiket alır: dış etiket (LDP, karşı PE’ye yol), iç etiket (BGP, hangi VRF).
• Nokia ile Huawei aynı işi yapıyor. Fark çoğunlukla sözdiziminde: Nokia’da servis tek vprn bloğunda, Huawei’de VRF ve arayüz bağlama ayrı komutlar. Transport tüneli Nokia’da açıkça seçiliyor (auto-bind-tunnel), Huawei’de LDP LSP varsayılan.