RE: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-20 Par sujet Sébastien 65
Merci Michel pour ton retour d'expérience  Au moins je suis fixé...

Je n'utilise pas de route-map dans mon cas, merci quand même Jérôme !

Bon je vais devoir me contenter de mon existant... Tampis pour le trafic du 
control-plane qui n'en fait qu'a sa tête !

Sébastien

De : frnog-requ...@frnog.org  de la part de Michel Py 

Envoyé : mercredi 20 mai 2020 02:52
À : 'Christophe LUCAS' ; Jérôme BERTHIER 

Cc : frnog@frnog.org 
Objet : RE: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

> Parce qu'il faut lui appliquer une politique locale "ip local policy 
> route-map map-tag "

Des fois çà marche, des fois pas.

J'ai utilisé cette commande dans le passé; si je comprends bien, çà dit au 
control-plane qui est différent du data-plane quoi faire.

Le problème, c'est que ce n'est pas consistent. Sur le modèle xxx, cà va réagir 
d'une façon, et sur le modèle yyy c'est différent, et en plus si la version 
d'IOS installée change, tout est à refaire.

J'ai lu ce fil depuis qu'il a démarré. J'ai essayé, çà a marché pour 1 an ou 2, 
après quoi tout a merdé, je laisse aux bleuebites se casser la tête dessus. 
QOS, c'est la définition parfaite du mètre étalon à géométrie variable.

TTL == 1 an, ou 2 ans.

J'ai perdu 10 ans de ma vie avec QOS, et 20 ans avec IPv6.

Michel.


---
Liste de diffusion du FRnOG
https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C32d949a0432843063cf108d7fc5837aa%7C84df9e7fe9f640afb435%7C1%7C0%7C637255328121816062sdata=Q%2BwGbq2Oh%2FB%2BzvETwNsWLsKKGV4Wt6%2F5L1gCssFJ%2Fhg%3Dreserved=0

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


RE: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-19 Par sujet Michel Py
> Parce qu'il faut lui appliquer une politique locale "ip local policy 
> route-map map-tag "

Des fois çà marche, des fois pas.

J'ai utilisé cette commande dans le passé; si je comprends bien, çà dit au 
control-plane qui est différent du data-plane quoi faire.

Le problème, c'est que ce n'est pas consistent. Sur le modèle xxx, cà va réagir 
d'une façon, et sur le modèle yyy c'est différent, et en plus si la version 
d'IOS installée change, tout est à refaire.

J'ai lu ce fil depuis qu'il a démarré. J'ai essayé, çà a marché pour 1 an ou 2, 
après quoi tout a merdé, je laisse aux bleuebites se casser la tête dessus. 
QOS, c'est la définition parfaite du mètre étalon à géométrie variable.

TTL == 1 an, ou 2 ans.

J'ai perdu 10 ans de ma vie avec QOS, et 20 ans avec IPv6.

Michel.


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


Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-18 Par sujet Christophe LUCAS
Bonjour,


Non non,
Cette commande concerne bien le traffic généré par le CPE.

Christophe

- Mail original -
De: "Jérôme BERTHIER via frnog" 
À: frnog@frnog.org
Envoyé: Lundi 18 Mai 2020 10:06:19
Objet: Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

Le 18/05/2020 à 09:36, Jérôme BERTHIER via frnog a écrit :
> Bonjour,
>
> Le 16/05/2020 à 11:37, Sébastien 65 a écrit :
>> Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou 
>> bien class class-default ?
>
> Parce qu'il faut lui appliquer une politique locale "ip local policy 
> route-map map-tag " :
>
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4
>  
>
>
> Bonne journée
>
Oups j'ai fait un magnifique HS, désolé.

ça marche pour du PBR, pas du marking COS

Je vais reboire un café.

Bonne journée

-- 
Jérôme BERTHIER


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


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


Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-18 Par sujet Jérôme BERTHIER via frnog

