OMP Yedekleme Yolları

[Nizam-ı Alem]

ROHAN2 WORLD 1-120 TR TİPİ OFFICIAL YOHARA, BALATHOR VE AMON! 80. GÜNÜNDE! +10.000 ONLİNE! HİLE VE BOT %100 ENGELLİ HEMEN TIKLA!

Merhaba Değerli forum arkadaşlarım bu konumda OMP Yedekleme yollarını inceleyeceğiz.

Çift ana bilgisayara sahip, çift taşımalı bir sitenin farklı kaynak metrikleri veya kaynak türleri içeren rotalar yayınladığı senaryolarda ortaya çıkan yaygın bir sorunu inceleyeceğiz. Site genellikle, ortamda BGP veya OSPF gibi yerel bir IGP'nin çalıştığı bir veri merkezi veya bölgesel bir merkez olacaktır. Overlay Management Protocol (OMP) en iyi yol seçiminin, yedek yollar mevcut olsa bile, bir bağlantı arızası durumunda uzak bir siteye erişimin tamamen kaybolmasına nasıl neden olduğunu göreceğiz.
OMP Send-Backup-Paths nedir?
Varsayılan olarak, bir Cisco vSmart denetleyicisi aynı hedefe birden fazla OMP rotası aldığında, bunları OMP en iyi yol algoritmasından geçirir ve hedef alt ağa en iyi olanları seçer. Ardından vSmart denetleyicisi, yalnızca en iyi rotaları kaplama yapısının geri kalanına duyurur. Bu davranış, ağ mühendisleri tarafından oldukça iyi bilinir. BGP rota yansıtıcıları, rota yansıtıcı istemcilerine rotaları alırken ve yeniden duyururken hemen hemen aynı şekilde çalışır.
Cisco SD-WAN çözümü, vSmart denetleyicisine en iyi olmayan rotaların ilk kümesini vEdge yönlendiricilerine duyurmasını söyleyen bir yapılandırma seçeneği sunar. Yapılandırma, aşağıdaki çıktıda gösterildiği gibi denetleyiciye bir yapılandırma satırı eklemek kadar basittir.

vSmart# config
Entering configuration mode terminal
vSmart(config)# omp send-backup-paths
vSmart(config-omp)# commit
Commit complete.
vSmart#

Burada dikkat edilmesi gereken en önemli nokta, "en iyi olmayan ilk rota kümesi"nin ne anlama geldiğidir. Diyelim ki bir hedefe giden iki eşit maliyetli en iyi rota var ve bunlara "routes-X" adını veriyoruz. Diyelim ki aynı hedefe giden iki eşit maliyetli en iyi olmayan rota daha var ve bunlara "routes-Y" adını verelim. Varsayılan olarak, vSmart yalnızca routes-X'i duyurur. "omp send-backup-path" seçeneğini etkinleştirdiğimizde, denetleyici routes-X ile birlikte routes-Y'yi de duyurur. Ancak, routes-Y'den daha kötü başka rotalar varsa, bunlar vSmart denetleyicisi tarafından gönderilmez, çünkü yalnızca ilk en iyi olmayan rota kümesi duyurulur!
OMP Send-Backup-Paths ne zaman kullanılır?
Şimdi vSmart denetleyicisinin en iyi olmayan yolları göndermesini sağlamak istediğimiz gerçek dünya örneğini görelim
Başlangıç durumu
Üç WAN uç yönlendiricimiz var - vEdges 1, 2 ve 3. Yönlendiriciler 1 ve 2, site kimliği 1 olan bir veri merkezinde yer almaktadır. Yönlendirici 3, site kimliği 3 olan uzak bir şubede yer almaktadır. Bu laboratuvar örneğinin başlangıç durumu aşağıdaki görselde görünmektedir.

Yönlendiricilerin aşağıdaki taşıma aparatları vardır:

• vEdge-1'in iki TLOC'si var - mpls rengiyle işaretlenmiş T11 ve biz-internet rengiyle işaretlenmiş T12.
• vEdge-2'nin ayrıca iki TLOC'si var - mpls rengiyle işaretlenmiş T21 ve biz-internet rengiyle işaretlenmiş T22.
• vEdge-3'ün sadece bir TLOC'si var - T31 mpls rengiyle işaretlenmiş.

OSPF, veri merkezinde vEdges 1 ve 2 ile yerel ağ cihazları arasında çalışır. Veri merkezindeki yerel yönlendirici, VPN10'daki vEdges 1 ve 2'ye 10.1.1.0/24 alt ağını duyurur:

• vEdge-1, 10.1.1.0/24'ü 50 metriğiyle OSPF üzerinden alır ve bunu origin-metric 50 ile OMP'ye yeniden dağıtır
• vEdge-2, 90 metriğiyle OSPF üzerinden 10.1.1.0/24'ü alır ve bunu 90 orijin metriğiyle OMP'ye yeniden dağıtır

