Re: [FRnOG] localisation des adresses IP

[Dominique Rousseau]

Le Tue, Jul 28, 2009 at 05:10:48PM +, yao marius hemann kanga 
[hermannka...@yahoo.fr] a écrit:
> je ne comprends pas ? sur quels critères ses outils se basent? est ce
> que ses outils sont fiables? en connaissez vous de fiables?

Ils se basent sur des données dont la production est non transparente
(forcément, c'est le métier de la boite qui les vend). Pour une part,
ils doivent dégrossir en utilisant le contenu des bases des RIR (RIPE,
APNIC, ARIN, ...), et un subtil mélange de trucs spécifiques.
Une très connue et très utilisée, notamment parcequ'il en existe un
extrait gratuit, c'est GeoIP de Maxmind.


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
50, rue Riolan 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Vlans traversants

[Raphael Mazelier]

Bonjour à tout le monde sur la liste.

Hier en regardant le design de notre archi de firewalling interne je me 
suis demandé pourquoi on en été arrivé à une telle complexité : pas 
moins de 8 sessions bgps croisés entre les deux firewalls en cluster... 
bref.


Je me rappelle que le départ de ce design "complexe" était du au fait 
que nous voulions pas de vlans 'traversants' entre nos différents sites 
et sur nos interlans.


Les différents ingé réseaux que j'ai connus m'ont toujours affirmé que 
faire des vlans propagés sur plusieurs sites physiques c'était pas bien.


Je peux concevoir qu'il vaut mieux avoir des coupures "propres" niveau 
layer3 plutôt qu'avoir un layer 2 coupé en deux, mais a quel prix niveau 
compléxité qui en découle ? Je penses aussi qu'il vaut mieux avoir des 
gateway sur le même site pour éviter des aller-retours inutiles sur 
l'interlan.


J'aimerai avoir votre avis et des arguments sur cette affirmation car je 
trouve ca quand même assez pratique du point de vue de l'administrateur 
système que je suis.



Cdt,

--
raf


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] localisation des adresses IP

[Guénolé Saurel]

Le Wed, Jul 29, 2009 at 10:02:07AM +0200, Dominique Rousseau racontait :
> Une très connue et très utilisée, notamment parcequ'il en existe un
> extrait gratuit, c'est GeoIP de Maxmind.

Je viens de déménager de 350km tout en gardant la même IP,  je vais de
ce pas vérifier si la base GeoIP est à jour :) 

-- 
 L'homme descend du singe.
 George Bush n'a pas encore trouvé l'échelle.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Vlans traversants

[Raphael Maunier]

Le 29 juil. 09 à 11:03, Raphael Mazelier a écrit :


Bonjour à tout le monde sur la liste.

Hier en regardant le design de notre archi de firewalling interne je  
me suis demandé pourquoi on en été arrivé à une telle complexité :  
pas moins de 8 sessions bgps croisés entre les deux firewalls en  
cluster... bref.


Je me rappelle que le départ de ce design "complexe" était du au  
fait que nous voulions pas de vlans 'traversants' entre nos  
différents sites et sur nos interlans.


Les différents ingé réseaux que j'ai connus m'ont toujours affirmé  
que faire des vlans propagés sur plusieurs sites physiques c'était  
pas bien.


Le soucis souvent des inge, c'est qu'ils n'ont souvent pas de notion  
de prix et de passation d'information en cas de changement de personnel.
C'est bien de se faire plaisir parfois, de mon cote je suis plutot  
partisan du "keep it simple". Chez Neo, nous avons fonctionne tres  
longtemps en spanning-tree sur Cisco 6500 sans soucis.
Ensuite quand on a commence a avoir beaucoup de debit, le load- 
balancing, backup etc etc, nous avons tout passe en L3.


Je peux concevoir qu'il vaut mieux avoir des coupures "propres"  
niveau layer3 plutôt qu'avoir un layer 2 coupé en deux, mais a quel  
prix niveau compléxité qui en découle ? Je penses aussi qu'il vaut  
mieux avoir des gateway sur le même site pour éviter des aller- 
retours inutiles sur l'interlan.
Je ne vois pas les blocages d'avoir des vlans pour chaque "interco" / 
31 ou /30 entre les equipements. Si le spanning-tree est correctement  
configure, je ne vois pas pourquoi monter une usine a gaz alors que  
l'on pourrait faire super simple.




