Petite déviation de notre infra VoIP !
On va revenir un peu sur la mini-série sur le segment routing. Après relecture, les explications étaient vraiment très imagées voir grossières.
On part sur une architecture un peu plus développée :
Et toujours dans un backbone full v6 ! On va même pousser la RFC 8950 (plutôt pensé pour du core) à nos intercos CPE-PE. Bah oui, autant avoir de l'IPv6 partout nan ?
On verra même un peu de traffic engineering via SR dans le cadre d'un L2 ET L3VPN MPLS d'un client.
Configuration de l'IGP
Pour les interco entre PE/P, j'utilise uniquement des v6 link local (fe80) comme définit dans la RFC 7404. Le principal avantage est que ce mode de fonctionnement ne nécessite pas de se prendre la tête sur l'unicité des adresses vù qu'elles ne sont pas routées ! Le management pourra se faire en OOB (out of band) ou via la loopback MPLS.
Rien de bien sorcier, on part sur de l'ISIS. Pour les adressages des loopbacks, je suis parti pour mes Px : 2001::x/128 et PEx : 2001::1x/128 où X est un chiffre.
PE1#sh run section isis
router isis BACKBONE
net 49.0001.2700.0000.0011.00
is-type level-2
log-adjacency-changes
advertise passive-only
!
address-family ipv6 unicast
Puis on configure les interfaces :
PE1#sh run int eth1
interface Ethernet1
mtu 1500
no switchport
ipv6 enable
isis enable BACKBONE
isis network point-to-point
PE1#sh run int lo1
interface Loopback1
ipv6 address 2001::11/128
node-segment ipv6 index 11
isis enable BACKBONE
isis passive
PS : Il semblerait qu'on ne puisse pas faire monter des adjacences ISIS avec une MTU > 1500 octets sur la version EOS 4.34.2F.
Nos neighbors ISIS montent bien. Les routes sont bien annoncées et apprises par l'ensemble des routeurs composant le backbone.
PE1#sh isis neighbors
Instance VRF System Id Type Interface SNPA State Hold time Circuit Id
BACKBONE default P1 L2 Ethernet1 P2P UP 28 19
BACKBONE default P2 L2 Ethernet2 P2P UP 25 13
BACKBONE default P3 L2 Ethernet3 P2P UP 22 11
PE1#sh ipv6 route isis
I L2 2001::1/128 [115/20]
via fe80::5200:ff:fed5:5dc0, Ethernet1
I L2 2001::2/128 [115/20]
via fe80::5200:ff:fe03:3766, Ethernet2
I L2 2001::3/128 [115/20]
via fe80::5200:ff:fe1b:5e8d, Ethernet3
I L2 2001::4/128 [115/30]
via fe80::5200:ff:fed5:5dc0, Ethernet1
via fe80::5200:ff:fe03:3766, Ethernet2
I L2 2001::5/128 [115/30]
via fe80::5200:ff:fed5:5dc0, Ethernet1
via fe80::5200:ff:fe03:3766, Ethernet2
via fe80::5200:ff:fe1b:5e8d, Ethernet3
I L2 2001::6/128 [115/30]
via fe80::5200:ff:fe03:3766, Ethernet2
via fe80::5200:ff:fe1b:5e8d, Ethernet3
I L2 2001::12/128 [115/40]
via fe80::5200:ff:fed5:5dc0, Ethernet1
via fe80::5200:ff:fe03:3766, Ethernet2
via fe80::5200:ff:fe1b:5e8d, Ethernet3
La connectivité est bien opérationnelle :
PE1#ping ipv6 2001::12 source 2001::11 repeat 1
PING 2001::12(2001::12) from 2001::11 : 52 data bytes
60 bytes from 2001::12: icmp_seq=1 ttl=62 time=4.22 ms
--- 2001::12 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.222/4.222/4.222/0.000 ms
On active le segment routing
La configuration est tout aussi simple que l'ISIS (une ligne de configuration). On pense aussi à activer MPLS car c'est du SR-MPLS et non SRv6 !
PE1#sh run section segment routing
router isis BACKBONE
segment-routing mpls
router-id 100.127.0.11
no shutdown
PE1#sh run | i mpls
mpls ip
On peut voir les nodes SID des autres routeurs :
PE1#sh isis segment-routing tunnel
Index Endpoint Next Hop/Tunnel Index Interface Labels
--------- ---------------- --------------------------- ------------- ----------
1 2001::1/128 fe80::5200:ff:fed5:5dc0 Ethernet1 [ 3 ]
2 2001::3/128 fe80::5200:ff:fe1b:5e8d Ethernet3 [ 3 ]
3 2001::12/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900012 ]
fe80::5200:ff:fe1b:5e8d Ethernet3 [ 900012 ]
fe80::5200:ff:fed5:5dc0 Ethernet1 [ 900012 ]
4 2001::5/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900005 ]
fe80::5200:ff:fe1b:5e8d Ethernet3 [ 900005 ]
fe80::5200:ff:fed5:5dc0 Ethernet1 [ 900005 ]
5 2001::4/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900004 ]
fe80::5200:ff:fed5:5dc0 Ethernet1 [ 900004 ]
6 2001::2/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 3 ]
7 2001::6/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900006 ]
fe80::5200:ff:fe1b:5e8d Ethernet3 [ 900006 ]
Les labels commencent à partir de 900000 sur Arista ! Pourquoi 3 sur certains ? Car c'est un node adjacent au PE1 donc le label est pop 😄
Un node SID est unique dans le backbone ce qui est la très grande différence avec le LDP. Il est donc propagé vers l'ensemble des routeurs faisant parti du core SR. Ainsi, si PE1 possède le 900011, les autres routeurs auront ce label dans leur table.
Il existe un autre SID dans le SR : Adjacency SID. Il permet d'attribuer un label sur les interco entre les routeurs. Cela permet de privilégier un lien entre deux routeurs plutôt qu'un autre en cas de traffic engineering. Comparé au node SID, celui ci est uniquement local au routeur.
PE1#sh isis segment-routing adjacency-segments
c - conflicting SR capability TLV, processed first advertisement
System ID: PE1 Instance: BACKBONE
SR supported Data-plane: MPLS SR Router ID: 100.127.0.11
Adj-SID allocation mode: SR-adjacencies
Adj-SID allocation pool: Base: 100000 Size: 16384
Adjacency Segment Count: 3
Flag Descriptions: F: IPv6 address family, B: Backup, V: Value
L: Local, S: Set
Segment Status codes: L1 - Level-1 adjacency, L2 - Level-2 adjacency, P2P - Point-to-Point adjacency, LAN - Broadcast adjacency
! - SR-unreachable, # - Some IS-IS next-hops are SR-unreachable
Locally Originated Adjacency Segments
Adj IP Address Local Intf SID SID Source Flags Type
----------------------- ---------- ------ ---------- ------------------- ------
fe80::5200:ff:fe1b:5e8d Et3 100003 Dynamic F:1 B:0 V:1 L:1 S:0 P2P L2
fe80::5200:ff:fe03:3766 Et2 100004 Dynamic F:1 B:0 V:1 L:1 S:0 P2P L2
fe80::5200:ff:fed5:5dc0 Et1 100005 Dynamic F:1 B:0 V:1 L:1 S:0 P2P L2
Protection
-----------
unprotected
unprotected
unprotected
Ces informations sont annoncées via l'ISIS dans un TLV :
Ici PE1 envoie son node SID 0x0000000b (11 en décimale). Mais 11 à partir de quoi ?
Du SRGB (Segment Routing Global Block). Par défaut, Arista le fait commencer à 900000. Il est communiqué aux autres routeurs via un autre TLV : (le début et le range)
On retrouve bien cette information sur les Arista :
PE1#sh mpls label ranges | grep isis-sr
900000 965535 65536 isis-sr
On peut aussi voir que les adjacences SID sont aussi envoyés dans l'ISIS même s'ils ne sont pas inscrits dans les autres routeurs :
Le TI-LFA, c'est quoi ?
L'un des enjeux majeurs est la convergence en cas de défaillance d'un node ou d'une adjacence dans un réseau. Il existe plusieurs moyen de répondre à ce besoin. Le Fast Reroute (FRR) est généralement utilisé dans un cadre MPLS LDP. Il permet de calculer un chemin de secours et de rétablir une connectivité en <50ms mais il ne couvre pas tous les cas et dépend de la topologie.
Le TI-LFA est une amélioration de ce mécanisme. Il utilise des labels SR et pré calcule un chemin de secours. Encore une fois, il n'y a pas besoin d'avoir du LDP, du RSVP ou des tunnels. Suffit juste, encore une fois, d'un IGP !
Admettons, le lien entre PE1 et P1 coupe :
PE1#sh isis segment-routing tunnel 2001::1/128
Index Endpoint Next Hop/Tunnel Index Interface Labels
--------- --------------- --------------------------- -------------- ----------
1 2001::1/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900001 ]
fe80::5200:ff:fe1b:5e8d Ethernet3 [ 900001 ]
Le trafic va passer via d'autres chemins mais le temps qu'ils soient dans la table, quelques ms se sont écoulées.
On active le TI-LFA :
router isis BACKBONE
timers local-convergence-delay protected-prefixes
!
address-family ipv6 unicast
fast-reroute ti-lfa mode link-protection level-2
Qu'est ce qui se passe dans la table des nodes SID :
PE1#sh isis segment-routing tunnel
Index Endpoint Next Hop/Tunnel Index Interface Labels
--------- ---------------- --------------------------- ------------- ----------
1 2001::1/128 TI-LFA (3) - [ 3 ]
2 2001::3/128 TI-LFA (4) - [ 3 ]
3 2001::12/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900012 ]
fe80::5200:ff:fe1b:5e8d Ethernet3 [ 900012 ]
fe80::5200:ff:fed5:5dc0 Ethernet1 [ 900012 ]
4 2001::5/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900005 ]
fe80::5200:ff:fe1b:5e8d Ethernet3 [ 900005 ]
fe80::5200:ff:fed5:5dc0 Ethernet1 [ 900005 ]
5 2001::4/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900004 ]
fe80::5200:ff:fed5:5dc0 Ethernet1 [ 900004 ]
6 2001::2/128 TI-LFA (10) - [ 3 ]
7 2001::6/128 fe80::5200:ff:fe03:3766 Ethernet2 [ 900006 ]
fe80::5200:ff:fe1b:5e8d Ethernet3 [ 900006 ]
On observe que les trois endpoints des nodes adjacents à PE1 ont un tunnel TI-LFA.
PE1#sh isis ti-lfa tunnel 3
Tunnel Index 3
via fe80::5200:ff:fed5:5dc0, 'Ethernet1'
label stack 3
backup via fe80::5200:ff:fe1b:5e8d, 'Ethernet3'
label stack 900005 900001
Et dans ce tunnel, on peut voir qu'il y a déjà un backup pour joindre P1 au cas où son interco avec PE1 tombe ! Ainsi, vu que le chemin est déjà dans la table, cela va convergeait encore plus rapidement 😄
Bon c'est énormément théorique car dans plutôt compliqué de "prouver" que cela fonctionne en lab. Pour ca que j'aimerai bien avoir la chance de voir en application dans un grand backbone (i hope).
Sessions EVPN entre PE1 et PE2
Une fois notre underlay configuré, il nous reste plus qu'à mettre en place l'overlay qui permettra de proposer des services (L2 ou L3VPN MPLS) à des clients.
Pour ce faire, au lieu d'utiliser du vpnv4 (ou v6), on va plutôt utiliser une autre adresse family : EVPN.
Elle permet, entre autre, de transporter des informations L2 ET L3. Plus besoin de séparer L3VPN (vpnv4) et L2VPN (vpls/vpws) !
PE1#sh run section bg
router bgp 65000
router-id 100.127.0.11
no bgp default ipv4-unicast
bgp default ipv6-unicast
neighbor 2001::12 remote-as 65000
neighbor 2001::12 next-hop-self
neighbor 2001::12 update-source Loopback1
neighbor 2001::12 description PE2-IPv6
neighbor 2001::12 send-community standard extended
!
address-family evpn
neighbor 2001::12 activate
neighbor 2001::12 encapsulation mpls next-hop-self source-interface Loopback1
!
address-family ipv6
no neighbor 2001::12 activate
Rien de bien compliqué ici. Il faut penser au next-hop-self pour le nexthop en iBGP et le send-community pour permettre l'envoi de communautés MP-BGP.
Nous n'avons pas besoin de l'adress family ipv6 car les préfixes v6 vont être transportées par l'EVPN.
PE1#sh bgp summary
BGP summary information for VRF default
Router identifier 100.127.0.11, local AS number 65000
Neighbor AS Session State AFI/SAFI AFI/SAFI State NLRI Rcd NLRI Acc NLRI Adv
-------- ----------- ------------- ----------------------- -------------- ---------- ---------- ----------
2001::12 65000 Established L2VPN EVPN Negotiated 2 2 2
La session EVPN est bien montée.
Sessions BGP entre CPE et PE + L3VPN MPLS + TE
J'aime bien le v6 donc on va continuer jusqu'au bout ! Le but étant que CPE-PE soit en v6 et que le CPE puisse annoncer des préfixes v4 à travers ce peering dans son L3VPN sur le PE (beau projet ?).
Je vais utiliser le même principe que l'underlay de ma fabric VXLAN/EVPN : du peering en BGP v6 Unnumbered avec des link local. De plus, sur ce peering, je pourrai transporter des NLRI v4 over v6 (l'application des RFC 4861 & 8950).
Côté CPE, on adresse les interfaces :
#CPE1
/ip address
add address=100.64.0.1 interface=lo network=100.64.0.1
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
/ipv6 address
add address=2001:dead:cafe::1/128 advertise=no interface=lo
add address=2001:dead:cafe:1::1 interface=ether2
#CPE2
/ip address
add address=100.64.0.2 interface=lo network=100.64.0.2
add address=192.168.1.2/24 interface=ether1 network=192.168.1.0
/ipv6 address
add address=2001:dead:cafe::2/128 advertise=no interface=lo
add address=2001:dead:cafe:2::1 interface=ether2
Et pour le BGP :
#CPE1
/ipv6 nd prefix
add interface=ether1 prefix=none
/routing bgp instance
add as=65001 name=PE1 router-id=100.64.0.1
/routing bgp connection
add afi=ip,ipv6 instance=PE1 local.address=ether1 .role=ebgp name=ToPE1 output.redistribute=connected
#CPE2
/ipv6 nd prefix
add interface=ether1 prefix=none
/routing bgp instance
add as=65001 name=PE1 router-id=100.64.0.2
/routing bgp connection
add afi=ip,ipv6 instance=PE1 local.address=ether1 .role=ebgp name=ToPE2 output.redistribute=connected
Mikrotik est assez sympa. Le routeur détecte tout seul l'AS du peer distant dans le BGP update ! Ensuite, il suffit de peer, comme sur Arista, avec l'interface et non une IP.
Côté PE, on va penser à l'industrialisation ! Le but étant d'avoir la même configuration si plusieurs sites du même client.
Tout d'abord on crée la VRF et on active le routage (v4 et v6). De plus, on place l'interco dans la VRF (ici, j'ai choisi un point à point mais cela peut être du PPPoE, etc).
PE1(config)#vrf instance Customer1
PE1(config)#ip routing vrf Customer1
PE1(config)#ipv6 unicast-routing vrf Customer1
PE1#sh run int eth8
interface Ethernet8
no switchport
vrf Customer1
ipv6 enable
On crée un peer filter qui va autoriser que l'AS du client :
PE1#sh peer-filter PF_Customer1_AS
peer-filter PF_Customer1_AS
10 match as-range 65001 result accept
Ensuite, ca go dans le BGP !
router bgp 65000
neighbor Customer1 peer group
neighbor Customer1 default-originate
!
address-family ipv4
neighbor Customer1 activate
neighbor Customer1 next-hop address-family ipv6 originate
!
vrf Customer1
rd 65000:65001
route-target import evpn 65000:65001
route-target export evpn 65000:65001
bgp default ipv4-unicast transport ipv6
bgp listen range fe80::/10 peer-group Customer1 peer-filter PF_Customer1_AS
redistribute connected
!
address-family ipv6
redistribute connected
J'ai décidé de faire un peer-group par client. Le PE va uniquement annoncer la route par défaut aux CPE via le default-originate. Il faut savoir un truc c'est que sur EOS, la configuration d'un peer group se fait majoritairement dans le process global du BGP (hormis le BGP listen range qu'il faut placer dans la VRF).
La configuration dans l'address family ipv4 est très importante car elle permet d'autoriser les préfixes v4 avec un nexthop v6 !
Pour la configuration dans la VRF, on importe et on exporte les routes 65000:65001 et on y place le BGP listen range.
Admettons qu'on ait un autre client, il montera automatiquement dans le peer group Customer1 s'il est configuré avec l'AS 65001 ! Plutôt pas mal ;)
PE1#sh bgp summary vrf Customer1
BGP summary information for VRF Customer1
Router identifier 100.64.0.11, local AS number 65000
Neighbor AS Session State AFI/SAFI AFI/SAFI State NLRI Rcd NLRI Acc NLRI Adv
------------------------ ----------- ------------- ----------------------- -------------- ---------- ---------- ----------
fe80::5200:ff:fe01:0%Et8 65001 Established IPv4 Unicast Negotiated 2 2 1
fe80::5200:ff:fe01:0%Et8 65001 Established IPv6 Unicast Negotiated 2 2 1
Les sessions sont bien montées et nos tables de routages ?
PE1#sh ipv6 route vrf Customer1
VRF: Customer1
Displaying 4 of 7 IPv6 routing table entries
Source Codes:
C - connected, S - static, K - kernel, O3 - OSPFv3,
O3 IA - OSPFv3 inter area, O3 E1 - OSPFv3 external type 1,
O3 E2 - OSPFv3 external type 2,
O3 N1 - OSPFv3 NSSA external type 1
O3 N2 - OSPFv3 NSSA external type2, B - Other BGP Routes,
A B - BGP Aggregate, R - RIP,
I L1 - IS-IS level 1, I L2 - IS-IS level 2, DH - DHCP,
NG - Nexthop Group Static Route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked,
G - gRIBI, RC - Route Cache Route,
CL - CBF Leaked Route
B E 2001:dead:cafe::1/128 [200/0]
via fe80::5200:ff:fe01:0, Ethernet8
B I 2001:dead:cafe::2/128 [200/0]
via 2001::12/128, IS-IS SR tunnel index 3, label 116385
via fe80::5200:ff:fe03:3766, Ethernet2, label 900012
via fe80::5200:ff:fe1b:5e8d, Ethernet3, label 900012
via fe80::5200:ff:fed5:5dc0, Ethernet1, label 900012
B E 2001:dead:cafe:1::/64 [200/0]
via fe80::5200:ff:fe01:0, Ethernet8
B I 2001:dead:cafe:2::/64 [200/0]
via 2001::12/128, IS-IS SR tunnel index 3, label 116385
via fe80::5200:ff:fe03:3766, Ethernet2, label 900012
via fe80::5200:ff:fe1b:5e8d, Ethernet3, label 900012
via fe80::5200:ff:fed5:5dc0, Ethernet1, label 900012
PE1#
PE1#sh ip route vrf Customer1
VRF: Customer1
Source Codes:
C - connected, S - static, K - kernel,
O - OSPF, O IA - OSPF inter area, O E1 - OSPF external type 1,
O E2 - OSPF external type 2, O N1 - OSPF NSSA external type 1,
O N2 - OSPF NSSA external type2, O3 - OSPFv3,
O3 IA - OSPFv3 inter area, O3 E1 - OSPFv3 external type 1,
O3 E2 - OSPFv3 external type 2,
O3 N1 - OSPFv3 NSSA external type 1,
O3 N2 - OSPFv3 NSSA external type2, B - Other BGP Routes,
B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
I L2 - IS-IS level 2, A B - BGP Aggregate,
A O - OSPF Summary, NG - Nexthop Group Static Route,
V - VXLAN Control Service, M - Martian,
DH - DHCP client installed default route,
DP - Dynamic Policy Route, L - VRF Leaked,
G - gRIBI, RC - Route Cache Route,
CL - CBF Leaked Route
Gateway of last resort is not set
B E 100.64.0.1/32 [200/0]
via fe80::5200:ff:fe01:0, Ethernet8
B I 100.64.0.2/32 [200/0]
via 2001::12/128, IS-IS SR tunnel index 3, label 116384
via fe80::5200:ff:fe03:3766, Ethernet2, label 900012
via fe80::5200:ff:fe1b:5e8d, Ethernet3, label 900012
via fe80::5200:ff:fed5:5dc0, Ethernet1, label 900012
B E 192.168.1.0/24 [200/0]
via fe80::5200:ff:fe01:0, Ethernet8
B I 192.168.2.0/24 [200/0]
via 2001::12/128, IS-IS SR tunnel index 3, label 116384
via fe80::5200:ff:fe03:3766, Ethernet2, label 900012
via fe80::5200:ff:fe1b:5e8d, Ethernet3, label 900012
via fe80::5200:ff:fed5:5dc0, Ethernet1, label 900012
Toutes les routes sont bien présentes dans les tables de routages des deux PE !
Et comment se passe le transport de ce service à travers le SR ?
Le segment routing va attribuer un label (unique et global à tous les PE) à cette VRF :
PE1#sh mpls lfib route | grep -B 1 Customer1
B3 116384 [0]
via I, ipv4, vrf Customer1
B3 116385 [0]
via I, ipv6, vrf Customer1
PE2#sh mpls lfib route | grep -B 1 Customer1
B3 116384 [0]
via I, ipv4, vrf Customer1
B3 116385 [0]
via I, ipv6, vrf Customer1
Un petit test de ping ?
[admin@CPE1] /ip/address> /ping 2001:dead:cafe:2::1 src-address=2001:dead:cafe:1::1 count=1
SEQ HOST SIZE TTL TIME STATUS
0 2001:dead:cafe:2::1 56 62 8ms342us echo reply
sent=1 received=1 packet-loss=0% min-rtt=8ms342us avg-rtt=8ms342us
max-rtt=8ms342us
L'aller se fait via P1 :
On voit bien le label de transport 90012 (PE2) et le label de service du L3VPN v6.
Le retour se fait via P3 :
Pourquoi on ne voit que le label de service ? Car, bien évidement, le label de transport est pop à l'avant dernier saut (via le mécanisme du PHP) donc pop à P3.
Et pourquoi le paquet n'emprunte pas le même chemin à l'aller qu'au retour ? ECMP !
Clarence Filsfils l'explique dans son livre. L'instruction d'un node SID est : "steer traffic along the ECMP-aware shortest path to the prefix associated with this segment".
Dans notre cas, cela veut dire que les PE envoient le trafic vers le N-SID associé à la route en utilisant l'ECMP de l'IGP ISIS ! Vu que les PE ont plusieurs chemins pour se joindre, le trafic peut emprunter un autre chemin à l'aller qu'au retour !
Et pour le trafic v4 ?
[admin@CPE1] /ip/address> /ping 192.168.2.1 src-address=192.168.1.1 count=1
SEQ HOST SIZE TTL TIME STATUS
0 192.168.2.1 timeout
sent=1 received=0 packet-loss=100%
Le trafic n'est pas forwardé à travers le routeur. Avec un trafic généré sur les PE (loopbacks), ils arrivent bien à se joindre entre eux, par contre impossibilité de communiquer avec les CPE ... Soit je suis passé à côté d'un truc soit c'est vraiment un bug du data plane v4 lors d'un underay SR v6.
Un peu de trafic engineering ?
Et vous allez voir que, comparé au LDP+RSVP-TE, c'est plutôt assez simple 😄. On va suivre la RFC 9256.
Tout d'abord, il faut comprendre le principe de color dans BGP. Une route peut avoir plusieurs attributs dans BGP (med, local pref, as-path, etc). Une color va, elle aussi, être un attribut BGP qui va pouvoir être attachée à un préfixe (ou un ensemble de préfixe). Ainsi, on va utiliser ce principe de color pour notre TE. Un trafic avec une color va pouvoir prendre un autre chemin qu'un trafic avec une autre color !
Définissons notre architecture :
- Trafic v6 : PE1 <-> P1 <-> P4 <-> PE2
- Trafic v4 : PE1 <-> P2 <-> P5 <-> PE2
Allez, on s'y attaque !
Tout d'abord, on va faire en sorte que les préfixes reçus par le CPE matchent avec la bonne color :
#PE1
ipv6 prefix-list Customer1-CPE1-v6
seq 10 permit 2001:dead:cafe::1/128
seq 20 permit 2001:dead:cafe:1::1/64
!
ip prefix-list Customer1-CPE1-v4
seq 10 permit 100.64.0.1/32
seq 20 permit 192.168.1.0/24
!
route-map RM_Customer1_IN permit 10
match ipv6 address prefix-list Customer1-CPE1-v6
set extcommunity color 10 additive
!
route-map RM_Customer1_IN permit 20
match ip address prefix-list Customer1-CPE1-v4
set extcommunity color 11 additive
#PE2
ipv6 prefix-list Customer1-CPE1-v6
seq 10 permit 2001:dead:cafe::2/128
seq 20 permit 2001:dead:cafe:2::1/64
!
ip prefix-list Customer1-CPE1-v4
seq 10 permit 100.64.0.2/32
seq 20 permit 192.168.2.0/24
!
route-map RM_Customer1_IN permit 10
match ipv6 address prefix-list Customer1-CPE1-v6
set extcommunity color 10 additive
!
route-map RM_Customer1_IN permit 20
match ip address prefix-list Customer1-CPE1-v4
set extcommunity color 11 additive
Ensuite, sur le peering BGP, on place la route-map en IN
PE1#sh run section bgp | i route-map
neighbor Customer1 route-map RM_Customer1_IN in
On observe bien que nos routes v6 ont une color 10 et v4 une color de 11 :
PE1#sh bgp ipv6 unicast 2001:dead:cafe:1::/64 vrf Customer1
BGP routing table information for VRF Customer1
Router identifier 100.64.0.11, local AS number 65000
BGP routing table entry for 2001:dead:cafe:1::/64
Paths: 1 available
65001
fe80::5200:ff:fe01:0%Et8 from fe80::5200:ff:fe01:0%Et8 (100.64.0.1)
Origin INCOMPLETE, metric 0, localpref 100, IGP metric 1, weight 0, tag 0
Received 01:38:30 ago, valid, external, best
Extended Community: Color:CO(00):10
Rx SAFI: Unicast
PE1#sh bgp ipv6 unicast 2001:dead:cafe::2/128 vrf Customer1
BGP routing table information for VRF Customer1
Router identifier 100.64.0.11, local AS number 65000
BGP routing table entry for 2001:dead:cafe::2/128
Paths: 1 available
65001
2001::12 from 2001::12 (100.127.0.12), imported EVPN route, RD 65000:65001
Origin INCOMPLETE, metric 0, localpref 100, IGP metric 0, weight 0, tag 0
Received 00:11:03 ago, valid, internal, best
Extended Community: Route-Target-AS:65000:65001 Color:CO(00):10 TunnelEncap:tunnelTypeMpls
Remote MPLS label: 116385
Rx SAFI: Unicast
Tunnel RIB eligible
PE1#sh bgp ipv4 unicast 100.64.0.1/32 vrf Customer1
BGP routing table information for VRF Customer1
Router identifier 100.64.0.11, local AS number 65000
BGP routing table entry for 100.64.0.1/32
Paths: 1 available
65001
fe80::5200:ff:fe01:0%Et8 from fe80::5200:ff:fe01:0%Et8 (100.64.0.1)
Origin INCOMPLETE, metric 0, localpref 100, IGP metric 1, weight 0, tag 0
Received 01:39:08 ago, valid, external, best
Extended Community: Color:CO(00):11
Rx SAFI: Unicast
PE1#sh bgp ipv4 unicast 192.168.2.0/24 vrf Customer1
BGP routing table information for VRF Customer1
Router identifier 100.64.0.11, local AS number 65000
BGP routing table entry for 192.168.2.0/24
Paths: 1 available
65001
2001::12 from 2001::12 (100.127.0.12), imported EVPN route, RD 65000:65001
Origin INCOMPLETE, metric 0, localpref 100, IGP metric 0, weight 0, tag 0
Received 00:11:17 ago, valid, internal, best
Extended Community: Route-Target-AS:65000:65001 Color:CO(00):11 TunnelEncap:tunnelTypeMpls
Remote MPLS label: 116384
Rx SAFI: Unicast
Tunnel RIB eligible
(Regardez sur la ligne Extended Community)
Bon c'est plutôt pas trop mal ! Maintenant, faisons la configuration du TE :
PE1(config-te-sr)#sh active
router traffic-engineering
segment-routing
rib system-colored-tunnel-rib
router-id ipv6 2001::11
Ainsi, on active le TE du SR via le système de color des préfixes BGP.
Ensuite, on peut créer le chemin vers l'endpoint avec la color associée :
PE1(config-te-sr)#sh active
router traffic-engineering
segment-routing
rib system-colored-tunnel-rib
!
policy endpoint 2001::12 color 10
binding-sid 1000010
!
path-group preference 10
segment-list label-stack 900001 900004 900012 116385
!
policy endpoint 2001::12 color 11
binding-sid 1000011
!
path-group preference 10
segment-list label-stack 900002 900005 900012 116384
PE2(config-te-sr)#sh active
router traffic-engineering
segment-routing
rib system-colored-tunnel-rib
!
policy endpoint 2001::11 color 10
binding-sid 1000010
!
path-group preference 10
segment-list label-stack 900004 900001 900011 116385
!
policy endpoint 2001::11 color 11
binding-sid 1000011
!
path-group preference 10
segment-list label-stack 900005 900002 900011 116384
PE1#show tunnel rib colored system-colored-tunnel-rib brief
Tunnel RIB: system-colored-tunnel-rib
Endpoint Color Tunnel Type Index(es) Tunnel Preference IGP Preference IGP Metric Metric Type
--------------- -------- --------------- ------------ -------------------- ----------------- -------------- -----------
2001::12/128 10 SR-TE Policy 12 35 3 0 metric
2001::12/128 11 SR-TE Policy 1 35 3 0 metric
Bon malheureusement, on ne va pouvoir tester le trafic v4 à cause de ce foutu bug mais pour le v6, regardons une trame wireshark (interface PE1 vers P1) :
Déjà, on aperçoit que le trafic aller et retour se fait sur la même interface. On peut voir aussi les labels apposés dans la trame.
Pour le reply (donc interface PE2 vers P4) :
Les labels sont bien aussi apposés suivant le chemin définit dans la configuration.
Quelle facilité de faire du TE avec SR !!!!!!
Et admettons une adjacence tombe ? Via le mécanisme TI-LFA, le trafic va être redirigé rapidement 😀
Ici, il passe par P2 puis P5 puis P1 puis P4 puis PE2 (il aurait fallu que je raccorde tous les P ensemble, ca aurait été plus pratique mais l'idée est là). Je n'observe pas de perte de paquets, juste une augmentation de la latence (ce qui est normal vu qu'on lui rajoute des sauts) :
[admin@CPE1] /ip/address> /ping 2001:dead:cafe:2::1 src-address=2001:dead:cafe:1::1
SEQ HOST SIZE TTL TIME STATUS
15 2001:dead:cafe:2::1 56 62 6ms20us echo reply
16 2001:dead:cafe:2::1 56 62 5ms411us echo reply
17 2001:dead:cafe:2::1 56 62 7ms784us echo reply
18 2001:dead:cafe:2::1 56 62 11ms704us echo reply
19 2001:dead:cafe:2::1 56 62 11ms804us echo reply
sent=20 received=20 packet-loss=0% min-rtt=5ms411us avg-rtt=7ms136us
max-rtt=11ms804us
SEQ HOST SIZE TTL TIME STATUS
20 2001:dead:cafe:2::1 56 62 9ms726us echo reply
21 2001:dead:cafe:2::1 56 62 9ms2us echo reply
22 2001:dead:cafe:2::1 56 62 10ms475us echo reply
23 2001:dead:cafe:2::1 56 62 9ms658us echo reply
24 2001:dead:cafe:2::1 56 62 7ms154us echo reply
Je fais manuellement tomber l'interface PE1 <-> P1 au ping 17 et je la reup au ping 24.
Et si un node tombe ?
Bah c'est foutu mdrrr, pour ca que c'est bien de faire un autre chemin dans la policy 😄
On rajoute donc un deuxième chemin :
#PE1
router traffic-engineering
segment-routing
policy endpoint 2001::12 color 10
path-group preference 20
segment-list label-stack 900002 900005 900012 116385
#PE2
router traffic-engineering
segment-routing
policy endpoint 2001::11 color 10
binding-sid 1000010
path-group preference 20
segment-list label-stack 900005 900002 900011 116385
Un ping en continu :
[admin@CPE1] > /ping 2001:dead:cafe:2::1 src-address=2001:dead:cafe:1::1
sent=171 received=171 packet-loss=0% min-rtt=5ms145us avg-rtt=6ms939us max-rtt=14ms570us
Je n'obverse aucune coupure !
Aussi, on voit que le chemin qui avait une préférence de 10 passe derrière :
PE1#show traffic-engineering segment-routing policy
Endpoint 2001::12 Color 10, Counters: not available
Path group: State: active (for 00:08:42), modified: 00:08:42 ago
Protocol: Static
Endpoint provisioning: Static
Originator: 0.0.0.0(AS0)
Discriminator: 32770
Preference: 20
IGP metric: 0 (static)
Binding SID: 1000010
Path computation: Configured
Explicit null label policy: IPv4 (system default)
Segment List: State: Valid, ID: 14, Counters: 248 packets, 20336 bytes
Protected: Yes
Label Stack: [900002 900005 900012 116385], Weight: 1
Resolved Label Stack: [900005 900012 116385], Next hop: fe80::5200:ff:fe03:3766, Interface: Ethernet2
Backup Resolved Label Stack: [900005 900002 900005 900012 116385], Next hop: fe80::5200:ff:fe1b:5e8d, Interface: Ethernet3
Path group: State: valid, modified: 01:15:39 ago
Protocol: Static
Endpoint provisioning: Static
Originator: 0.0.0.0(AS0)
Discriminator: 32769
Preference: 10
Binding SID: 1000010
Path computation: Configured
Explicit null label policy: IPv4 (system default)
Segment List: State: Valid, ID: 11, Counters: 24 packets, 2016 bytes
Protected: Yes
Label Stack: [900001 900004 900012 116385], Weight: 1
Resolved Label Stack: [900004 900012 116385], Next hop: fe80::5200:ff:fed5:5dc0, Interface: Ethernet1
Backup Resolved Label Stack: [900005 900001 900004 900012 116385], Next hop: fe80::5200:ff:fe03:3766, Interface: Ethernet2
Dernier point : du TE en cas de L2VPN
Bon avant de faire du TE, il faut peut-être monter cet L2 nan ?
Tout d'abord, on place l'interface en trunk :
#PE1 et PE2
interface Ethernet8
switchport trunk allowed vlan 3000
switchport mode trunk
Puis .... Bah c'est de l'EVPN donc trop méga trop simple !!!
#PE1 et PE2
router bgp 65000
vlan 3000
rd 65000:3000
route-target both 65000:3000
redistribute learned
Ensuite, on configure l'interface sur les CPE :
#CPE1
/interface vlan
add interface=ether1 name=WAN vlan-id=3000
/ipv6 address
add address=2001:babe::1 interface=WAN
#CPE2
/interface vlan
add interface=ether1 name=WAN vlan-id=3000
/ipv6 address
add address=2001:babe::2 interface=WAN
On peut déjà tester un petit ping ?
[admin@CPE1] > /ping 2001:babe::2 count=1
SEQ HOST SIZE TTL TIME STATUS
0 2001:babe::2 56 64 7ms203us echo reply
sent=1 received=1 packet-loss=0% min-rtt=7ms203us avg-rtt=7ms203us max-rtt=7ms203us
Top le L2VPN fonctionne bien ! De plus, on peut valider le L2 par le fait que la MAC du CPE2 est bien connu par CPE1 :
[admin@CPE1] > /tool/mac-scan WAN
Columns: MAC-ADDRESS, AGE
MAC-ADDRESS AGE
50:00:00:02:00:00 17
En état actuel des choses, le trafic est transporté via notre SR avec le label de service 1047390 tout en respectant l'instruction du node SID : "steer traffic along the ECMP-aware shortest path to the prefix associated with this segment".
PE1#sh mpls lfib route | grep -B 1 vlan3000
B2 1047390 [0]
via V, vlan3000, control word present
On aimerait quand même vachement faire faire du TE sur cet L2, cela serait énormément stylé nan ? De plus, on a "réservé" un chemin chacun pour le trafic v6 et v4. Nous en avons encore un autre (P3 <-> P6) donc autant l'utiliser !
On reprend le même fonctionnement des colors. Cependant, on ne souhaite pas les associer à un préfixe IP mais plutôt au MAC du VLAN 3000. La question qui se pose c'est comment ?
Nous avons défini, dans la configuration du VLAN dans le BGP, un route-target. On va jouer là dessus pour matcher dans une route-map et ainsi set la bonne color !
#PE1 et PE2
ip extcommunity-list RT-Customer1-Vl3000 permit rt 65000:3000
route-map RM_EVPN_COLOR permit 10
match extcommunity RT-Customer1-Vl3000
set extcommunity color 12 additive
route-map RM_EVPN_COLOR permit 9999
router bgp 65000
address-family evpn
neighbor 2001::12 route-map RM_EVPN_COLOR in
Tout le trafic entrant du peering EVPN et qui match le premier permit de la route-map (tout trafic avec un rt 65000:3000 soit celui du VLAN 3000) se verra attribuer la color 12 !
PE1#sh bgp evpn route-type mac-ip 5000.0002.0000 detail
BGP routing table information for VRF default
Router identifier 100.127.0.11, local AS number 65000
BGP routing table entry for mac-ip 5000.0002.0000, Route Distinguisher: 65000:3000
Paths: 1 available
Local
2001::12 from 2001::12 (100.127.0.12)
Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, internal, best
Extended Community: Route-Target-AS:65000:3000 Color:CO(00):12 TunnelEncap:tunnelTypeMpls
MPLS label: 1047390 ESI: 0000:0000:0000:0000:0000
On peut voir que la color 12 est bien associée à la MAC du CPE2 sur le PE1 !
Ainsi, il nous reste plus qu'à refaire un nouveau chemin TE mais associé à la color 12 ce coup ci :
#PE1
router traffic-engineering
segment-routing
policy endpoint 2001::12 color 12
binding-sid 1000012
!
path-group preference 10
segment-list label-stack 900003 900006 900012
#PE2
router traffic-engineering
segment-routing
policy endpoint 2001::11 color 12
binding-sid 1000012
!
path-group preference 10
segment-list label-stack 900006 900003 900011
Il semblerait que je n'ai pas besoin de renseigner le label de service pour ce type de L2VPN mais pour les L3VPN si. Je suis assez étonné de ce comportement, je vais essayer de creuser de mon côté pour vérifier cela.
Allons regarder de plus près dans wireshark :
Le trafic aller/retour passe bien via le même chemin. (ne faites pas gaffe au PW Ethernet Control Word, je suis obligé de décoder la trame avec ce paramètre car wireshark la voit comme malformed).
On voit bien les deux labels de transports et le label de service !!!
Conclusion
Très gros épisode aujourd'hui !!! Honnêtement, je ne comptais pas le rédiger mais après un entretien fort enrichissant techniquement (pitié faites en sorte que j'ai le taf), je me suis chauffé et le voici 😄.
Il se pourrait que des erreurs se soient glissées surtout sur le TE. C'est bien la première fois que j'utilise ce genre de fonctionnement (c'est la première fois que je pousse le réseau aussi loin on va dire). J'aimerai vraiment voir ce genre de réseau dans un grand opérateur. Le lab et la théorie c'est sympa mais rien ne vaut la production.
Au final, je suis assez content de moi surtout sur l'utilisation de l'IPv6. Et je ne suis pas encore passé au SRv6 mais mon backbone core et edge tournent déjà en full v6 !!!!
Si un jour me prend l'idée de configurer le SRv6 d'Arista, j'en ferai un épisode mais je pense que ca sera dans un futur lointain (quoique).
Je termine sur un mot de fin : Regardez Person of interest. Meilleure série ever