Yukarıdaki şekilde gösterildiği gibi, vSmart denetleyicisi 10.1.1.0/24 için dört OMP rotası alır. OMP en iyi yol algoritmasını çalıştırır ve vEdge-1 üzerinden gelenleri, vEdge-2 üzerinden gelen yönlendiriciden (metrik 90) daha düşük kaynak metriği 50'ye sahip oldukları için en iyi rotalar olarak seçer.

vSmart# show omp routes vpn 10 10.1.1.0/24 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                 PATH                      ATTRIBUTE                                                     
FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
-----------------------------------------------------------------------------------------------------------
1.1.1.1          66     1009     C,R       installed  1.1.1.1          mpls             ipsec  -         
1.1.1.1          68     1009     C,R       installed  1.1.1.1          biz-internet     ipsec  -         
1.1.1.2          66     1016     R         installed  1.1.1.2          mpls             ipsec  -         
1.1.1.2          68     1016     R         installed  1.1.1.2          biz-internet     ipsec  -

Daha sonra, vSmart denetleyicisi vEdge-3'e yalnızca en iyi rotaları - T11 üzerinden 10.1.1.0/24 ve T12 üzerinden 10.1.1.0/24 - duyurur. Bu nedenle, vEdge-3, 10.1.1.0/24 alt ağının vEdge-2 üzerinden de erişilebilir olduğunu bile bilmez!

Ayrıca, vEdge-3, vEdge-1'in iş-internet TLOC'sine bir üst katman tüneli olmadığı için T12 üzerinden 10.1.1.0/24 rotasını Geçersiz olarak işaretler.

vEdge-3# sh omp route vpn 10 10.1.1.0/24 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                 PATH                      ATTRIBUTE                                                     
FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
-----------------------------------------------------------------------------------------------------------
1.1.1.30         87     1009     C,I,R     installed  1.1.1.1          mpls             ipsec  -         
1.1.1.30         88     1009     Inv,U     installed  1.1.1.1          biz-internet     ipsec  -

Sonuç olarak, vEdge-3'ün vEdge-1'in mpls arayüzü üzerinden 10.1.1.0/24 alt ağına ulaşmak için yalnızca bir geçerli yolu vardır; oysa alt ağa vEdge2'nin mpls arayüzü üzerinden ulaşılabilir!

vEdge-3# sh ip route vpn 10 10.1.1.0/24 | t

     ADDRESS               PATH            PROTOCOL          NEXTHOP  NEXTHOP                         NEXTHOP       
VPN  FAMILY   PREFIX       ID    PROTOCOL  SUB TYPE  METRIC  IFNAME   ADDR     TLOC IP  COLOR  ENCAP  VPN      STATUS
-----------------------------------------------------------------------------------------------------------------------
10   ipv4     10.1.1.0/24  0     omp       -         0       -        -        1.1.1.1  mpls   ipsec  -        F,S

Ancak ortamın normal durumunda uzak site ile veri merkezi ağı arasında IP ulaşılabilirliği mevcuttur.

vEdge-3# ping vpn 10 10.1.1.1
Ping in VPN 10
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=254 time=46.7 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=254 time=61.9 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=254 time=41.7 ms
^C
--- 10.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 41.730/50.150/61.944/8.593 ms

Sorun
Aşağıdaki Şekil 2'de gösterildiği gibi, vEdge-1 üzerindeki mpls TLOC'yi kapatarak bir arıza oluşturduğumuzda ne olacağını görelim.

vEdge-1, mpls arayüzü kapalı olduğu için artık T11 üzerinden 10.1.1.0/24 OMP rotasını duyurmuyor. Sonuç olarak, vSmart denetleyicisinin vEdge-1 üzerinden 10.1.1.0/24'e yalnızca bir rotası var. Ancak, OMP en iyi yol algoritması, vEdge-2 üzerinden olanlardan (90) daha düşük bir başlangıç metriğine (50) sahip olduğu için bu rotayı yine de en iyi rota olarak seçiyor. Sonuç olarak, vEdge-3 yalnızca T12 üzerinden 10.1.1.0/24'e giden OMP rotasını (vEdge-1'in iş-internet TLOC'si) alır. Ancak vEdge-3'ün herhangi bir uzak iş-internet TLOC'sine bir üst katman tüneli yoktur. Bu nedenle, vEdge-1'in iş-internet TLOC'si üzerinden 10.1.1.0/24 rotası Geçersiz ve Çözümlenmemiş olarak işaretlenir.

vEdge-3# show omp route vpn 10 10.1.1.0/24 | t 
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                 PATH                      ATTRIBUTE                                                     
FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
-----------------------------------------------------------------------------------------------------------
1.1.1.30         94     1009     Inv,U     installed  1.1.1.1          biz-internet     ipsec  -

