BGP · remove-private-as & AS

Pourquoi ces deux commandes existent

🧹 remove-private-as — Nettoyage ISP

Un client connecté à un ISP utilise souvent un AS privé (range 64512–65535). Si l'ISP propage ce chemin vers Internet, les AS privés ne doivent pas y apparaître — ils n'ont pas de signification globale et peuvent provoquer des filtrages.

→ L'ISP applique remove-private-as sur la session eBGP sortante vers ses peers upstream.

🔄 as-override — MPLS VPN même AS

Dans un VPN MPLS L3, si deux sites d'un même client partagent le même numéro d'AS, les routes échangées contiennent l'AS client. Le site destinataire les rejetterait (loop prevention).

→ Le PE applique as-override pour remplacer l'AS client par l'AS du provider dans le path avant l'envoi.

Plages d'AS privés

RFC	Plage	Type	Usage
RFC 1930	`64512 – 65534`	2-octets privés	Clients ISP, labs, use-cases internes. Ne doivent pas apparaître sur Internet public.
—	`65535`	2-octets réservé	Réservé (IANA). Parfois traité comme privé par certaines implémentations.
RFC 6996	`4200000000 – 4294967294`	4-octets privés	Plage privée 4-octets. Équivalent 4B des 64512–65534.
RFC 6996	`4294967295`	4-octets réservé	`0xFFFFFFFF` — réservé IANA.

⚠️

Par défaut, remove-private-as ne supprime que la plage 64512–65534 (RFC 1930). La plage 4-octets RFC 6996 (4200000000+) n'est supprimée que si la plateforme et la version IOS supportent explicitement ce comportement. Vérifier avec show ip bgp neighbors X advertised-routes.

Récapitulatif des commandes

Commande	Sens	Effet	Use case
`neighbor X remove-private-as`	Outbound	Supprime les AS privés du path envoyé au peer	ISP vers upstream, cliente AS privé
`neighbor X remove-private-as all`	Outbound	Supprime tous les AS privés même si path mixte public+privé	ISP avec clients multi-hops privés
`neighbor X remove-private-as all replace-as`	Outbound	Remplace les AS privés par le local AS au lieu de les supprimer	Préserver la longueur du path
`neighbor X as-override`	Outbound (PE→CE)	Remplace l'AS du peer dans le path par l'AS local	MPLS L3VPN sites même AS client

Principe de fonctionnement

La commande remove-private-as est configurée sur un routeur PE/ISP, sur la session eBGP sortante vers un peer upstream. Elle agit comme un filtre sur l'AS_PATH : avant l'envoi de l'UPDATE, les numéros AS privés sont retirés (ou remplacés).

Direction

Outbound uniquement

Modifie la table locale ?

Non — filtre à l'envoi seulement

Condition de déclenchement

AS privé dans le path reçu du client

Affecte les routes apprises en iBGP ?

Non — seulement celles du peer configuré

Les 3 variantes — Syntaxe complète

BASIQUE neighbor X remove-private-as

Supprime les AS privés (64512–65534) du path. Condition : le comportement varie selon IOS. Sur IOS classique : retire uniquement si l'AS local n'est pas dans le path. Sur IOS-XE : retire dans tous les cas sauf si public+privé mélangés en tête.

AS_PATH reçu du client

Avant envoi upstream

65001 64800

AS_PATH envoyé upstream

Après remove-private-as

vide — tous les AS étaient privés

ALL neighbor X remove-private-as all

Supprime tous les AS privés même quand le path contient un mélange de public et privé. Sans all, si des AS publics sont présents dans le path, les AS privés ne sont pas retirés.

AS_PATH reçu — mixte

Path avec AS public + AS privé

200 65001 100 64512

Avec `all` — privés supprimés

Envoyé upstream

200 100

⚠️

Sans all : si le path est 200 65001 100 (mélange), les AS privés ne sont pas retirés. Avec all : ils sont systématiquement supprimés.

