> Quelqu'un a des retours d'exp�rience des routeurs foundry netiron (NI4GMR) ?
Salut, Vaste sujet et long debat :) Le fonctionnement du routage chez Foundry est malheureusement peu documente et parfois un peu exotique (si quelqu'un a compris le fonctionnement et l'utilitee de la table ip-cache qu'il me fasse signe!) Il existe 2 generations chez Foundry networks, dont les caracteristiques techniques sont tres differentes. Mieux vaut bien comprendre le fonctionnement du routage Foundry avant de s'engager sur ce type de materiel. Dans tous les cas, malheureusement, le materiel bigiron/netiron souffre d'un probleme recurrent de sensibilite aux floods et de non adequation aux reseaux des FAI (peer-to-peer notament), de part leur fonctionnement au niveau du routage, flow-based. - Le materiel Ironcore, ancienne generation, concue au debut des annees 2000 lorsque la table de routage Internet n'etait pas si grosse et desaggrege, fonctionne comme beaucoup de materiel du marche sur le principe du "flow-based" (comme beaucoup d'Extreme par exemple) Le routage sur cette generation d'asics fonctionne de la maniere suivante : Le premier paquet IP, pour une combinaison d'ip SRC/DST qui n'est pas deja en CAM, est integralement envoye au CPU via le bus de management (1Gbit/sec fullduplex je crois), qui vas proceder au -routage soft du paquet- et pusher un enregistrement source (/32) et destination (/32) dans les CAM des cartes. Les paquets suivants pour la meme source/destination seront routes en hardware, via les asics ironcore, pendant 8 secondes (duree par defaut de l'expiration des entrees en CAM). Pour les ACL, meme principe, flow-based, la premiere combinaison ip source/ip destination est evaluee (deny ou accept) et forwardee en CPU. Conclusion: Ce principe de fonctionnement pose probleme en cas de floods distribues, ou en cas de nombreuses combinaisons ip source/ip destination (trafic peer-to-peer par exemple). A partir de 1500-2000 combinaisons differentes par secondes, le CPU approche des 100% d'utilisation, le BGP commence a flapouiller, tu perds la main sur l'equipement, etc... Autres limitations, les asics ironcore ne supportent pas l'IPV6, et ne disposent d'aucune fonctionnalitees d'accounting, pas de netflow ni de sflow, pas de RMON, pas de mac-accounting non plus ... La NI4GMR est une carte ironcore. - Le materiel Jetcore, nouvelle generation, fonctionne egalement sur le principe du "flow-based" tout comme la generation ironcore, mais apporte quelques ameliorations notable. Au niveau routage, le header du premier paquet pour une combinaison SRC / DST est envoye via le bus de management au CPU qui lui-meme vas pusher un enregistrement SRC / DST dans les CAM / TCAM des cartes. Le CPU ne route pas le paquet en soft, le routage est effectue par l'asic jetcore apres programmation de l'entree. Les paquets suivants pour la meme SRC/ DST sont routes en hardware via l'asics, pendant une duree de 8 secondes, sans evaluation par le CPU. Pour les ACL, elles sont integralement descendues en TCAM, donc non flow-based. L'avantage est non negligeable, seul le header est renvoye au CPU (et non l'integralite du paquet), et le routage du premier paquet flow-based est effectue par les asics (et non le cpu). Ceci permet d'atteindre assez facilement une vitesse d'apprentissage de 6000-7000 combinaisons par secondes, mais reste malheureusement tres sensible aux floods distribues... (cpu a 100%, flapouillage BGP etc...). On aime bien cependant le support IPV6 en hardware, la presence de sflow/rmon/netflow completement harware, le CPU puissant (powerpc 466Mhz), le support de 1Go de ram etc... Pour info, Foundry developpe egalement une version Service Provider (versions 09.x.x) que nous testons actuellement, qui apparament descend la classe SRC et DST en cam (au lieu de la src /32 dst /32), ce qui permet d'economiser beaucoup de CPU. Quoiqu'il arrive, le materiel Jetcore reste du flow-based... Il existe plusieures solutions pour optimiser un peu la chose, et baisser la sensibilite aux floods, notament l'aggregation des CAM (ip net-aggregate) qui divise l'internet en /16 par evaluation sur la route par defaut (a fixer par exemple sur un transitaire). Il ne faut pas hesiter non plus a repartionner les CAM (augmenter la CAM layer3 et baisser la CAM layer2/layer4), le CPU-protection aide egalement, en protegeant ton CPU lors des floods en fesant expirer plus rapidement les entrees en CAM et evitant ainsi tout debordement (lorsque la cam est pleine, le reste est traite en 100% soft). Contacte moi en privee si tu veut quelques conseils pour optimiser ton materiel Foundry si en fait l'acquisition. Concernant la differente Netiron/Bigiron, il n'y en as pas ! A part l'argument "vitrine" ou "j'ai la plus grosse", les cartes et le chassis sont strictement identiques techniquement parlant, a part la possibilite de faire du MPLS sur les Netiron moyennant une PROM et un soft special a un prix completement prohibitif. L'argument ISIS n'est plus d'actualite, les versions 07.7.x du soft foundry supportant l'IGP ISIS sur l'ensemble des generations d'equipements, y compris l'ironcore. La taille des CAM est identique (heee oui!) entre les netiron/bigiron (ironcore) si tu met ton routeur en route-only et que tu transfert la cam layer2 des bigiron en cam layer3 ... Je te recommande donc plutot la generation Jetcore en bigiron, meilleur rapport qualite/prix. Cependant si ton trafic est faible (moins de 400-500mbits) et tes combinaison de src/dst faible (moins de 1000 combinaisons par secondes), et que tu n'as pas de problemes recurents de floods, la generation ironcore suffira largement a tes besoins. D'une maniere generale, evite le materiel "gris" Foundry (ebay etc..) comme la peste, on y retrouve de nombreuses cartes moisies notament les fameuses premieres B8G equipees d'optiques auto-suicide Molex, ou les cartes SDH B2P622 d'ancienne generation qui ne forwardent pas entre leurs deux ports POS et qui aiment bouffer du packet-lost ... Les mauvaises experiences avec Foundry sont nombreuses, tu peut les eviter avec du materiel neuf et recent. L'implementation du BGP sur les softs assez anciens est completement moisie, je te recommandes la serie 07.7.x qui regle definitivement les problemes de stabilite du BGP. Excellent week-end, Arnaud -- Arnaud - OVANET Eurowan operations manager 130-136 Bvd verdun BAT9 - 92400 Courbevoie Tel +33 140590968 - Fax +33 145757613 -- Arnaud - OVANET Eurowan operations manager 130-136 Bvd verdun BAT9 - 92400 Courbevoie Tel +33 140590968 - Fax +33 145757613 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
