Carrier supporting Carrier (IGP+LDP)

Carrier Supporting Carrier Lab Setup

Gjorde mit første forsøg i CsC idag. Fik gennemført hele setuppet på 21 routere på ca. 1,5 time - fra blank konfig til endeligt setup.

Jeg havde enkelte fejl, som på den positive side ikke relaterede sig til forståelsen af teknologien.

Første fejl var at angive forkert loopback nummer til CSC LDP loopback hvorved jeg overskrev mit globale LDP router-id (loopback0). Derudover benyttede jeg ISIS som CsC-PE til CsC-CE protokol med redundans, og var ikke opmærksom på at Cost information ikke bæres i MP-BGP på samme måde som ved OSPF. Det skabte et loop - da dette var justeret fungerede alt fint.

PE-CE konfig var basalt set:

!
vrf definition CSC-A
rd 100:200
route-target both 100:200
adresse-family ipv4
exit-address-family
!
interface loopback200
vrf forwarding CSC-A
ip address 200.0.0.5 255.255.255.255
!
router isis 2
vrf CSC-A
redistribute bgp 100 level-1-2 metric 1000
net 49.0200.0200.0000.0005.00
metric-style wide
passive-interface loopback200
!
mpls ldp router-id vrf CSC-A loopback200 force
!
interface fastethernet 0/0
vrf forwarding CSC-A
ip address 200.5.9.5 255.255.255.0
ip router isis 2
mpls ip
!
router bgp 100
!
address-family ipv4 vrf CSC-A
redistribute isis 2 level-1-2
exit-address-family
!

RR-groups

RR-groups - en interessant feature jeg stødte på i mine MPLS studier.

Funktionaliteten går i sin enkelthed ud på, at man vha. extended community-lists kan styre hvilke route-targets man ønsker, at RR’eren skal acceptere og distribuere…. og man kan bruge expanded ext-community lists (regular expressions!!) :)

!
ip extcommunity-list 100 permit [1-2]00:1[0-9][0-9]$
!
router bgp 100
!
address-family vpnv4
bgp rr-group 100
exit-address-family
!

Ovenstående RR accepterer alle RT fra AS100 og AS200 med en værdi imellem 100 og 199.

Jeg finder denne feature ret interessant især i forbindelse med Inter-AS MPLS VPN, hvor man eksempelvis kunne strukturere sine RR’s i et hierarkisk design og oprette “blokke” som varetager intern distribution og en AS Edge/PoI blok. Herved ville man tildels kunne opnå en beskyttelse af sit interne net fra fejl i nabo AS, samt strukturere sine route-policies således at alle routes internt fra sit AS ikke skal holdes i memory på ASBR’eren som følge af ‘no bgp default route-target filter’. RT rewrites ASN’erne imellem ville måske også være oplagt, at placere i edge/PoI RR-blokken.
InterAS MPLS VPN Option B + RR-groups
I mit testlab til formålet, har jeg placeret alle “core-facing” RT rewrite policies på AS edge RR’eren, og alle policies mod nabo AS på ASBR’eren i MPLS VPN option B setuppet. Optimalt set ville jeg have placeret alt på ASBR’eren, hvilket er Best Practice i flg. Cisco.

Det er en fed feature i denne type af setup, og man kan helt bestemt lave nogle fede og stabile designs hvis man tager sig god tid. :D