REPLACE neighbor X remove-private-as all replace-as

Au lieu de supprimer les AS privés, les remplace par le numéro d'AS local. Préserve la longueur du path (utile pour le trafic engineering ou quand des AS en aval attendent une certaine longueur).

AS_PATH reçu du client

ISP = AS 1000 · Client = AS 65001

65001 64800

Avec replace-as

Envoyé upstream

1000 1000 ← AS privés remplacés par AS ISP

Configuration IOS complète

! ISP (AS 1000) — peer upstream (AS 500) et client (AS 65001)

router bgp 1000
  ! Session vers client (reçoit les routes avec AS 65001 dans le path)
  neighbor 10.0.0.2 remote-as 65001

  ! Session vers upstream — on nettoie le path avant envoi
  neighbor 198.51.100.1 remote-as 500
  neighbor 198.51.100.1 remove-private-as all replace-as

! Vérification — voir ce qui est réellement envoyé au peer 198.51.100.1
show ip bgp neighbors 198.51.100.1 advertised-routes

! Sur IOS-XE — effacer le soft-reset outbound après modification
clear ip bgp 198.51.100.1 soft out

Règle de suppression — Conditions précises

Contenu du path	Sans `all`	Avec `all`	Avec `all replace-as`
`65001 64512` (tout privé)	Privés supprimés → vide	Privés supprimés → vide	Remplacés par local AS
`200 65001 100` (mixte)	Rien supprimé	65001 supprimé → `200 100`	65001 remplacé → `200 1000 100`
`65001 65001 65001` (prepend privé)	Tout supprimé → vide	Tout supprimé → vide	Remplacés → `1000 1000 1000`
`200 300` (tout public)	Inchangé	Inchangé	Inchangé

Problème résolu par as-override

Dans un déploiement MPLS L3VPN, plusieurs sites d'un même client peuvent utiliser le même numéro d'AS. Lorsque le PE propage une route d'un site A vers un site B, l'AS_PATH contient l'AS client. Le routeur CE du site B reconnaît son propre AS dans le path et rejette la route (loop prevention eBGP).

🔄

Problème : Site A (AS 65000) envoie route → PE la propage vers Site B (AS 65000) → Site B voit AS 65000 dans l'AS_PATH → rejet (own AS detected).

✅

Solution as-override : Le PE remplace l'AS source (65000) dans le path par son propre AS (ex: 100) avant envoi vers le CE destinataire. Le CE reçoit un AS_PATH sans son propre numéro → route acceptée.

Topologie MPLS L3VPN

Site A MPLS Backbone Site B CE-A ────────── PE-A ─────────────────────── PE-B ────────── CE-B AS 65000 AS 100 VRF CUSTOMER AS 100 AS 65000 Route 10.1.0.0/24 originée par CE-A (AS 65000). Sans as-override : CE-A → PE-A : AS_PATH = 65000 PE-A → PE-B : MP-BGP (AS_PATH = 65000 dans VPNv4) PE-B → CE-B : AS_PATH = 65000 ← CE-B voit son propre AS → REJET ✗ Avec "neighbor CE-B as-override" sur PE-B : PE-B → CE-B : AS_PATH = 100 (PE-B remplace 65000 par son AS 100) ← CE-B voit AS 100 → ACCEPTÉ ✓

Configuration PE — as-override

! PE-B (AS 100) — VRF CUSTOMER, session eBGP vers CE-B (AS 65000)

router bgp 100
  address-family ipv4 vrf CUSTOMER

    ! Session eBGP vers CE-B
    neighbor 192.168.1.2 remote-as 65000
    neighbor 192.168.1.2 activate
    neighbor 192.168.1.2 as-override   ← remplace AS65000 par AS100 dans le path

! Vérification
show bgp vpnv4 unicast vrf CUSTOMER neighbors 192.168.1.2 advertised-routes
show bgp vpnv4 unicast vrf CUSTOMER ! vérifier AS_PATH après substitution

