MPLS vpnv4 a loopback

Problemy z pozostałymi technologiami (SDH, IronPort, WAAS itp.)
Wiadomość
Autor
lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

MPLS vpnv4 a loopback

#1

#1 Post autor: lukaszbw »

Witam,

Straciłem pare godzin nad dziwactwem i nie wiem czy to błąd IOS czy coś źle robie. Ogólnie problem był w tym, że router P czyścił mi wszystkie labels dla ruchu wychodzącego do PE.

Kod: Zaznacz cały

show mpls forwarding-table 
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
16     16            150.1.3.3/32      2412          Fa1/0      150.1.12.1  
17     No Label      150.1.4.4/32      1704          Se2/0.1    point2point 
18     Pop Label     150.1.13.0/24     1620          Fa1/0      150.1.12.1  
Jak widać ruch do 150.1.4.4/32 przy outgoing jest no label zamiast pop label. Oczywiście router usuwał label vpnv4 co powodowało blokowanie ruchu. 150.1.4.4 to interface loopback na zdalnym routerze. Po 3 godzinach chyba robienia wszystkiego co się da włącznie z restartowaniem routerów okazało się że winą była maska na loopback. Otóż adres był 150.1.4.4/24, po zmianie na 150.1.4.4/32 mamy :

Kod: Zaznacz cały

show mpls forwarding-table 
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    
Label  Label or VC   or Tunnel Id      Switched      interface              
16     16            150.1.3.3/32      5933          Fa1/0      150.1.12.1  
17     Pop Label     150.1.4.4/32      1411          Se2/0.1    point2point 
18     Pop Label     150.1.13.0/24     2439          Fa1/0      150.1.12.1  
Teraz jest dobrze. Nie rozumiem tylko dlaczego maska w loopback musi być /32 ? Zastanawia mnie czy to błąd IOS czy gdzieś w RFC jest ukryte, że sesje BGP i MPLS w przypadku vpnv4 muszą być robione z loopback posiadający maske /32. OSPF działający wewnątrz P i tak rozgłasza loopback z /32 niezależnie jaka jest maska na interface.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2349
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: MPLS vpnv4 a loopback

#2

#2 Post autor: gangrena »

lukaszbw pisze:Teraz jest dobrze. Nie rozumiem tylko dlaczego maska w loopback musi być /32 ? Zastanawia mnie czy to błąd IOS czy gdzieś w RFC jest ukryte, że sesje BGP i MPLS w przypadku vpnv4 muszą być robione z loopback posiadający maske /32. OSPF działający wewnątrz P i tak rozgłasza loopback z /32 niezależnie jaka jest maska na interface.
Mechanizm, który opisałeś zgadza się z tym, jak działa OSPF. Rozgłasza on bowiem zawsze adresy należące do interfejsu Loopback z maską /32 i z taką maską pojawia się adres u sąsiada w bazie OSPF. Tymczasem LDP rozgłasza ten sam adres z maską rzeczywistą. Prowadzi to do tego, że nie ma routingu do rzeczywistego prefiksu Loopbacka, gdyż prefiks uzyskany od OSPF jest bardziej szczegółowy (maska /32), niż rozgłoszony przez LDP (np. maska /24). W takim wypadku etykieta nie zostaje przypisana do prefiksu. Jest kilka rozwiązań tej kwestii:

1. Zastosować maskę /32 na interfejsie Loopback.
2. Dodać "ip ospf network point-to-point" na interfejsie Loopback.
3. Dodać static route u sąsiada z rzeczywistą maską odpowiadającą interfejsowi Loopback np. z maską /24.
4. Użyć ISIS zamiast OSPF :)

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#3

#3 Post autor: lukaszbw »

Ok dzięki. W LFIB był wpis z maską /32 więc myślałem, że wszystko jest ok poza faktem, że pisał na outgoing "No label". Sądziłem, że problem jest z PHP. Tak czy inaczej loopback powinien mieć maske /32 tylko jakoś takie przyzwyczajenie z CCIE R&S mnie trzyma gdzie na ogół był z maską /24 i nie było problemów.

Tak BTW bo nie chce mi się teraz tego sprawdzać przy większych prędkościach. Czy stosowanie loopback jako next-hop na platformach sprzętowych takich jak 6500 czy distributed jak GSR/CRS-1 nie powoduje problemów z wrzucaniem ("punt") ruchu do RP? Pewnie nie ale wole się spytać zanim zaczne stosować to w poważnej konfiguracji. Normalnie robiąc BGP zawsze next-hop używam adres ip interface między peerami a loopback co najwyżej jako router-id.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2349
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

#4

#4 Post autor: gangrena »

lukaszbw pisze:Ok dzięki. W LFIB był wpis z maską /32 więc myślałem, że wszystko jest ok poza faktem, że pisał na outgoing "No label". Sądziłem, że problem jest z PHP. Tak czy inaczej loopback powinien mieć maske /32 tylko jakoś takie przyzwyczajenie z CCIE R&S mnie trzyma gdzie na ogół był z maską /24 i nie było problemów.
Informacja w LFIB jest już pochodną tego, co router ma w RIB oraz LIB. Stąd sprawdzenie LIB poprzez "sh mpls ldp bindings" jest również pomocne. W Twoim przypadku w LIB przy problematycznym prefiksie będzie "no route".
lukaszbw pisze:Tak BTW bo nie chce mi się teraz tego sprawdzać przy większych prędkościach. Czy stosowanie loopback jako next-hop na platformach sprzętowych takich jak 6500 czy distributed jak GSR/CRS-1 nie powoduje problemów z wrzucaniem ("punt") ruchu do RP? Pewnie nie ale wole się spytać zanim zaczne stosować to w poważnej konfiguracji. Normalnie robiąc BGP zawsze next-hop używam adres ip interface między peerami a loopback co najwyżej jako router-id.
Nie zauważyłem jakichś niepokojących objawów na 7600/12k/CRS-1. W sieciach MPLS/VPN rozgłaszanie loopbacków jest powszechne. Sesje MP-iBGP rozpina się praktycznie jedynie pomiędzy adresami Loopback.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#5

#5 Post autor: lbromirs »

lukaszbw pisze:Tak BTW bo nie chce mi się teraz tego sprawdzać przy większych prędkościach. Czy stosowanie loopback jako next-hop na platformach sprzętowych takich jak 6500 czy distributed jak GSR/CRS-1 nie powoduje problemów z wrzucaniem ("punt") ruchu do RP?
Co ma piernik do wiatraka?

CEF rozwiązuje adres na adres lub etykietę wynikową od razu. 'sh ip cef prefix' pokazuje next-hop IP ale również interfejs/etykietę. Adres loopback w tym sensie nie ma żadnego związku z przekazywaniem ruchu a zatem to czy robimy CEF czy dCEF nie ma żadnego znaczenia.

ODPOWIEDZ