J'aimerai avoir votre avis et des arguments sur cette affirmation  
car je trouve ca quand même assez pratique du point de vue de  
l'administrateur système que je suis.



Cdt,

--
raf


---
Liste de diffusion du FRnOG
http://www.frnog.org/



--
Raphaël Maunier
NEO TELECOMS
Engineering Manager





---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Comment mon switch a exploser

[Youssef Ghorbal]

Bonjour,

 Certain d'entre vous l'ont peut etre remarque, Interoute a eu un
incident sur son backbone Parisien vers midi hier.
 Au meme moment, un de mes switch qui acceuille une Interlan (Service
FastEthernet) a commence a souffrir le martyr et dropper des paquets
(80% de perte de paquets) Le probleme est que le drop des paquetes ne
concernais pas uniquement le traffic venant ou a destinantion de ce
port en particulier mais sur tout le traffic qui traverse ce switch
(Meme le reboot de l'equipement n'as pas eu d'effet, il ne s'est calme
que quand on a vire le cable de l'Interlan)
 J'essaye donc de glaner quelques infos sur la nature exacte de
l'incident Interoute qui pourrais expliquer pourquoi mon switch est
parti en live et surtout comment me premenir contre ce genre de
situation a l'avenir. Le switch en lui meme peut etre en cause (bug ou
mauvaise implementation d'une fonction, ce qui ne m'etonne pas, vu
qu'il s'agit apres tout d'un PowerConnect de chez Dell)
 Si vous avez eu des cas similaires je suis aussi preneur de vos
retour d'experience.

Youssef Ghorbal
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Comment mon switch a exploser

[Thomas Mangin]

pourquoi mon switch est
parti en live et surtout comment me premenir contre ce genre de
situation a l'avenir. Le switch en lui meme peut etre en cause (bug ou
mauvaise implementation d'une fonction, ce qui ne m'etonne pas, vu
qu'il s'agit apres tout d'un PowerConnect de chez Dell)


Sans infos specifiques, dur a dire. Tu devais surement recevoir des  
frames corrompues sur le port.
Cela peux causer le switch a enregister plus de MAC sur ce port que le  
switch supporte.

Google MAC filtering :) ...

Thomas


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re : Re: [FRnOG] Comment mon switch a exploser

[marc celier]

Re : [FRnOG] Vlans traversants

[marc celier]

Re: Re : Re: [FRnOG] Comment mon switch a exploser

[Youssef Ghorbal]

Bonjour,

 En effet, c'est visiblement une tempete de broadcast ethernet qu'on
s'est pris. D'apres les graphes, au moment du probleme le nombre de
paquet sur les ports explose.
 Sur Cisco y'a t'il des commandes pour limiter le broadcast ethetnet
par interface ou par VLAN. Un rate-limiting pour les paquets
ff:ff:ff:ff:ff:ff en quelque sorte.

Youssef Ghorbal
---

2009/7/29 marc celier :
> normalement quand une trame est corrompue et que le CRC est faux, cette
> trame est purement est simplement supprimee.
>
> Je pense qu'il s'agit de broadcasts, qui ont ete recus sur le port interoute
> est retransmis aux autres ports du meme vlan.
>
> as tu des VLAN configures sur ton switch, ou bien tous les ports sont sur le
> meme VLAN. compare les courbes de trafic des ports appartenants aux meme
> VLAN que celui ou est configure le port interoute.
>
> Durant ce probleme, nous avons recu jusqu'a 800 mbits de trafic venant de
> interoute au lieu de 300 mbits habituellement.
>
> - Message d'origine -
>
> De : Thomas Mangin
>
> Envoyés : 29.07.09 11:43
>
> À : Youssef Ghorbal
>
> Objet : Re: [FRnOG] Comment mon switch a exploser
>
>
>
>> pourquoi mon switch est
>> parti en live et surtout comment me premenir contre ce genre de
>> situation a l'avenir. Le switch en lui meme peut etre en cause (bug ou
>> mauvaise implementation d'une fonction, ce qui ne m'etonne pas, vu
>> qu'il s'agit apres tout d'un PowerConnect de chez Dell)
>
> Sans infos specifiques, dur a dire. Tu devais surement recevoir des
> frames corrompues sur le port.
> Cela peux causer le switch a enregister plus de MAC sur ce port que le
> switch supporte.
> Google MAC filtering :) ...
>
> Thomas
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: Re : Re: [FRnOG] Comment mon switch a exploser