Profil de la commande

Configuré sur

PE (Provider Edge)

Direction

Outbound (PE → CE)

Effet

Remplace AS du peer dans le path par l'AS local

Modifie table locale ?

Non — filtre à l'envoi

Contexte principal

MPLS L3VPN — sites même AS

Alternative côté CE

allow-as-in (côté récepteur)

as-override vs allow-as-in — Différence fondamentale

as-override — Côté émetteur (PE)

Le PE modifie le path avant envoi. Le CE reçoit un path propre, sans son propre AS. La loop prevention fonctionne normalement du côté CE — il n'a pas besoin de configuration spéciale.

! Sur PE-B uniquement
neighbor CE-B as-override

allow-as-in — Côté récepteur (CE)

Le CE accepte malgré son propre AS dans le path. La loop prevention est bypassée côté récepteur. Le path reçu contient toujours l'AS client (moins propre, moins sécurisé).

! Sur CE-B uniquement
neighbor PE-B allow-as-in 1

ℹ️

Bonne pratique : Préférer as-override côté PE. Le CE n'a pas besoin de configuration supplémentaire, et la loop prevention reste intacte du côté client. allow-as-in sur le CE est une alternative si le PE n'est pas sous votre contrôle (CE géré par le client).

Scénario 1 — ISP avec client AS privé

Client ISP Upstream Internet CE (AS 65001) ─eBGP─▶ PE-ISP (AS 1000) ─eBGP─▶ PEER-UPSTREAM (AS 500) CE annonce : 203.0.113.0/24 AS_PATH initial : 65001

CE → PE-ISP

eBGP · AS65001 → AS1000

↳ CE envoie UPDATE, PE-ISP reçoit

AS_PATH dans table PE-ISP

65001

PE-ISP → UPSTREAM

eBGP · remove-private-as all

↳ remove-private-as all actif sur cette session — 65001 supprimé

Sans remove-private-as

Reçu par UPSTREAM

1000 65001 ← AS privé visible sur Internet

Avec remove-private-as all

Reçu par UPSTREAM

1000 ← propre, AS privé retiré

Scénario 2 — MPLS VPN · as-override

Site A PE-A MP-BGP VPNv4 PE-B Site B CE-A (AS 65000) ─eBGP─ (AS 100) ─────────────────── (AS 100) ─eBGP─ CE-B (AS 65000) 10.1.0.0/24 10.2.0.0/24

CE-A → PE-A

eBGP · AS65000 → AS100

↳ CE-A annonce 10.1.0.0/24

AS_PATH reçu par PE-A (VRF CUSTOMER)

65000

PE-A → PE-B

MP-BGP VPNv4 · iBGP/MPLS

↳ Transport VPNv4 — AS_PATH préservé dans le VRF

AS_PATH dans VRF PE-B

65000

PE-B → CE-B

eBGP · as-override actif

↳ PE-B remplace AS65000 par son propre AS (100)

Sans as-override

CE-B reçoit

100 65000 ← own AS → REJET ✗

Avec as-override sur PE-B

CE-B reçoit

100 100 ← AS privé remplacé → ACCEPTÉ ✓

remove-private-as vs as-override vs allow-as-in

Critère	remove-private-as	as-override	allow-as-in
Configuré sur	Routeur émetteur (ISP/PE)	Routeur émetteur (PE)	Routeur récepteur (CE)
Effet	Supprime/remplace AS privés dans le path	Remplace l'AS du peer par l'AS local	Accepte malgré propre AS dans le path
Use case principal	ISP → upstream, client AS privé	MPLS L3VPN, sites même AS	MPLS L3VPN, sites même AS (alternatif)
Path côté récepteur	Propre (AS privés absents)	Propre (AS PE à la place)	Contient l'AS client (brut)
Loop prevention	Préservée	Préservée côté CE	Bypassée côté CE
Risque sécurité	Faible	Faible (contrôle PE)	Plus élevé (bypass loop check)
Modifie table locale ?	Non	Non	Non
Soft-reset requis après config ?	Oui — `clear bgp … soft out`	Oui — `clear bgp … soft out`	Oui — `clear bgp … soft in`

