Re: [FRnOG] [TECH] IOS XE et validation RPKI: Comportements étranges (bgp bestpath prefix-validate disable)
Re, On Wed, 2022-05-25 at 16:52 +0200, Fabien VINCENT FrNOG via frnog wrote: > N'hésites pas à partager ta trouvaille. Ma trouvaille, c'est qu'IOS XE a vraiment des comportement incompréhensibles (pour ne pas dire clownesques), pour le coup. Je ne suis arrivé à rien de vraiment concluant: - Soit j'utilise la validation RPKI, et je me retrouve avec une implémentation du bgp best path selection toute pétée: Depuis quand l'état "valide" d'une route RPKI est supérieur à une localpref ?! --> Et du coup, comme la route choisie par le routeur est apprise en eBGP, au passage, elles ne sont plus tagguées avec les communautés qui vont bien, donc mes downstreams ne sont plus annoncés sur les IXP portés par le dit routeur. - Soit je n'utilise pas de validation RPKI, et je me retrouve avec des routes potentiellement invalides dans mon IBGP. J'ai eu l'idée saugrenue de faire un match en IBGP des communautés de mes downstream/origin et ensuite de forcer un état RPKI valid. Sauf qu'on peut matcher un rpki state, mais pas le positionner, donc retour à la case départ. Bref, l'état RPKI d'une route ce n'est pas un attribut, mais les génies de chez Cisco semblent penser l'inverse. Si quelqu'un a une autre idée, je suis preneur... -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IOS XE et validation RPKI: Comportements étranges (bgp bestpath prefix-validate disable)
Oui je crois que j'ai lu /répondu un peu vite à ton message. En fait j'ai souvenir d'un truc que j'avais documenté sur IOS-XR qui m'avait déjà cassé les pieds. https://beufa.net/blog/rpki-use-routinator-rtr-cache-validator-cisco-ios-xr/ router bgp 64567 ! address-family ipv4 unicast bgp origin-as validation enable bgp bestpath origin-as use validity => ne semble pas dispo sur XE. bgp bestpath origin-as allow invalid ! address-family ipv6 unicast bgp origin-as validation enable bgp bestpath origin-as use validity bgp bestpath origin-as allow invalid ! La seule doc que j'ai trouvé sur IOS-XE c'est assez vieux : https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/bgp-origin-as-validation.pdf Le comportement que tu rencontres est bien documenté : During BGP best path selection, the default behavior, if neither of the above options is configured, is that the system will prefer prefixes in the following order: • Those with a validation state of valid. • Those with a validation state of not found. • Those with a validation state of invalid (which, by default, will not be installed in the routing table). These preferences override metric, local preference, and other choices made during the bestpath computation. The standard bestpath decision tree applies only if the validation state of the two paths is the same Donc un valid c'est un tie breaker prioritaire sur le best selection path algorithm dans la selection BGP, ce qui est exactement ce que tu rencontres. Par contre effectivement, j'ai lu trop vite, mais si tu ajoutes le allow-invalid, ca va juste autoriser les invalid a être selected au lieu de drop dans le best path. Il manque donc le use-validity comme sur IOS-XR. Sinon, ce que j'avais fait par le passé pour éviter les problèmes de BGP algorithm à la sauce cisco qui change sur des versions mineures (si,si) : - route-map ou RPL - drop state invalid - - if roa valid => local-pref ou med ++ et je désactive la feature de BGP best path selection n°1 qui tie break si ROV=valid>>>ROV=unknown Bon courage, ca me rappelle pourquoi quelqu'un avait demandé la suppression des MAY dans les RFC :p N'hésites pas à partager ta trouvaille. Le 25-05-2022 16:20, Clement Cavadore a écrit : Hello Fabien, On Wed, 2022-05-25 at 09:30 +0200, Fabien VINCENT FrNOG via frnog if the BGP—Origin AS Validation feature is enabled, and you want to allow invalid prefixes to be used as the best path, even if valid prefixes are available. Thus, you have control over announcing invalid networks, but preferring them less than valid and not-found prefixes. Also, the downstream peer can modify path attributes based on a route map that matches invalid prefixes Je ne suis pas devant mon cisco, mais pour le coup, ce ne sont pas des "invalid" que je cherche à exploiter, juste des unknown. Il faudrait que je regarde si la directive existe avec un "allow-unknown", pour le coup, réponse ce soir :) Merci, Clément --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Fabien VINCENT _@beufanet_ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IOS XE et validation RPKI: Comportements étranges (bgp bestpath prefix-validate disable)
Hello Fabien, On Wed, 2022-05-25 at 09:30 +0200, Fabien VINCENT FrNOG via frnog > if the BGP—Origin AS Validation feature is > enabled, and you want to allow invalid prefixes > to be used as the best path, even if valid prefixes are available. > Thus, you have control over announcing invalid > networks, but preferring them less than valid and not-found > prefixes. > Also, the downstream peer can modify > path attributes based on a route map that matches invalid prefixes > Je ne suis pas devant mon cisco, mais pour le coup, ce ne sont pas des "invalid" que je cherche à exploiter, juste des unknown. Il faudrait que je regarde si la directive existe avec un "allow-unknown", pour le coup, réponse ce soir :) Merci, Clément --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IOS XE et validation RPKI: Comportements étranges (bgp bestpath prefix-validate disable)
Hola !
router bgp
address-family {ipv4 | ipv6} unicast
bgp bestpath prefix-validate allow-invalid
?
From the cisco doc :
Perform this task if the BGP—Origin AS Validation feature is enabled,
and you want to allow invalid prefixes
to be used as the best path, even if valid prefixes are available. Thus,
you have control over announcing invalid
networks, but preferring them less than valid and not-found prefixes.
Also, the downstream peer can modify
path attributes based on a route map that matches invalid prefixes
Bon courage !
Le 25-05-2022 09:08, Clement Cavadore a écrit :
Hello,
Je suis confronté à un probleme étrange sur IOS XE.
Voici le contexte:
- 1 ASR1002-X
- Qui fait de la validation RPKI sur les sessions eBGP (pas iBGP)
- Qui fait du peering sur un IXP
- Qui recoit ses routes du réseau depuis des RR (notamment des
downstreams)
Par défaut, j'ai remarqué que l'état RPKI de la route était pris en
compte dans le BGP selection path, chose qui m'emmerde car si une route
recue en eBGP est valide, il la préfere à une route "unknown" recue en
IBGP, et ce même si la localpref est supérieure sur celle recue en
interne (car downstream):
Ici, en l'occurence, selon la localpref, il devrait plutot choisir la
premiere, mais par défaut, il choisit celle d'apres:
BGP routing table entry for 193.43.214.0/24, version 36202932
Paths: (8 available, best #7, table default)
Advertised to update-groups:
16 17
Refresh Epoch 1
44097
193.164.153.126 (metric 5020) from 193.164.153.2 (193.164.153.2)
Origin incomplete, metric 500, localpref 600, valid, internal
Community: 34019:44097 65512:20001
Originator: 193.17.192.143, Cluster list: 193.164.153.2
path 7F8057EB3658 RPKI State not found
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
(...)
43100 200780 44097
91.206.52.207 from 91.206.52.252 (91.206.52.252)
Origin IGP, metric 400, localpref 400, valid, external, best
Community: 34019:65000 34019:65130 34019:65133 65512:20009
unknown transitive attribute: flag 0xE0 type 0x20 length 0x24
value A5EC FC00 000B A5EC
FC00 0015 A5EC FC00
001F
path 7F805E0F0418 RPKI State valid
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
(...)
Du coup, je me suis inspiré du lien suivant:
https://bgpfilterguide.nlnog.net/guides/reject_invalids/
... pour revoir ma conf, et rajouter "bgp bestpath prefix-validate
disable" dans la conf de mes address-family en BGP, en rajoutant un
statement dans mes route-map rejetant les rpki invalid, et ca semble...
juste désactiver RPKI. En effet, on ne voit plus du tout d'état RPKI,
alors que 1.1.1.0/24 est supposé être signé:
RPKI validation codes: V valid, I invalid, N Not found
Network Next HopMetric LocPrf Weight Path
*> 1.0.0.0/24 91.206.52.192 100400 0 13335
i
*> 1.1.1.0/24 91.206.52.192 100400 0 13335
i
BGP routing table entry for 1.1.1.0/24, version 27436194
Paths: (6 available, best #5, table default)
Advertised to update-groups:
16 17
Refresh Epoch 1
(...)
13335, (aggregated by 13335 162.158.148.1)
91.206.52.192 from 91.206.52.192 (162.158.148.1)
Origin IGP, metric 100, localpref 400, valid, external, best
Community: 34019:65000 34019:65130 34019:65131 65512:20009
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
Une idée de comment faire en sorte que IOS XE fasse de la validation
RPKI proprement ?
A noter: Il n'est pas concevable de faire de la validation RPKI reçues
sur les routes en IBGP, car on reçoit des RR des more specific de nos
subnets (que l'on redistribue en BGP plutot qu'en ISIS), et il serait
contre productif de faire des ROA autorisant jusqu'au /32 + /128 de nos
supernets :)
Merci par avance pour vos lumières,
--
Fabien VINCENT
_@beufanet_
---
Liste de diffusion du FRnOG
http://www.frnog.org/
[FRnOG] [TECH] IOS XE et validation RPKI: Comportements étranges (bgp bestpath prefix-validate disable)
Hello, Je suis confronté à un probleme étrange sur IOS XE. Voici le contexte: - 1 ASR1002-X - Qui fait de la validation RPKI sur les sessions eBGP (pas iBGP) - Qui fait du peering sur un IXP - Qui recoit ses routes du réseau depuis des RR (notamment des downstreams) Par défaut, j'ai remarqué que l'état RPKI de la route était pris en compte dans le BGP selection path, chose qui m'emmerde car si une route recue en eBGP est valide, il la préfere à une route "unknown" recue en IBGP, et ce même si la localpref est supérieure sur celle recue en interne (car downstream): Ici, en l'occurence, selon la localpref, il devrait plutot choisir la premiere, mais par défaut, il choisit celle d'apres: >>BGP routing table entry for 193.43.214.0/24, version 36202932 >>Paths: (8 available, best #7, table default) >> Advertised to update-groups: >> 16 17 >> Refresh Epoch 1 >> 44097 >>193.164.153.126 (metric 5020) from 193.164.153.2 (193.164.153.2) >> Origin incomplete, metric 500, localpref 600, valid, internal >> Community: 34019:44097 65512:20001 >> Originator: 193.17.192.143, Cluster list: 193.164.153.2 >> path 7F8057EB3658 RPKI State not found >> rx pathid: 0, tx pathid: 0 >> Refresh Epoch 1 >>(...) >> 43100 200780 44097 >>91.206.52.207 from 91.206.52.252 (91.206.52.252) >> Origin IGP, metric 400, localpref 400, valid, external, best >> Community: 34019:65000 34019:65130 34019:65133 65512:20009 >> unknown transitive attribute: flag 0xE0 type 0x20 length 0x24 >>value A5EC FC00 000B A5EC >> FC00 0015 A5EC FC00 >> 001F >> path 7F805E0F0418 RPKI State valid >> rx pathid: 0, tx pathid: 0x0 >> Refresh Epoch 1 >>(...) Du coup, je me suis inspiré du lien suivant: https://bgpfilterguide.nlnog.net/guides/reject_invalids/ ... pour revoir ma conf, et rajouter "bgp bestpath prefix-validate disable" dans la conf de mes address-family en BGP, en rajoutant un statement dans mes route-map rejetant les rpki invalid, et ca semble... juste désactiver RPKI. En effet, on ne voit plus du tout d'état RPKI, alors que 1.1.1.0/24 est supposé être signé: >> RPKI validation codes: V valid, I invalid, N Not found >> >> Network Next HopMetric LocPrf Weight Path >> *> 1.0.0.0/24 91.206.52.192 100400 0 13335 i >> *> 1.1.1.0/24 91.206.52.192 100400 0 13335 i >>BGP routing table entry for 1.1.1.0/24, version 27436194 >>Paths: (6 available, best #5, table default) >> Advertised to update-groups: >> 16 17 >> Refresh Epoch 1 >>(...) >> 13335, (aggregated by 13335 162.158.148.1) >>91.206.52.192 from 91.206.52.192 (162.158.148.1) >> Origin IGP, metric 100, localpref 400, valid, external, best >> Community: 34019:65000 34019:65130 34019:65131 65512:20009 >> rx pathid: 0, tx pathid: 0x0 >> Refresh Epoch 1 Une idée de comment faire en sorte que IOS XE fasse de la validation RPKI proprement ? A noter: Il n'est pas concevable de faire de la validation RPKI reçues sur les routes en IBGP, car on reçoit des RR des more specific de nos subnets (que l'on redistribue en BGP plutot qu'en ISIS), et il serait contre productif de faire des ROA autorisant jusqu'au /32 + /128 de nos supernets :) Merci par avance pour vos lumières, -- Clément Cavadore signature.asc Description: This is a digitally signed message part
