> Paul Rolland a écrit :
> Oui, a peu pres... c'est un peu le role de cette "optimisation" ;) (et si
> qq'un
> sait pkoi Cisco ne l'active pas par defaut, je veux bien l'info, histoire de
> satisfaire ma curiosite, mais je sens venir le "c'etait bugge au debut...").
Ce que je me rappelle c'était
Hello,
On Mon, 13 Jan 2020 13:54:30 +0100
Fabien H wrote:
> access-list compiled => Turbo ACL => Cela a effectivement largement allégé
> le CPU (à mon avis, je suis retombé au niveau de CPU d'avant les ACL)
Oui, a peu pres... c'est un peu le role de cette "optimisation" ;) (et si
qq'un sait
Bonjour,
pour vous faire un retour:
access-list compiled => Turbo ACL => Cela a effectivement largement allégé
le CPU (à mon avis, je suis retombé au niveau de CPU d'avant les ACL)
Lors d'un DDOS, ACL sur une interface IN est encore plus efficace qu'une
route BGP envoyée en RTBH, mais forcément
>> Michel Py a écrit :
>> Pour débugger le CPU sur un Cisco j'ai cet alias sympa :
>> alias exec ps sh proc cpu | excl 0.00%__0.00%__0.00%
> Paul Rolland a écrit :
> Cette version me parait plus sympa :
> sh proc cpu | excl 0.0[0-9]%__0.0[0-9]%__0.0[0-9]%
Ah ouais il est sympa celui-ci aussi !
Bonsoir,
On Thu, 9 Jan 2020 19:05:09 +
Michel Py wrote:
> > Bcp de unsupported et de redirect aussi
>
> Moi j'ai 0 dans les redirect.
Pareil, sauf en IPv6 ou j'en ai un peu... mais OSEF, c'est V6 ;)
Paul
---
Liste de diffusion du FRnOG
Salut Michel,
On Thu, 9 Jan 2020 19:09:04 +
Michel Py wrote:
> Pour débugger le CPU sur un Cisco j'ai cet alias sympa :
>
> alias exec ps sh proc cpu | excl 0.00%__0.00%__0.00%
Cette version me parait plus sympa :
sh proc cpu | excl 0.0[0-9]%__0.0[0-9]%__0.0[0-9]%
Ca laissse moins de 10
OUAHH
Pa Py a sorti son alias de course :)
> Le 9 janv. 2020 à 20:09, Michel Py a
> écrit :
>
> Pour débugger le CPU sur un Cisco j'ai cet alias sympa :
>
> alias exec ps sh proc cpu | excl 0.00%__0.00%__0.00%
>
>
> ---
> Liste de diffusion du FRnOG
>
Pour débugger le CPU sur un Cisco j'ai cet alias sympa :
alias exec ps sh proc cpu | excl 0.00%__0.00%__0.00%
---
Liste de diffusion du FRnOG
http://www.frnog.org/
>> Vérifie si t’as pas des routes statiques vers une interface Broadcast (c’est
>> le mal)
+1
ip route 0.0.0.0 0.0.0.0 g1/0 c'est une catastrophe.
Il faut faire : ip route 0.0.0.0 0.0.0.0 x.x.x.x
Aussi voir si t'as pas un problème de flooding / unresolved unicast, c'est un
classique sur
Hello,
On Thu, 9 Jan 2020 19:52:03 +0100
David Ponzone wrote:
> Ouais et les Unsupp'ted font couler beaucoup d’encre, mais leurs causes
> sont floues.
- ipsec,
- nat,
- access-list avec log keyword
semblent etre les plus frequemment citees...
> Fabien, tu as de l’IPSec sur le bouzin ?
>
Ouais et les Unsupp'ted font couler beaucoup d’encre, mais leurs causes sont
floues.
Fabien, tu as de l’IPSec sur le bouzin ?
Des virtual-template ?
Tu peux vérifier ton CPU en virant toutes tes ACL inbound/outbound quand même ?
Vu l’âge de ton IOS, je suis méfiant…
> Le 9 janv. 2020 à 19:50,
Hello,
On Thu, 9 Jan 2020 19:42:22 +0100
Fabien H wrote:
> sh cef not-cef-switched => semble bon ( beaucoup de unsupported ?)
>
> IPv4 CEF Packets passed on to next switching layer
> Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access
> Frag
> RP 0 0
> La moitié de ton problème c'est que le 7301 est limité à 1GO de mémoire,
> même si çà rentre encore, 1GO c'est pas suffisant aujourd'hui pour faire du
> full-feed.
>
>
>
>
Surtout quand il y' a 2 full feed :-)
Sinon sh ip arp => Pas d'incomplete
statiques vers Interfaces de broadcast : à
Bonjour,
On Thu, 9 Jan 2020 18:16:15 +0100
David Ponzone wrote:
> Ouais pas faux.
>
> Fabien:
>
> Vérifie si t’as pas des routes statiques vers une interface Broadcast
> (c’est le mal) Et aussi sh ip arp pour voir si t’as beaucoup de
> incomplète (ce qui signifierait que t’as un truc à toi ou
> David Ponzone
> Tu peux casser ta tirelire et passer sur un ASR d’occase please ?
> T’en a pour 1000-1500€ et t’es peinard pour un moment.
+1.
La moitié de ton problème c'est que le 7301 est limité à 1GO de mémoire, même
si çà rentre encore, 1GO c'est pas suffisant aujourd'hui pour faire du
Ouais pas faux.
Fabien:
Vérifie si t’as pas des routes statiques vers une interface Broadcast (c’est le
mal)
Et aussi sh ip arp pour voir si t’as beaucoup de incomplète (ce qui
signifierait que t’as un truc à toi ou pas qui scande comme un fou)
Source:
Tu peux essayer:
sh cef not-cef-switched
sh interfaces stats
Pour vérifier s’il y a des INT sur lequel c’est le processeur qui bosse.
> Le 9 janv. 2020 à 18:07, Fabien H a écrit :
>
> On le remplacement est prévu .. prochainement :-)
>
> Oui c'est normalement OK pour l'IP CEF j'ai
Bonjour,
On Thu, 9 Jan 2020 17:44:33 +0100
Fabien H wrote:
> PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
>5 184144078492973711 19806 13.83% 3.30% 2.39% 0 Check
> heaps
> 19 1503589012 3790327737 0 2.00% 1.94% 1.92% 0 ARP
> Input
On le remplacement est prévu .. prochainement :-)
Oui c'est normalement OK pour l'IP CEF j'ai re-vérifié
Merci pour les conseils ..
Le jeu. 9 janv. 2020 à 18:02, David Ponzone a
écrit :
> H un 7301 en 2020 ? :)
>
> Tu peux casser ta tirelire et passer sur un ASR d’occase please ? T’en a
>
H un 7301 en 2020 ? :)
Tu peux casser ta tirelire et passer sur un ASR d’occase please ? T’en a pour
1000-1500€ et t’es peinard pour un moment.
CPU élevé, qui ne semble pas venir d’un process en particulier, si mes
souverains sont bons, ça signifie qu’il y a beaucoup d’interrupt.
Pas grand
On s'éloigne un peu du sujet là .. on va peut être arreter là ? :-)
La nuit ça descend à 40% environ.
Le CISCO est : Cisco IOS Software, 7301 Software (C7301-ADVIPSERVICESK9-M),
Version 12.4(24)T1,
Voici sh proc cpu sorted quand très peu de trafic :
CPU utilization for five seconds: 48%/29%;
> Paul Rolland a écrit :
> Ton CPU est a 70% d'usage ??? Je sais pas ce que c'est comme modele et de
> quand il date,
C'est un AGS ? ;-)
J'ai du full-feed sur une bouse antique (c3825), et mon CPU est à 4%. Si un
full-feed tombe (je fais clear ip BGP x.x.x.x pour simuler) pendant quelques
C’est beaucoup ce niveau de CPU sur un Cisco…
Sachant que c’est un moyenne, ça signifie que tu as des crêtes plus hautes.
Pour le filtrage ntp, je crois que tu peux te permettre de filtrer aussi:
deny udp any eq ntp any eq ntp
Tout client NTP moderne ne doit plus utiliser le port 123 comme port
Non, il ne l'a pas !
Je vais appliquer en soirée pour voir merci.
Mais nos routeurs sont un peu chargés d'habitude environ 60-65% à cause des
sessions BGP..
Le jeu. 9 janv. 2020 à 12:48, Paul Rolland (ポール・ロラン)
a écrit :
> Hello,
>
> On Thu, 9 Jan 2020 12:41:39 +0100
> Fabien H wrote:
>
> >
Hello,
On Thu, 9 Jan 2020 12:41:39 +0100
Fabien H wrote:
> J'ai appliqué l'ACL suivante sur plusieurs interfaces (transitaires + GIX)
> du routeur CISCO :
>
> ip access-list extended INTERNET_TRANSIT_IN
> deny udp any eq ntp host A.B.C.D
> permit ip any any
>
> Pour un trafic équivalent
Juste pour faire un retour sur les perfs :
J'ai appliqué l'ACL suivante sur plusieurs interfaces (transitaires + GIX)
du routeur CISCO :
ip access-list extended INTERNET_TRANSIT_IN
deny udp any eq ntp host A.B.C.D
permit ip any any
Pour un trafic équivalent à hier, le CPU a pris un bon 5%
> OK mais pour vous ce quoi le mieux ? Transitaire avec Arbor ou transitaire
> avec RTBH et tu gères tes annonces /32 en interne ?
Pour moi c'est Arbor mais pour mon portefeuille c'est RTBH !
Michel.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
OK mais pour vous ce quoi le mieux ? Transitaire avec Arbor ou transitaire
avec RTBH et tu gères tes annonces /32 en interne ?
J'aurai tendance à dire Arbor parce que c'est quand même reconnu et je
suppose que la mitigation est très rapide et efficace dans la plupart des
cas ..
Le mer. 8 janv.
> David Ponzone a écrit :
> Sauf que maintenant le transitaire Tier2 un peu gros va essayer de te fourguer
> du Arbor, et n’a donc aucun intérêt à avoir du RTBH à la papa/maman :)
C'est clair, et justement quand tu es en phase de renouvellement du contrat tu
leur dis que tu réduis le commit et
Sauf que maintenant le transitaire Tier2 un peu gros va essayer de te fourguer
du Arbor, et n’a donc aucun intérêt à avoir du RTBH à la papa/maman :)
> Le 8 janv. 2020 à 17:13, Michel Py a
> écrit :
>
>> David Ponzone a écrit :
>> Ben déjà les IP RFC1918 et assimilées.
>
> David m'a enlevé
J'ai essayé avec le transitaire, mais sans donner son nom (ça va être
facile à trouver :-) ) , il propose un serveur blackhole sur lequel on
ouvre une session BGP et je n'arrive pas jusqu'à maintenant à ouvrir cette
session (Problème de MD5..)
Je vais me re-concentrer dessus..
Le mer. 8 janv.
> David Ponzone a écrit :
> Ben déjà les IP RFC1918 et assimilées.
David m'a enlevé les mots de la bouche !
Fabien, il faut que tu travailles avec tes transitaires pour que le RTBH soit
fait chez eux. Il y en a certains qui acceptent des préfixes /32 avec la bonne
communauté et qui bloquent en
> Fabien H a écrit :
> Sans forcément donner toutes les ficelles : Je pensais qu'en tant
> qu'opérateur, on fournissait un internet sans filtrage particulier,
C'est la majorité, mais çà veut pas dire que c'est propre. Par exemple, RFC1918
sur un lien client ou un lien transit çà devrait être
Internet ouvert, mon cul :)
Ben déjà les IP RFC1918 et assimilées.
Et puis d’autres merdes.
Tu sais de nos jours les gens font HTTP à 99% alors tu peux bloquer Gopher :)
> Le 8 janv. 2020 à 16:59, Fabien H a écrit :
>
> OK merci pour ce 2eme retour.
>
> Sans forcément donner toutes les
OK merci pour ce 2eme retour.
Sans forcément donner toutes les ficelles : Je pensais qu'en tant
qu'opérateur, on fournissait un internet sans filtrage particulier, j'ai du
mal à imaginer ce qu'on peut filtrer en IN et OUT sans aller à l'encontre
de l'internet ouvert ?
C'est peut-être en lien
> Fabien H a écrit :
> La question est juste de savoir si c'est une pratique qui se fait
> régulièrement sur un routeur de bordure de mettre une ACL extended
> sur les interfaces des transitaires ou alors si c'est pas conseillé..
Pour moi c'est systématique. In et out. Avec un routeur pas trop
Ouf ça me rassure.
Donc je vais préparer l'ACL extended et l'appliquer en soirée pour voir..
Le mer. 8 janv. 2020 à 13:08, David Ponzone a
écrit :
> Ben ouais quand même, faut bien filtrer des petits trucs :)
> Sur un Cisco, c’est pas géré par le CPU normalement, depuis quelques
> années
Ben ouais quand même, faut bien filtrer des petits trucs :)
Sur un Cisco, c’est pas géré par le CPU normalement, depuis quelques années
maintenant.
> Le 8 janv. 2020 à 12:47, Fabien H a écrit :
>
> Bonne remarque !
>
> Pendant l'attaque, je n'ai pas eu l'idée de regarder, j'ai préférer
>
Bonne remarque !
Pendant l'attaque, je n'ai pas eu l'idée de regarder, j'ai préférer
vérifier le RTBH. Je ferais la prochaine fois..
La question est juste de savoir si c'est une pratique qui se fait
régulièrement sur un routeur de bordure de mettre une ACL extended sur les
interfaces des
Ca donne quoi un sh proc c ?
> Le 8 janv. 2020 à 12:27, Fabien H a écrit :
>
> Bonjour,
> bonne année à la communauté FRNOG :-)
>
> Je suis toujours sur mes histoires de DDOS : Le RTBH fonctionne, mais je
> trouve que mes routeurs de bordure montent un peu trop en CPU à mon gout
> (encore pas
Bonjour,
bonne année à la communauté FRNOG :-)
Je suis toujours sur mes histoires de DDOS : Le RTBH fonctionne, mais je
trouve que mes routeurs de bordure montent un peu trop en CPU à mon gout
(encore pas mal de pertes de paquets sur les paquets traversant).
Je voulais juste savoir sur du CISCO,
>>> Alarig Le Lay a écrit :
>>> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre.
>> Moi aussi, mais à part le problème d'avoir le matos récent qui le fait, va
>> donc trouver un transitaire qui ferait
>> çà en amont pour toi :-( Déjà en trouver qui connaissent quelque choses
On dim. 22 déc. 10:24:32 2019, Yannis Aribaud wrote:
> Je ne dévoilerai pas le tarif qu'ils m'ont proposé, mais pour vous
> donner un ordre d'idée, c'est presque 3x le prix de mon port 10Gb en
> récurrent et encore 3x plus en setup...
Ah ouais… ça te fait réfléchir deux minutes avant de signer le
22 décembre 2019 11:24 "Yannis Aribaud" a écrit:
> 22 décembre 2019 11:13 "Alarig Le Lay" a écrit:
>
>> On dim. 22 déc. 09:57:59 2019, Yannis Aribaud wrote:
>>
>>> Hurricane Electric propose le support de flowspec en option sur leurs
>>> offres de transit. Mais ça coûte une blinde !
>>
>>
22 décembre 2019 11:13 "Alarig Le Lay" a écrit:
> On dim. 22 déc. 09:57:59 2019, Yannis Aribaud wrote:
>
>> Hurricane Electric propose le support de flowspec en option sur leurs
>> offres de transit. Mais ça coûte une blinde !
>
> Genre combien ?
Je ne dévoilerai pas le tarif qu'ils m'ont
On dim. 22 déc. 09:57:59 2019, Yannis Aribaud wrote:
> Hurricane Electric propose le support de flowspec en option sur leurs
> offres de transit. Mais ça coûte une blinde !
Genre combien ?
--
Alarig
---
Liste de diffusion du FRnOG
http://www.frnog.org/
20 décembre 2019 22:16 "Michel Py" a écrit:
>> Alarig Le Lay a écrit :
>> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre.
>
> Moi aussi, mais à part le problème d'avoir le matos récent qui le fait, va
> donc trouver un
> transitaire qui ferait çà en amont pour toi :-(
>
On ven. 20 déc. 21:24:52 2019, Michel Py wrote:
> Moi aussi, mais à part le problème d'avoir le matos récent qui le
> fait, va donc trouver un transitaire qui ferait çà en amont pour toi
> :-( Déjà en trouver qui connaissent quelque choses aux communautés
> c'est pas évident.
Flowspec en eBGP
> Alarig Le Lay a écrit :
> Dans ce cas je préfère faire du flowspec, je trouve ça plus propre.
Moi aussi, mais à part le problème d'avoir le matos récent qui le fait, va donc
trouver un transitaire qui ferait çà en amont pour toi :-(
Déjà en trouver qui connaissent quelque choses aux
On ven. 20 déc. 17:50:10 2019, Michel Py wrote:
> Il faut bien comprendre que je n'utilise pas uRPF dans l'esprit ou il
> a été conçu. L'origine de uRPF c'était de ne pas propager la merdasse
> spoofée, et ce n'est pas un succès. Ce que j'utilise dans uRPF (et en
> particulier avec
> Fabien H a écrit :
> Pendant une attaque DDOS vers une seule IP
Pour clarifier, le /32 que tu bloques, c'est une de tes propres adresses, la
cible de l'attaque ?
Dans ce cas, uRPF ne sert à rien, car ton RTBH est basé sur l'adresse de
destination.
uRPF, çà sert quand le RTBH est basé sur
> Fabien H a écrit :
> Par contre juste une question qui me chagrine, en environnement multi-homé,
> multi-transitaire avec ton préfixe /22 annoncé sur tous les transitaires,
> sans local pref sur le sortant vers tel ou tel transitaire, il n'y a pas un
> risque que le paquet arrive "de bonne foi"
ug. - The Elements of Programming Style
>> (Kernighan & Plauger)
>>
>> ――― Original Message ――――――― From: David Ponzone
>> Sent: 20 décembre 2019 10:37 +01 Subject:
>> Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un
>> routeur CISCO depuis
noncer non plus.
> --
> Don't stop at one bug.
>- The Elements of Programming Style (Kernighan & Plauger)
>
> ――― Original Message ―――
> From: David Ponzone
> Sent: 20 décembre 2019 10:37 +01
> Subject: Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0
uger)
――― Original Message ―――
From: David Ponzone
Sent: 20 décembre 2019 10:37 +01
Subject: Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur
CISCO depuis une VM Linux
To: Alarig Le Lay
Cc: frnog@frnog.org
> A la base c’est pas considéré comme « bad practice » d’av
A la base c’est pas considéré comme « bad practice » d’avoir des équipements
qui renvoient des ICMP depuis des IP non annoncées ?
> Le 20 déc. 2019 à 10:35, Alarig Le Lay a écrit :
>
> Pour les traceroutes/mtr et le PMTUd.
>
> On 20/12/2019 10:34, David Ponzone wrote:
>> OK ça se défend.
>>
Pour les traceroutes/mtr et le PMTUd.
On 20/12/2019 10:34, David Ponzone wrote:
> OK ça se défend.
> Ca te gêne pour les traceroute ou pour autre chose ?
>
>> Le 20 déc. 2019 à 10:29, Alarig Le Lay a écrit :
>>
>> Je n’ai jamais eu de soucis de spoof d’IP pas annoncées. Par contre, ne
>> plus
OK ça se défend.
Ca te gêne pour les traceroute ou pour autre chose ?
> Le 20 déc. 2019 à 10:29, Alarig Le Lay a écrit :
>
> Je n’ai jamais eu de soucis de spoof d’IP pas annoncées. Par contre, ne
> plus recevoir les ICMP des backbones pas annoncés, j’ai déjà eu. Donc
> l’intérêt est négatif
Je n’ai jamais eu de soucis de spoof d’IP pas annoncées. Par contre, ne
plus recevoir les ICMP des backbones pas annoncés, j’ai déjà eu. Donc
l’intérêt est négatif pour moi.
On 20/12/2019 10:27, David Ponzone wrote:
> Ben si t’as pas de route pour l’IP source du paquet, tu le drop au plus tôt
>
Ben non, mais en mode loose.
Mais bon, Alarig est pas d’accord alors ça mérite d’écouter son argument :)
> Le 20 déc. 2019 à 10:27, Fabien H a écrit :
>
> Mauvais transitaire, je voulais dire que le paquet arrive par la GW du
> transitaire qui n'est pas celle défini dans la table de routage
Ben si t’as pas de route pour l’IP source du paquet, tu le drop au plus tôt non
?
> Le 20 déc. 2019 à 10:23, Alarig Le Lay a écrit :
>
> Je ne vois pas l’utilité de l’uRPF si c’est pas en mode strict perso :p
>
> On 20/12/2019 10:22, David Ponzone wrote:
>> Pas en mode strict en tout cas.
>>
Mauvais transitaire, je voulais dire que le paquet arrive par la GW du
transitaire qui n'est pas celle défini dans la table de routage pour le
réseau source du paquet
OK compris, donc sur les interfaces transitaire, on oublie uRPF.
Le ven. 20 déc. 2019 à 10:01, David Ponzone a
écrit :
>
Je ne vois pas l’utilité de l’uRPF si c’est pas en mode strict perso :p
On 20/12/2019 10:22, David Ponzone wrote:
> Pas en mode strict en tout cas.
>
>> Le 20 déc. 2019 à 10:16, Alarig Le Lay a écrit :
>>
>> uRPF faut le faire sur ton réseau à toi, pas sur les intercos vers
>> l’extérieur,
Pas en mode strict en tout cas.
> Le 20 déc. 2019 à 10:16, Alarig Le Lay a écrit :
>
> uRPF faut le faire sur ton réseau à toi, pas sur les intercos vers
> l’extérieur, sinon effectivement ça casse tout.
>
> On 20/12/2019 09:57, Fabien H wrote:
>> Bonjour Michel (quand il fera jour
uRPF faut le faire sur ton réseau à toi, pas sur les intercos vers
l’extérieur, sinon effectivement ça casse tout.
On 20/12/2019 09:57, Fabien H wrote:
> Bonjour Michel (quand il fera jour outre-atlantique :-) )
>
> J'ai regardé un peu uRPF, effectivement, c'est très intéressant
> effectivement
Définis « mauvais transitaire » ? :)
> Le 20 déc. 2019 à 09:57, Fabien H a écrit :
>
> Bonjour Michel (quand il fera jour outre-atlantique :-) )
>
> J'ai regardé un peu uRPF, effectivement, c'est très intéressant
> effectivement !
>
> Par contre juste une question qui me chagrine, en
Bonjour Michel (quand il fera jour outre-atlantique :-) )
J'ai regardé un peu uRPF, effectivement, c'est très intéressant
effectivement !
Par contre juste une question qui me chagrine, en environnement multi-homé,
multi-transitaire avec ton préfixe /22 annoncé sur tous les transitaires,
sans
On jeu. 19 déc. 20:27:49 2019, Michel Py wrote:
> > Fabien H a écrit :
> > announce route A.B.C.D/32 next-hop 10.10.2.41 community 65532:666
>
> Change 65532 pour quelque chose d'autre. Réservé pour Michel/CBBC :P
> A éviter aussi : 65332 (team Cymru)
Ni l’un ni l’autre, la commu standard pour
C'est OK pour la communauté et le no-export addditive.
Oui du coup, j'ai enlevé le set ip next-hop pour que réellement le next hop
soit celui envoyé par exaBGP 10.10.2.41
Et ensuite je rajoute sur le CISCO une route statique 10.10.2.41/32 vers
Null0 (qui est plus spécifique que le réseau
> Fabien H
> exaBGP
> announce route A.B.C.D/32 next-hop 10.10.2.41
Mets une communauté 65000:666
> route-map ANTIDDOS_IN permit 10
> no set ip next-hop 192.0.2.1
"no" ?
match community 65000:666
SET COMMUNITY NO-EXPORT ADDITIVE
Tant que tu n'es pas près à annoncer ce préfixe à tes
#show ip route 192.0.2.1
Routing entry for 192.0.2.1/32
Known via "static", distance 1, metric 0 (connected)
Redistributing via bgp ASN
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
Bon finalement je pense que cette fois
> A noter que j'ai encore un problème : La route BGP ci-dessous
> ne s'installe pas car 192.0.2.1 est inaccessible à priori
sh ip route 192.0.2.1 ?
---
Liste de diffusion du FRnOG
http://www.frnog.org/
C'est noté merci pour les conseils.
A noter que j'ai encore un problème : La route BGP ci-dessous ne s'installe
pas car 192.0.2.1 est inaccessible à priori
#show ip bgp A.B.C.D/32
BGP routing table entry for A.B.C.D /32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
> Fabien H a écrit :
> announce route A.B.C.D/32 next-hop 10.10.2.41 community 65532:666
Change 65532 pour quelque chose d'autre. Réservé pour Michel/CBBC :P
A éviter aussi : 65332 (team Cymru)
Ne pas oublier :
interface null 0
no ip unreachables
> Pas de problème de peformance si le routeur
Ca y'est j'ai réussi :-)
J'ai juste annoncé avec un next hop qui est directly connected au routeur
CISCO mais pas sur le routeur CISCO et la route s'est bien installée :
exaBGP
announce route A.B.C.D/32 next-hop 10.10.2.41 community 65532:666
CISCO
#show ip bgp A.B.C.D/32
BGP routing table
route-map ANTIDDOS_IN permit 10
match ip address prefix-list ANTIDDOS_IN
Cà c'est pas glop : route-map et prefix-list avec le même nom.
Enlèves : match ip address prefix-list ANTIDDOS_IN
Michel.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
% Network not in table
La route n'est pas installée..
Le jeu. 19 déc. 2019 à 21:08, Michel Py
a écrit :
> Si tu fais sh ip bgp x.x.x.x/32 (l'addresse que tu bloques) tu as quoi ?
>
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Si tu fais sh ip bgp x.x.x.x/32 (l'addresse que tu bloques) tu as quoi ?
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Cisco IOS Software, 7301 Software (C7301-ADVIPSERVICESK9-M), Version
12.4(24)T1, RELEASE SOFTWARE (fc3)
show ip bgp neighbors 10.10.2.40
10.10.2.40 = IP de la VM exaBGP
Le jeu. 19 déc. 2019 à 20:59, Michel Py
a écrit :
> > Fabien H a écrit :
> > @Michel,
> > J'obtiens toujours l'erreur
> Fabien H a écrit :
> @Michel,
> J'obtiens toujours l'erreur NEXT_HOP non-local sur le neighbor sur le CISCO
> :-(
> OutboundInbound
> Local Policy Denied Prefixes:---
> route-map: 797007 0
> NEXT_HOP
Dans ce cas il faut mieux le faire comme une route:
ip route 192.0.2.1 255.255.255.255 Null0
Et ce que tu cherche à faire a un nom: le RTBH
("Remotely-Triggered Black Hole")
Et je te conseille ce super article sur le sujet:
@Michel,
j'ai donc testé comme ceci comme dans CBBC :
...
neighbor 10.10.2.40 route-map ANTIDDOS_IN in
...
...
route-map ANTIDDOS_IN permit 10
match ip address prefix-list ANTIDDOS_IN
set community no-export additive
set ip next-hop 192.0.2.1
!
...
ip route 192.0.2.1 255.255.255.255 Null0
> Paul Rolland a écrit :
> Ou alors Cisco fait un cas particulier quand la resolution finale est un
> Null0 ???
C'est le cas en effet.
> Truc a la con :
> interface loopback 192021
> ip addr 192.0.2.1 255.255.255.255
> Et tu routes vers cette adresse
> Possible que ca ne charge pas trop le
Hello,
On Thu, 19 Dec 2019 19:33:31 +0100
Fabien H wrote:
> @Paul : A mon avis, la condition c'est une route directly Connected
Truc a la con :
interface loopback 192021
ip addr 192.0.2.1 255.255.255.255
Et tu routes vers cette adresse
Possible que ca ne charge pas trop le CPU sur un
Super
un grand merci à la communauté pour les réponses !!
@Michel : J'avais pas pensé au route-map qui change le next-hop je vais
tester rapidement..
@Paul : A mon avis, la condition c'est une route directly Connected
@Alexis : Même principe que Michel : route-map mais pour changer
l'interface,
Tu as 2 solutions pour moi,
Si tu as du matos récent, je pense que bgp flowspec est là voie à emprunter
Sinon, je passerais une route avec une communauté (genre 65000:666) et
faire une route map qui set l'interface a null0 en matchant la
communauté
Cordialement
Le jeu. 19 déc. 2019 à 19:26,
Hello,
On Thu, 19 Dec 2019 19:20:55 +0100
Fabien H wrote:
> Alors je n'avais pas essayé ça parce que ma route est refusée par le
> routeur CISCO si le next hop n'existe pas sur le routeur CISCO (erreur
> NEXT_HOP non-local)
>
> J'ai essayé malgré tout de créer une route vers Null0 sur le CISCO
>> Fabien H a écrit :
>> J'ai essayé avec exaBGP qui semblait vraiment adapté mais la commande à
>> envoyer autorise
>> uniquement un next-hop de type IP ! : announce route X.Y.Z.A/32 next-hop
C'est tout a fait adapté, c'est ce que je fais.
> David Ponzone a écrit :
> Tu envoies la route avec
Bonsoir David,
comme d'habitude, réponse plus vite que l'éclair !
Alors je n'avais pas essayé ça parce que ma route est refusée par le
routeur CISCO si le next hop n'existe pas sur le routeur CISCO (erreur
NEXT_HOP non-local)
J'ai essayé malgré tout de créer une route vers Null0 sur le CISCO
Tu envoies la route avec un next-hop bidon et tu routes le next-hop sur le
Cisco vers Null0.
David Ponzone
> Le 19 déc. 2019 à 19:09, Fabien H a écrit :
>
> Bonsoir,
>
> Le titre résume ce que j'ai besoin de faire :
>
> Pendant une attaque DDOS vers une seule IP, selon l'intensité de
90 matches
Mail list logo