[Thomas Mangin]

Salut,
normalement quand une trame est corrompue et que le CRC est faux,  
cette trame est purement est simplement supprimee.



Yep, j aurais du parler de Mac leak
as tu des VLAN configures sur ton switch, ou bien tous les ports  
sont sur le meme VLAN. compare les courbes de trafic des ports  
appartenants aux meme VLAN que celui ou est configure le port  
interoute.



Generalement quand ca arrive SNMP polling ne marche plus.

Y a t il tjs des switchs qui passe en "hub mode" durant un storm ?

Thomas

Ps: ecrire francais sur in iPhone anglais c est la galere
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Vlans traversants

[Fabien Delmotte]

Bonjour,

Il n'y a pas de solution miracle, par moment le niveau 2 répond au besoin et 
par moment il faut du niveau 3. Ce n'est pas une question de complexité mais 
plutôt de guerre de cloché (stérile) entre les pro du L3 et ceux du L2.

Dicton du jour :
"Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers !!!"

Fabien
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Administration de pare-feu Cisco ASA 5520

[Romain LE DISEZ]

Salut à tous,

nous sommes en train de terminer le déploiement de deux pare-feu Cisco
ASA 5520. Notre architecture étant redondante, ils doivent avoir tous
les deux les même règles de filtrage afin que la reprise en cas de panne
se passe bien.

Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et
quelques commandes (SCP, pfctl), nous pouvions facilement répliquer la
configuration.

Nous cherchons le moyen d'avoir un fonctionnement similaire avec les
Cisco. Par exemple, un fichier texte de ce type :
 
qui nous permette, en une commande, de construire les groupes (auxquels
nous appliquons les ACL) et de les pousser sur les deux pare-feu.

Avant que l'on commence à scripter, connaissez vous une solution de ce
type ? Comment faites vous pour bien gérer vos ASA ?

Merci.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[Fabrice]

Bonjour,


Je me trompe peut être mais Firewall Builder en gui ?


Le 29 juillet 2009 15:36, Romain LE DISEZ  a écrit
:

> Salut à tous,
>
> nous sommes en train de terminer le déploiement de deux pare-feu Cisco
> ASA 5520. Notre architecture étant redondante, ils doivent avoir tous
> les deux les même règles de filtrage afin que la reprise en cas de panne
> se passe bien.
>
> Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et
> quelques commandes (SCP, pfctl), nous pouvions facilement répliquer la
> configuration.
>
> Nous cherchons le moyen d'avoir un fonctionnement similaire avec les
> Cisco. Par exemple, un fichier texte de ce type :
> 
> qui nous permette, en une commande, de construire les groupes (auxquels
> nous appliquons les ACL) et de les pousser sur les deux pare-feu.
>
> Avant que l'on commence à scripter, connaissez vous une solution de ce
> type ? Comment faites vous pour bien gérer vos ASA ?
>
> Merci.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: Re : Re: [FRnOG] Comment mon switch a exploser

[Ronnie Garcia]

Youssef Ghorbal a écrit :
>  En effet, c'est visiblement une tempete de broadcast ethernet qu'on
> s'est pris. D'apres les graphes, au moment du probleme le nombre de
> paquet sur les ports explose.
>  Sur Cisco y'a t'il des commandes pour limiter le broadcast ethetnet
> par interface ou par VLAN. Un rate-limiting pour les paquets
> ff:ff:ff:ff:ff:ff en quelque sorte.

man storm-control


> ---
> 
> 2009/7/29 marc celier :
>> normalement quand une trame est corrompue et que le CRC est faux, cette
>> trame est purement est simplement supprimee.
>>
>> Je pense qu'il s'agit de broadcasts, qui ont ete recus sur le port interoute
>> est retransmis aux autres ports du meme vlan.
>>
>> as tu des VLAN configures sur ton switch, ou bien tous les ports sont sur le
>> meme VLAN. compare les courbes de trafic des ports appartenants aux meme
>> VLAN que celui ou est configure le port interoute.
>>
>> Durant ce probleme, nous avons recu jusqu'a 800 mbits de trafic venant de
>> interoute au lieu de 300 mbits habituellement.
>>
>> - Message d'origine -
>>
>> De : Thomas Mangin
>>
>> Envoyés : 29.07.09 11:43
>>
>> À : Youssef Ghorbal
>>
>> Objet : Re: [FRnOG] Comment mon switch a exploser
>>
>>
>>
>>> pourquoi mon switch est
>>> parti en live et surtout comment me premenir contre ce genre de
>>> situation a l'avenir. Le switch en lui meme peut etre en cause (bug ou
>>> mauvaise implementation d'une fonction, ce qui ne m'etonne pas, vu
>>> qu'il s'agit apres tout d'un PowerConnect de chez Dell)
>> Sans infos specifiques, dur a dire. Tu devais surement recevoir des
>> frames corrompues sur le port.
>> Cela peux causer le switch a enregister plus de MAC sur ce port que le
>> switch supporte.
>> Google MAC filtering :) ...
>>
>> Thomas
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 


