Re: [FRnOG] [TECH] SR(-TE) MPLS
Pour être plus explicite, le problème vient de SR-TE policy sous IOS-XE. Je m'en vais tester sous IOS-XR en ce moment même mais voici le détail du problème : R1#sh run | beg ^segment-routing t segment-routing traffic-eng interface GigabitEthernet1 metric 10 interface GigabitEthernet2 metric 100 interface GigabitEthernet3 metric 100 logging policy status policy H2 color 2 end-point 192.168.0.2 binding-sid mpls 15002 candidate-paths preference 200 dynamic metric type igp ! preference 100 dynamic metric type te ! ! ! ! ! Un check rapide de la politique retourne toujours le même problème : R1#show segment-routing traffic-eng policy all Name: H2 (Color: 2 End-point: 192.168.0.2) Status: Admin: up, Operational: down for 00:26:35 (since 09-23 12:13:00.445) Candidate-paths: Preference 200: Dynamic (inactive) Inactive Reason: source address is not specified Weight: 0, Metric Type: IGP Preference 100: Dynamic (inactive) Inactive Reason: source address is not specified Weight: 0, Metric Type: TE Attributes: Binding SID: 15002 Allocation mode: explicit State: Init En static / auto-tunnel (static route LSP) ca fonctionne sans soucis. Une idée de l'origine du "source address is not specified" ? Encore merci pour les retours de certains en PV ;) Le 23-09-2020 13:40, Fabien VINCENT FrNOG via frnog a écrit : Je me réponds à moi même (personne ne fait de SR-(TE)-MPLS en FR ? Moi qui croyait que certains SP l'avaient déjà implémenté WW ^^) Je me suis effectivement emmêlé les pinceaux (mode n00b), le principe de dynamic LSP avec coloration / on-demand semble uniquement possiblement avec un PCE type ODL, ou avec MP-BGP, mais pas directement possible avec l'IGP (OSPFv2 ici en l'occurrence). Quelqu'un pour me confirmer / infirmer ça ? Il est donc obligatoire de faire des interfaces tunnels, qu'elles soient automatiques (auto-tunnel P2P) ou statiques sans PCE ? Pas possible de faire du on-demand policy SR localement ? Pour l'unnumbered, il y a bien une limitation qui faisait que cela ne fonctionnait pas comme voulu en statique, et c'est subtile : Utiliser l'unnumbered sur l'interface Tunnel TE/MPLS en IOS-XE engendre une impossibilité de faire du dynamic dans les path options ! https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-16-12/segrt-xe-16-12-book/sr-te-ospf.html#con_1056159 Voila, si des gens maquettent/font du SR avec des interfaces Tunnel MPLS-TE, ou avec des LSP on-demand, je suis intéressé par votre feedback ou par des corrections ! Le 21-09-2020 21:50, Fabien VINCENT FrNOG via frnog a écrit : Hello la liste, J'ai un petit lab pour tester / appréhender un peu mieux la magic hype de SR avec TE (Fwding MPLS) sur CSR1000v tournant sous IOS-XE/16.12 (Gibraltar) (pas si hype, mais mon idée chez SR-MPLS first, on verra SRv6 avec XR plus tard :p) SR basé sur IGP avec SR preferred fonctionne à priori parfaitement bien. R1#show segment-routing attributes ipv4 sr_label_preferred : Yes explicit_null : No R1#show mpls traffic-eng segment-routing summary IGP Area[1]: ospf 1 area 0, Strict SPF Disabled: Nodes: IGP Id: 192.168.0.0, MPLS TE Id: 192.168.0.0, OSPF area 0 3 links with segment-routing adjacency SID IGP Id: 192.168.0.1, MPLS TE Id: 192.168.0.1, OSPF area 0 2 links with segment-routing adjacency SID IGP Id: 192.168.0.2, MPLS TE Id: 192.168.0.2, OSPF area 0 3 links with segment-routing adjacency SID IGP Id: 192.168.0.4, MPLS TE Id: 192.168.0.4, OSPF area 0 2 links with segment-routing adjacency SID Prefixes: 192.168.0.0/32, SID index: 1000 192.168.0.1/32, SID index: 1 192.168.0.2/32, SID index: 2 192.168.0.4/32, SID index: 4 Total: Node Count : 4 Adjacency-SID Count: 20 Prefix-SID Count : 4 Grand Total: Node Count : 4 Adjacency-SID Count: 20 Prefix-SID Count : 4 IGP Areas Count: 1 Que ce soit en mode auto tunnel P2P ou avec un tunnel pré-configuré en unnumbered Loopback0, aucun soucis de forwarding MPLS / règles de TE, je peux faire ce que je veux et ce qu'il me plaît, soit avec des routes static + auto-tunnel + explicit path, soit en tunnel static + explicit path comme ci dessous. R1#sh ip explicit-paths name H2_VIA_R0 PATH H2_VIA_R0 (strict source route, path complete, generation 6) 1: next-address 192.168.0.0 2: next-address 192.168.0.2 10: next-label 2 20: next-label 20002 R1#sh mpls traffic-eng tunnels tunnel 2 Name: R1_t2 (Tunnel2) Destination: 192.168.0.2 Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type explicit H2_VIA_R0 (Basis for Setup) Config Parameters: Bandwidth: 0kbps (Global) Priority: 6 6 Affinity: 0x0/0x Metric Type: IGP (interface) Path Selection: Protection: any (default)
Re: [FRnOG] [TECH] SR(-TE) MPLS
Je me réponds à moi même (personne ne fait de SR-(TE)-MPLS en FR ? Moi qui croyait que certains SP l'avaient déjà implémenté WW ^^) Je me suis effectivement emmêlé les pinceaux (mode n00b), le principe de dynamic LSP avec coloration / on-demand semble uniquement possiblement avec un PCE type ODL, ou avec MP-BGP, mais pas directement possible avec l'IGP (OSPFv2 ici en l'occurrence). Quelqu'un pour me confirmer / infirmer ça ? Il est donc obligatoire de faire des interfaces tunnels, qu'elles soient automatiques (auto-tunnel P2P) ou statiques sans PCE ? Pas possible de faire du on-demand policy SR localement ? Pour l'unnumbered, il y a bien une limitation qui faisait que cela ne fonctionnait pas comme voulu en statique, et c'est subtile : Utiliser l'unnumbered sur l'interface Tunnel TE/MPLS en IOS-XE engendre une impossibilité de faire du dynamic dans les path options ! https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-16-12/segrt-xe-16-12-book/sr-te-ospf.html#con_1056159 Voila, si des gens maquettent/font du SR avec des interfaces Tunnel MPLS-TE, ou avec des LSP on-demand, je suis intéressé par votre feedback ou par des corrections ! Le 21-09-2020 21:50, Fabien VINCENT FrNOG via frnog a écrit : Hello la liste, J'ai un petit lab pour tester / appréhender un peu mieux la magic hype de SR avec TE (Fwding MPLS) sur CSR1000v tournant sous IOS-XE/16.12 (Gibraltar) (pas si hype, mais mon idée chez SR-MPLS first, on verra SRv6 avec XR plus tard :p) SR basé sur IGP avec SR preferred fonctionne à priori parfaitement bien. R1#show segment-routing attributes ipv4 sr_label_preferred : Yes explicit_null : No R1#show mpls traffic-eng segment-routing summary IGP Area[1]: ospf 1 area 0, Strict SPF Disabled: Nodes: IGP Id: 192.168.0.0, MPLS TE Id: 192.168.0.0, OSPF area 0 3 links with segment-routing adjacency SID IGP Id: 192.168.0.1, MPLS TE Id: 192.168.0.1, OSPF area 0 2 links with segment-routing adjacency SID IGP Id: 192.168.0.2, MPLS TE Id: 192.168.0.2, OSPF area 0 3 links with segment-routing adjacency SID IGP Id: 192.168.0.4, MPLS TE Id: 192.168.0.4, OSPF area 0 2 links with segment-routing adjacency SID Prefixes: 192.168.0.0/32, SID index: 1000 192.168.0.1/32, SID index: 1 192.168.0.2/32, SID index: 2 192.168.0.4/32, SID index: 4 Total: Node Count : 4 Adjacency-SID Count: 20 Prefix-SID Count : 4 Grand Total: Node Count : 4 Adjacency-SID Count: 20 Prefix-SID Count : 4 IGP Areas Count: 1 Que ce soit en mode auto tunnel P2P ou avec un tunnel pré-configuré en unnumbered Loopback0, aucun soucis de forwarding MPLS / règles de TE, je peux faire ce que je veux et ce qu'il me plaît, soit avec des routes static + auto-tunnel + explicit path, soit en tunnel static + explicit path comme ci dessous. R1#sh ip explicit-paths name H2_VIA_R0 PATH H2_VIA_R0 (strict source route, path complete, generation 6) 1: next-address 192.168.0.0 2: next-address 192.168.0.2 10: next-label 2 20: next-label 20002 R1#sh mpls traffic-eng tunnels tunnel 2 Name: R1_t2 (Tunnel2) Destination: 192.168.0.2 Status: Admin: up Oper: up Path: valid Signalling: connected path option 10, (SEGMENT-ROUTING) type explicit H2_VIA_R0 (Basis for Setup) Config Parameters: Bandwidth: 0kbps (Global) Priority: 6 6 Affinity: 0x0/0x Metric Type: IGP (interface) Path Selection: Protection: any (default) Path-selection Tiebreaker: Global: not set Tunnel Specific: not set Effective: min-fill (default) Hop Limit: disabled [ignore: Explicit Path Option with all Strict Hops] Cost Limit: disabled Path-invalidation timeout: 1 msec (default), Action: Tear AutoRoute: enabled LockDown: disabled Loadshare: 0 [0] bw-based auto-bw: disabled Fault-OAM: disabled, Wrap-Protection: disabled, Wrap-Capable: No Active Path Option Parameters: State: explicit path option 10 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled History: Tunnel: Time since created: 13 minutes, 45 seconds Time since path change: 13 minutes, 11 seconds Number of LSP IDs (Tun_Instances) used: 11 Current LSP: [ID: 11] Uptime: 13 minutes, 11 seconds Tun_Instance: 11 Segment-Routing Path Info (ospf 1 area 0) Segment0[Node]: 192.168.0.0, Label: 26000 Segment1[Node]: 192.168.0.2, Label: 25002 Segment2[ - ]: Label: 2 Segment3[ - ]: Label: 20002 (Ne pas être trop exigeant sur les Node/Link/Label utilisés, c'est du test, donc forcément pas toujours très propre) En revanche, dès que j'essaie de configurer des politiques / coloration pour privilégier la métrique TE over IGP, j'ai toujours 2 problèmes majeurs R1#show segment-routing traffic-eng policy all Name: foo (Color: 102 End-point: 192.168.0.2) Status: Admin: up, Operational: down for
