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 li...@freeheberg.com: 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 frede...@syn.fr 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 marque/modèle_préféré(e)_de_la_personne ;) 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é
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 fr...@radu-adrian.feurdean.net 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] 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 nicolas.str...@jaguar-network.com 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 m...@my.gd 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 bbil...@splio.fr 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é
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 fr...@radu-adrian.feurdean.net 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é
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é mohamed.to...@secresys.com 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 fr...@radu-adrian.feurdean.net 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] 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 antoine.duran...@yahoo.fr 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 lel...@gandi.net À : Leland Vandervort lel...@gandi.net Cc : Antoine Durant antoine.duran...@yahoo.fr; 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] 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 antoine.duran...@yahoo.fr 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] 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 antoine.duran...@yahoo.fr 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 fr...@l2ct.eu À : 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) [ 5] local 192.168.0.170 port 54553 connected with 192.168.0.160 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0-11.1 sec 1.38 MBytes 1.04 Mbits/sec [ 4] local 192.168.0.170 port 5001 connected with 192.168.0.160 port 50462 [ 4] 0.0-15.5 sec 896 KBytes 473 Kbits/sec - Test 3 (1M) : police 100 10 exceed-action drop
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 antoine.duran...@yahoo.fr 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
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 antoine.duran...@yahoo.fr 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] 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 antoine.duran...@yahoo.fr 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é mohamed.to...@secresys.com *À :* Antoine Durant antoine.duran...@yahoo.fr *Cc :* frnog-t...@frnog.org 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 antoine.duran...@yahoo.fr 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] 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 jehan.procac...@int-evry.fr 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, j'avais au moins 30% du trafic qui ne prenait pas le chemin retour attendu pas l'as-prepend :-( . Si qq'un a encore une meilleur idée, je reste a l’écoute, je suis surpris que BGP ne sache pas gérer ça !? Le 01/03/2013 20:05, Ccde Cissp a écrit : Bonjour, Effectivement, vue cette histoire de AND Logique entre les différentes maps définies. Vous pouvez par exemple tester: 1. Et là (je pense que) ce notre dernier espoir avec les annonces
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 thomas.man...@exa-networks.co.uk 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 frede...@syn.fr 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 thomas.man...@exa-networks.co.uk 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/