-- 
Ronnie Garcia
Dirigeant - Fondateur

Tél: +33 4 67 67 
Gsm: +33 6 295 00 295

http://www.ovea.com
http://www.linkedin.com/in/ronniegarcia

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[Simon Morvan]

Le 29/07/2009 16:25, Fabrice a écrit :

Bonjour,


Je me trompe peut être mais Firewall Builder en gui ?
Mais avec des scripts custom alors. Firewall Builder ne gère pas deux 
firewalls pour un jeu de règles il me semble.


Par ailleurs, ASA ne gère pas de lui même le fait que le slave soit iso 
au master ? PIX le faisait pourtant.


--
Simon




Le 29 juillet 2009 15:36, Romain LE DISEZ > a écrit :


Salut à tous,

nous sommes en train de terminer le déploiement de deux pare-feu Cisco
ASA 5520. Notre architecture étant redondante, ils doivent avoir tous
les deux les même règles de filtrage afin que la reprise en cas de
panne
se passe bien.

Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et
quelques commandes (SCP, pfctl), nous pouvions facilement répliquer la
configuration.

Nous cherchons le moyen d'avoir un fonctionnement similaire avec les
Cisco. Par exemple, un fichier texte de ce type :
 
qui nous permette, en une commande, de construire les groupes
(auxquels
nous appliquons les ACL) et de les pousser sur les deux pare-feu.

Avant que l'on commence à scripter, connaissez vous une solution de ce
type ? Comment faites vous pour bien gérer vos ASA ?

Merci.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[gu!llaume]

Le 29/7/2009, "Simon Morvan"  a écrit:
>Par ailleurs, ASA ne gère pas de lui même le fait que le slave soit iso
>au master ? PIX le faisait pourtant.


Les firewalls Juniper SSG ont nativement un mode cluster.
Ca serait quand meme pas de veine que les ASA ne le fasse pas...

gu!llaume
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[Raphael Mazelier]

Le 29/07/2009 15:36, Romain LE DISEZ a écrit :

Salut à tous,

nous sommes en train de terminer le déploiement de deux pare-feu Cisco
ASA 5520. Notre architecture étant redondante, ils doivent avoir tous
les deux les même règles de filtrage afin que la reprise en cas de panne
se passe bien.

   
Petite question ? pourquoi vouloir se faire du mal avec des cisco ASA 
qui sont vraiment relou à configurer alors que vous aviez une solution 
qui marchait avant ? pas assez cher ?

Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et
quelques commandes (SCP, pfctl), nous pouvions facilement répliquer la
configuration.

Nous cherchons le moyen d'avoir un fonctionnement similaire avec les
Cisco. Par exemple, un fichier texte de ce type :
   
qui nous permette, en une commande, de construire les groupes (auxquels
nous appliquons les ACL) et de les pousser sur les deux pare-feu.

Avant que l'on commence à scripter, connaissez vous une solution de ce
type ? Comment faites vous pour bien gérer vos ASA ?

   
Normalement les ASA peuvent se gérer en cluster automatiquement et 
répliquer la conf (voir les sessions) pour basculer automatiquement.
=> 
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00807dac5f.shtml#cmd

Je crois par contre que c'est optionnel et payant.


Merci.



   

--
raf
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[Radu-Adrian Feurdean]

On Wed, 29 Jul 2009 17:50:40 +0200, "Raphael Mazelier"
 said:

> Petite question ? pourquoi vouloir se faire du mal avec des cisco ASA 
> qui sont vraiment relou à configurer alors que vous aviez une solution 
> qui marchait avant ? pas assez cher ?

> > Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et

Because OpenBSD c'est pas "corporate", et certains "big chiefs" n'aiment
pas les trucs qui sortent des normes "corporate".
Il y a aussi le fait de pouvoir dire "on a utilise le meilleur (dpdv
marketing) qui existe" quand/si les choses tournent mal.

Parfois il faut faire des choses debiles pour des raisons encore plus
debiles.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[Thierry Del-Monte]

Bonjour,

Je confirme les ASA 5510, 5520, 5550 et 5580 peuvent s'administrer via 
une interface graphique ASDM (beaucoup moins ergonomique et moins 
pratique que Fwbuilder car par exemple pas possible de regrouper des 
règles ... ce n'est qu'un exemple parmi beaucoup d'autres) et peuvent 
aussi bien évidement se gérer en cluster actif/passif et suivant les 
modèles actif/actif avec même des contextes différents.


C'est assez facile à prendre en main, et assez fiable en cas de bascule 
(les boitiers se partagent les sessions donc en cas de bascule c'est 
transparent (normalement) )


Thierry




Le 29/07/2009 17:39, gu!llaume a écrit :

Le 29/7/2009, "Simon Morvan"  a écrit:
   

Par ailleurs, ASA ne gère pas de lui même le fait que le slave soit iso
au master ? PIX le faisait pourtant.
 



Les firewalls Juniper SSG ont nativement un mode cluster.
Ca serait quand meme pas de veine que les ASA ne le fasse pas...

gu!llaume
---
Liste de diffusion du FRnOG
http://www.frnog.org/

   

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[Raphael Mazelier]

Le 29/07/2009 18:06, Radu-Adrian Feurdean a écrit :

Because OpenBSD c'est pas "corporate", et certains "big chiefs" n'aiment
pas les trucs qui sortent des normes "corporate".
Il y a aussi le fait de pouvoir dire "on a utilise le meilleur (dpdv
marketing) qui existe" quand/si les choses tournent mal.

Parfois il faut faire des choses debiles pour des raisons encore plus
debiles.

   
Oui je te rassure chez nous aussi on a eu notre lot de solutions 
imposés, surtaillées et plus complexe que l'existant.
Celle qui m'est vraiment resté en travers c'est de remplacer Openvpn qui 
marchait juste bien par des ASAs avec au final bien plus de problèmes.
Mais bon parfois il faut savoir avaler des couleuvres pour progresser 
dans une boite.


--
raf
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Administration de pare-feu Cisco ASA 5520

[Hugues Brunel]

Hello,

Je confirme que c'est automatique à partir du moment où tes ASA sont 
bien configurés. Eventuellement un "write standby" force la synchronisation.


Pour la doc, ca devrait etre ici pour du Actif/Stdby:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00807dac5f.shtml

et ici pour de l'actif/actif:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080834058.shtml

En ce qui concerne le suivi de session, je n'ai jamais eu de problème, 
que ce soit en cas de crash d'un des 2 FW ou pendant un upgrade de l'OS, 
aucune coupure de session (testé sur Pix6.3.5, ASA7.0 et ASA7.2)...


Hugues.



Romain LE DISEZ a écrit :

Salut à tous,

nous sommes en train de terminer le déploiement de deux pare-feu Cisco
ASA 5520. Notre architecture étant redondante, ils doivent avoir tous
les deux les même règles de filtrage afin que la reprise en cas de panne
se passe bien.

Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et
quelques commandes (SCP, pfctl), nous pouvions facilement répliquer la
configuration.

Nous cherchons le moyen d'avoir un fonctionnement similaire avec les
Cisco. Par exemple, un fichier texte de ce type :
 
qui nous permette, en une commande, de construire les groupes (auxquels
nous appliquons les ACL) et de les pousser sur les deux pare-feu.

Avant que l'on commence à scripter, connaissez vous une solution de ce
type ? Comment faites vous pour bien gérer vos ASA ?

Merci.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Re : Re: [FRnOG] Comment mon switch a exploser

[Jean-Edouard Babin]

Le 29 juil. 09 à 15:00, Youssef Ghorbal a écrit :


Bonjour,

En effet, c'est visiblement une tempete de broadcast ethernet qu'on
s'est pris. D'apres les graphes, au moment du probleme le nombre de
paquet sur les ports explose.
Sur Cisco y'a t'il des commandes pour limiter le broadcast ethetnet
par interface ou par VLAN. Un rate-limiting pour les paquets
ff:ff:ff:ff:ff:ff en quelque sorte.


