Re: [FRnOG] [TECH] -- Cisco Route-Map sur PE MPLS

2017-02-19 Par sujet Steeve BEAUVAIS 
Bonjour,

Selon les architectures il peut y avoir des sites distants plus simples
(pas de répartition de charge qui sont dans cette même VRF).
Découper en 2 VRF va demander des import/export qui vont être plus
compliqués à mettre en place à exploiter et à troubleshooter.

J'utilise déjà actuellement une solution avec une VRF pour l'ADSL une VRF
pour la SDSL et la VRF globale pour collecter les autres sites et faire les
import/export.
Je cherche a simplifier tout ça.

J'ai pour le moment 2 pistes:

Celle de la NAT évoqué plus tot.

Ou alors faire arriver les fluxs sur un autre PE créer une interco /30
entre ce PE annexe et le PE qui collecte la SDSL dans la VRF et appliquer
la route-map sur cette interco.

Cordialement,





Le 18 février 2017 à 12:19, Christophe LUCAS  a
écrit :

> Salut,
>
> Tu peux pas justement au contraire utilisé deux VRF ?
> Une pour trafic métier et l’autre pour internet.
>
> Cdt,
> ---
> Christophe LUCAS
> christo...@lucas.fr.eu.org
> ---
>
>
>
>
> Le 17 févr. 2017 à 15:25, Steeve BEAUVAIS  a
> écrit :
>
> Bonjour,
>
> Je suis face à un petit obstacle technique sur une environnement MPLS full
> cisco.
> J'aimerais mettre en place une répartition de charge par flux sur un CPE
> qui a 2 liaisons montées en PPP (une ADSL et une SDSl par exemple).
> Je veux par exemple, envoyer que les flux web sur l'ADSL et le reste sur
> la SDSL et pareil en descendant.
>
> En montant pas de problème, je fais une route 0 vers mon dialer 1 (SDSL)
> et une route map avec un set interface dialer 2 (ADSL) appliqué sur les
> interface vlan du LAN client.
>
> Le soucis que j'ai est en descendant. Je fais en sorte que seul le PE qui
> collecte la SDSL annonce les réseaux clients pour qu'il fasse la
> répartition.
> Ce PE a connaissance des réseaux clients via les negociations PPP.
>
> J'aimerais lui appliquer la même route-map que sur le CPE pour envoyer les
> flux web vers le PE qui collecte l'ADSL.
> Et la c'est le drame.
>
> Il faudrait que j'applique la route-map sur l'interface MPLS du PE, mais
> elle ne match pas à cause des labels.
>
> Auriez-vous une idée pour faire en sorte que cette route-map puisse
> fonctionner?
>
> Je vous met ci-dessous un schéma fait maison pour illustrer ma question.
> Le MPLS est en GRT et le CPE du client remonte dans une VRF.
>
> 
>
> Cordialement,
> Steeve Beauvais
>
>
>
>
>
>

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

[FRnOG] [TECH] Re: [MISC] RFC 8092: BGP Large Communities Attribute

2017-02-19 Par sujet Stephane Bortzmeyer 
On Sun, Feb 19, 2017 at 02:23:36PM +0100,
 Clement Cavadore  wrote 
 a message of 12 lines which said:

> Je me demandais quand est-ce que tu nous ferais enfin un article à ce
> sujet. Tu vieillis Stéphane, ca a été long à venir :D

Et puis il fallait que je termine d'abord mon article sur le RFC 1997,
qui était en TODO depuis le siècle dernier :-)


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

[FRnOG] [TECH] Re: [MISC] RFC 8092: BGP Large Communities Attribute

2017-02-19 Par sujet Stephane Bortzmeyer 
On Sun, Feb 19, 2017 at 02:23:36PM +0100,
 Clement Cavadore  wrote 
 a message of 12 lines which said:

> Je me demandais quand est-ce que tu nous ferais enfin un article à
> ce sujet. Tu vieillis Stéphane, ca a été long à venir :D

Des problèmes à compiler bgpdump, puis à trouver où étaient les
grandes communautés dans les dumps MRT de RouteViews :-)


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

[TECH] Re: [FRnOG] [MISC] RFC 8092: BGP Large Communities Attribute

2017-02-19 Par sujet Clement Cavadore 
Bon dimanche,

On Sun, 2017-02-19 at 14:12 +0100, Stephane Bortzmeyer wrote:
> Ce RFC normalise un nouvel attribut des annonces BGP, « "Large
> Communities" ».

Je me demandais quand est-ce que tu nous ferais enfin un article à ce
sujet. Tu vieillis Stéphane, ca a été long à venir :D

-- 
Clément Cavadore


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

[FRnOG] [TECH] RFC 8092: BGP Large Communities Attribute

2017-02-19 Par sujet Stephane Bortzmeyer 
http://www.bortzmeyer.org/8092.html