vEdge-3, vEdge-2'ye bir üst katman tüneli ve UP durumunda bir BFD oturumu sunmasına rağmen, vEdge-2 üzerinden 10.1.1.0/24 alt ağına ulaşılabileceğini bilmiyor! 10.1.1.1'e ping atarsak, vEdge-3'ün veri merkezinin ağına olan bağlantısının tamamen kesildiğini göreceğiz.

vEdge-3# ping vpn 10 10.1.1.1
Ping in VPN 10
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
From 127.1.0.2 icmp_seq=1 Destination Net Unreachable
From 127.1.0.2 icmp_seq=2 Destination Net Unreachable
From 127.1.0.2 icmp_seq=3 Destination Net Unreachable
^C
--- 10.1.1.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Çözüm
Bu soruna en etkili çözümlerden biri, vSmart denetleyicisine en iyi olmayan ilk rota kümesini de duyurmasını söylemektir. Örneğimizde bunlar, vEdge-2 üzerinden geçen rotalar olacaktır.

Özelliğin yapılandırılması, aşağıdaki çıktıda gösterildiği gibi vSmart denetleyicisine omp send-backup-paths yapılandırma satırını uygulamak kadar basittir:

vSmart# conf t
Entering configuration mode terminal
vSmart(config)# omp ?               
Possible completions:
  controller-send-path-limit   Limit number of paths sent to vSmart controller
                               for a prefix
  discard-rejected             Enable/Disable storage of information rejected
                               by policy
  graceful-restart             Enable/Disable graceful restart
  send-backup-paths            Enable/Disable transmission of backup paths
  send-path-limit              Maximum number of paths sent for a prefix
  shutdown                     Enable/disable OMP
  timers                       Set timers
  <cr>                       
vSmart(config)# omp send-backup-paths
vSmart(config-omp)# commit and-quit
Commit complete.

Send-backup-paths seçeneğini yapılandırdıktan sonra, denetleyicinin artık vEdge-1 üzerinden en iyi rotaların yanı sıra vEdge-2 üzerinden rotaları da duyurduğunu görebiliriz. Şimdi vEdge-3 üzerindeki omp yönlendirme tablosunu kontrol edersek, vEdge-2'nin mpls TLOC'si aracılığıyla 10.1.1.0/24 adresine geçerli bir rota olduğunu göreceğiz.

vEdge-3# show omp route vpn 10 10.1.1.0/24 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                 PATH                      ATTRIBUTE                                                     
FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
-----------------------------------------------------------------------------------------------------------
1.1.1.30         94     1009     Inv,U     installed  1.1.1.1          biz-internet     ipsec  -         
1.1.1.30         106    1016     C,I,R     installed  1.1.1.2          mpls             ipsec  -         
1.1.1.30         107    1016     Inv,U     installed  1.1.1.2          biz-internet     ipsec  -

Artık uzak lokasyon ile veri merkezi arasında IP ulaşılabilirliği var.

vEdge-3# ping vpn 10 10.1.1.1
Ping in VPN 10
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=254 time=57.6 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=254 time=48.9 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=254 time=47.1 ms
^C
--- 10.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 47.182/51.229/57.600/4.563 ms

Ve nihai test, vEdge-3'ten veri merkezi ağına bir traceroute kullanarak gerçek veri yolunu kontrol etmektir. Veri merkezine vEdge-2 üzerinden giren trafiği görebilirsiniz.

vEdge-3# traceroute vpn 10 10.1.1.1
VPN 10'da 10.1.1.1'i izleyin
10.1.1.1'e (10.1.1.1) izleme, maksimum 30 atlama, 60 bayt paketler
1 10.10.1.5 (10.10.1.5) 31,16 ms 41,46 ms 41,46 ms --> vEdge-2
2 10.10.1.6 (10.10.1.6) 42,91 ms * * --> Yerel site yönlendiricisi

Temel Çıkarımlar

• vSmart, yalnızca OMP en iyi yol algoritmasına göre bir hedefe giden en iyi rotaları duyurur.
• vSmart'ın varsayılan davranışı, bir BGP rota yansıtıcısına benzer şekilde, erişilebilirlik bilgilerini uzak eşlerden gizler.
• TLOC'ler arasında tam IP erişilebilirliğinin olmadığı ve sınırlı örtüşmeye sahip uzak sitelerin bulunduğu senaryolarda, bu durum arıza senaryolarında kara delikler yaratabilir.
• OMP geri gönderme yolları seçeneği, vSmart denetleyicisine en iyi olanların yanında en iyi olmayan yolların ilk kümesini duyurmasını söyler.
• Reklamı yapılan rotaların toplam sayısının OMP send-path-limit parametresine tabi olduğunu unutmayın.

 

[Lightning]

Eline sağlık