Le 18/05/2020 à 09:36, Jérôme BERTHIER via frnog a écrit :

Bonjour,

Le 16/05/2020 à 11:37, Sébastien 65 a écrit :
Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou 
bien class class-default ?


Parce qu'il faut lui appliquer une politique locale "ip local policy 
route-map map-tag " :


https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4 



Bonne journée


Oups j'ai fait un magnifique HS, désolé.

ça marche pour du PBR, pas du marking COS

Je vais reboire un café.

Bonne journée

--
Jérôme BERTHIER


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


Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-18 Par sujet Jérôme BERTHIER via frnog

Bonjour,

Le 16/05/2020 à 11:37, Sébastien 65 a écrit :

Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien 
class class-default ?


Parce qu'il faut lui appliquer une politique locale "ip local policy 
route-map map-tag " :


https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4

Bonne journée

--
Jérôme BERTHIER


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


Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-17 Par sujet Guillaume Roux
Par contre quel est le but de ta QoS ? Et pourquoi le fait que tes ping générés 
par le routeur ne soient pas en CS3 te gène ? 

Si c’est que les flux pour administrer ton routeur soient priorisé, tu 
prioriseras en amont en fonction de tes IPs d’admin (serveur rebond ?).
Si c’est pour tes protocoles de routage, normalement ils "s’auto-marquent" dans 
la bonne classe (tout ce qui est Control-plan est marqué CS6).

Pour les flux auto-généré par le routeur SSH/Telnet/SNMP en effet il faut 
spécifiquement déclarer la valeur du champs DSCP/TOS dans ta config.

Bonne soirée,

G

> Le 16 mai 2020 à 18:06, Sébastien 65  a écrit :
> 
> Salut Nicolas,
> 
> Je suis d'accord que le COS6 est la bonne valeur !
> 
> Juste je voulais dire que je suis obligé de forcer le COS3 sur SSH car même 
> avec l'access-list cela ne match pas 
> 
> 
> 
> De : Nicolas KARP 
> Envoyé : samedi 16 mai 2020 14:16
> À : Sébastien 65 
> Cc : Guillaume Roux ; Frnog-tech 
> Objet : Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !
>  
> Bonjour Sébastien,
> 
> C'est le but de marquer en precedence 6, comme ça tu peux réserver un peu de 
> bande passante pour l'admin ou les protocoles de routage afin de ne pas 
> perdre la main sur ton équipement.
> 
> ++


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


RE: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-16 Par sujet Sébastien 65
Salut Nicolas,

Je suis d'accord que le COS6 est la bonne valeur !

Juste je voulais dire que je suis obligé de forcer le COS3 sur SSH car même 
avec l'access-list cela ne match pas 




De : Nicolas KARP 
Envoyé : samedi 16 mai 2020 14:16
À : Sébastien 65 
Cc : Guillaume Roux ; Frnog-tech 
Objet : Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

Bonjour Sébastien,

C'est le but de marquer en precedence 6, comme ça tu peux réserver un peu de 
bande passante pour l'admin ou les protocoles de routage afin de ne pas perdre 
la main sur ton équipement.

++

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


Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-16 Par sujet Nicolas KARP
Bonjour Sébastien,

C'est le but de marquer en precedence 6, comme ça tu peux réserver un peu
de bande passante pour l'admin ou les protocoles de routage afin de ne pas
perdre la main sur ton équipement.

++

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


RE: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-16 Par sujet Sébastien 65
Guillaume,

Oui, il me semble bien que c'est le comportement par défaut...

J'avais exactement le même problème dès que je faisais un SSH sur l'IP du 
routeur, IOS marque automatiquement SSH/Telnet en 802.1p = 6, DSCP = CS6 (48).

Pour contourner cela, en CLI j'utilise ip ssh dscp 24 afin de passer le trafic 
SSH en COS3. Dommage que le routeur ne match pas cela sur access-list 
OTHER_TRAFFIC afin que cela soit plus simple et universel pour avoir une 
stratégie d'application DSCP/COS aux petits oignons !!