Quand utiliser quoi

ISP — Client avec AS privé, annonce vers Internet

→ neighbor UPSTREAM remove-private-as all (ou replace-as pour préserver la longueur)

MPLS L3VPN — Sites du même client avec même AS — PE sous contrôle opérateur

→ neighbor CE as-override sur le PE. Le CE n'a besoin de rien configurer.

MPLS L3VPN — Sites même AS — CE géré par le client (pas d'accès PE)

→ neighbor PE allow-as-in 1 sur le CE. Solution de repli quand le PE n'est pas configurable.

ISP — Client multi-homed AS privé, chemins différents

→ remove-private-as all replace-as sur chaque PE pour que les upstream voient l'AS ISP (longueur préservée, différentiation par MED ou prepend).

⚠️ Piège 1 — remove-private-as sans `all` ne retire pas les AS privés si le path est mixte

Si le path est 200 65001 100 (AS publics + AS privé), la version basique ne retire rien. Il faut remove-private-as all pour traiter les paths mixtes.

⚠️ Piège 2 — as-override et remove-private-as modifient la table BGP locale

Faux. Ces deux commandes sont des filtres outbound : ils ne modifient que les UPDATE envoyés au peer. La table BGP locale et les routes apprises restent intactes. La modification est visible uniquement via show bgp … neighbors X advertised-routes.

⚠️ Piège 3 — as-override remplace seulement l'AS du peer direct

Important : as-override remplace uniquement le numéro d'AS configuré pour ce neighbor (l'AS du peer). Si d'autres AS privés apparaissent dans le path (ex: AS en transit derrière le CE), ils ne sont pas touchés. Ce n'est pas un remove-private-as générique.

⚠️ Piège 4 — remove-private-as couvre la plage 4-octets RFC 6996

Dépend de la version IOS. La plage privée 4-octets (4200000000–4294967294) n'est pas toujours couverte automatiquement. Vérifier le comportement de la plateforme avant de supposer que les AS 4-octets privés sont supprimés.

⚠️ Piège 5 — as-override et allow-as-in peuvent coexister mais c'est redondant

Il ne faut pas configurer les deux simultanément pour le même flow. Si le PE a as-override, le CE voit déjà un path propre — allow-as-in sur le CE est inutile. Configurer les deux peut masquer des erreurs de configuration.

📌 Point d'attention — Soft reset obligatoire après modification

Après avoir ajouté ou retiré remove-private-as ou as-override, les routes déjà annoncées ne sont pas automatiquement réannoncées. Un soft reset outbound est nécessaire : clear ip bgp X soft out. Sans cela, le peer continue à recevoir l'ancien AS_PATH.

📌 Point d'attention — AS 65535 traitement spécial

L'AS 65535 est réservé (pas dans la plage privée RFC 1930 stricte qui va jusqu'à 65534). Son traitement par remove-private-as dépend de l'implémentation. Sur certaines versions IOS-XE, il est inclus dans la suppression. À vérifier selon la plateforme cible CCIE.

Cliquez sur une carte pour révéler la réponse.

Quelle est la plage d'AS privés 2-octets selon RFC 1930 ?

64512 – 65534. L'AS 65535 est réservé (pas strictement privé). La plage 4-octets privée (RFC 6996) est 4200000000–4294967294.

RFC 1930 + RFC 6996

Que fait remove-private-as all replace-as différemment de remove-private-as all ?

all seul supprime les AS privés du path. all replace-as les remplace par le numéro d'AS local. Résultat : la longueur du path est préservée.

Suppression vs remplacement

Pourquoi remove-private-as sans all ne fonctionne pas sur un path mixte public+privé ?

