> David Ponzone a écrit :
> Et je complète: le reboot a corrigé le truc et m’a fait sauter une ligne de
> conf sans
> rapport direct (un port-forward vers un client dans un VPN MPLS). Jamais vu
> ça avant.
Welcome to Cisco :P
Il y a plein de fois ou le reboot a pas suffi et j'ai fait un write
> David Ponzone a écrit :
> Et je complète: le reboot a corrigé le truc et m’a fait sauter une ligne de
> conf sans
> rapport direct (un port-forward vers un client dans un VPN MPLS). Jamais vu
> ça avant.
J'ai une confession : j'ai des problèmes zarbis avec NAT et VRF aussi et je
t'ai laissé
Et je complète: le reboot a corrigé le truc et m’a fait sauter une ligne de
conf sans rapport direct (un port-forward vers un client dans un VPN MPLS).
Jamais vu ça avant.
> Le 7 juin 2019 à 08:35, David Ponzone a écrit :
>
> Hélas, pas le temps de faire ça.
>
> Le reboot a bien corrigé le
Hélas, pas le temps de faire ça.
Le reboot a bien corrigé le truc.
> Le 6 juin 2019 à 08:22, Paul Rolland (ポール・ロラン) a écrit :
>
> Hello,
>
> On Wed, 5 Jun 2019 20:41:12 +0200
> David Ponzone wrote:
>
>> Tu penses bien que j’ai déjà envisagé ça et fait toutes les permutations
>> possibles.
J’ai essayé, j’ai l’impression que d’être passé sur une ACL numérotée puis
repassée sur une nommée a changé les choses.
J’ai des ping qui ne passaient pas avant qui passent et inversement….
Ca rend fou...
> Hello,
>
> Une piste à défaut d'en savoir plus sur la config: essayer une ACL
Hello,
On Wed, 5 Jun 2019 20:41:12 +0200
David Ponzone wrote:
> Tu penses bien que j’ai déjà envisagé ça et fait toutes les permutations
> possibles.
Il fallait que je demande, il y a des gens qui ne veulent pas entendre
parler des netmask avec des bits a 1 eparpilles ;)
> En fait maintenant
Le 05/06/2019 à 20:41, David Ponzone a écrit :
Tu penses bien que j’ai déjà envisagé ça et fait toutes les permutations
possibles.
En fait maintenant je sais: si le paquet a comme IP source 10.11.X.Y, l’ACL est
correctement matchée.
Si c’est 10.15.X.Y, ça matche pas le deny, et c’est NATé.
Tu penses bien que j’ai déjà envisagé ça et fait toutes les permutations
possibles.
En fait maintenant je sais: si le paquet a comme IP source 10.11.X.Y, l’ACL est
correctement matchée.
Si c’est 10.15.X.Y, ça matche pas le deny, et c’est NATé.
Je pense que j’ai fait le tour, ça ne peut être
Hello,
On Wed, 5 Jun 2019 09:17:31 +0200
David Ponzone wrote:
> ip access-list extended test
> deny ip 10.11.0.0 0.0.255.255 10.11.0.0 0.0.255.255 -> celle-ci exclut
> bien le traffic à ne pas NATer deny ip 10.11.0.0 0.0.255.255 10.15.0.0
> 0.0.255.255 -> celle-ci ne fait pas son job deny
Pas de debug ip nat vrf sur cet ASR :(
Et les compteurs d’ACL ne s’incrémentent pas non plus.
Je te cache pas que l’IOS est pas tout jeune.
Je pense que j’ai isolé ce qui délire.
L’ACL pour le NAT est:
ip access-list extended test
deny ip 10.11.0.0 0.0.255.255 10.11.0.0 0.0.255.255 ->
Hello David,
On Tue, 4 Jun 2019 08:31:08 +0200
David Ponzone wrote:
> Ca sent le bug et le reboot mais si quelqu’un a une meilleure idée ou une
> confirmation, je suis preneur…
Tu as surement deja regarde, mais au cas ou...
- debug ip nat (detailed|vrf|xx)
- show access-list pour regarder
Le 04/06/2019 à 08:31, David Ponzone a écrit :
Ciscomaniaques,
Je crois que je deviens fou.
Une ACL de NAT (inside source list) en sortie d’un VRF vers Internet qui se met
à matcher tous les paquets alors qu’elle devrait pas, quelqu’un a déjà vu ?
Une ACL classique du type:
deny ip 10.0.0.0
12 matches
Mail list logo