Il y a le storm control qui permet de faire ca :
http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_50_se/configuration/guide/swtrafc.html#wp1063295

Ca fonctionne très bien :)---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Administration de pare-feu Cisco ASA 5520

[[FrameIP] - Aghiles GANI]

Lu,

Concernant la gamme ASA faut admettre que ça reste de bon produit, ayant déjà 
mis en œuvre plusieurs solution en FailOver (5510 et 5520) je n’ai pour le 
moment pas rencontré de problème majeur avec ce produit. Celui-ci est 
relativement stable, cependant attention au version du système d’exploitation, 
les toutes dernières versions offrent comme d’hab de nouvelles fonctionnalités 
mais ne garantissent pas une stabilité exemplaire (ceci n’est pas vrai dans 
tous les cas et heureusement).

Pense également que en terme de débit annoncé par le constructeur le 5520, 
c’est environ 450 Mbps de throughtpout sur l’ensemble des interfaces , cette 
valeur est basé sur un mode de calcul en IMIX.
Concernant le FailOver, l’ASA 5520 gère deux mode, le premier actif – actif en 
statefull et le second actif passif également en statefull.
Concernant la gestion des ACL, bien que l’ASDM soit une interface graphique 
assez ergonomique et très complète (ça ne vaut pas un checkpoint de ce coté), 
je ne suis pas un adepte de l’interface (bug potentiel etc … comme pour 
beaucoup d’interface GUI) . Il m’arrive de l’utiliser pour le debug via 
l’interface graphique.
Une gestion des ACL via un bon vieux fichier texte reste l’idéal à condition 
qu’une nomenclature simple et cohérente soit déterminé à la base, surtout si 
l’utilisation d’objet est effectuée.
Concernant la création d’access-list via l’ASDM avec l’intégration des objets, 
ceci doit se faire de manière organisé au risque de tombé sur un méchant bordel 
avec des objets génériques qui ont des noms qui ressemblent à rien. 
 
Exemple :

object-group network DM_INLINE_NETWORK_2   (objet créé dynamiquement par 
l’ASDM, pas très propre)
 network-object host 192.X.X.X
 network-object host 192.X.X.X
 network-object lan 255.255.255.0
 network-object 192. .X.X.X 255.255.255.0

ce qui donne dans l’access-list
access-list INTERCO_backbone_nat0_outbound extended permit ip object-group 
DM_INLINE_NETWORK_2 object-group DM_INLINE_NETWORK_5

donc la lecture pas top !!!
surtout quand tu commence à atteindre la centaine d’ACL voir plus, ça peut 
devenir une sacrée galère.
L’idéal est de créer ces propres objets et ces propres groupes d’objets 
(logique !!!) et par la même occasion lors de leurs applications dans les ACL 
nommer les ACL et du coup la lecture est bien plus aisé.

Si tu as des questions hésite pas

Qu’est ce qui justifie le choix d’un 5520 plutôt qu’un 5510 ou 5540 par exemple 
??

@+

PS : pour le scripting tu peux utiliser le generateur de conf « confterm » 
super pratique « http://www.fcug.fr/confterm-la-version-6-8 »



-Message d'origine-
De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Romain 
LE DISEZ
Envoyé : mercredi 29 juillet 2009 15:37
À : frnog@FRnOG.org
Objet : [FRnOG] Administration de pare-feu Cisco ASA 5520

Salut à tous,

nous sommes en train de terminer le déploiement de deux pare-feu Cisco
ASA 5520. Notre architecture étant redondante, ils doivent avoir tous
les deux les même règles de filtrage afin que la reprise en cas de panne
se passe bien.

Nous utilisions auparavant des OpenBSD avec pf. Avec un petit make et
quelques commandes (SCP, pfctl), nous pouvions facilement répliquer la
configuration.

Nous cherchons le moyen d'avoir un fonctionnement similaire avec les
Cisco. Par exemple, un fichier texte de ce type :
 
qui nous permette, en une commande, de construire les groupes (auxquels
nous appliquons les ACL) et de les pousser sur les deux pare-feu.

Avant que l'on commence à scripter, connaissez vous une solution de ce
type ? Comment faites vous pour bien gérer vos ASA ?

Merci.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/