Auteur(s) du RFC: J. Heitz (Cisco), J. Snijders
  (NTT), K. Patel (Arrcus), I. Bagdonas
  (Equinix), N. Hilliard (INEX)

Chemin des normes




Ce RFC normalise un nouvel attribut des annonces BGP, « "Large 
Communities" ». Les « communautés » BGP sont des courtes données 
collées aux annonces BGP et qui permettent d'indiquer certaines 
caractéristiques des routes. Les décisions des routeurs peuvent 
utiliser ces caractéristiques. Mais les communautés originales étaient 
trop courtes (seulement quatre octets) : le nouvel attribut permet des 
communautés de douze octets.

Les « communautés » sont définies dans le RFC 1997. On les apprend via 
les documentations des opérateurs ou des points d'échange. Par exemple, 
celle du point d'échange irlandais 
 (section « "Community 
based prefix filtering" »). Un attribut COMMUNITY dans une annonce BGP 
peut comporter plusieurs communautés. Traditionnellement, les quatre 
octets des communautés initiales sont utilisées pour représenter le 
numéro d'AS dans les deux premiers octets (ainsi, une communauté est 
mondialement unique, par ce système d'allocation à deux niveaux), et 
des données spécifiques à l'AS dans les deux suivants. Évidemment, avec 
les numéros d'AS de quatre octets du RFC 6793, ça ne marchait plus. 
D'où cet attribut LARGE_COMMUNITY, désormais stocké dans le registre 
IANA 
 sous le numéro ("type code") 32. (Il y a bien eu une autre 
tentative d'augmenter la taille des communautés, dans le RFC 4360, mais 
pas suffisamment pour que les AS à quatre octets puissent être utilisés 
partout.) Comme pour les « petites » communautés, ces grandes 
communautés dans une annonce forment un ensemble (donc, non ordonné) : 
plusieurs routeurs auront pu ajouter une communauté à cet ensemble.

Les communautés sont importantes car elles sont utilisées dans la 
politique de routage. BGP ne cherche pas à trouver le meilleur chemin : 
il fait du routage politique, où les décisions sont prises en fonction 
de choix faits par les opérateurs (privilégier tel ou tel lien pour le 
trafic entrant, par exemple). Les informations contenues dans une 
annonce BGP (section 4.3 du RFC 4271) habituelle ne sont pas toujours 
suffisantes, et c'est pour cela que les communautés ont été introduites 
par le RFC 1997, pour ajouter des informations utiles, comme l'endroit 
où telle route a été apprise. L'attribut COMMUNITY (numéro 8) est 
transitif (section 5 du RFC 4271), ce qui veut dire qu'après réception 
d'une annonce, il est transmis aux autres routeurs (d'où l'importance 
de marquer la communauté avec un numéro d'AS, pour que les communautés 
soient uniques au niveau mondial, sans qu'il existe un registre central 
des communautés).

Le nouvel attribut LARGE_COMMUNITY (numéro 32) est également optionnel 
et transitif (section 2 de notre RFC). Il se compose d'un ensemble de 
grandes communautés, chacune étant stockée sur douze octets. L'idée est 
qu'on utilise les quatre premiers octets pour identifier l'AS (ce qui 
va bien avec les grands AS du du RFC 6793), ce qui va garantir 
l'unicité des communautés. Le nombre de communautés dans un attribut 
LARGE_COMMUNITY est donné par le champ Longueur de l'attribut, les 
attributs BGP étant encodés en TLV (cf. RFC 4271, section 4.3).
 
En cas d'agrégation de routes (section 3 du RFC), il est recommandé 
d'utiliser comme communautés l'union des ensembles de communautés des 
différentes annonces.

Et comment on va représenter ces grandes communautés sous forme texte ? 
(Sur le câble, entre les deux routeurs, c'est du binaire, en gros 
boutien, cf. RFC 4271, section 4.) On note trois groupes de quatre 
octets, séparés par un deux-points, par exemple 2914:65400:38016 
(section 4 de notre RFC), où le premier champ est presque toujours 
l'AS.

Comme toutes les grandes communautés font exactement douze octets, si 
le champ Longueur de l'attribut n'est pas un multiple de douze, 
l'attribut est invalide, et le routeur qui reçoit cette annonce doit la 
gérer comme étant un retrait de la route (RFC 7606).

Un point de sécurité important en section 6 du RFC ; en gros, les 
grandes communautés ont quasiment les mêmes propriétés de sécurité que 
les anciennes petites communautés. Notamment, elles ne sont pas 
protégées contre une manipulation en transit : tout AS dans le chemin 
peut ajouter des communautés (même « mensongères », c'est-à-dire 
indiquant un autre AS que le sien) ou retirer des communautés 
existantes). La section 11 du RFC 7454 donne quelques détails à ce 
sujet. Ce problème n'est pas spécifique aux communautés, c'est un 
problème général de BGP. L'Internet n'a pas de chef et il est donc 
difficile de concevoir un mécanisme permettant de garantir 
l'authenticité des annonces.

Il