Re: [FRnOG] [TECH] Cisco et NAT fou en sortie de VRF

[Rudy GAVRON]

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 0.255.255.255 10.0.0.0 0.255.255.255
permit ip 10.0.0.0 0.255.255.255 any

Je me retrouve avec des paquets de 10.X.X.X vers 10.Y.Y.Y qui sont natés et qui 
arrivent quand même à 10.Y.Y.Y alors que 10.Y.Y.Y n’est connue que dans le VRF 
(en BGP VPNv4) donc NAT en restant dans le VRF alors que ma seule route de 
sortie du VRF, c’est la route par défaut vers global.

Ca sent le bug et le reboot mais si quelqu’un a une meilleure idée ou une 
confirmation, je suis preneur…

Merci

David


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


Bonsoir,

Il faudrait un peu de détail sur la config, a minima:

interfaces .*

ip route vrf .*

ip nat inside .*

ip access-list .*

access-list .*


Salutations.

Rudy


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

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[Ludovic RAMOSFILIPE]

effectivement il faut tag le vlan en sortie sinon la session PPP ne monte
pas





Le mar. 4 juin 2019 à 17:32, David Ponzone  a
écrit :

> Oui:
>
> switchport trunk allowed vlan 1,835,1002-1005
> switchport mode trunk
>
> devrait suffire.
>
> (1002-1005 pas obligatoire, ça dépend des équipements Cisco)
>
> > Le 4 juin 2019 à 17:17, DONNET, Sylvain  a
> écrit :
> >
> > Je viens de trouver des conf où ils trunkent comme suit :
> > switchport trunk allowed vlan 1,835,838,840,851,1002-1005
> > switchport mode trunk
> >
> > A part que je ne veux faire que de la data (vlan835), ça devrait suffire
> à résoudre mon pb ?
> >
> >
> > Le 04/06/2019 17:09, « frnog-requ...@frnog.org au nom de Jérémy Prego
> »  a écrit :
> >
> >Le 04/06/2019 à 17:00, DONNET, Sylvain a écrit :
> >> Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le
> Vlan832 ? ou les deux modes cohabitent ?
> >
> >c'est vrai sauf pour l'ip fixe pour le moment qui est elle, encore en
> ppp.
> >Jerem
> >
> >>
> >> Le 04/06/2019 16:57, « David Ponzone »  a
> écrit :
> >>
> >>Là ton port est en access 835, donc le port a comme VLAN Native 835,
> donc les paquets PPPoE sortent sans TAG.
> >>Il taut le mettre en trunk avec VLAN 1 Native
> >>
> >>> Le 4 juin 2019 à 16:34, DONNET, Sylvain  a
> écrit :
> >>>
> >>> Bonjour à tous,
> >>>
> >>> Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec
> IP fixe d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
> >>>
> >>> Voici ma conf, en résumé :
> >>>
> >>> interface FastEthernet0
> >>> description Link from FTTH Orange
> >>> switchport access vlan 835
> >>> no ip address
> >>> no cdp enable
> >>> !
> >>> …/…
> >>> interface Vlan835
> >>> description Link to ORANGE
> >>> no ip address
> >>> pppoe enable group global
> >>> pppoe-client dial-pool-number 1
> >>> !
> >>> interface Dialer1
> >>> ip address negotiated
> >>> ip mtu 1492
> >>> ip nat outside
> >>> ip virtual-reassembly in
> >>> encapsulation ppp
> >>> no ip route-cache
> >>> ip tcp adjust-mss 1452
> >>> dialer pool 1
> >>> dialer-group 1
> >>> ppp authentication chap
> >>> ppp chap hostname fti/*
> >>> ppp chap password 0 *
> >>> ppp ipcp dns request accept
> >>> ppp ipcp route default
> >>> ppp ipcp address accept
> >>> no cdp enable
> >>> !
> >>> …/…
> >>> ip route 0.0.0.0 0.0.0.0 Dialer1
> >>> …/…
> >>> access-list 1 permit any
> >>>
> >>>
> >>> En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont
> UP, mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois
> même pas de session ppp enclenchée (pas de traces sur des debug  ppp *).
> >>> Ca doit être gros comme le nez au milieu de la figure, et je
> m’esquinte les yeux dessus, mais je ne vois pas où ça cloche.
> >>>
> >>> Quelqu’un aurait une idée, SVP ?
> >>>
> >>>
> >>> Le « show int Dialer1 » :
> >>>
> >>> Dialer1 is up, line protocol is up (spoofing)
> >>> Hardware is Unknown
> >>> Internet address will be negotiated using IPCP
> >>> MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
> >>>reliability 255/255, txload 1/255, rxload 1/255
> >>> Encapsulation PPP, LCP Closed, loopback not set
> >>> Keepalive set (10 sec)
> >>> DTR is pulsed for 1 seconds on reset
> >>> Last input never, output never, output hang never
> >>> Last clearing of "show interface" counters 00:13:26
> >>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
> >>> Queueing strategy: fifo
> >>> Output queue: 0/40 (size/max)
> >>> 5 minute input rate 0 bits/sec, 0 packets/sec
> >>> 5 minute output rate 0 bits/sec, 0 packets/sec
> >>>0 packets input, 0 bytes
> >>>0 packets output, 0 bytes
> >>>
> >>> Le “sh pppoe session” :
> >>>1 client session
> >>>
> >>> Uniq ID  PPPoE  RemMAC  PortVT  VA
>  State
> >>>  SID  LocMAC  VA-st
> Type
> >>>   N/A  0  ..  Vl835   Di1 N/A
> PADISNT
> >>>   ..
> >>>
> >>> Le “sh ppp interface Dialer1” :
> >>>
> >>> PPP Serial Context Info
> >>> ---
> >>> Interface: Di1
> >>> PPP Serial Handle: 0x0
> >>> PPP Handle   : 0x0
> >>> SSS Handle   : 0x0
> >>> AAA ID   : 0
> >>> Access IE: 0x0
> >>> SHDB Handle  : 0x0
> >>> State: Down
> >>> Last State   : Init
> >>> Last Event   : RestartTimeout
> >>> 
> >>>
> >>> Ce message électronique et tous les fichiers attachés peuvent contenir
> des informations confidentielles et destinées exclusivement à l’usage de la
> personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas
> destinataire de ce message, vous n'êtes pas autorisés à le lire,
> l'imprimer, le garder, le copier, le divulguer, le distribuer, l'utiliser,
> ni dans son ensemble, ni en partie, sans autorisation préalable. Si vous
> recevez ce message par erreur, merci de le détruire et d’en avertir sans
> délai l’expéditeur.
> >>>
> 

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[David Ponzone]

Oui:

switchport trunk allowed vlan 1,835,1002-1005
switchport mode trunk

devrait suffire.

(1002-1005 pas obligatoire, ça dépend des équipements Cisco)

> Le 4 juin 2019 à 17:17, DONNET, Sylvain  a écrit :
> 
> Je viens de trouver des conf où ils trunkent comme suit :
> switchport trunk allowed vlan 1,835,838,840,851,1002-1005
> switchport mode trunk
> 
> A part que je ne veux faire que de la data (vlan835), ça devrait suffire à 
> résoudre mon pb ?
> 
> 
> Le 04/06/2019 17:09, « frnog-requ...@frnog.org au nom de Jérémy Prego » 
>  a écrit :
> 
>Le 04/06/2019 à 17:00, DONNET, Sylvain a écrit :
>> Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le 
>> Vlan832 ? ou les deux modes cohabitent ?
> 
>c'est vrai sauf pour l'ip fixe pour le moment qui est elle, encore en ppp.
>Jerem
> 
>> 
>> Le 04/06/2019 16:57, « David Ponzone »  a écrit :
>> 
>>Là ton port est en access 835, donc le port a comme VLAN Native 835, donc 
>> les paquets PPPoE sortent sans TAG.
>>Il taut le mettre en trunk avec VLAN 1 Native
>> 
>>> Le 4 juin 2019 à 16:34, DONNET, Sylvain  a écrit :
>>> 
>>> Bonjour à tous,
>>> 
>>> Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP 
>>> fixe d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
>>> 
>>> Voici ma conf, en résumé :
>>> 
>>> interface FastEthernet0
>>> description Link from FTTH Orange
>>> switchport access vlan 835
>>> no ip address
>>> no cdp enable
>>> !
>>> …/…
>>> interface Vlan835
>>> description Link to ORANGE
>>> no ip address
>>> pppoe enable group global
>>> pppoe-client dial-pool-number 1
>>> !
>>> interface Dialer1
>>> ip address negotiated
>>> ip mtu 1492
>>> ip nat outside
>>> ip virtual-reassembly in
>>> encapsulation ppp
>>> no ip route-cache
>>> ip tcp adjust-mss 1452
>>> dialer pool 1
>>> dialer-group 1
>>> ppp authentication chap
>>> ppp chap hostname fti/*
>>> ppp chap password 0 *
>>> ppp ipcp dns request accept
>>> ppp ipcp route default
>>> ppp ipcp address accept
>>> no cdp enable
>>> !
>>> …/…
>>> ip route 0.0.0.0 0.0.0.0 Dialer1
>>> …/…
>>> access-list 1 permit any
>>> 
>>> 
>>> En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont UP, 
>>> mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même 
>>> pas de session ppp enclenchée (pas de traces sur des debug  ppp *).
>>> Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte les 
>>> yeux dessus, mais je ne vois pas où ça cloche.
>>> 
>>> Quelqu’un aurait une idée, SVP ?
>>> 
>>> 
>>> Le « show int Dialer1 » :
>>> 
>>> Dialer1 is up, line protocol is up (spoofing)
>>> Hardware is Unknown
>>> Internet address will be negotiated using IPCP
>>> MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
>>>reliability 255/255, txload 1/255, rxload 1/255
>>> Encapsulation PPP, LCP Closed, loopback not set
>>> Keepalive set (10 sec)
>>> DTR is pulsed for 1 seconds on reset
>>> Last input never, output never, output hang never
>>> Last clearing of "show interface" counters 00:13:26
>>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>>> Queueing strategy: fifo
>>> Output queue: 0/40 (size/max)
>>> 5 minute input rate 0 bits/sec, 0 packets/sec
>>> 5 minute output rate 0 bits/sec, 0 packets/sec
>>>0 packets input, 0 bytes
>>>0 packets output, 0 bytes
>>> 
>>> Le “sh pppoe session” :
>>>1 client session
>>> 
>>> Uniq ID  PPPoE  RemMAC  PortVT  VA State
>>>  SID  LocMAC  VA-st  Type
>>>   N/A  0  ..  Vl835   Di1 N/APADISNT
>>>   ..
>>> 
>>> Le “sh ppp interface Dialer1” :
>>> 
>>> PPP Serial Context Info
>>> ---
>>> Interface: Di1
>>> PPP Serial Handle: 0x0
>>> PPP Handle   : 0x0
>>> SSS Handle   : 0x0
>>> AAA ID   : 0
>>> Access IE: 0x0
>>> SHDB Handle  : 0x0
>>> State: Down
>>> Last State   : Init
>>> Last Event   : RestartTimeout
>>> 
>>> 
>>> Ce message électronique et tous les fichiers attachés peuvent contenir des 
>>> informations confidentielles et destinées exclusivement à l’usage de la 
>>> personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas 
>>> destinataire de ce message, vous n'êtes pas autorisés à le lire, 
>>> l'imprimer, le garder, le copier, le divulguer, le distribuer, l'utiliser, 
>>> ni dans son ensemble, ni en partie, sans autorisation préalable. Si vous 
>>> recevez ce message par erreur, merci de le détruire et d’en avertir sans 
>>> délai l’expéditeur.
>>> 
>>> Le contenu de ce message ne pourrait engager la responsabilité de DDO 
>>> Organisation que s’il a été émis par une personne dûment habilitée agissant 
>>> dans le strict cadre des fonctions auxquelles elle est employée et à des 
>>> fins non étrangères à ses attributions. Tout message électronique étant 
>>> 

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[David Ponzone]

Et l’IPv6 en DHCP seulement non ?

> Le 4 juin 2019 à 17:06, Jérémy Prego  a écrit :
> 
> Le 04/06/2019 à 17:00, DONNET, Sylvain a écrit :
>> Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le 
>> Vlan832 ? ou les deux modes cohabitent ?
> 
> c'est vrai sauf pour l'ip fixe pour le moment qui est elle, encore en ppp.
> Jerem
> 
>> 
>> Le 04/06/2019 16:57, « David Ponzone »  a écrit :
>> 
>>Là ton port est en access 835, donc le port a comme VLAN Native 835, donc 
>> les paquets PPPoE sortent sans TAG.
>>Il taut le mettre en trunk avec VLAN 1 Native
>> 
>>> Le 4 juin 2019 à 16:34, DONNET, Sylvain  a écrit :
>>> 
>>> Bonjour à tous,
>>> 
>>> Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP 
>>> fixe d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
>>> 
>>> Voici ma conf, en résumé :
>>> 
>>> interface FastEthernet0
>>> description Link from FTTH Orange
>>> switchport access vlan 835
>>> no ip address
>>> no cdp enable
>>> !
>>> …/…
>>> interface Vlan835
>>> description Link to ORANGE
>>> no ip address
>>> pppoe enable group global
>>> pppoe-client dial-pool-number 1
>>> !
>>> interface Dialer1
>>> ip address negotiated
>>> ip mtu 1492
>>> ip nat outside
>>> ip virtual-reassembly in
>>> encapsulation ppp
>>> no ip route-cache
>>> ip tcp adjust-mss 1452
>>> dialer pool 1
>>> dialer-group 1
>>> ppp authentication chap
>>> ppp chap hostname fti/*
>>> ppp chap password 0 *
>>> ppp ipcp dns request accept
>>> ppp ipcp route default
>>> ppp ipcp address accept
>>> no cdp enable
>>> !
>>> …/…
>>> ip route 0.0.0.0 0.0.0.0 Dialer1
>>> …/…
>>> access-list 1 permit any
>>> 
>>> 
>>> En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont UP, 
>>> mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même 
>>> pas de session ppp enclenchée (pas de traces sur des debug  ppp *).
>>> Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte les 
>>> yeux dessus, mais je ne vois pas où ça cloche.
>>> 
>>> Quelqu’un aurait une idée, SVP ?
>>> 
>>> 
>>> Le « show int Dialer1 » :
>>> 
>>> Dialer1 is up, line protocol is up (spoofing)
>>> Hardware is Unknown
>>> Internet address will be negotiated using IPCP
>>> MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
>>>reliability 255/255, txload 1/255, rxload 1/255
>>> Encapsulation PPP, LCP Closed, loopback not set
>>> Keepalive set (10 sec)
>>> DTR is pulsed for 1 seconds on reset
>>> Last input never, output never, output hang never
>>> Last clearing of "show interface" counters 00:13:26
>>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>>> Queueing strategy: fifo
>>> Output queue: 0/40 (size/max)
>>> 5 minute input rate 0 bits/sec, 0 packets/sec
>>> 5 minute output rate 0 bits/sec, 0 packets/sec
>>>0 packets input, 0 bytes
>>>0 packets output, 0 bytes
>>> 
>>> Le “sh pppoe session” :
>>>1 client session
>>> 
>>> Uniq ID  PPPoE  RemMAC  PortVT  VA State
>>>  SID  LocMAC  VA-st  Type
>>>   N/A  0  ..  Vl835   Di1 N/APADISNT
>>>   ..
>>> 
>>> Le “sh ppp interface Dialer1” :
>>> 
>>> PPP Serial Context Info
>>> ---
>>> Interface: Di1
>>> PPP Serial Handle: 0x0
>>> PPP Handle   : 0x0
>>> SSS Handle   : 0x0
>>> AAA ID   : 0
>>> Access IE: 0x0
>>> SHDB Handle  : 0x0
>>> State: Down
>>> Last State   : Init
>>> Last Event   : RestartTimeout
>>> 
>>> 
>>> Ce message électronique et tous les fichiers attachés peuvent contenir des 
>>> informations confidentielles et destinées exclusivement à l’usage de la 
>>> personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas 
>>> destinataire de ce message, vous n'êtes pas autorisés à le lire, 
>>> l'imprimer, le garder, le copier, le divulguer, le distribuer, l'utiliser, 
>>> ni dans son ensemble, ni en partie, sans autorisation préalable. Si vous 
>>> recevez ce message par erreur, merci de le détruire et d’en avertir sans 
>>> délai l’expéditeur.
>>> 
>>> Le contenu de ce message ne pourrait engager la responsabilité de DDO 
>>> Organisation que s’il a été émis par une personne dûment habilitée agissant 
>>> dans le strict cadre des fonctions auxquelles elle est employée et à des 
>>> fins non étrangères à ses attributions. Tout message électronique étant 
>>> susceptible d’altération au cours de son acheminement sur Internet, DDO 
>>> Organisation et le Groupe Cogeser ne peuvent être tenus responsables de son 
>>> contenu. En outre, les idées et opinions présentées dans ce message sont 
>>> celles de son auteur et ne représentent pas nécessairement celles de DDO 
>>> Organisation ni du Groupe Cogeser.
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> 
>> 
>> 

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[DONNET, Sylvain]

Je viens de trouver des conf où ils trunkent comme suit :
switchport trunk allowed vlan 1,835,838,840,851,1002-1005
 switchport mode trunk

A part que je ne veux faire que de la data (vlan835), ça devrait suffire à 
résoudre mon pb ?


Le 04/06/2019 17:09, « frnog-requ...@frnog.org au nom de Jérémy Prego » 
 a écrit :

Le 04/06/2019 à 17:00, DONNET, Sylvain a écrit :
> Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le 
Vlan832 ? ou les deux modes cohabitent ?

c'est vrai sauf pour l'ip fixe pour le moment qui est elle, encore en ppp.
Jerem

>
> Le 04/06/2019 16:57, « David Ponzone »  a écrit :
>
> Là ton port est en access 835, donc le port a comme VLAN Native 835, 
donc les paquets PPPoE sortent sans TAG.
> Il taut le mettre en trunk avec VLAN 1 Native
>
> > Le 4 juin 2019 à 16:34, DONNET, Sylvain  a 
écrit :
> >
> > Bonjour à tous,
> >
> > Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, 
avec IP fixe d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
> >
> > Voici ma conf, en résumé :
> >
> > interface FastEthernet0
> > description Link from FTTH Orange
> > switchport access vlan 835
> > no ip address
> > no cdp enable
> > !
> > …/…
> > interface Vlan835
> > description Link to ORANGE
> > no ip address
> > pppoe enable group global
> > pppoe-client dial-pool-number 1
> > !
> > interface Dialer1
> > ip address negotiated
> > ip mtu 1492
> > ip nat outside
> > ip virtual-reassembly in
> > encapsulation ppp
> > no ip route-cache
> > ip tcp adjust-mss 1452
> > dialer pool 1
> > dialer-group 1
> > ppp authentication chap
> > ppp chap hostname fti/*
> > ppp chap password 0 *
> > ppp ipcp dns request accept
> > ppp ipcp route default
> > ppp ipcp address accept
> > no cdp enable
> > !
> > …/…
> > ip route 0.0.0.0 0.0.0.0 Dialer1
> > …/…
> > access-list 1 permit any
> >
> >
> > En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) 
sont UP, mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois 
même pas de session ppp enclenchée (pas de traces sur des debug  ppp *).
> > Ca doit être gros comme le nez au milieu de la figure, et je 
m’esquinte les yeux dessus, mais je ne vois pas où ça cloche.
> >
> > Quelqu’un aurait une idée, SVP ?
> >
> >
> > Le « show int Dialer1 » :
> >
> > Dialer1 is up, line protocol is up (spoofing)
> >  Hardware is Unknown
> >  Internet address will be negotiated using IPCP
> >  MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
> > reliability 255/255, txload 1/255, rxload 1/255
> >  Encapsulation PPP, LCP Closed, loopback not set
> >  Keepalive set (10 sec)
> >  DTR is pulsed for 1 seconds on reset
> >  Last input never, output never, output hang never
> >  Last clearing of "show interface" counters 00:13:26
> >  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output 
drops: 0
> >  Queueing strategy: fifo
> >  Output queue: 0/40 (size/max)
> >  5 minute input rate 0 bits/sec, 0 packets/sec
> >  5 minute output rate 0 bits/sec, 0 packets/sec
> > 0 packets input, 0 bytes
> > 0 packets output, 0 bytes
> >
> > Le “sh pppoe session” :
> > 1 client session
> >
> > Uniq ID  PPPoE  RemMAC  PortVT  VA  
   State
> >   SID  LocMAC  VA-st
  Type
> >N/A  0  ..  Vl835   Di1 N/A  
  PADISNT
> >..
> >
> > Le “sh ppp interface Dialer1” :
> >
> > PPP Serial Context Info
> > ---
> > Interface: Di1
> > PPP Serial Handle: 0x0
> > PPP Handle   : 0x0
> > SSS Handle   : 0x0
> > AAA ID   : 0
> > Access IE: 0x0
> > SHDB Handle  : 0x0
> > State: Down
> > Last State   : Init
> > Last Event   : RestartTimeout
> > 
> >
> > Ce message électronique et tous les fichiers attachés peuvent 
contenir des informations confidentielles et destinées exclusivement à l’usage 
de la personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas 
destinataire de ce message, vous n'êtes pas autorisés à le lire, l'imprimer, le 
garder, le copier, le divulguer, le distribuer, 

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[Jérémy Prego]

Le 04/06/2019 à 17:00, DONNET, Sylvain a écrit :
> Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le 
> Vlan832 ? ou les deux modes cohabitent ?

c'est vrai sauf pour l'ip fixe pour le moment qui est elle, encore en ppp.
Jerem

>
> Le 04/06/2019 16:57, « David Ponzone »  a écrit :
>
> Là ton port est en access 835, donc le port a comme VLAN Native 835, donc 
> les paquets PPPoE sortent sans TAG.
> Il taut le mettre en trunk avec VLAN 1 Native
>
> > Le 4 juin 2019 à 16:34, DONNET, Sylvain  a 
> écrit :
> >
> > Bonjour à tous,
> >
> > Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP 
> fixe d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
> >
> > Voici ma conf, en résumé :
> >
> > interface FastEthernet0
> > description Link from FTTH Orange
> > switchport access vlan 835
> > no ip address
> > no cdp enable
> > !
> > …/…
> > interface Vlan835
> > description Link to ORANGE
> > no ip address
> > pppoe enable group global
> > pppoe-client dial-pool-number 1
> > !
> > interface Dialer1
> > ip address negotiated
> > ip mtu 1492
> > ip nat outside
> > ip virtual-reassembly in
> > encapsulation ppp
> > no ip route-cache
> > ip tcp adjust-mss 1452
> > dialer pool 1
> > dialer-group 1
> > ppp authentication chap
> > ppp chap hostname fti/*
> > ppp chap password 0 *
> > ppp ipcp dns request accept
> > ppp ipcp route default
> > ppp ipcp address accept
> > no cdp enable
> > !
> > …/…
> > ip route 0.0.0.0 0.0.0.0 Dialer1
> > …/…
> > access-list 1 permit any
> >
> >
> > En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont 
> UP, mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même 
> pas de session ppp enclenchée (pas de traces sur des debug  ppp *).
> > Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte 
> les yeux dessus, mais je ne vois pas où ça cloche.
> >
> > Quelqu’un aurait une idée, SVP ?
> >
> >
> > Le « show int Dialer1 » :
> >
> > Dialer1 is up, line protocol is up (spoofing)
> >  Hardware is Unknown
> >  Internet address will be negotiated using IPCP
> >  MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
> > reliability 255/255, txload 1/255, rxload 1/255
> >  Encapsulation PPP, LCP Closed, loopback not set
> >  Keepalive set (10 sec)
> >  DTR is pulsed for 1 seconds on reset
> >  Last input never, output never, output hang never
> >  Last clearing of "show interface" counters 00:13:26
> >  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
> >  Queueing strategy: fifo
> >  Output queue: 0/40 (size/max)
> >  5 minute input rate 0 bits/sec, 0 packets/sec
> >  5 minute output rate 0 bits/sec, 0 packets/sec
> > 0 packets input, 0 bytes
> > 0 packets output, 0 bytes
> >
> > Le “sh pppoe session” :
> > 1 client session
> >
> > Uniq ID  PPPoE  RemMAC  PortVT  VA 
> State
> >   SID  LocMAC  VA-st  
> Type
> >N/A  0  ..  Vl835   Di1 N/A
> PADISNT
> >..
> >
> > Le “sh ppp interface Dialer1” :
> >
> > PPP Serial Context Info
> > ---
> > Interface: Di1
> > PPP Serial Handle: 0x0
> > PPP Handle   : 0x0
> > SSS Handle   : 0x0
> > AAA ID   : 0
> > Access IE: 0x0
> > SHDB Handle  : 0x0
> > State: Down
> > Last State   : Init
> > Last Event   : RestartTimeout
> > 
> >
> > Ce message électronique et tous les fichiers attachés peuvent contenir 
> des informations confidentielles et destinées exclusivement à l’usage de la 
> personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas destinataire 
> de ce message, vous n'êtes pas autorisés à le lire, l'imprimer, le garder, le 
> copier, le divulguer, le distribuer, l'utiliser, ni dans son ensemble, ni en 
> partie, sans autorisation préalable. Si vous recevez ce message par erreur, 
> merci de le détruire et d’en avertir sans délai l’expéditeur.
> >
> > Le contenu de ce message ne pourrait engager la responsabilité de DDO 
> Organisation que s’il a été émis par une personne dûment habilitée agissant 
> dans le strict cadre des fonctions auxquelles elle est employée et à des fins 
> non étrangères à ses attributions. Tout message électronique étant 
> susceptible d’altération au cours de son acheminement sur Internet, DDO 
> Organisation et le Groupe Cogeser ne peuvent être tenus responsables de son 
> contenu. En outre, les idées et opinions présentées dans ce 

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[Pierre Emeriaud]

Le mar. 4 juin 2019 à 17:02, DONNET, Sylvain  a écrit :
>
> Merci,
>
> Je vais modifier en ce sens.
> Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le 
> Vlan832 ? ou les deux modes cohabitent ?

Les deux cohabitent.


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

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[David Ponzone]

Perso, je n’ai jamais rencontré de problème pour monter en PPP.
Je pense que par endroits, les 2 cohabitent mais ils ne peuvent probablement 
pas virer le PPP à cause des anciens clients.

> Le 4 juin 2019 à 17:00, DONNET, Sylvain  a écrit :
> 
> Merci,
> 
> Je vais modifier en ce sens.
> Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le 
> Vlan832 ? ou les deux modes cohabitent ?
> 
> 
> Le 04/06/2019 16:57, « David Ponzone »  a écrit :
> 
>Là ton port est en access 835, donc le port a comme VLAN Native 835, donc 
> les paquets PPPoE sortent sans TAG.
>Il taut le mettre en trunk avec VLAN 1 Native
> 
>> Le 4 juin 2019 à 16:34, DONNET, Sylvain  a écrit :
>> 
>> Bonjour à tous,
>> 
>> Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP fixe 
>> d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
>> 
>> Voici ma conf, en résumé :
>> 
>> interface FastEthernet0
>> description Link from FTTH Orange
>> switchport access vlan 835
>> no ip address
>> no cdp enable
>> !
>> …/…
>> interface Vlan835
>> description Link to ORANGE
>> no ip address
>> pppoe enable group global
>> pppoe-client dial-pool-number 1
>> !
>> interface Dialer1
>> ip address negotiated
>> ip mtu 1492
>> ip nat outside
>> ip virtual-reassembly in
>> encapsulation ppp
>> no ip route-cache
>> ip tcp adjust-mss 1452
>> dialer pool 1
>> dialer-group 1
>> ppp authentication chap
>> ppp chap hostname fti/*
>> ppp chap password 0 *
>> ppp ipcp dns request accept
>> ppp ipcp route default
>> ppp ipcp address accept
>> no cdp enable
>> !
>> …/…
>> ip route 0.0.0.0 0.0.0.0 Dialer1
>> …/…
>> access-list 1 permit any
>> 
>> 
>> En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont UP, 
>> mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même 
>> pas de session ppp enclenchée (pas de traces sur des debug  ppp *).
>> Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte les 
>> yeux dessus, mais je ne vois pas où ça cloche.
>> 
>> Quelqu’un aurait une idée, SVP ?
>> 
>> 
>> Le « show int Dialer1 » :
>> 
>> Dialer1 is up, line protocol is up (spoofing)
>> Hardware is Unknown
>> Internet address will be negotiated using IPCP
>> MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
>>reliability 255/255, txload 1/255, rxload 1/255
>> Encapsulation PPP, LCP Closed, loopback not set
>> Keepalive set (10 sec)
>> DTR is pulsed for 1 seconds on reset
>> Last input never, output never, output hang never
>> Last clearing of "show interface" counters 00:13:26
>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>> Queueing strategy: fifo
>> Output queue: 0/40 (size/max)
>> 5 minute input rate 0 bits/sec, 0 packets/sec
>> 5 minute output rate 0 bits/sec, 0 packets/sec
>>0 packets input, 0 bytes
>>0 packets output, 0 bytes
>> 
>> Le “sh pppoe session” :
>>1 client session
>> 
>> Uniq ID  PPPoE  RemMAC  PortVT  VA State
>>  SID  LocMAC  VA-st  Type
>>   N/A  0  ..  Vl835   Di1 N/APADISNT
>>   ..
>> 
>> Le “sh ppp interface Dialer1” :
>> 
>> PPP Serial Context Info
>> ---
>> Interface: Di1
>> PPP Serial Handle: 0x0
>> PPP Handle   : 0x0
>> SSS Handle   : 0x0
>> AAA ID   : 0
>> Access IE: 0x0
>> SHDB Handle  : 0x0
>> State: Down
>> Last State   : Init
>> Last Event   : RestartTimeout
>> 
>> 
>> Ce message électronique et tous les fichiers attachés peuvent contenir des 
>> informations confidentielles et destinées exclusivement à l’usage de la 
>> personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas 
>> destinataire de ce message, vous n'êtes pas autorisés à le lire, l'imprimer, 
>> le garder, le copier, le divulguer, le distribuer, l'utiliser, ni dans son 
>> ensemble, ni en partie, sans autorisation préalable. Si vous recevez ce 
>> message par erreur, merci de le détruire et d’en avertir sans délai 
>> l’expéditeur.
>> 
>> Le contenu de ce message ne pourrait engager la responsabilité de DDO 
>> Organisation que s’il a été émis par une personne dûment habilitée agissant 
>> dans le strict cadre des fonctions auxquelles elle est employée et à des 
>> fins non étrangères à ses attributions. Tout message électronique étant 
>> susceptible d’altération au cours de son acheminement sur Internet, DDO 
>> Organisation et le Groupe Cogeser ne peuvent être tenus responsables de son 
>> contenu. En outre, les idées et opinions présentées dans ce message sont 
>> celles de son auteur et ne représentent pas nécessairement celles de DDO 
>> Organisation ni du Groupe Cogeser.
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> 
> 
> 
> 
> Ce message électronique et tous les fichiers attachés 

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[DONNET, Sylvain]

Merci,

Je vais modifier en ce sens.
Ce que dit Erwan est vrai ? Ils sont passés DHCP au lieu de PPP, sur le Vlan832 
? ou les deux modes cohabitent ?


Le 04/06/2019 16:57, « David Ponzone »  a écrit :

Là ton port est en access 835, donc le port a comme VLAN Native 835, donc 
les paquets PPPoE sortent sans TAG.
Il taut le mettre en trunk avec VLAN 1 Native

> Le 4 juin 2019 à 16:34, DONNET, Sylvain  a écrit :
>
> Bonjour à tous,
>
> Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP 
fixe d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
>
> Voici ma conf, en résumé :
>
> interface FastEthernet0
> description Link from FTTH Orange
> switchport access vlan 835
> no ip address
> no cdp enable
> !
> …/…
> interface Vlan835
> description Link to ORANGE
> no ip address
> pppoe enable group global
> pppoe-client dial-pool-number 1
> !
> interface Dialer1
> ip address negotiated
> ip mtu 1492
> ip nat outside
> ip virtual-reassembly in
> encapsulation ppp
> no ip route-cache
> ip tcp adjust-mss 1452
> dialer pool 1
> dialer-group 1
> ppp authentication chap
> ppp chap hostname fti/*
> ppp chap password 0 *
> ppp ipcp dns request accept
> ppp ipcp route default
> ppp ipcp address accept
> no cdp enable
> !
> …/…
> ip route 0.0.0.0 0.0.0.0 Dialer1
> …/…
> access-list 1 permit any
>
>
> En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont 
UP, mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même 
pas de session ppp enclenchée (pas de traces sur des debug  ppp *).
> Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte 
les yeux dessus, mais je ne vois pas où ça cloche.
>
> Quelqu’un aurait une idée, SVP ?
>
>
> Le « show int Dialer1 » :
>
> Dialer1 is up, line protocol is up (spoofing)
>  Hardware is Unknown
>  Internet address will be negotiated using IPCP
>  MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
> reliability 255/255, txload 1/255, rxload 1/255
>  Encapsulation PPP, LCP Closed, loopback not set
>  Keepalive set (10 sec)
>  DTR is pulsed for 1 seconds on reset
>  Last input never, output never, output hang never
>  Last clearing of "show interface" counters 00:13:26
>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>  Queueing strategy: fifo
>  Output queue: 0/40 (size/max)
>  5 minute input rate 0 bits/sec, 0 packets/sec
>  5 minute output rate 0 bits/sec, 0 packets/sec
> 0 packets input, 0 bytes
> 0 packets output, 0 bytes
>
> Le “sh pppoe session” :
> 1 client session
>
> Uniq ID  PPPoE  RemMAC  PortVT  VA 
State
>   SID  LocMAC  VA-st  Type
>N/A  0  ..  Vl835   Di1 N/A
PADISNT
>..
>
> Le “sh ppp interface Dialer1” :
>
> PPP Serial Context Info
> ---
> Interface: Di1
> PPP Serial Handle: 0x0
> PPP Handle   : 0x0
> SSS Handle   : 0x0
> AAA ID   : 0
> Access IE: 0x0
> SHDB Handle  : 0x0
> State: Down
> Last State   : Init
> Last Event   : RestartTimeout
> 
>
> Ce message électronique et tous les fichiers attachés peuvent contenir 
des informations confidentielles et destinées exclusivement à l’usage de la 
personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas destinataire 
de ce message, vous n'êtes pas autorisés à le lire, l'imprimer, le garder, le 
copier, le divulguer, le distribuer, l'utiliser, ni dans son ensemble, ni en 
partie, sans autorisation préalable. Si vous recevez ce message par erreur, 
merci de le détruire et d’en avertir sans délai l’expéditeur.
>
> Le contenu de ce message ne pourrait engager la responsabilité de DDO 
Organisation que s’il a été émis par une personne dûment habilitée agissant 
dans le strict cadre des fonctions auxquelles elle est employée et à des fins 
non étrangères à ses attributions. Tout message électronique étant susceptible 
d’altération au cours de son acheminement sur Internet, DDO Organisation et le 
Groupe Cogeser ne peuvent être tenus responsables de son contenu. En outre, les 
idées et opinions présentées dans ce message sont celles de son auteur et ne 
représentent pas nécessairement celles de DDO Organisation ni du Groupe Cogeser.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/






Ce message électronique et tous les fichiers attachés peuvent contenir des 

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[David Ponzone]

Là ton port est en access 835, donc le port a comme VLAN Native 835, donc les 
paquets PPPoE sortent sans TAG.
Il taut le mettre en trunk avec VLAN 1 Native

> Le 4 juin 2019 à 16:34, DONNET, Sylvain  a écrit :
> 
> Bonjour à tous,
> 
> Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP fixe 
> d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
> 
> Voici ma conf, en résumé :
> 
> interface FastEthernet0
> description Link from FTTH Orange
> switchport access vlan 835
> no ip address
> no cdp enable
> !
> …/…
> interface Vlan835
> description Link to ORANGE
> no ip address
> pppoe enable group global
> pppoe-client dial-pool-number 1
> !
> interface Dialer1
> ip address negotiated
> ip mtu 1492
> ip nat outside
> ip virtual-reassembly in
> encapsulation ppp
> no ip route-cache
> ip tcp adjust-mss 1452
> dialer pool 1
> dialer-group 1
> ppp authentication chap
> ppp chap hostname fti/*
> ppp chap password 0 *
> ppp ipcp dns request accept
> ppp ipcp route default
> ppp ipcp address accept
> no cdp enable
> !
> …/…
> ip route 0.0.0.0 0.0.0.0 Dialer1
> …/…
> access-list 1 permit any
> 
> 
> En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont UP, 
> mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même pas 
> de session ppp enclenchée (pas de traces sur des debug  ppp *).
> Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte les 
> yeux dessus, mais je ne vois pas où ça cloche.
> 
> Quelqu’un aurait une idée, SVP ?
> 
> 
> Le « show int Dialer1 » :
> 
> Dialer1 is up, line protocol is up (spoofing)
>  Hardware is Unknown
>  Internet address will be negotiated using IPCP
>  MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
> reliability 255/255, txload 1/255, rxload 1/255
>  Encapsulation PPP, LCP Closed, loopback not set
>  Keepalive set (10 sec)
>  DTR is pulsed for 1 seconds on reset
>  Last input never, output never, output hang never
>  Last clearing of "show interface" counters 00:13:26
>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>  Queueing strategy: fifo
>  Output queue: 0/40 (size/max)
>  5 minute input rate 0 bits/sec, 0 packets/sec
>  5 minute output rate 0 bits/sec, 0 packets/sec
> 0 packets input, 0 bytes
> 0 packets output, 0 bytes
> 
> Le “sh pppoe session” :
> 1 client session
> 
> Uniq ID  PPPoE  RemMAC  PortVT  VA State
>   SID  LocMAC  VA-st  Type
>N/A  0  ..  Vl835   Di1 N/APADISNT
>..
> 
> Le “sh ppp interface Dialer1” :
> 
> PPP Serial Context Info
> ---
> Interface: Di1
> PPP Serial Handle: 0x0
> PPP Handle   : 0x0
> SSS Handle   : 0x0
> AAA ID   : 0
> Access IE: 0x0
> SHDB Handle  : 0x0
> State: Down
> Last State   : Init
> Last Event   : RestartTimeout
> 
> 
> Ce message électronique et tous les fichiers attachés peuvent contenir des 
> informations confidentielles et destinées exclusivement à l’usage de la 
> personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas destinataire 
> de ce message, vous n'êtes pas autorisés à le lire, l'imprimer, le garder, le 
> copier, le divulguer, le distribuer, l'utiliser, ni dans son ensemble, ni en 
> partie, sans autorisation préalable. Si vous recevez ce message par erreur, 
> merci de le détruire et d’en avertir sans délai l’expéditeur.
> 
> Le contenu de ce message ne pourrait engager la responsabilité de DDO 
> Organisation que s’il a été émis par une personne dûment habilitée agissant 
> dans le strict cadre des fonctions auxquelles elle est employée et à des fins 
> non étrangères à ses attributions. Tout message électronique étant 
> susceptible d’altération au cours de son acheminement sur Internet, DDO 
> Organisation et le Groupe Cogeser ne peuvent être tenus responsables de son 
> contenu. En outre, les idées et opinions présentées dans ce message sont 
> celles de son auteur et ne représentent pas nécessairement celles de DDO 
> Organisation ni du Groupe Cogeser.
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problème CISCO / FTTH Orange

[Erwan David]

On 04/06/2019 16:34, DONNET, Sylvain wrote:
> Bonjour à tous,
>
> Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP fixe 
> d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).
>
[]


> En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont UP, 
> mais rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même pas 
> de session ppp enclenchée (pas de traces sur des debug  ppp *).
> Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte les 
> yeux dessus, mais je ne vois pas où ça cloche.
>
> Quelqu’un aurait une idée, SVP ?
>

D'après les docs que j'ai lu en FTTH Orange ne fait pas de ppp mais du
DHCP, avec des petits détails qui font tout le sel, genre la QOS à
mettre sur les paquets DHCP.

Les docs que j'avais vu (ça n'utilise pas un Cisco, mais ça donne de l'info)

https://sebastien.warin.fr/2017/02/11/4284-fonctionnement-fibre-orange-remplacement-livebox-routeur-mikrotik-routeros/

http://wiki.csnu.org/index.php/Fibre_orange_en_DHCP_avec_routeur_pfsense

https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/


Bon déjà tu n'auras sans doute pas besoin de faire passer la TV et le
téléphone, ça simplifie.


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

[FRnOG] [TECH] Problème CISCO / FTTH Orange

[DONNET, Sylvain]

Bonjour à tous,

Je cherche à brancher un Cisco 887 sur une liaison FTTH Orange, avec IP fixe 
d’ailleurs, chez un client (en remplacement d’une Livebox Pro 4).

Voici ma conf, en résumé :

interface FastEthernet0
description Link from FTTH Orange
switchport access vlan 835
no ip address
no cdp enable
!
…/…
interface Vlan835
description Link to ORANGE
no ip address
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
ip virtual-reassembly in
encapsulation ppp
no ip route-cache
ip tcp adjust-mss 1452
dialer pool 1
dialer-group 1
ppp authentication chap
ppp chap hostname fti/*
ppp chap password 0 *
ppp ipcp dns request accept
ppp ipcp route default
ppp ipcp address accept
no cdp enable
!
…/…
ip route 0.0.0.0 0.0.0.0 Dialer1
…/…
access-list 1 permit any


En terme de liaisons, toutes mes interfaces (Fa0,Vlan835,Dialer1) sont UP, mais 
rien ne passe (quelques paquets sur Fa0 et Vlan835). Je ne vois même pas de 
session ppp enclenchée (pas de traces sur des debug  ppp *).
Ca doit être gros comme le nez au milieu de la figure, et je m’esquinte les 
yeux dessus, mais je ne vois pas où ça cloche.

Quelqu’un aurait une idée, SVP ?


Le « show int Dialer1 » :

Dialer1 is up, line protocol is up (spoofing)
  Hardware is Unknown
  Internet address will be negotiated using IPCP
  MTU 1500 bytes, BW 56 Kbit/sec, DLY 2 usec,
 reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Closed, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 1 seconds on reset
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 00:13:26
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
 0 packets input, 0 bytes
 0 packets output, 0 bytes

Le “sh pppoe session” :
 1 client session

Uniq ID  PPPoE  RemMAC  PortVT  VA State
   SID  LocMAC  VA-st  Type
N/A  0  ..  Vl835   Di1 N/APADISNT
..

Le “sh ppp interface Dialer1” :

PPP Serial Context Info
---
Interface: Di1
PPP Serial Handle: 0x0
PPP Handle   : 0x0
SSS Handle   : 0x0
AAA ID   : 0
Access IE: 0x0
SHDB Handle  : 0x0
State: Down
Last State   : Init
Last Event   : RestartTimeout


Ce message électronique et tous les fichiers attachés peuvent contenir des 
informations confidentielles et destinées exclusivement à l’usage de la 
personne dont le nom est mentionné ci-dessus. Si vous n'êtes pas destinataire 
de ce message, vous n'êtes pas autorisés à le lire, l'imprimer, le garder, le 
copier, le divulguer, le distribuer, l'utiliser, ni dans son ensemble, ni en 
partie, sans autorisation préalable. Si vous recevez ce message par erreur, 
merci de le détruire et d’en avertir sans délai l’expéditeur.

Le contenu de ce message ne pourrait engager la responsabilité de DDO 
Organisation que s’il a été émis par une personne dûment habilitée agissant 
dans le strict cadre des fonctions auxquelles elle est employée et à des fins 
non étrangères à ses attributions. Tout message électronique étant susceptible 
d’altération au cours de son acheminement sur Internet, DDO Organisation et le 
Groupe Cogeser ne peuvent être tenus responsables de son contenu. En outre, les 
idées et opinions présentées dans ce message sont celles de son auteur et ne 
représentent pas nécessairement celles de DDO Organisation ni du Groupe Cogeser.

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

Re: [FRnOG] [TECH] Teltonika RUT240: perfs douteuses

[Anthony Deshayes]

>
> 10Mbps dans chaque sens max, même  avec un signal à  -51dB.


Il faudrait vérifier :

- si tu as le même débit de manière constante ou sur certaines plages
horaires (genre saturation le midi et fin d'après-midi)
- avec un autre opérateur situé sur le même pylone (pour s'assurer que ce
n'est pas un affaiblissement ayant pour cause une obstruction extérieure)

Personne a testé la mANT50 de Mikrotik ?
>

Pas eu l'occasion et vu le tarif j'ai un doute sur les réelles performances
du produit (et pourtant j'apprécie en général les produits Mikrotik).

Anthony

Le mar. 4 juin 2019 à 11:51, David Ponzone  a
écrit :

>
> Le 4 juin 2019 à 11:37, Frank ALEXIS  a écrit :
>
> Je plussois sur le choix de l'antenne, si je peux apporter une petite
> pierre :-)
> Plusieurs installées et ça apporte un grand bol d'air frais !
>
> Frank
>
> Le 4 juin 2019 à 11:24, Anthony Deshayes  a
> écrit :
>
> Bonjour,
>
> Qu'entends tu par "sous-performent" ?
> Nous utilisons essentiellement le RUT950 pour nos différentes installations
> et la seule chose que l'on constate est sur certains secteurs un débit
> moindre mais qui est dû à la végétation pouvant se trouver entre l'antenne
> et l'émetteur (l'épaisseur de feuillage à traverser étant plus dense en
> cette période).
>
>
> 10Mbps dans chaque sens max, même  avec un signal à  -51dB.
>
> Concernant les antennes LTE, après en avoir testé quelques unes, nous
> optons désormais systématiquement pour celle-ci
>
> https://www.amazon.fr/Antenne-Directionnelle-LowcostMobile-Connectique-Netgear/dp/B01NBTQUAE/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91=antenne+lte+lowcost+mobile=1559640163=gateway=8-1
> 
>
>
> Personne a testé la mANT50 de Mikrotik ?
>
>
>

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

Re: [FRnOG] [TECH] Teltonika RUT240: perfs douteuses

[David Ponzone]

> 
> Le 4 juin 2019 à 11:37, Frank ALEXIS  a écrit :
> 
> Je plussois sur le choix de l'antenne, si je peux apporter une petite pierre 
> :-)
> Plusieurs installées et ça apporte un grand bol d'air frais !
> 
> Frank
> 
>> Le 4 juin 2019 à 11:24, Anthony Deshayes  a 
>> écrit :
>> 
>> Bonjour,
>> 
>> Qu'entends tu par "sous-performent" ?
>> Nous utilisons essentiellement le RUT950 pour nos différentes installations
>> et la seule chose que l'on constate est sur certains secteurs un débit
>> moindre mais qui est dû à la végétation pouvant se trouver entre l'antenne
>> et l'émetteur (l'épaisseur de feuillage à traverser étant plus dense en
>> cette période).

10Mbps dans chaque sens max, même  avec un signal à  -51dB.

>> Concernant les antennes LTE, après en avoir testé quelques unes, nous
>> optons désormais systématiquement pour celle-ci
>> https://www.amazon.fr/Antenne-Directionnelle-LowcostMobile-Connectique-Netgear/dp/B01NBTQUAE/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91=antenne+lte+lowcost+mobile=1559640163=gateway=8-1
>>  
>> 

Personne a testé la mANT50 de Mikrotik ?



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

Re: [FRnOG] [TECH] Teltonika RUT240: perfs douteuses

[Frank ALEXIS]

Je plussois sur le choix de l'antenne, si je peux apporter une petite pierre :-)
Plusieurs installées et ça apporte un grand bol d'air frais !

Frank

> Le 4 juin 2019 à 11:24, Anthony Deshayes  a écrit 
> :
> 
> Bonjour,
> 
> Qu'entends tu par "sous-performent" ?
> Nous utilisons essentiellement le RUT950 pour nos différentes installations
> et la seule chose que l'on constate est sur certains secteurs un débit
> moindre mais qui est dû à la végétation pouvant se trouver entre l'antenne
> et l'émetteur (l'épaisseur de feuillage à traverser étant plus dense en
> cette période).
> 
> Concernant les antennes LTE, après en avoir testé quelques unes, nous
> optons désormais systématiquement pour celle-ci
> https://www.amazon.fr/Antenne-Directionnelle-LowcostMobile-Connectique-Netgear/dp/B01NBTQUAE/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91=antenne+lte+lowcost+mobile=1559640163=gateway=8-1
> 
> Anthony
> 
> Le mar. 4 juin 2019 à 08:14, David Ponzone  a
> écrit :
> 
>> J’ai l’impression étrange que mes RUT240 sous-performent depuis quelques
>> temps.
>> Comme le 240 est assez récent et qu'il y a eu une mise à jour récemment,
>> je me méfie.
>> 
>> Est-ce quelqu’un d’autre a constaté la même chose ?
>> Est-ce quelqu’un a trouvé des antennes LTE faciles à installer et avec un
>> meilleur gain que le 2.5dBm de celle que Telto vend en accessoires ?
>> 
>> 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/

Re: [FRnOG] [TECH] Teltonika RUT240: perfs douteuses

[Anthony Deshayes]

Bonjour,

Qu'entends tu par "sous-performent" ?
Nous utilisons essentiellement le RUT950 pour nos différentes installations
et la seule chose que l'on constate est sur certains secteurs un débit
moindre mais qui est dû à la végétation pouvant se trouver entre l'antenne
et l'émetteur (l'épaisseur de feuillage à traverser étant plus dense en
cette période).

Concernant les antennes LTE, après en avoir testé quelques unes, nous
optons désormais systématiquement pour celle-ci
https://www.amazon.fr/Antenne-Directionnelle-LowcostMobile-Connectique-Netgear/dp/B01NBTQUAE/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91=antenne+lte+lowcost+mobile=1559640163=gateway=8-1

Anthony

Le mar. 4 juin 2019 à 08:14, David Ponzone  a
écrit :

> J’ai l’impression étrange que mes RUT240 sous-performent depuis quelques
> temps.
> Comme le 240 est assez récent et qu'il y a eu une mise à jour récemment,
> je me méfie.
>
> Est-ce quelqu’un d’autre a constaté la même chose ?
> Est-ce quelqu’un a trouvé des antennes LTE faciles à installer et avec un
> meilleur gain que le 2.5dBm de celle que Telto vend en accessoires ?
>
> Merci
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Cisco et NAT fou en sortie de VRF

[David Ponzone]

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 0.255.255.255 10.0.0.0 0.255.255.255
permit ip 10.0.0.0 0.255.255.255 any

Je me retrouve avec des paquets de 10.X.X.X vers 10.Y.Y.Y qui sont natés et qui 
arrivent quand même à 10.Y.Y.Y alors que 10.Y.Y.Y n’est connue que dans le VRF 
(en BGP VPNv4) donc NAT en restant dans le VRF alors que ma seule route de 
sortie du VRF, c’est la route par défaut vers global.

Ca sent le bug et le reboot mais si quelqu’un a une meilleure idée ou une 
confirmation, je suis preneur…

Merci

David



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

[FRnOG] [TECH] Teltonika RUT240: perfs douteuses

[David Ponzone]

J’ai l’impression étrange que mes RUT240 sous-performent depuis quelques temps.
Comme le 240 est assez récent et qu'il y a eu une mise à jour récemment, je me 
méfie.

Est-ce quelqu’un d’autre a constaté la même chose ?
Est-ce quelqu’un a trouvé des antennes LTE faciles à installer et avec un 
meilleur gain que le 2.5dBm de celle que Telto vend en accessoires ?

Merci


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