Je n'ai pas essayé avec SNMP mais à première vu même galère !

J'ai regardé ce que je pouvais faire rapidement en control-plane mais j'ai 
l'impression que je ne peux pas faire ce que je cherche 



De : Guillaume Roux 
Envoyé : samedi 16 mai 2020 12:42
À : Sébastien 65 
Cc : frnog-t...@frnog.org 
Objet : Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

Bonjour,

Sauf erreur de ma part, le traffic généré par le routeur lui-même n’est pas 
matché par la service policy. Tout comme en ZBF le routeur à sa propre zone 
(self) avec ses propres règles.

Comme tu le précise, lorsque tu teste depuis un PC du LAN tout est ok, preuve 
que ta config est bonne. ;-)

Bon weekend

G

Le 16 mai 2020 à 11:37, Sébastien 65 
mailto:sebastien...@live.fr>> a écrit :

Hello,

Petite prise de tête du moment avec le marquage de paquet sur un CISCO 891F en 
sortie !

Je marque les paquets en COS3 pour tout le trafic sauf mon trafic VoIP qui est 
en COS5.

Si je fais un ping depuis le 891F en console ou SSH vers l'IP d'interco (par 
exemple: ping 10.0.1.2 source gigabitEthernet 8.10) le paquet n'est pas marqué, 
il reste en DSCP CS0 eu lieu de CS3 !

Si je fais un ping depuis un PC du LAN du 891F vers l'IP d'interco le paquet 
est bien marqué en DSCP CS3, ainsi que le reste du trafic. Je ne vois rien 
partir en CS0 lorsque le LAN fait du trafic vers le WAN !

J'ai également fait un test en branchant un PC avec Wireshark sur l'interface 
GigabitEthernet8.10 pour vérifier la sortie du field DSCP !

voici la conf :
!
policy-map LAN
 class VOICE-IN
  set dscp ef
 class OTHER_TRAFFIC
  set dscp cs3
 class class-default
  set cos 3
!
policy-map WAN-OUT
 class VOICE
  set cos 5
 class OTHER_TRAFFIC
  set cos 3
 class class-default
  set cos 3
!
interface GigabitEthernet8.10
 encapsulation dot1Q 10
 ip address 10.0.1.1 255.255.255.252
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 ip virtual-reassembly in
 service-policy output WAN-OUT
!
interface Vlan1
 ip address 192.168.1.254 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat inside
 ip virtual-reassembly in
 service-policy input LAN
!
ip access-list extended OTHER_TRAFFIC
 permit ip 192.168.1.0 0.0.0.255 any
 permit ip 10.0.1.0 0.0.0.3 any
!

Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien 
class class-default ?

Merci pour l'aide 


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


Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-16 Par sujet Guillaume Roux
Bonjour,

Sauf erreur de ma part, le traffic généré par le routeur lui-même n’est pas 
matché par la service policy. Tout comme en ZBF le routeur à sa propre zone 
(self) avec ses propres règles.

Comme tu le précise, lorsque tu teste depuis un PC du LAN tout est ok, preuve 
que ta config est bonne. ;-)

Bon weekend 

G

> Le 16 mai 2020 à 11:37, Sébastien 65  a écrit :
> 
> Hello,
> 
> Petite prise de tête du moment avec le marquage de paquet sur un CISCO 891F 
> en sortie !
> 
> Je marque les paquets en COS3 pour tout le trafic sauf mon trafic VoIP qui 
> est en COS5.
> 
> Si je fais un ping depuis le 891F en console ou SSH vers l'IP d'interco (par 
> exemple: ping 10.0.1.2 source gigabitEthernet 8.10) le paquet n'est pas 
> marqué, il reste en DSCP CS0 eu lieu de CS3 !
> 
> Si je fais un ping depuis un PC du LAN du 891F vers l'IP d'interco le paquet 
> est bien marqué en DSCP CS3, ainsi que le reste du trafic. Je ne vois rien 
> partir en CS0 lorsque le LAN fait du trafic vers le WAN !
> 
> J'ai également fait un test en branchant un PC avec Wireshark sur l'interface 
> GigabitEthernet8.10 pour vérifier la sortie du field DSCP !
> 
> voici la conf :
> !
> policy-map LAN
>  class VOICE-IN
>   set dscp ef
>  class OTHER_TRAFFIC
>   set dscp cs3
>  class class-default
>   set cos 3
> !
> policy-map WAN-OUT
>  class VOICE
>   set cos 5
>  class OTHER_TRAFFIC
>   set cos 3
>  class class-default
>   set cos 3
> !
> interface GigabitEthernet8.10
>  encapsulation dot1Q 10
>  ip address 10.0.1.1 255.255.255.252
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip nat outside
>  ip virtual-reassembly in
>  service-policy output WAN-OUT
> !
> interface Vlan1
>  ip address 192.168.1.254 255.255.255.0
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip nat inside
>  ip virtual-reassembly in
>  service-policy input LAN
> !
> ip access-list extended OTHER_TRAFFIC
>  permit ip 192.168.1.0 0.0.0.255 any
>  permit ip 10.0.1.0 0.0.0.3 any
> !
> 
> Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien 
> class class-default ?
> 
> Merci pour l'aide 


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


Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !

2020-05-16 Par sujet Fabien H
Salut,

je me trompe peut-être mais il me semble que sur une interface L3 sur le
routeur CISCO, tu ne peux que marquer le DSCP, pas le COS qui est niveau
2.. Même si la commande set cos apparait dans la policy map..





Le sam. 16 mai 2020 à 11:38, Sébastien 65  a écrit :

> Hello,
>
> Petite prise de tête du moment avec le marquage de paquet sur un CISCO
> 891F en sortie !
>
> Je marque les paquets en COS3 pour tout le trafic sauf mon trafic VoIP qui
> est en COS5.
>
> Si je fais un ping depuis le 891F en console ou SSH vers l'IP d'interco
> (par exemple: ping 10.0.1.2 source gigabitEthernet 8.10) le paquet n'est
> pas marqué, il reste en DSCP CS0 eu lieu de CS3 !
>
> Si je fais un ping depuis un PC du LAN du 891F vers l'IP d'interco le
> paquet est bien marqué en DSCP CS3, ainsi que le reste du trafic. Je ne
> vois rien partir en CS0 lorsque le LAN fait du trafic vers le WAN !
>
> J'ai également fait un test en branchant un PC avec Wireshark sur
> l'interface GigabitEthernet8.10 pour vérifier la sortie du field DSCP !
>
> voici la conf :
> !
> policy-map LAN
>  class VOICE-IN
>   set dscp ef
>  class OTHER_TRAFFIC
>   set dscp cs3
>  class class-default
>   set cos 3
> !
> policy-map WAN-OUT
>  class VOICE
>   set cos 5
>  class OTHER_TRAFFIC
>   set cos 3
>  class class-default
>   set cos 3
> !
> interface GigabitEthernet8.10
>  encapsulation dot1Q 10
>  ip address 10.0.1.1 255.255.255.252
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip nat outside
>  ip virtual-reassembly in
>  service-policy output WAN-OUT
> !
> interface Vlan1
>  ip address 192.168.1.254 255.255.255.0
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip nat inside
>  ip virtual-reassembly in
>  service-policy input LAN
> !
> ip access-list extended OTHER_TRAFFIC
>  permit ip 192.168.1.0 0.0.0.255 any
>  permit ip 10.0.1.0 0.0.0.3 any
> !
>
> Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien
> class class-default ?
>
> Merci pour l'aide 
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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