Sans all, IOS ne supprime les AS privés que si le path est entièrement privé. En présence d'un AS public dans le chemin, les AS privés sont conservés. Le mot-clé all force la suppression inconditionnelle des AS privés.

Comportement sans all = only-if-pure-private

Quel est le problème résolu par as-override dans un VPN MPLS L3 ?

Quand plusieurs sites d'un même client utilisent le même numéro d'AS, les routes entre sites contiennent l'AS client dans le path. Le CE destinataire rejette la route (loop prevention — own AS detected). as-override sur le PE remplace l'AS client par l'AS PE avant envoi vers le CE.

MPLS L3VPN — sites même AS

as-override est configuré côté PE ou côté CE ? Et dans quel sens ?

Configuré sur le PE, direction outbound (PE → CE). C'est le PE qui modifie le path avant envoi. Le CE n'a pas besoin de configuration supplémentaire.

PE outbound, pas sur le CE

Quelle est la différence entre as-override et allow-as-in ?

as-override : côté émetteur (PE), modifie le path avant envoi → le CE reçoit un path propre, loop prevention intacte. allow-as-in : côté récepteur (CE), bypass la loop prevention à la réception → le CE accepte malgré son propre AS dans le path.

Sender vs Receiver — propre vs bypass

Ces commandes modifient-elles la table BGP locale ?

Non. remove-private-as et as-override sont des filtres outbound. Ils ne modifient que les UPDATE envoyés au peer. La table BGP locale reste intacte. Les routes modifiées sont visibles via show bgp neighbors X advertised-routes.

Filtre outbound — table locale inchangée

Après avoir configuré remove-private-as, faut-il un soft reset ? Lequel ?

Oui. Les routes déjà annoncées ne sont pas automatiquement réannoncées. Il faut un soft reset outbound : clear ip bgp X soft out (ou clear bgp X soft out en IPv6/VPNv4). Sans cela, le peer continue à recevoir l'ancien path.

clear ip bgp X soft out

as-override remplace-t-il tous les AS privés du path ou seulement celui du peer ?

Seulement le numéro d'AS configuré pour ce neighbor (l'AS du peer direct). Si d'autres AS apparaissent dans le path au-delà du CE direct, ils ne sont pas touchés. Ce n'est pas un outil de nettoyage d'AS privés génériques.

Uniquement l'AS du neighbor configuré

Quelle commande utiliser pour vérifier le path réellement envoyé à un peer après remove-private-as ?

show ip bgp neighbors X advertised-routes — affiche les routes avec le path modifié tel qu'envoyé au peer. Différent de show ip bgp qui montre le path brut dans la table locale.

show ip bgp neighbors X advertised-routes

remove-private-as & AS_OVERRIDE

🧹 remove-private-as — Nettoyage ISP

🔄 as-override — MPLS VPN même AS

AS_PATH reçu du client

AS_PATH envoyé upstream

AS_PATH reçu — mixte

Avec all — privés supprimés

AS_PATH reçu du client

Avec replace-as

as-override — Côté émetteur (PE)

allow-as-in — Côté récepteur (CE)

Sans remove-private-as

Avec remove-private-as all

Sans as-override

Avec as-override sur PE-B

⚠️ Piège 1 — remove-private-as sans all ne retire pas les AS privés si le path est mixte

⚠️ Piège 2 — as-override et remove-private-as modifient la table BGP locale

⚠️ Piège 3 — as-override remplace seulement l'AS du peer direct

⚠️ Piège 4 — remove-private-as couvre la plage 4-octets RFC 6996

⚠️ Piège 5 — as-override et allow-as-in peuvent coexister mais c'est redondant

📌 Point d'attention — Soft reset obligatoire après modification

📌 Point d'attention — AS 65535 traitement spécial

Avec `all` — privés supprimés

⚠️ Piège 1 — remove-private-as sans `all` ne retire pas les AS privés si le path est mixte