Difference between revisions of "Cisco MPLS"
Helikopter (talk | contribs) |
Helikopter (talk | contribs) |
||
Line 23: | Line 23: | ||
För att veta vilka labels en LSR ska sätta på paketen som ska skickas iväg används Label Distribution Protocol (TDP är legacy). Routrar bygger LDP-grannskap och utbyter sedan dynamiskt labels med varandra för att kunna bygga korrekta forwarding tables. Det fungerar ungefär som ett routingprotokoll. För unicast IP routing så utbyts en label per prefix i routingtabellen, Cisco IOS använder independent label distribution control. Dyker det upp något nytt i routingtabellen skapas en ny lokal label i LIB och sedan annonseras det till alla LDP-grannarna. På så sätt kan en label-switched path (LSP) byggas. Dessa är enkelriktade och en enskild LSR känner inte till hela pathen för det behövs inte. En label går aldrig längre än till grannen utan där poppas eller byts den mot nästa routers label. MPLS låter routingtabellen och IGP stå för path selection och därmed loop-prevention och convergence. | För att veta vilka labels en LSR ska sätta på paketen som ska skickas iväg används Label Distribution Protocol (TDP är legacy). Routrar bygger LDP-grannskap och utbyter sedan dynamiskt labels med varandra för att kunna bygga korrekta forwarding tables. Det fungerar ungefär som ett routingprotokoll. För unicast IP routing så utbyts en label per prefix i routingtabellen, Cisco IOS använder independent label distribution control. Dyker det upp något nytt i routingtabellen skapas en ny lokal label i LIB och sedan annonseras det till alla LDP-grannarna. På så sätt kan en label-switched path (LSP) byggas. Dessa är enkelriktade och en enskild LSR känner inte till hela pathen för det behövs inte. En label går aldrig längre än till grannen utan där poppas eller byts den mot nästa routers label. MPLS låter routingtabellen och IGP stå för path selection och därmed loop-prevention och convergence. | ||
− | MPLS-nätet måste använda något routingprotokoll för att lära sig routes och dra nytta av label-annonsering, vanligtvis används ett IGP för detta. När en ny lokal label skapas, pga nylärd route från IGP, annonseras det till alla LDP-grannarna (även den man fick route-uppdateringen ifrån, frame-mode MPLS har inte hört talas om split horizon :). Detta händer för alla routes på alla LSR. Router-ID väljs på exakt samma sätt som för [[Cisco_OSPF#Router_ID|OSPF]]. Om man har en LSR med LDP-grannskap till säg 5 andra enheter så kommer alla grannskap gå ner om man stänger ett av sina 5 interface eftersom LDP skapar | + | MPLS-nätet måste använda något routingprotokoll för att lära sig routes och dra nytta av label-annonsering, vanligtvis används ett IGP för detta. När en ny lokal label skapas, pga nylärd route från IGP, annonseras det till alla LDP-grannarna (även den man fick route-uppdateringen ifrån, frame-mode MPLS har inte hört talas om split horizon :). Detta händer för alla routes på alla LSR. Router-ID väljs på exakt samma sätt som för [[Cisco_OSPF#Router_ID|OSPF]]. Om man har en LSR med LDP-grannskap till säg 5 andra enheter så kommer alla grannskap gå ner om man stänger ett av sina 5 interface eftersom LDP skapar sitt ID utifrån tillgängliga IGP interface. Det ändras om ett interface försvinner vilket det gör om man t.ex. shutar ett av dem. Hold time ska kommas överens om och är default 15 sekunder (3x Hello). Om två LSR inte kommer överens om timers, label distribution method etc kan man öka intevallet mellan försöken med ''mpls ldp backoff''-kommandot. T.ex. från 5 sekunder till att börja med till 120 sekunder mellan varje försök. |
'''Packets:''' 2, Hellos var 5:e sekund (UDP), Updates (TCP) | '''Packets:''' 2, Hellos var 5:e sekund (UDP), Updates (TCP) | ||
Line 35: | Line 35: | ||
mpls ldp router-id loopback0 [force] | mpls ldp router-id loopback0 [force] | ||
show mpls ldp parameters | show mpls ldp parameters | ||
+ | |||
Man kan per interface slå på MPLS, höja MTU för att stödja MPLS-headers och ändra vilken adress som ldp ska bygga grannskap med. Om man har flera länkar till samma LSR och ska sätta upp flera parallella LDP-sessioner måste man använda samma transport address på alla interface. | Man kan per interface slå på MPLS, höja MTU för att stödja MPLS-headers och ändra vilken adress som ldp ska bygga grannskap med. Om man har flera länkar till samma LSR och ska sätta upp flera parallella LDP-sessioner måste man använda samma transport address på alla interface. | ||
interface gi1/1 | interface gi1/1 | ||
Line 40: | Line 41: | ||
mpls mtu 1508 | mpls mtu 1508 | ||
mpls ldp discovery transport-address interface | mpls ldp discovery transport-address interface | ||
− | Range | + | Range, default är 16-1048575. |
mpls label range 200-299 | mpls label range 200-299 | ||
show mpls label range | show mpls label range | ||
Line 49: | Line 50: | ||
Verify | Verify | ||
show mpls interfaces [vrf NAME] | show mpls interfaces [vrf NAME] | ||
+ | show mpls ldp neighbor | ||
show mpls ldp discovery | show mpls ldp discovery | ||
− | |||
===Session Protection=== | ===Session Protection=== | ||
− | Om två directly connected LDP-grannar tappar kontakten flushas alla bindings från LIB. Men det behöver inte betyda att det inte fortfarande finns IP-reachability en annan väg. Session Protection är en optimerings-feature som gör att LIB inte flushas sålänge det finns en annan väg till LDP-peer | + | Om två directly connected LDP-grannar tappar kontakten flushas alla bindings från LIB. Men det behöver inte betyda att det inte fortfarande finns IP-reachability mellan dem en annan väg. Session Protection är en optimerings-feature som gör att LIB inte flushas sålänge det finns en annan väg till LDP-peer, targeted LDP sätts då upp för att hålla LIB synkat. När sedan directly connected grannskapet kommer tillbaka behöver ej allt synkas om. Detta måste konfigureras på båda sidor annars kommer inte andra sidan acceptera targeted hellos. Max hops är 255 och för Hello och Hold time gäller 10 sekunder respektive 90 sekunder default. |
mpls ldp session protection | mpls ldp session protection | ||
mpls ldp discovery targeted-hello accept | mpls ldp discovery targeted-hello accept | ||
+ | show mpls ldp neighbor detail | i Targeted|Session | ||
Både session protection och accept unicast hellos kan begränsas med ACL. | Både session protection och accept unicast hellos kan begränsas med ACL. | ||
Line 86: | Line 88: | ||
show mpls ldp igp sync | show mpls ldp igp sync | ||
show mpls interface detail | i Interface|IGP | show mpls interface detail | i Interface|IGP | ||
+ | |||
+ | ===Labels=== | ||
+ | Mode | ||
+ | mpls label mode all-vrfs protocol all-afs per-prefix #Default | ||
+ | mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf | ||
+ | |||
+ | Advertisments <br/> | ||
+ | Default annonseras labels för allt, detta går att ändra. | ||
+ | no mpls ldp advertise-label | ||
+ | mpls ldp advertise-lable for <dest prefix> to <ldp peer> | ||
+ | |||
+ | show mpls ldp discovery | ||
+ | 10.0.0.10:'''0''' | ||
+ | 0 betyder platform wide label space | ||
+ | 1 betyder interface label space | ||
=VPN= | =VPN= | ||
− | MPLS VPN (RFC 4364) är en populär MPLS-applikation. PHP är på default. För PE-PE label utbyten används [[Cisco_BGP#Multiprotocol_BGP|MP-BGP]]. För L2 VPN se [[Cisco_VPLS|VPLS]]. | + | MPLS VPN (RFC 4364) är en populär MPLS-applikation och räknas som trusted VPN. PHP är på default. För PE-PE label utbyten används [[Cisco_BGP#Multiprotocol_BGP|MP-BGP]]. För L2 VPN se [[Cisco_VPLS|VPLS]]. |
ip bgp-community new-format | ip bgp-community new-format | ||
show ip bgp community ? #''Så står det antingen aa:nn eller 1-4294967295'' | show ip bgp community ? #''Så står det antingen aa:nn eller 1-4294967295'' | ||
Line 106: | Line 123: | ||
router bgp 100 | router bgp 100 | ||
no bgp default route-target filter | no bgp default route-target filter | ||
+ | |||
+ | Man kan partitionera upp nätverket genom att skapa RR-grupper som filtrerar på route-targets. | ||
+ | address-family vpnv4 | ||
+ | bgp rr-group EXTCOM-LIST | ||
==Inter-AS MPLS VPN== | ==Inter-AS MPLS VPN== | ||
Line 120: | Line 141: | ||
Istället för att använda PEs för att hålla koll och distribuera VPN-routes bygger man grannskap mellan RRs i varje AS. Dock måste PE hålla koll på labeled routes till alla andra PE/RR i sitt AS och skicka med eBGP till andra sidan AS så deras PE/RR hittar till PE/RR i det egna AS. Då kan PE/RR i olika AS bygga eBGP multi-hop grannskap och utbyta labeled VPN-routes. Om P routrar får känna till PE i andra AS fungerar det som vanligt med dubbla labels. Men om det däremot inte är uppsatt så måste det trippel labelas. En för kundens IP till egress PE, en satt av ASBR för egress PE och en för IGP next-hop. Använder man RR är detta ett väldigt skalbart alternativ. | Istället för att använda PEs för att hålla koll och distribuera VPN-routes bygger man grannskap mellan RRs i varje AS. Dock måste PE hålla koll på labeled routes till alla andra PE/RR i sitt AS och skicka med eBGP till andra sidan AS så deras PE/RR hittar till PE/RR i det egna AS. Då kan PE/RR i olika AS bygga eBGP multi-hop grannskap och utbyta labeled VPN-routes. Om P routrar får känna till PE i andra AS fungerar det som vanligt med dubbla labels. Men om det däremot inte är uppsatt så måste det trippel labelas. En för kundens IP till egress PE, en satt av ASBR för egress PE och en för IGP next-hop. Använder man RR är detta ett väldigt skalbart alternativ. | ||
− | |||
− | |||
− | |||
=VRF Lite= | =VRF Lite= | ||
Line 131: | Line 149: | ||
vrf upgrade-cli multi-af-mode common-policies | vrf upgrade-cli multi-af-mode common-policies | ||
show vrf detail | i CLI | show vrf detail | i CLI | ||
+ | Kolla vilka interface som tillhör vilken vrf. | ||
+ | show ip vrf interfaces | ||
=ICMP= | =ICMP= |
Revision as of 12:06, 3 July 2016
Multiprotocol Label Switching (RFC 3031) är protokoll som routrar kan använda för att forwardera paket baserat på labels istället för destination IP address. Routrarna kallas då LSR, Label Switch Router. Genom att separera forwarding decision från destination IP address kan besluten baseras på andra faktorer såsom QoS eller Traffic Engineering. Det kan användas för vanlig unicast IP forwarding men också annat som t.ex. VPN-tjänster. En grupp av paket som skall till ett visst destinationsnät kommer vanligtvis att skickas samma väg genom nätverket. I MPLS grupperas dessa paket i klasser som kallas Forwarding Equivalence Class, FEC. En MPLS-header är 4 bytes och innehåller bl.a. ett 20-bitars fält som är den unika labeln. Bottom-of-stack bit, QoS marking och TTL finns också i headern. Olika protokoll kan användas för control plane, t.ex. LDP och MP-BGP.
MPLS på Cisco-enheter använder sig av CEF. MPLS går även att tunnla över IP (RFC 4023), se GRE.
Contents
Tables
För varje VRF skapas det nya tabeller, show cef table
RIB
show ip route show ip route vrf NAME
LIB, innehåller all labels known to LSR
show mpls ldp bindings show mpls ldp binding summary show mpls ldp bindings vrf NAME
FIB, används för paket utan label
show ip cef show ip cef vrf NAME
LFIB, används för paket med label
show mpls forwarding-table show mpls forwarding-table vrf NAME
LDP
För att veta vilka labels en LSR ska sätta på paketen som ska skickas iväg används Label Distribution Protocol (TDP är legacy). Routrar bygger LDP-grannskap och utbyter sedan dynamiskt labels med varandra för att kunna bygga korrekta forwarding tables. Det fungerar ungefär som ett routingprotokoll. För unicast IP routing så utbyts en label per prefix i routingtabellen, Cisco IOS använder independent label distribution control. Dyker det upp något nytt i routingtabellen skapas en ny lokal label i LIB och sedan annonseras det till alla LDP-grannarna. På så sätt kan en label-switched path (LSP) byggas. Dessa är enkelriktade och en enskild LSR känner inte till hela pathen för det behövs inte. En label går aldrig längre än till grannen utan där poppas eller byts den mot nästa routers label. MPLS låter routingtabellen och IGP stå för path selection och därmed loop-prevention och convergence.
MPLS-nätet måste använda något routingprotokoll för att lära sig routes och dra nytta av label-annonsering, vanligtvis används ett IGP för detta. När en ny lokal label skapas, pga nylärd route från IGP, annonseras det till alla LDP-grannarna (även den man fick route-uppdateringen ifrån, frame-mode MPLS har inte hört talas om split horizon :). Detta händer för alla routes på alla LSR. Router-ID väljs på exakt samma sätt som för OSPF. Om man har en LSR med LDP-grannskap till säg 5 andra enheter så kommer alla grannskap gå ner om man stänger ett av sina 5 interface eftersom LDP skapar sitt ID utifrån tillgängliga IGP interface. Det ändras om ett interface försvinner vilket det gör om man t.ex. shutar ett av dem. Hold time ska kommas överens om och är default 15 sekunder (3x Hello). Om två LSR inte kommer överens om timers, label distribution method etc kan man öka intevallet mellan försöken med mpls ldp backoff-kommandot. T.ex. från 5 sekunder till att börja med till 120 sekunder mellan varje försök.
Packets: 2, Hellos var 5:e sekund (UDP), Updates (TCP)
Destination: 224.0.0.2
Port: 646
Global
mpls label protocol ldp #Default mpls ldp router-id loopback0 [force] show mpls ldp parameters
Man kan per interface slå på MPLS, höja MTU för att stödja MPLS-headers och ändra vilken adress som ldp ska bygga grannskap med. Om man har flera länkar till samma LSR och ska sätta upp flera parallella LDP-sessioner måste man använda samma transport address på alla interface.
interface gi1/1 mpls ip mpls mtu 1508 mpls ldp discovery transport-address interface
Range, default är 16-1048575.
mpls label range 200-299 show mpls label range
Graceful
mpls ldp graceful-restart show mpls ldp graceful-restart
Verify
show mpls interfaces [vrf NAME] show mpls ldp neighbor show mpls ldp discovery
Session Protection
Om två directly connected LDP-grannar tappar kontakten flushas alla bindings från LIB. Men det behöver inte betyda att det inte fortfarande finns IP-reachability mellan dem en annan väg. Session Protection är en optimerings-feature som gör att LIB inte flushas sålänge det finns en annan väg till LDP-peer, targeted LDP sätts då upp för att hålla LIB synkat. När sedan directly connected grannskapet kommer tillbaka behöver ej allt synkas om. Detta måste konfigureras på båda sidor annars kommer inte andra sidan acceptera targeted hellos. Max hops är 255 och för Hello och Hold time gäller 10 sekunder respektive 90 sekunder default.
mpls ldp session protection mpls ldp discovery targeted-hello accept show mpls ldp neighbor detail | i Targeted|Session
Både session protection och accept unicast hellos kan begränsas med ACL.
Security
Med autentisering kan man säkra LDP-kommunikationen. ACL ska träffa LDP ID som andra sidan har och måste vara standard.
ip access-list standard LDP-PEERS permit host 10.0.0.5 permit host 10.0.0.6 mpls ldp password required for LDP-PEERS mpls ldp neighbor 10.0.0.5 password SECRET
Verify
show mpls ldp discovery detail | i Ethernet|Password
IGP
LDP går att autokonfa tillsammans med IS-IS och OSPF, dvs slå på LDP på de interface som är aktiva i IGPn, detta kan antingen göras per interface eller under routingprocessen.
router ospf/isis 1 mpls ldp autoconfig
Synchronization
Länkkostnaden för nyetablerade grannskap sätts till max tills LDP är klar med labelutbyte och berättar för link-state IGP att det är okej att använda länken.
Per interface
interface gi2 mpls ldp igp sync
Alternativt under IGP
router ospf/isis 1 mpls ldp sync
Verify
show mpls ldp igp sync show mpls interface detail | i Interface|IGP
Labels
Mode
mpls label mode all-vrfs protocol all-afs per-prefix #Default mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf
Advertisments
Default annonseras labels för allt, detta går att ändra.
no mpls ldp advertise-label mpls ldp advertise-lable for <dest prefix> to <ldp peer>
show mpls ldp discovery 10.0.0.10:0 0 betyder platform wide label space 1 betyder interface label space
VPN
MPLS VPN (RFC 4364) är en populär MPLS-applikation och räknas som trusted VPN. PHP är på default. För PE-PE label utbyten används MP-BGP. För L2 VPN se VPLS.
ip bgp-community new-format show ip bgp community ? #Så står det antingen aa:nn eller 1-4294967295
Route Distinguisher: är ett 64-bitars nummer som skickas med BGP-uppdateringarna och används för att göra routes unika mellan VRFer. Det används med adressfamiljerna vpnv4 och vpnv6.
Route Target: skickas med BGP-uppdateringarna som ett Extended Community PA. Det används för att bestämma vilken/vilka VRFer routsen ska in i.
Import och export bestämmer vad som ska redistribueras mellan VRF och BGP.
Add IBGP neighbor
router bgp 100 neighbor 10.0.0.10 remote-as 100 address-family vpnv4 unicast send-community extended
Default är att droppa VPNv4 updates för RTs som det inte finns någon lokal vrf för. Detta kan man ändra på.
router bgp 100 no bgp default route-target filter
Man kan partitionera upp nätverket genom att skapa RR-grupper som filtrerar på route-targets.
address-family vpnv4 bgp rr-group EXTCOM-LIST
Inter-AS MPLS VPN
Back to Back VRFs Option 10A
PE använder iBGP för att distribuera labeled VPN-routes inom sitt AS som vanligt. PE kommunicerar med andra sidan PE med ett sub-interface, länknät och eBGP-grannskap per VRF. Det krävs ingen MPLS mellan PE utan det är unlabeled IP-adresser som annonseras. Detta är dock inte den mest skalbara lösningen.
VPNv4 eBGP Option 10B
PE använder iBGP för att distribuera labeled VPN-routes inom sitt AS som vanligt. PE använder sedan eBGP för att distribuera labeled VPN-routes till PE i ett annat AS, som i sin tur distribuerar dem till PE routrar i sitt AS. Det kan finnas flera vägar mellan de olika AS för redundans och ökad kapacitet. Service Providers måste komma överens om detta. Detta är mer skalbart eftersom det räcker med ett BGP-grannskap per koppling mellan AS.
interface GigabitEthernet1/0 mpls bgp forwarding
VPNv4 between RRs Option 10C
(eller PEs using multihop eBGP)
Istället för att använda PEs för att hålla koll och distribuera VPN-routes bygger man grannskap mellan RRs i varje AS. Dock måste PE hålla koll på labeled routes till alla andra PE/RR i sitt AS och skicka med eBGP till andra sidan AS så deras PE/RR hittar till PE/RR i det egna AS. Då kan PE/RR i olika AS bygga eBGP multi-hop grannskap och utbyta labeled VPN-routes. Om P routrar får känna till PE i andra AS fungerar det som vanligt med dubbla labels. Men om det däremot inte är uppsatt så måste det trippel labelas. En för kundens IP till egress PE, en satt av ASBR för egress PE och en för IGP next-hop. Använder man RR är detta ett väldigt skalbart alternativ.
VRF Lite
VRF Lite är vrf:er utan mpls.
show ip vrf show cef vrf
Konfiguration
vrf upgrade-cli multi-af-mode common-policies show vrf detail | i CLI
Kolla vilka interface som tillhör vilken vrf.
show ip vrf interfaces
ICMP
När en E-LSR får in ett IP-paket sänker den IP TTL med ett och sedan pushar den en label och kopierar TTLen till MPLS-headern. När sedan paketet traverserar en LSR sänks endast MPLS-TTLen men vid egress E-LSR kopieras MPLS-TTLen till IP TTL och skickas vidare. Detta går att ändra på så att även MPLS-TTL sätts till 255 av ingress E-LSR för att hela MPLS-nätet verkligen ska vara som ett router hop.
no mpls ip propagate-ttl
Ping
ping mpls ipv4 10.1.1.1/32
Traceroute
traceroute mpls ipv4 10.1.1.1/32
NX-OS
Förutsättningar
install feature-set mpls feature-set mpls feature mpls l3vpn feature mpls ldp interface loopback 1 ip address 10.0.0.1/24 mpls ldp configuration session protection router-id loopback 1
Aktivera på interface
interface e1/1 mpls ip
Synk med routing protokoll
router isis P1 mpls ldp sync
Authentication
ip prefix-list <namn> permit <granne1>/32 mpls ldp configuration password required for <prefix-list> password option 1 for <prefix-list> key-chain <key-chain-name>