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 20000
    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: 0 kbps (Global) Priority: 6 6 Affinity: 0x0/0xFFFF
    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: 10000 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: 20000
    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 00:00:12 (since 09-21 19:33:11.215)
  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: 16002
      Allocation mode: explicit
      State: Init

Sauf que je ne trouve aucune doc mentionnant ce problème de "source
address" (voir de cspf failed ??). Ca me semble lié à l'unnumbered
sous IOS-XE, mais soit je suis aveugle, soit j'ai le syndrome tête
dans le guidon. Est ce que quelqu'un à déjà mis en place de la
coloration de traffic / policy TE avec SR MPLS sous IOS-XE ? Y aun
petit truc de config que j'ai zappé ?

Est ce que je me trompe de voie ? J'ai loupé une logique quelque part ?

Merci d'avance pour l'aide ;)

Je vais tenter sous IOSXRv, mais la RAM de mon laptop pourrait vous
dire merci :)

++

--
Fabien VINCENT
_@beufanet_


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à