Re: [FRnOG] [TECH] Encapsulation BGP
Bonjour, Avez vous essayer de faire du shaping au CIR souscrit chez l'opérateur? BR Mohamed 2014-02-03 Jérémy Martin : > Bon, je me répond à moi même pour ceux que ça peut intéresser. > La mise en place du tunnel GRE n'a pas apporté les effets escompté. > Logique puisque au final, les paquets, même encapsulé, son toujours lisible > car non chiffrés par du L2TP par exemple. > > Brocade ne permet pas de créer un tunnel GRE chiffré a priori, nous voilà > donc revenu à la case départ. > > Je continue de chercher pourquoi nous avons de fortes pertes de trames > entre 2 routeurs Brocade distant de 70km avec 1 Layer 2 entre les deux. > > D'ailleurs, Brocade ne nous a pas apporté beaucoup d'aide sur ce problème, > alors que nous étions prêt à payer le contrat de support qui va bien pour > pouvoir travailler sur les trames en elle même... Dommage:( > > Cordialement, > Jérémy Martin > > Le 02/02/2014 14:57, Jérémy Martin a écrit : > >> Salut les geek, >> >> Bon, j'ai un opérateur qui s'occupe du transport L2 d'un uplink BGP, et >> celui ci semble s'amuser à faire de la QoS au niveau des paquets SSH (et >> FTP). >> Comme il ne veut rien entendre et persiste à me dire que c'est chez nous >> (ou chez notre transitaire) que se situe le problème, on essaye de trouver >> des solutions. >> >> Là on a imaginé de faire deux choses pour tester : >> 1) Faire un Vlan entre mon transitaire et mon routeur pour tester. >> 2) Si ça marche pas, on va tester de faire une encapsulation GRE au >> niveau de la session BGP >> >> De votre point de vue, vous pensez que ça peut fonctionner ? >> >> >> > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Configuration L3/L2 sur 3560G
Bon,jour et Bonne année Si les sessions BGP sont maintenues entre les deux memes equipements (3560 <-> BB), je suggèrerai de monter une seule session BGP dans la Globale ou dans une VRF créée à cet effet et par un jeu d'import/export (route leaking) et progager la default route dans chaque VRF. On mutualiserait le port L3 (no switchport). Ce qui réduit le nombre de SVI, de sessions BGP et de configuration. Par conséquent pas de spanning-tree sur le port L3. BR Mohamed 2014/1/2 Frederic Dhieux > Bonjour et bonne année à tous, > > Je suis en train de configurer des Cisco 3560G pour un besoin > particulier et dont le rôle serait à la fois de gérer une poignée de > sessions BGP vers un backbone (qui envoie uniquement la default route) > et d'agréger le L2 d'un ensemble de switchs de l'autre côté. > > J'ai actuellement un point qui m'ennuie dans l'optique d'avoir quelque > chose de bien propre : > > - Le 3560G ne gère pas le tagging d'interface L3 aussi loin que je le > connaisse, donc je dois passer mes /31 d'interco L3 en mode switchport > trunk pour passer plusieurs VRF sur un même lien. > > - J'ai un certain nombre de VLANs à gérer en L2 sur cet équipement. La > logique voudrait que je fasse du MST plutôt que du PVST, mais du coup > voilà, mes interfaces L3 tombent irrémédiablement dans le MST même en > faisant un "no spanning-tree vlan " sur mes VLANs utilisés pour les > intercos. > > Du coup ça m'irrite pas mal de voir mes interfaces d'interco L3 > impliquées dans le spanning tree et potentiellement bloquées. Si des > personnes ici on l'expérience d'une configuration élégante pour faire > cohabiter MST et intercos L3 avec plusieurs VRFs, ça m'intéresserait > d'avoir votre retour sur le sujet. Je n'ai pas pu pour le moment exclure > des vlans ou des interfaces de mon spanning tree MST. > > Merci pour votre aide :) > > P.S. : Je pose la question par intérêt technique par rapport à cette > situation avec cet équipement. Merci de ne pas me proposer de solution à > base de "jette le à la poubelle et prends un > " ;) > > Conf exemple (tourne sur une version 12.2 en mode routeur bien sûr) : > > - > > spanning-tree mode mst > spanning-tree extend system-id > ! > spanning-tree mst configuration > name rtblw > instance 1 vlan 2000-2999 > instance 2 vlan 3000-3999 > ! > spanning-tree mst 0-2 priority 20480 > no spanning-tree vlan 100-299 > > > interface Port-channel10 > description L3 r2 (Po10) > switchport trunk encapsulation dot1q > switchport trunk allowed vlan 100,200 > switchport mode trunk > > interface Vlan100 > description ic-r1-r2 > ip address xxx.xxx.xxx.xxx 255.255.255.254 > no ip redirects > no ip proxy-arp > > interface Vlan200 > description ic-r1-r2-vrf2 > ip vrf forwarding VRF2 > ip address xxx.xxx.xxx.xxx 255.255.255.254 > no ip redirects > no ip proxy-arp > > - > > > Frederic > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Errata ! Une erreur de ma part. Je viens de m'en rendre compte ! Le MED est évalué après le LOCAL_PREF. (confusion avec le WEIGHT) Oubliez ce que je viens de dire sur MED. Il faut lire aussi : AS2 et non AS1 On aurait eu AS3 ->AS4->AS2->AS1 ou AS3->AS2->AS1 (s'il ya un peering entre AS2 et AS3). De ce fait AS2 absorberait tout le trafic de à destination de AS1. Mais seulement aujourd'hui cette méthode n'est plus fiable car l'AS-PATH peut etre ignoré dans le calcul du best path. Pour conclure, la solution avec les annonces conditionnelles peut etre une bonne piste. Cordialement 2013/6/27 Mohamed Touré > Le MED n'a de valeur que pour ton peer ! C'est une manière de forcer son > "LOCAL PREF" à lui, car l'attribut MED est évalué avant ce dernier. S'il le > prend en compte cela veut dire que tout le trafic vers AS1 (qu'il gère) > passera localement sur le meme peering (du point de vue de ton peer > uniquement).C'est une manière d'influencer son local pref pour ton trafic > entrant. > > AS3 continuera bien entendu à envoyer ton trafic au plus proche c'est à > dire sur son lien de peering avec toi. ça n'a aucun impact sur les autres > peers qui vont router ton trafic destination au plus proche. > > Après AS2 peut aussi se mettre d'accord avec AS4 pour positionner son MED > pour ton trafic. C'est pas très pratique, c'est vrai. Ce n'est pas une > solution viable. > > Une solution utilisée jadis était AS-PATH preprend. L'AS PATH etant > propagé partout permet d'influencer le trafic ce qui pouvait obliger AS3 à > ne pas utiliser son lien direct avec AS1. > > On aurait eu AS3 ->AS4->AS2->AS1 ou AS3->AS2->AS1 (s'il ya un peering > entre AS2 et AS3). De ce fait AS1 absorberait tout le trafic de à > destination de AS1. Mais seulement aujourd'hui cette méthode n'est plus > fiable car l'AS-PATH peut etre ignoré dans le calcul du best path. > > Comme déjà discuté sur ce forum, une solution consiste plutot à faire des > annonces conditionnelles. Cela consiste à annoncer tes prefixes à AS3 que > si AS2 est down. Ce qui te garantit que AS2 sera toujours le meilleur > chemin pour tes destinations, tant qu'il sera UP. > > > Cordialement > > > > 2013/6/27 Radu-Adrian Feurdean > >> On Thu, Jun 27, 2013, at 11:52, Mohamed Touré wrote: >> > Bonjour >> > >> > Si ton equipement le supporte et que ton peer le supporte également et >> > qu'il est d'accord pour le prendre en compte, l'attribut MED, optional >> et >> > non transitive est une solution pour forcer ton traffic à entrer dans >> ton >> > AS multihomed par un chemin précis. >> >> Le MED n'a strictement aucune valeur vers 2 AS differents. D'ailleurs le >> MED est non-transitif, donc il ne sera pas re-transmis par ton/tes >> upstream(s). >> >> Pour faire plus clair, toi (AS1) a deux upstreams (AS2 et AS3), et un >> autre AS (AS4) a les memes upstreams (AS2 et AS3). Si toi tu veux tout >> passer (in et out) via AS2, et que AS4 veut tout passer via AS3, tu fais >> comment pour le traffic entre AS1 et AS4 ? >> Ton localpref va forcer le traffic AS1->AS2->AS4, alors que le localpref >> d'AS4 va forcer le chemin AS4->AS3->AS1 (rappel, le localpref est >> prioritaire par rapport a la taille de l'AS-PATH). Si AS2 et AS3 peerent >> entre eux, en general ils vont appliquer leurs propres localprefs, pour >> forcer une route de type "customer" par rapport a une route de type >> "peer". Vous allez avoir tous les deux du traffic entrant la ou vous le >> voulez pas. Il peut y avoir des solutions, mais ca depend du cas precis >> de chaque de tes upstreams (AS2 et AS3). >> > > > > -- > Mohamed Touré > 06 38 62 99 07 > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Le MED n'a de valeur que pour ton peer ! C'est une manière de forcer son "LOCAL PREF" à lui, car l'attribut MED est évalué avant ce dernier. S'il le prend en compte cela veut dire que tout le trafic vers AS1 (qu'il gère) passera localement sur le meme peering (du point de vue de ton peer uniquement).C'est une manière d'influencer son local pref pour ton trafic entrant. AS3 continuera bien entendu à envoyer ton trafic au plus proche c'est à dire sur son lien de peering avec toi. ça n'a aucun impact sur les autres peers qui vont router ton trafic destination au plus proche. Après AS2 peut aussi se mettre d'accord avec AS4 pour positionner son MED pour ton trafic. C'est pas très pratique, c'est vrai. Ce n'est pas une solution viable. Une solution utilisée jadis était AS-PATH preprend. L'AS PATH etant propagé partout permet d'influencer le trafic ce qui pouvait obliger AS3 à ne pas utiliser son lien direct avec AS1. On aurait eu AS3 ->AS4->AS2->AS1 ou AS3->AS2->AS1 (s'il ya un peering entre AS2 et AS3). De ce fait AS1 absorberait tout le trafic de à destination de AS1. Mais seulement aujourd'hui cette méthode n'est plus fiable car l'AS-PATH peut etre ignoré dans le calcul du best path. Comme déjà discuté sur ce forum, une solution consiste plutot à faire des annonces conditionnelles. Cela consiste à annoncer tes prefixes à AS3 que si AS2 est down. Ce qui te garantit que AS2 sera toujours le meilleur chemin pour tes destinations, tant qu'il sera UP. Cordialement 2013/6/27 Radu-Adrian Feurdean > On Thu, Jun 27, 2013, at 11:52, Mohamed Touré wrote: > > Bonjour > > > > Si ton equipement le supporte et que ton peer le supporte également et > > qu'il est d'accord pour le prendre en compte, l'attribut MED, optional et > > non transitive est une solution pour forcer ton traffic à entrer dans ton > > AS multihomed par un chemin précis. > > Le MED n'a strictement aucune valeur vers 2 AS differents. D'ailleurs le > MED est non-transitif, donc il ne sera pas re-transmis par ton/tes > upstream(s). > > Pour faire plus clair, toi (AS1) a deux upstreams (AS2 et AS3), et un > autre AS (AS4) a les memes upstreams (AS2 et AS3). Si toi tu veux tout > passer (in et out) via AS2, et que AS4 veut tout passer via AS3, tu fais > comment pour le traffic entre AS1 et AS4 ? > Ton localpref va forcer le traffic AS1->AS2->AS4, alors que le localpref > d'AS4 va forcer le chemin AS4->AS3->AS1 (rappel, le localpref est > prioritaire par rapport a la taille de l'AS-PATH). Si AS2 et AS3 peerent > entre eux, en general ils vont appliquer leurs propres localprefs, pour > forcer une route de type "customer" par rapport a une route de type > "peer". Vous allez avoir tous les deux du traffic entrant la ou vous le > voulez pas. Il peut y avoir des solutions, mais ca depend du cas precis > de chaque de tes upstreams (AS2 et AS3). > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Du fait qu'il soit optionnel comme attribut, son implémentation par les développeurs ou son support par un carrier ne sont pas garantis. Il est important de se mettre d'accord avec le peer au préalable, ou il sera ignoré par défaut. Cordialement 2013/6/27 Nicolas Strina > Hello, > > Surement parce que la plupart des opérateurs avec des ASN à 3-4 chiffres > (ou plus) ne savent pas l'honorer correctement ? > Je vois pour nous .. On utilise clairement le MED et souvent .. Tout le > monde s'en fout. Peer, uplinks, clients etc .. INGRESS ou EGRESS donc. > > J'ai pas mal d'ex. ou ça se passe très mal :) > > En tout cas bonne remarque pour le coup :) > > Bref .. > > -- > Nicolas STRINA > > Jaguar Network Switzerland > 19 Boulevard Georges Favon > CH - 1204 Geneva > > More Than Your Hosting Company > > Tel : +33 4 88 00 65 16 > Gsm : +33 6 18 20 49 55 > > Std : +41 8 40 65 61 11 > Fax : +33 4 88 00 65 25 > > URL: <http://www.jaguar-network.ch/> > Support 24+7 : supp...@jaguar-network.ch > > Le 27 juin 2013 à 11:56, Fleuriot Damien a écrit : > > > Au risque de poser une question un peu noob, pourquoi vous utilisez du > preprend en ingress au lieu du MED ? > > > > Le MED c'est quand même fait pour ça… > > > > > > On Jun 27, 2013, at 9:37 AM, Benjamin BILLON wrote: > > > >> Hiho, > >> > >> local-pref pour la sortie, et prepend pour l'entrée. > >> > >> Sinon y'a ça : > >> > http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml?referring_site=bodynav > >> mais j'ai pas lu. > >> > >> SALUT. > >> > >> Benjamin > >> > >> Bonjour, > >>> > >>> Juste une petite question : > >>> Je dispose actuellement de 2 sessions BGP vers 2 transtaires > différents. > >>> Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs > >>> sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à > tout > >>> mon traffic (entrant et sortant) de passer uniquement sur un seul > >>> transitaire. > >>> On peut mettre en place le local-preference mais je ne suis pas > >>> convaincu... > >>> Avez-vous un retour d'expérience dessus? > >>> > >>> Merci. > >>> > >>> Etienne. > >>> > >>> --- > >>> Liste de diffusion du FRnOG > >>> http://www.frnog.org/ > >>> > >> > >> --- > >> Liste de diffusion du FRnOG > >> http://www.frnog.org/ > > > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Bonjour Si ton equipement le supporte et que ton peer le supporte également et qu'il est d'accord pour le prendre en compte, l'attribut MED, optional et non transitive est une solution pour forcer ton traffic à entrer dans ton AS multihomed par un chemin précis. Cordialment 2013/6/27 Radu-Adrian Feurdean > On Thu, Jun 27, 2013, at 9:37, Benjamin BILLON wrote: > > > local-pref pour la sortie, et prepend pour l'entrée. > > Juste pour rappeler que le prepend pour l'entree donne des resultats un > peu aleatoires (ton traffic entrant, c'est le traffic sortant de > quelqu'un d'autre, qui peut utiliser a son tour le localpref pour forcer > la sortie a un certain endroit). > Pour couper totalement l'entree, il faut soit retirer les annonces, soit > couper carrement la session. > > Le prepend c'est juste ce que tu aimerais que les autres fassent, pas ce > que les autres vont faire dans la realite. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] cisco port-security par adresse IP ?
Bonsoir, Pour attribuer toujours la même IP à un user en fonction de sa mac-address, il te faudra un Serveur DHCP (open source dhcp3-server ou autre ). Pour "lier une IP à un port", comprenant ainsi, non au port du switch (Layer 2), mais au host qui se trouve sur le segment connecté au port du switch tu as une fonctionnalité qui s'appelle *DHCP Snooping*. Cette fonction va créer une table d'association entre le IP/MAC/Port en écoutant les requetes dhcp. Cette base est réutilisée pour faire ton filtrage. A ce moment entre en jeu une autre fonction* IP Source Guard* qui s'appuie sur DHCP binding pour autoriser ou non l'IP. Pour mettre le port en * err-disabled* tu peux combiner IP Source Guard et port-security. NB : Si tu n'as pas de serveur DHCP, tu peux quand même remplir ta base avec des entrées statiques. Mot-clés Google : DHCP Snooping, IP source Guard, Port-Security. Néanmoins, il faut vérifier que c'est compatible avec ton switch Cordialement Mohamed Touré 2013/6/18 Antoine Durant > Bonsoir, > > Toujours les mains dans cisco pour changer... Je connais switchport > port-security mac-address 0011.2233.4455 et je me demande maintenant > comment faire une régle qui fixe l'adresse IP de la machine à un port. > > Par exemple le port f0/10 du switch à une machine qui utilise l'adresse > 192.168.0.10, si l'utilisateur change l'adresse IP du PC en 192.168.0.11 > comment détecter le changement et shutdown le port ? > > Si shutdown n'est pas possible, une régle qui deny tout le trafic ?? > > Est-ce que cela est possible ? > > A+ > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] ACL ip access-list deny/permit switch cisco
Bonjour Tu peux inserer aussi ! Il suffit de précéder ton ACE du numero de séquence. Si tu veux inserer en 50 : 50 permit ip any host X.x.x.x Mohamed 2013/6/18 Antoine Durant > Ha oui ! J'avais oublié les numéros de séquence ! > Je pense que je vais faire comme ça... > > Par contre dommage que dans une liste comme ça il va chercher le numéro le > plus haut pour ajouter l'action :S au lieu de la placer en 50... > ip access-list extended ACL_IP > 10 permit ip any host x.x.x.x > 20 deny ip any host x.x.x.x > 30 ... > 40 ... > 65000 deny ip any any > 65010 permit ip any host X.x.x.x > > > > De : Leland Vandervort > À : Leland Vandervort > Cc : Antoine Durant ; "frnog-t...@frnog.org" < > frnog-t...@frnog.org> > Envoyé le : Mardi 18 juin 2013 16h40 > Objet : Re: [FRnOG] [TECH] ACL ip access-list deny/permit switch cisco > > > j'ai oublie de dire que tu peux meme INSERER dans une liste en specifiant > la sequence... > > Pour voir les numeros de sequence - show access-list xxx > > Pareil, tu peux aussi supprimer une entree en simplement specifiant la > sequence > > ip access-list extended ACL_IP > 22 permit ip any host x.x.x.x !--- insert this one before sequence > 30 > no 50 !--- delete sequence 50 > ! > > > > > > > Leland Vandervort > Gandi SAS > 63-65 Boulevard Massena > 75013 Paris, France > > WWW: http://www.gandi.net/ > > T: +33 1 70 39 37 59 > M: +33 6 31 15 15 07 > > > > > > On 18 Jun 2013, at 16:36, Leland Vandervort wrote: > > > soit, refaire l'ACL completement, soit utiliser des sequence... > > > > ip access-list extended ACL_IP > > 10 permit ip any host x.x.x.x > > 20 deny ip any host x.x.x.x > > 30 ... > > 40 ... > > 65000 deny ip any any > > ! > > > > > > > > > > Leland Vandervort > > Gandi SAS > > 63-65 Boulevard Massena > > 75013 Paris, France > > > > WWW: http://www.gandi.net/ > > > > T: +33 1 70 39 37 59 > > M: +33 6 31 15 15 07 > > > > > > > > > > > > On 18 Jun 2013, at 16:33, Antoine Durant wrote: > > > >> Bonsoir, > >> > >> Je voudrais savoir si sur cisco il est possible de faire une liste d'IP > en permit et une liste d'IP en mode deny pour le même groupe ? > >> > >> Parceque mon problème est le suivant sur mon switch : > >> > >> Si je rajoute l'IP permit 192.168.0.190 et l'IP deny 192.168.0.10 j'ai > le résultat suivant : > >> ip access-list extended ACL_IP > >> permit ip any host 192.168.0.170 > >> permit ip any host 192.168.0.150 > >> permit ip any host 192.168.0.181 > >> deny ip any any > >> permit ip any host 192.168.0.190 > >> deny ip any host 192.168.0.10 > >> > >> Je voudrais avoir les régles bien rangées du style toutes les régles > permit les unes derrières les autres, même chose pour les deny. > >> > >> Comment faire ? > >> > >> Merci > >> --- > >> Liste de diffusion du FRnOG > >> http://www.frnog.org/ > > > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Test bandwidth IPERF/CISCO bisarre
Bonjour Antoine, Si je me réfère à la commande ci-dessous (ton test 3) : police 100 10 exceed-action drop En effet cette commande, spécifie que le policer est un Single-Token Bucket (Je te renvoie à la documentation pour plus de détails). En vert tu spécifies le taux de remplissage de ton "Bucket" (panier ou seau) exprimé en bit/s, soit 1Mbit/s. En bleu la capacité maximale que peut contenir et contient le panier à l'état initial exprimée en bytes, soit environ 97KB. Supposons qu'à l'instant T0, sur ton interface, arrivent 50 trames de 1KB, 50KB <97KB dans ce cas on dit que ces trames sont conformes à la politique (conform-action transmit) et sont transmises. Il reste dans le panier (97-50)KB, soit 47KB. Supposons maintenant, que 200ms (0,2s) plutard des trames (80 trames de 1KB chacune) arrivent à nouveau sur l'interface. Pendant ce temps le panier s'est rempli de (0,2*100)/8 = 25000B, soit 24KB. Au total, à l'instant T0+200ms, le panier contient 24+47= 71KB. Nous devons transmettre 80KB > 71KB. Dans ce cas les trames ne sont pas conformes et sont "droppées" (exceed-action drop) et le bucket contiendra toujours 71KB à cet instant. De plus en TCP, la gestion de la congestion fait que ta fenêtre d'émission se réduit. UDP est plus adapté pour des tests de débits, comme suggéré plus haut. Une piste consiste à bien définir tes paramètres au niveau de la commande ou d'utiliser un Dual-Token Bucket (2 paniers). Dans le premier cas, single-token, si on restait 1s sans émettre de traffic, le panier se remplirait de 1Mbit, soit 122KB > 97KB. L'excédant est ainsi perdu. Tandis que dans le cas du Dual-Token, l'excédant sera stocké dans le deuxieme panier qu'on pourra utiliser (exceed-action). La commande reste la meme, à la différence qu'il faut ajouter une action en cas de violation et autorisé le trafic en excès. Dans la pratique le trafic en excès est autorisé et marqué avec un dscp moins prioritaire afin qu'il soit "droppé" en cas de congestion en aval. Aussi, lorsque tu fais tes tests, regardes régulièrement la sortie de la commande : *show policy-map interface* pour voir le taux de drop de tes paquets . Un lien pour mieux l'interpréter ( http://www.cisco.com/en/US/tech/tk543/tk760/technologies_tech_note09186a0080108e2d.shtml ) Bon courage Mohamed Touré 2013/6/16 Antoine Durant > Bonjour, > > Je ne sais pas et ne comprend pas le phénomène justement... > > Même un test avec iperf en UDP ne me permet pas de monter à 10M. > > Les RFC ne m'aide pas du tout dans ce cas la... J'ai l'impression que le > switch se bride tout seul à 4.10Mbps au lieu du 10M configuré dans la > police !! > > wget http://10.0.0.110/200M.bin -O /dev/null on 192.168.0.170 : > > Avec service-policy : 513KB/s (~4.10 Mbps <> 10Mbps) > Sans service-policy : 11.2MB/s (~90 Mbps = 100Mbps) > > service-policy 1000 = 10,00 Mbps > > Une solution ? Avez vous une conf sur switch cisco qui fonctionne ?? > > > > De : Laurent Cima > À : frnog@frnog.org > Envoyé le : Samedi 15 juin 2013 23h48 > Objet : Re: [FRnOG] [TECH] Test bandwidth IPERF/CISCO bisarre > > > Parce-que la limitation dans l'autre sens drop les ACK, que l'ouverture > fait du yoyo et que les 6Mbps restant sont pleins de retransmit ? > > Laurent > > Le 14/06/2013 18:04, Antoine Durant a écrit : > > Bonjour, > > > > J’ai un problème d’incompréhension des résultats suivants effectués avec > IPERF et un switch cisco ayant un service-policy sur les ports de tests. > > > > 192.168.0.160 : Test limité à 1M > > 192.168.0.170 : Test limité à 0.5M, 1M et 10M > > interface f0/X > > service-policy input policy_ip > > > > Le test 2 et 3 me semble bon mais pas le 4 !!?? > > > > -> Test 1 (100M) : Pas de limitation (pas de police activé pour les > ports du switch) > > > > Client connecting to 192.168.0.160, TCP port 5001 > > TCP window size: 80.6 KByte (default) > > > > [ 5] local 192.168.0.170 port 54551 connected with 192.168.0.160 port > 5001 > > [ ID] Interval Transfer Bandwidth > > [ 5] 0.0-10.0 sec 113 MBytes 94.8 Mbits/sec > > [ 4] local 192.168.0.170 port 5001 connected with 192.168.0.160 port > 50460 > > [ 4] 0.0-10.1 sec 113 MBytes 94.1 Mbits/sec > > > > -> Test 2 (500K) : police 50 10 exceed-action drop > > > > Client connecting to 192.168.0.160, TCP port 5001 > > TCP window size: 115 KByte (default) > >
Re: [FRnOG] [TECH] Limitation trafic entre deux MAC sur 2960
si ton LAN est 192.168.10.0/24 par exemple, essaies : *! ip access-list extended acl_ip * *deny ip 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255 * *permit ip any any ! * L'idéal c'est de pouvoir marquer tes paquets sur le LAN (IP prec, DSCP) ensuite tu matches sur ces valeurs dans la classe, moins gourmant en ressources que les ACLs. Cordialement 2013/6/13 Antoine Durant > Alors j'arrive a faire ma limitation par port uniquement en input avec > permit ip any any > > ip access-list extended acl_ip > permit ip any any > class-map match-all class_ip > match access-group name acl_ip > > Je n'arrive pas à appliquer une access-list qui dit que tout ce qui est > dans le réseau local ne doit pas matcher mais tous ce qui passe par la > passerelle doit matcher. > Un exemple de conf a me donner ? > > Une autre question : > il n'est pas possible d'utiliser service-policy output sur 2960. > > Quel switch cisco accepte d'utiliser service-policy output ??? > ------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Limitation trafic entre deux MAC sur 2960
En effet j'avais compris filtrage (interdiction de communiquer) plutôt que limitation de trafic. Désolé. Par ailleurs d'après la config ci-dessus, tu mixes deux concepts : CBFWQ et CAR. Tu as de la doc sur CAR : http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfcar_ps1835_TSD_Products_Configuration_Guide_Chapter.html 1. Tu definis ton ACL 2. Tu appliques le rate-limit au niveau de l'interface Cordialement Mohamed 2013/6/12 Antoine Durant > J'ai la version suivante : Cisco IOS Software, C2960 Software > (C2960-LANBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1) > > J'ai essayé la configuration suivante mais cela ne marche pas... > > class-map match-all LIMIT-TRAFFIC > match access-group 100 > ! > policy-map LIMIT-TRAFFIC > class LIMIT-TRAFFIC > police 100 1 exceed-action drop > ! > interface FastEthernet0/11 > service-policy input LIMIT-TRAFFIC > ! > access-list rate-limit 100 0040.63dd.e086 >*De :* Mohamed Touré > *À :* Antoine Durant > *Cc :* "frnog-t...@frnog.org" > *Envoyé le :* Mercredi 12 juin 2013 13h41 > *Objet :* Re: [FRnOG] [TECH] Limitation trafic entre deux MAC sur 2960 > > Bonjour > > Tu peux essayer les Port ACLS (Lan base Image) en utilisant une MAC > extended access-list. Ils ne s'appliquent normalement que sur des > interfaces L2 physiques et uniquement en entrée. > > Les Vlan ACL ne sont pas officiellement supportés sur les 2960, de mémoire > tu peux les utiliser sur du 12.2(58)SE. A tester > > Cordialement > > Mohamed Touré > > > 2013/6/12 Antoine Durant > > > Bonjour la liste, > > > > Toujours dans ma quête de limitation du trafic, je reviens pour avoir des > > infos… > > Après quelques échanges avec certains d’entre vous (merci au passage !), > > la majorité me préconise de faire ma limitation sur mon cisco 2960, > plutôt > > que sur le routeur. > > > > Donc j’en déduis une configuration de ce type puis il est que L2 : > > Il faut limiter le trafic entre l’adresse MAC du serveur et l’adresse MAC > > du routeur WAN. > > Pas de limite de trafic dans le LAN. > > > > Server1 MAC : 00-1F-F0-5D-5D-6C > > Interface WAN MAC : 00-50-56-C0-00-01 > > Server1[2960]----[ROUTER]WAN > > > > Cependant je ne trouve absolument pas comment faire et appliquer cette > > technique sur le 2960… > > > > Merci ! > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > > > > -- > Mohamed Touré > 06 38 62 99 07 > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Limitation trafic entre deux MAC sur 2960
Bonjour Tu peux essayer les Port ACLS (Lan base Image) en utilisant une MAC extended access-list. Ils ne s'appliquent normalement que sur des interfaces L2 physiques et uniquement en entrée. Les Vlan ACL ne sont pas officiellement supportés sur les 2960, de mémoire tu peux les utiliser sur du 12.2(58)SE. A tester Cordialement Mohamed Touré 2013/6/12 Antoine Durant > Bonjour la liste, > > Toujours dans ma quête de limitation du trafic, je reviens pour avoir des > infos… > Après quelques échanges avec certains d’entre vous (merci au passage !), > la majorité me préconise de faire ma limitation sur mon cisco 2960, plutôt > que sur le routeur. > > Donc j’en déduis une configuration de ce type puis il est que L2 : > Il faut limiter le trafic entre l’adresse MAC du serveur et l’adresse MAC > du routeur WAN. > Pas de limite de trafic dans le LAN. > > Server1 MAC : 00-1F-F0-5D-5D-6C > Interface WAN MAC : 00-50-56-C0-00-01 > Server1[2960][ROUTER]WAN > > Cependant je ne trouve absolument pas comment faire et appliquer cette > technique sur le 2960… > > Merci ! > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] multihome BGP avec annonces conditionnelles et statiques
Bonjour, Je peux vous proposer une solution qui consiste à mettre à jour les prefix-list via cisco EEM. (je suppose que vous utilisez du cisco) La solution est spécifique certes, mais c'est pour répondre à un besoin non standard. Topogie : CPE : R1 f0/0 : *192.168.12.1* -> To ISP1 f0/1 : *192.168.13.1* -> To ISP2 PE1: R2 f0/0 : 192.168.12.2 -> To R1 PE2: R3 f0/0 : *192.168.13.3 *-> To R1 *Config BGP* : ! * router bgp 1 neighbor 192.168.12.2 remote-as 2* * neighbor 192.168.12.2 route-map TO-ISP1 out neighbor 192.168.12.2 soft-reconfiguration inbound neighbor 192.168.13.3 remote-as 3* * neighbor 192.168.13.3 route-map TO-ISP2 out neighbor 192.168.13.3 soft-reconfiguration inbound* *exit* ! *ip prefix-list ISP1 permit 10.10.10.0/24* *ip prefix-list ISP2 permit 11.11.11.0/24 *!* *!* route-map TO-ISP1 permit 10 match ip address prefix-list ISP1 *!* **route-map TO-ISP2 permit 10 match ip address prefix-list ISP2 *! *Mise en situation *: A ce stade, supposons que CPE1 ait dans sa table BGP les prefix : 10.10.10.0/24 et 11.11.11.0/24. Avec la config ci-dessus, ISP1 recevra le prefix *10* et ISP2 le prefix *11* : on est en situation nominale. Maintenant supposons qu'on perde le lien vers ISP1. Ce que vous souhaitez c'est d'annoncer 10 et 11 à l'ISP2. *Code EEM* : *event manager applet DOWN event syslog pattern "%BGP-5-ADJCHANGE: neighbor 192.168.12.2 Down Interface flap" action 1.0 syslog msg "Interface Down : Modifying Prefix-list" **=> message qui va apparaitre dans les logs action 1.1 cli command "enable" action 1.2 cli command "configure terminal" action 2.0 cli command "ip prefix-list ISP2 permit 10.10.10.0/24" action 3.0 cli command "end" action 4.0 cli command "write" action 5.0 "clear ip bgp 192.168.13.3 soft"* ! *event manager applet UP event syslog pattern "%BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up" action 1.0 syslog msg "BGP Session UP : Modifying Prefix-list" => message qui va apparaitre dans les logs action 1.1 cli command "enable" action 1.2 cli command "configure terminal" action 2.0 cli command "no ip prefix-list ISP2 permit 10.10.10.0/24" action 3.0 cli command "end" action 4.0 cli command "write" action 5.0 "clear ip bgp 192.168.13.3 soft"* ! *Explications* : Principe : Si* évenement* alors *action*. L'événement peut-être choisi parmi une liste définie par le constructeur (présence d'un préfixe dans la table de routage, interface down, ipsla ...). Ici je traque le message *%BGP-5-ADJCHANGE: neighbor 192.168.12.2 Down Interface flap *dans syslog. Un autre peut-être choisi bien entendu. Lorsque cette condition est satisfaite, je modifie à la volée ma prefix-list vers ISP2. *! enable configure terminal ip prefix-list ISP2 permit 10.10.10.0/24 end *! Dans le meme principe, si la session devient UP à nouveau, je retire le prefix. A chaque fois un clear soft sera necessaire pour prendre en compte la route-map au niveau du process BGP. NB : A toute fin utile, il faudrait surveiller la charge CPU avant de mettre en production. Cordialement Mohamed Touré 2013/3/4 jehan procaccia INT > bonjour, > > la methode suivante fonctionne partiellement mieux: > > > router bgp ASNUM > neighbor x.x.x.x advertise-map QQ-PREFIX exist-map 1ST-ISP-UP > neighbor x.x.x.x advertise-map MY-PREFIXES non-exist-map 1ST-ISP-UP > neighbor x.x.x.x route-map MY-PREFIXES out > > en mode nominal (ISP primaire UP) j'annonce bien mes QQ-PREFIX à l'ISP > secondaire > en cas de perte de l'ISP primaire j'annonce bien dynamiquement tous mes > prefixes MY-PREFIXES à l'ISP secondaire > mais malheureusement je n'annonce plus les prefix QQ-PREFIX dans cette > situation, en effet "exist-map 1ST-ISP-UP" n'est plus vrai, donc je > suppose qu'il élimine les prefix QQ-PREFIX qui sont inclus dans MY-PREFIXES > et n’annonce que le reste des MY-PREFIXES . > > Bref c'est mieux, mais ce n'est pas encore satisfaisant pour assurer le > trafic engineering attendu , en effet quand l'ISP primaire est tombé, les > QQ-PREFIX qui profitaient d'un trafic engineering via les 2eme ISP se > retrouvent coupé du monde car ils ne sont plus annoncés au secondaire, > alors même que ce dernier (ISP 2) n'a subit aucune perte ! > > J'ai bien entendu les differentes suggestions concernant l'AS-Prepend, > j'avais commencé par ça, mais malheureusement ce n'est pas déterministe, il > y aura toujours qq-part sur le chemin un ISP qui se foutra de la longueur > de l'AS-PATH et favorisera son peering gratuit plutôt qu'un transit $$$ > c'est du vecu,
Re: [FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
En effet la fonctionnalité premiere du module conntrack est de gérer l'état des connexions (ce qui rend Netfilter stateful). Il enregistre les connexions dans les tables avec un timeout et met à jour les sessions. Ces tables sont consultées dans la base de règles pour autoriser ou non le trafic en fonction de son état. http://people.netfilter.org/pablo/docs/login.pdf Des modules qui pourraient aider à contrer un DoS (qui ne sature pas forcément le lien upstream vers ISP), sont *ipset, recent*, *iplimit*, *condition, geoip*... Combinés ou non, ils peuvent donner de bons résultats. Encore une fois tout dépendra du type de DoS ... Contrer un DoS applicatif (slowloris par exemple) nécessitera d'autres approches au niveau 7. Le problème primaire sera de pouvoir "profiler" les utilisateurs légitimes et de les distinguer des utilisateurs DoS. Tache pas toujours facile surtout que lorsqu'on fait fasse à un DoS, le temps de réaction est très limité. Par ailleurs en disposant d'outil d'analyse adapté, on peut arriver à trouver un discriminant. Les paquets issus de l'attaque auront potentiellement des points communs (paramètres TCP/IP, as hop count, as path, ...) L'idée derriere, c'est de créer une sorte de Whitelist temporaire au moment où on est confronté au DoS. Le module geoip permet par exemple de n'autoriser que certains pays à se connecter au serveur en cas d'attaque. Une proposition serait d'utiliser plusieurs chaines de traitement des paquets (Netfilter est bien adapté pour ça) et d'activer les actions de défense lorsque une condition de DoS a été déclenchée (module condition). Le module recent quant à lui permet de limiter le nombre de paquet par seconde. Le nombre de règles aura un impact sur la performance du firewall. Cela dépendra des paramètres de la machine (RAM, CPU, I/O ...). Le parcours d'un firewall classique étant linéaire (Pour Netfliter : du moins au sein d'une chaine), l'ordre des règles reste important. On aura intérêt à placer les règles qui ont un hitcount élevé au tout début de la base de règles. Mohamed Touré 2012/9/8 Thomas Mangin > Ce qu il faut surtout avec conntrack c est augmenter l allocation de > memoire par defaut pour le module > > Sent from my iPad > > On 8 Sep 2012, at 18:02, Frederic Dhieux wrote: > > > Le 08/09/2012 18:50, Radu-Adrian Feurdean a écrit : > >> > >> Meme pas besoin d'une regle. Charger le module conntrack est > >> generalement assez. > >> Sans conntrack, quelques centaines de regles posent pas beaucoup de > >> problemes. Pour plus, faut essayer de hierarchiser un peu. > > le module conntrack pose plutôt problème par rapport au trafic > indépendamment des règles, les règles sur certains aspects peuvent charger > le serveur, même sans conntrack, si on cumule trop de règles longues à > traiter dans le cycle de netfilter. > > > > Enfin dans mes souvenirs c'est plutôt ça. > > > > Fred > > > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Detecter DDos outils et null-router sur quagga
La solution Iptables (tout firewall en général) peut convenir mais dépendra de la volumétrie du DoS et du type d'applications hébergées derrière. Deux questions essentielles : dimensionnement du FW (aussi de la taille de BW) et possibilité de fonctionner en mode blacklist ou whitelist. Le plugin *ipset* de Netfilter permet de justement créer des règles qui permettent de filtrer en fonction des listes définies. Un bon algorithme d'analyse des logs permet de populer automatiquement les sets en cas d'attaque et dropper les paquets très tôt dans le passage au niveau des chaines. Aprés au niveau opérateur, ils peuvent avoir des solutions comme arbornetworks, qui permettent de ne laisser passer que le flux intéressant et qu'ils facturent surement :-) Au niveau routage pur, tu peux jouer avec les annonces bgp, sinkholing, urpf, filtrage en entrée ou sortie d'AS .. Mohamed Touré 2012/9/6 Thomas Mangin > > Quand à la détection, c'est pour le coup bien plus complexe. Je n'ai pas > > connaissance d'un produit non commercial fournissant ce service. Les > > technologies les plus connues sont sans doute celles de cisco et > > d'arbornetworks. > > Pareil ici, NetFlow est souvent la source des informations. Dans beaucoup > de cas la solution est une sauce maison. > > Thomas > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