!
hostname R10
!
router bgp 100
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor RR-PEER peer-group
neighbor RR-PEER remote-as 100
neighbor RR-PEER update-source Loopback0
neighbor RR-CLIENT peer-group
neighbor RR-CLIENT remote-as 100
neighbor RR-CLIENT update-source Loopback0
neighbor 6.6.6.6 peer-group RR-CLIENT
neighbor 7.7.7.7 peer-group RR-PEER
neighbor 8.8.8.8 peer-group RR-PEER
!
address-family vpnv4
bgp rr-group 100
neighbor RR-PEER send-community extended
neighbor RR-PEER route-map RT-REWRITE out
neighbor RR-CLIENT send-community extended
neighbor RR-CLIENT route-reflector-client
neighbor 6.6.6.6 activate
neighbor 7.7.7.7 activate
neighbor 8.8.8.8 activate
exit-address-family
!
!
ip extcommunity-list 1 permit rt 200:1
ip extcommunity-list 2 permit rt 200:3
ip extcommunity-list 3 permit rt 200:6
ip extcommunity-list 4 permit rt 200:4
ip extcommunity-list 100 permit [1-2]00:(1|3|6)
!
route-map RT-REWRITE permit 10
match extcommunity 1
continue 20
set extcomm-list 1 delete
set extcommunity rt 100:1
!
route-map RT-REWRITE permit 20
match extcommunity 2
continue 30
set extcomm-list 2 delete
set extcommunity rt 100:3
!
route-map RT-REWRITE permit 30
match extcommunity 3
continue 40
set extcomm-list 3 delete
set extcommunity rt 100:6
!
route-map RT-REWRITE permit 40
match extcommunity 4
continue 1000
set extcomm-list 4 delete
!
route-map RT-REWRITE permit 1000
!

Categories: CCIE, MPLS Tags: , , ,

Skruer så småt op for tempoet på studierne…

Nu nærmer tiden sig snart for recertificeringen (d. 31/8) - hvilket efterhånden stresser mig lidt. Men det hjælper dog med til, at jeg får studeret og LAB’et nogle ret interessante teknologier/designs. Den sidste uges tid har stået på Inter-AS MPLS VPN - mest fokuseret på option B, hvilket er super inspirerende også set i forhold til hvordan man kunne optimere sine designs på arbejde osv.

Derudover bliver der knoklet med L2VPN Interworking (AToM), hvilket også er sjovt da man lige får genopfrisket nogle af legacy teknologierne som jeg har slidt så meget med på R&S sporet.

… så der er så småt vind i sejlene igen. :)

Categories: CCIE, Generelt Tags:

Inter-AS EoMPLS

inter-as_eompls

Jeg har på det seneste rodet lidt med tanken om end-2-end labelswitched pseudowires på tværs af BGP AS, og er kommet frem til et umiddelbart fungerende koncept.

Mit udgangspunkt var, som altid, at have en BGP-free core og ikke at skulle have AS1’s IGP routes i AS2 IGP; altså ingen redistribution. Måden hvorpå det kan lade sig gøre er ved hjælp af labelled IPv4 unicast, hvor man på snitfladerne mellem AS’erne benytter ‘MPLS BGP forwarding’, og BGP send-label på både eBGP og iBGP sessionerne.

På ASBR lærer nabo routes via eBGP annonceret med en label. BGP speakeren allokerer en lokal label og annoncerer prefixet videre til sine iBGP peers, samt sætter sig selv som next-hop. Den iBGP peer der sourcer en pseudowire kender sin pseudowire peer via BGP rekursivt via ASBR’en. Dette giver en labelstack med IGP label til ASBR’en, BGP-labelen til pseudowire peer (som ASBR’eren bruger til at forwarde til nabo AS), og VC labellen + PW control-word. I vedhæftede tegning er datapakkens struktur illustreret, samt hvordan labels flytter sig (som følge af PHP osv.).

Meget sjovt at gennemskue, og interessant for NSP/ISP’er som ønsker AToM på tværs af AS’er, og ikke ønsker det øgede mængde ressourcer/VLANs det kræver, at stitche dem sammen på AS kanten. Største udfordringer er ‘trust’, samt at kunne sende /32 til hinanden i global route tabel, hvis dette også samtidig er Internet route tabellen. :)

Categories: AToM, BGP, L2VPN, MPLS Tags: , , ,

Mål for 2012

Målet for mit vedkommende, for 2012 er at bestå den skriftlige CCIE SP written. Hermed får jeg også fornyet min CCIE R/S som har deadline den 31. August i år.

Categories: CCIE, Certificering, Generelt Tags: