RE: [FRnOG] [TECH] Dual ISP load balancing+failover cisco 1841

2016-02-02 Par sujet Michel Py 
> Sébastien 65 a écrit :
> J'essaye de faire du load balancing sur deux ADSL tout en essayant le failover

Pourquoi tu ne fais pas Multilink PPP ?

Michel.

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

Re: [FRnOG] [TECH] Dual ISP load balancing+failover cisco 1841

2016-02-02 Par sujet David Ponzone 
BERRRK
Ca marche quand ça veut et ça dépend pas mal des saloperies que le DSLAM 
renvoie au LNS.
Si même DSLAM, il a une chance que ça marche.


> Le 2 févr. 2016 à 19:51, Michel Py  a 
> écrit :
> 
>> Sébastien 65 a écrit :
>> J'essaye de faire du load balancing sur deux ADSL tout en essayant le 
>> failover
> 
> Pourquoi tu ne fais pas Multilink PPP ?
> 
> Michel.
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

RE: [FRnOG] [TECH] Dual ISP load balancing+failover cisco 1841

2016-02-02 Par sujet Michel Py 
>> Michel Py a écrit :
>> Pourquoi tu ne fais pas Multilink PPP ?

> David Ponzone a écrit :
> BERRRK
> Ca marche quand ça veut et ça dépend pas mal des saloperies que le DSLAM
> renvoie au LNS. Si même DSLAM, il a une chance que ça marche.

Je devais pas être réveillé; aucune chance que çà marche dans cette situation 
en effet.
coffee++


> Sébastien a écrit :
> Une autre question, faut-il utiliser "ip load-sharing per-packet" sur les 
> interfaces dialer ainsi que sur l'interface du LAN ?

Je déconseille ; si tu fais çà tu vas avoir pleins de trucs louches qui vont 
t'arriver, du genre adresse publique qui change pendant la session, et autres 
joyeusetés. Je conseille de garder le défaut: Per-Source-Destination 
Load-Sharing using CEF, most commonly referred to as Per-Destination 
Load-Balancing, this is the default switching scheme CEF uses if enabled.

> Je rebranche le câble ADSL sur le Cisco une fois que la session est UP, les 
> derniers pings qui
> étaient repassés OK redeviennent HS ??? La je ne comprend pas pourquoi...

Tu ping du routeur ou d'un PC ? Si c'est du routeur, essaies d'un PC voir si ca 
change quelque chose.
(j'ai vu de la magie noire quand le ping vient du routeur lui-même; en gardant 
le défaut de CEF c'est un hash entre la source et la destination, autant être 
sur de la source)

Si le PC que tu utilises est 192.168.1.1, pour les destinations x.x.x.x que tu 
ping, que donne:
sh ip cef exact-route 192.168.1.1 x.x.x.x
Avant, avec un des aDSL débranchés, après rebranché ?

Michel.


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

RE: [FRnOG] [MISC] Alerte au démarchage en masse par un call-center en Afrique du Nord pour le compte d'Orange

2016-02-02 Par sujet Michel Py 
> David Ponzone a écrit :
> un call-center en Tunisie appelle beaucoup de numéros

La Tunisie, c'est l'équivalent Français de Bangalore ?

David, ce qu'il te faut c'est une version Française de Lenny.
http://toao.net/595-lenny


> Jonathan Leroy a écrit :
> Comment peuvent-ils récupérer ce numéro ? Auprès de l'ARCEP ? C'est légal ?

En Tunisie, va savoir.

Michel.


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

Re: [FRnOG] [BIZ] Alerte au démarchage en masse par un call-center en Afrique du Nord pour le compte d'Orange

2016-02-02 Par sujet David Ponzone 
Directvox est une marque de MKS-Direct, opérateur licencié, à priori 
interconnecté et membre de l’APNF.
Tu as porté ce 0811 ? Tu n’avais pas donné ce numéro de portable comme contact 
au moment de cette porta ?
S’il tape dans l’APNF pour faire ses campagnes, il peut avoir des ennuis.

> Le 2 févr. 2016 à 18:28, Jonathan Leroy  a 
> écrit :
> 
> Le 2 février 2016 à 17:45, David Ponzone  a écrit :
>> Afin de faire des recoupements avec des confrères, voilà une information qui 
>> peut vous intéresser.
>> Nous avons remarqué "par hasard" que depuis quelques temps, un call-center 
>> en Tunisie appelle beaucoup de numéros que nous avons portés (attributaires 
>> Orange) pour faire des devis Orange à nos clients, en se présentant comme 
>> Orange.
>> Il est probable qu’Orange ait lancé une campagne sur les numéros d’anciens 
>> clients.
> 
> C'est marrant, j'ai justement reçu un appel ce matin d'une personne au
> fort accent portugais (?) concernant un vieux 0 811 que je n'utilise
> quasiment plus : https://1fichier.com/?k108j0pl23
> 
> L'appel provenait du 0186229002 (DirectVox, http://www.directvox.fr/).
> 
> Ce n'est pas la première fois qu'un opérateur douteux m'appelle
> concernant ce numéro, mais ils appellent toujours sur mon portable
> perso, qui n'est utilisé nulle part... sauf chez Keyyo (l'opérateur
> chez lequel se trouve ce numéro).
> Comment peuvent-ils récupérer ce numéro ? Auprès de l'ARCEP ? C'est légal ?
> 
> -- 
> Jonathan Leroy.


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

RE: [FRnOG] [TECH] Boitier Conférence Skype ?

2016-02-02 Par sujet Olivier Varenne 
Avec un gvc ca permet de faire des reunion visio pas trop cher. On en a (on en 
vend), ca fonctionne. Mais il faut bien définir les besoins car on peut vite 
être déçu….

Provenance : Courrier Outlook pour téléphone Windows 10

De : Alain Bieuzent
Envoyé le :mardi 2 février 2016 18:33
À : frnog@frnog.org
Objet :Re: [FRnOG] [TECH] Boitier Conférence Skype ?

Le 01/02/2016 17:26, SIMANCAS Hugo a écrit :
> Bonjour,
>
> Connaissez-vous un boitier sympa pour de la réunion éloignée sous Skype ou 
> autre ?
> Caméra intelligente grand Angle + interface d'appel ?
>
> Merci d'avance
>
> Hugo
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
Si la vidéo n'est pas indispensable et que tu veut l'utiliser aussi pour
du SIP, je vient de commander ça :
http://www.ipandgo.com/fr/audio-conference/971-grandstream-gac2500.html
je la reçoit dans 48h00 ...

Alain


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


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

[FRnOG] [TECH] RE: Dual ISP load balancing+failover cisco 1841

2016-02-02 Par sujet Sébastien 65 
Bonjour à tous,

Petite précision, j'utilise l'IOS suivant c1841-adventerprisek9-mz.151-4.M10.

Une autre question, faut-il utiliser "ip load-sharing per-packet" sur les 
interfaces dialer ainsi que sur l'interface du LAN ?

A++


Objet : [FRnOG] [TECH] Dual ISP load balancing+failover cisco 1841

Bonjour,


J'essaye de faire du load balancing sur deux ADSL tout en essayant le 
failover... J'ai un petit soucis sur le "failover" que je ne m'explique pas !!


Je lance une série de ping vers quelques destinations, je débranche le câble 
d'une ADSL, au bout de quelques secondes le Cisco converge bien vers l'autre 
ADSL active, les pings HS repassent donc OK.


On se dit tout va bien c'est cool ça marche ! Mais en fait NON !


Je rebranche le câble ADSL sur le Cisco une fois que la session est UP, les 
derniers pings qui étaient repassés OK redeviennent HS ??? La je ne comprend 
pas pourquoi...


Voici ma config :


!
track 1 interface Dialer1 ip routing
 delay down 1 up 1
!
track 2 interface Dialer2 ip routing
 delay down 1 up 1
!
interface FastEthernet0/0
 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
 ip verify unicast reverse-path
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface ATM0/0/0
 no ip address
 no atm ilmi-keepalive
 pvc 8/35
  description *** ADSL_1 / SLOT0 ***
  pppoe-client dial-pool-number 1
 !
!
interface ATM0/1/0
 no ip address
 no atm ilmi-keepalive
 pvc 8/35
  description *** ADSL_2 / SLOT1 ***
  pppoe-client dial-pool-number 2
 !
!
interface Dialer1
 description *** ADSL_1 ***
 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
 ppp authentication pap callin
 ppp chap hostname
 ppp chap password 7
 ppp ipcp dns request
 no cdp enable
!
interface Dialer2
 description *** ADSL_2 ***
 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 2
 ppp authentication pap callin
 ppp chap hostname
 ppp chap password 7
 ppp ipcp dns request
 no cdp enable
!
ip nat inside source route-map ADSL_1 interface Dialer1 overload
ip nat inside source route-map ADSL_2 interface Dialer2 overload
ip route 0.0.0.0 0.0.0.0 Dialer1 track 1
ip route 0.0.0.0 0.0.0.0 Dialer2 track 2
!
ip sla 1
 icmp-echo 8.8.8.8 source-interface Dialer1
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 8.8.8.8 source-interface Dialer2
ip sla schedule 2 life forever start-time now
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 102 permit ip 192.168.2.0 0.0.0.255 any
no cdp run
!
route-map ADSL_1 permit 1
 match ip address 101 102
 match interface Dialer1
!
route-map ADSL_2 permit 1
 match ip address 101 102
 match interface Dialer2
!

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


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

[FRnOG] [MISC] À faire en France ?

2016-02-02 Par sujet Stéphane Bortzmeyer 
http://www.fredzone.org/il-a-cree-un-bot-pour-pourrir-son-fai-sur-twitter-441
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RE: Dual ISP load balancing+failover cisco 1841

2016-02-02 Par sujet David Ponzone 
Vérifie le comportement par défaut du load-sharing, je crois que c’est 
per-packet.

Attention, avec cette forme de load-balancing « bête » , tu vas avoir des 
problèmes avec certaines sites en HTTPS, voir en HTTP.


> Le 2 févr. 2016 à 09:54, Sébastien 65  a écrit :
> 
> Bonjour à tous,
> 
> Petite précision, j'utilise l'IOS suivant c1841-adventerprisek9-mz.151-4.M10.
> 
> Une autre question, faut-il utiliser "ip load-sharing per-packet" sur les 
> interfaces dialer ainsi que sur l'interface du LAN ?
> 
> A++
> 
> 
> Objet : [FRnOG] [TECH] Dual ISP load balancing+failover cisco 1841
> 
> Bonjour,
> 
> 
> J'essaye de faire du load balancing sur deux ADSL tout en essayant le 
> failover... J'ai un petit soucis sur le "failover" que je ne m'explique pas !!
> 
> 
> Je lance une série de ping vers quelques destinations, je débranche le câble 
> d'une ADSL, au bout de quelques secondes le Cisco converge bien vers l'autre 
> ADSL active, les pings HS repassent donc OK.
> 
> 
> On se dit tout va bien c'est cool ça marche ! Mais en fait NON !
> 
> 
> Je rebranche le câble ADSL sur le Cisco une fois que la session est UP, les 
> derniers pings qui étaient repassés OK redeviennent HS ??? La je ne comprend 
> pas pourquoi...
> 
> 
> Voici ma config :
> 
> 
> !
> track 1 interface Dialer1 ip routing
> delay down 1 up 1
> !
> track 2 interface Dialer2 ip routing
> delay down 1 up 1
> !
> interface FastEthernet0/0
> 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
> ip verify unicast reverse-path
> duplex auto
> speed auto
> !
> interface FastEthernet0/1
> no ip address
> shutdown
> duplex auto
> speed auto
> !
> interface ATM0/0/0
> no ip address
> no atm ilmi-keepalive
> pvc 8/35
>  description *** ADSL_1 / SLOT0 ***
>  pppoe-client dial-pool-number 1
> !
> !
> interface ATM0/1/0
> no ip address
> no atm ilmi-keepalive
> pvc 8/35
>  description *** ADSL_2 / SLOT1 ***
>  pppoe-client dial-pool-number 2
> !
> !
> interface Dialer1
> description *** ADSL_1 ***
> 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
> ppp authentication pap callin
> ppp chap hostname
> ppp chap password 7
> ppp ipcp dns request
> no cdp enable
> !
> interface Dialer2
> description *** ADSL_2 ***
> 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 2
> ppp authentication pap callin
> ppp chap hostname
> ppp chap password 7
> ppp ipcp dns request
> no cdp enable
> !
> ip nat inside source route-map ADSL_1 interface Dialer1 overload
> ip nat inside source route-map ADSL_2 interface Dialer2 overload
> ip route 0.0.0.0 0.0.0.0 Dialer1 track 1
> ip route 0.0.0.0 0.0.0.0 Dialer2 track 2
> !
> ip sla 1
> icmp-echo 8.8.8.8 source-interface Dialer1
> ip sla schedule 1 life forever start-time now
> ip sla 2
> icmp-echo 8.8.8.8 source-interface Dialer2
> ip sla schedule 2 life forever start-time now
> access-list 101 permit ip 192.168.1.0 0.0.0.255 any
> access-list 102 permit ip 192.168.2.0 0.0.0.255 any
> no cdp run
> !
> route-map ADSL_1 permit 1
> match ip address 101 102
> match interface Dialer1
> !
> route-map ADSL_2 permit 1
> match ip address 101 102
> match interface Dialer2
> !
> 
> ---
> 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] RE: Dual ISP load balancing+failover cisco 1841

2016-02-02 Par sujet Sébastien 65 
Salut David,

Il me semble que c'est peer-packet mais je n'en suis pas sur justement...

>Attention, avec cette forme de load-balancing « bête » , tu vas avoir des 
>problèmes avec certaines sites en HTTPS, voir en HTTP.
Donc tu me conseilles quoi alors ? 

De ne pas activer "ip load-sharing per-packet" sur les dialer et laisser faire 
iproute avec le même poids pour basculer soit sur dial1 ou dial2 ?


De : frnog-requ...@frnog.org  de la part de David 
Ponzone 
Envoyé : mardi 2 février 2016 10:46
À : Sébastien 65
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] RE: Dual ISP load balancing+failover cisco 1841

Vérifie le comportement par défaut du load-sharing, je crois que c’est 
per-packet.

Attention, avec cette forme de load-balancing « bête » , tu vas avoir des 
problèmes avec certaines sites en HTTPS, voir en HTTP.


> Le 2 févr. 2016 à 09:54, Sébastien 65  a écrit :
>
> Bonjour à tous,
>
> Petite précision, j'utilise l'IOS suivant c1841-adventerprisek9-mz.151-4.M10.
>
> Une autre question, faut-il utiliser "ip load-sharing per-packet" sur les 
> interfaces dialer ainsi que sur l'interface du LAN ?
>
> A++
> 
>
> Objet : [FRnOG] [TECH] Dual ISP load balancing+failover cisco 1841
>
> Bonjour,
>
>
> J'essaye de faire du load balancing sur deux ADSL tout en essayant le 
> failover... J'ai un petit soucis sur le "failover" que je ne m'explique pas !!
>
>
> Je lance une série de ping vers quelques destinations, je débranche le câble 
> d'une ADSL, au bout de quelques secondes le Cisco converge bien vers l'autre 
> ADSL active, les pings HS repassent donc OK.
>
>
> On se dit tout va bien c'est cool ça marche ! Mais en fait NON !
>
>
> Je rebranche le câble ADSL sur le Cisco une fois que la session est UP, les 
> derniers pings qui étaient repassés OK redeviennent HS ??? La je ne comprend 
> pas pourquoi...
>
>
> Voici ma config :
>
>
> !
> track 1 interface Dialer1 ip routing
> delay down 1 up 1
> !
> track 2 interface Dialer2 ip routing
> delay down 1 up 1
> !
> interface FastEthernet0/0
> 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
> ip verify unicast reverse-path
> duplex auto
> speed auto
> !
> interface FastEthernet0/1
> no ip address
> shutdown
> duplex auto
> speed auto
> !
> interface ATM0/0/0
> no ip address
> no atm ilmi-keepalive
> pvc 8/35
>  description *** ADSL_1 / SLOT0 ***
>  pppoe-client dial-pool-number 1
> !
> !
> interface ATM0/1/0
> no ip address
> no atm ilmi-keepalive
> pvc 8/35
>  description *** ADSL_2 / SLOT1 ***
>  pppoe-client dial-pool-number 2
> !
> !
> interface Dialer1
> description *** ADSL_1 ***
> 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
> ppp authentication pap callin
> ppp chap hostname
> ppp chap password 7
> ppp ipcp dns request
> no cdp enable
> !
> interface Dialer2
> description *** ADSL_2 ***
> 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 2
> ppp authentication pap callin
> ppp chap hostname
> ppp chap password 7
> ppp ipcp dns request
> no cdp enable
> !
> ip nat inside source route-map ADSL_1 interface Dialer1 overload
> ip nat inside source route-map ADSL_2 interface Dialer2 overload
> ip route 0.0.0.0 0.0.0.0 Dialer1 track 1
> ip route 0.0.0.0 0.0.0.0 Dialer2 track 2
> !
> ip sla 1
> icmp-echo 8.8.8.8 source-interface Dialer1
> ip sla schedule 1 life forever start-time now
> ip sla 2
> icmp-echo 8.8.8.8 source-interface Dialer2
> ip sla schedule 2 life forever start-time now
> access-list 101 permit ip 192.168.1.0 0.0.0.255 any
> access-list 102 permit ip 192.168.2.0 0.0.0.255 any
> no cdp run
> !
> route-map ADSL_1 permit 1
> match ip address 101 102
> match interface Dialer1
> !
> route-map ADSL_2 permit 1
> match ip address 101 102
> match interface Dialer2
> !
>
> ---
> 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/


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

Re: [FRnOG] [TECH] RE: Dual ISP load balancing+failover cisco 1841

2016-02-02 Par sujet David Ponzone 
Moi je dis ça, je dis rien :)

Si tu as pas de problèmes en per-packet, genre avec des sites bancaires par 
exemple, ou la SNCF Réservation (à moins qu’ils aient corrigé chez eux depuis), 
touche à rien.
Sinon, tu peux essayer le load-sharing per-destination, mais ça risque de pas 
équilibrer très bien la charge.
Ou sinon, tu modifies tes route-map pour forcer le trafic HTTPS sur un seul 
ADSL.
Il te restera le problème pour les sites HTTP qui n’aiment pas les IP sources 
qui changent en cours de session, comme la SNCF il y a quelques temps.
Beaucoup de sites sont maintenant passés en HTTPS, sauf bien sûr la SNCF, qui a 
toujours un train d’avance.
Ok je sors.

Ou si tu gères les LNS, tu mets tes 2 ADSL dans un VRF et tu fais le NAT en 
coeur de réseau vers une seule IP publique.
Ca marche très bien même avec 4 ADSL.

> Le 2 févr. 2016 à 11:13, Sébastien 65  a écrit :
> 
> Salut David,
> 
> Il me semble que c'est peer-packet mais je n'en suis pas sur justement...
> 
>> Attention, avec cette forme de load-balancing « bête » , tu vas avoir des 
>> problèmes avec certaines sites en HTTPS, voir en HTTP.
> Donc tu me conseilles quoi alors ? 
> 
> De ne pas activer "ip load-sharing per-packet" sur les dialer et laisser 
> faire iproute avec le même poids pour basculer soit sur dial1 ou dial2 ?
> 
> 
> De : frnog-requ...@frnog.org  de la part de David 
> Ponzone 
> Envoyé : mardi 2 février 2016 10:46
> À : Sébastien 65
> Cc : frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] RE: Dual ISP load balancing+failover cisco 1841
> 
> Vérifie le comportement par défaut du load-sharing, je crois que c’est 
> per-packet.
> 
> Attention, avec cette forme de load-balancing « bête » , tu vas avoir des 
> problèmes avec certaines sites en HTTPS, voir en HTTP.
> 
> 
>> Le 2 févr. 2016 à 09:54, Sébastien 65  a écrit :
>> 
>> Bonjour à tous,
>> 
>> Petite précision, j'utilise l'IOS suivant c1841-adventerprisek9-mz.151-4.M10.
>> 
>> Une autre question, faut-il utiliser "ip load-sharing per-packet" sur les 
>> interfaces dialer ainsi que sur l'interface du LAN ?
>> 
>> A++
>> 
>> 
>> Objet : [FRnOG] [TECH] Dual ISP load balancing+failover cisco 1841
>> 
>> Bonjour,
>> 
>> 
>> J'essaye de faire du load balancing sur deux ADSL tout en essayant le 
>> failover... J'ai un petit soucis sur le "failover" que je ne m'explique pas 
>> !!
>> 
>> 
>> Je lance une série de ping vers quelques destinations, je débranche le câble 
>> d'une ADSL, au bout de quelques secondes le Cisco converge bien vers l'autre 
>> ADSL active, les pings HS repassent donc OK.
>> 
>> 
>> On se dit tout va bien c'est cool ça marche ! Mais en fait NON !
>> 
>> 
>> Je rebranche le câble ADSL sur le Cisco une fois que la session est UP, les 
>> derniers pings qui étaient repassés OK redeviennent HS ??? La je ne comprend 
>> pas pourquoi...
>> 
>> 
>> Voici ma config :
>> 
>> 
>> !
>> track 1 interface Dialer1 ip routing
>> delay down 1 up 1
>> !
>> track 2 interface Dialer2 ip routing
>> delay down 1 up 1
>> !
>> interface FastEthernet0/0
>> 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
>> ip verify unicast reverse-path
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet0/1
>> no ip address
>> shutdown
>> duplex auto
>> speed auto
>> !
>> interface ATM0/0/0
>> no ip address
>> no atm ilmi-keepalive
>> pvc 8/35
>> description *** ADSL_1 / SLOT0 ***
>> pppoe-client dial-pool-number 1
>> !
>> !
>> interface ATM0/1/0
>> no ip address
>> no atm ilmi-keepalive
>> pvc 8/35
>> description *** ADSL_2 / SLOT1 ***
>> pppoe-client dial-pool-number 2
>> !
>> !
>> interface Dialer1
>> description *** ADSL_1 ***
>> 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
>> ppp authentication pap callin
>> ppp chap hostname
>> ppp chap password 7
>> ppp ipcp dns request
>> no cdp enable
>> !
>> interface Dialer2
>> description *** ADSL_2 ***
>> 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 2
>> ppp authentication pap callin
>> ppp chap hostname
>> ppp chap password 7
>> ppp ipcp dns request
>> no cdp enable
>> !
>> ip nat inside source route-map ADSL_1 interface Dialer1 overload
>> ip nat inside source route-map ADSL_2 interface Dialer2 overload
>> ip route 0.0.0.0 0.0.0.0 Dialer1 track 1
>> ip route 0.0.0.0 0.0.0.0 Dialer2 track 2
>> !
>> ip sla 1
>> icmp-echo 8.8.8.8 source-interface Dialer1
>> ip sla schedule 1 life forever start-time now
>> ip sla 2
>> icmp-echo 8.8.8.8 source-interface Dialer2
>> ip sla schedule 2 life forever start-time now
>> access-list 101 permit ip

[FRnOG] [BIZ] Alerte au démarchage en masse par un call-center en Afrique du Nord pour le compte d'Orange

2016-02-02 Par sujet David Ponzone 
Afin de faire des recoupements avec des confrères, voilà une information qui 
peut vous intéresser.
Nous avons remarqué "par hasard" que depuis quelques temps, un call-center en 
Tunisie appelle beaucoup de numéros que nous avons portés (attributaires 
Orange) pour faire des devis Orange à nos clients, en se présentant comme 
Orange.
Il est probable qu’Orange ait lancé une campagne sur les numéros d’anciens 
clients.

Même si la démarche d’Orange était parfaitement légale (ce qui reste à 
vérifier), il peut être intéressant de prévenir vos clients car l’argumentaire 
et les propositions de ce call-center sont, comme vous pouvez l’imaginer, 
pathétiques voir dangereux pour une société qui se laisserait abuser, parce 
qu’elles ne tiennent pas compte des besoins réels du client, ni de l’impact 
possible sur les autres services s’il signe le devis dans un moment d’égarement.

Histoire de voir si vous êtes concernés, le call-center (qui d’ailleurs sévit 
dans d’autres domaines que les telecoms) appelle avec ces numéros là:
0180487640
0170651330
0176547126

Nous avons même le sentiment que le call-center exploite le fichier Orange pour 
proposer d’autres services qui n’ont rien à voir avec Orange mais cela reste à 
confirmer.

Bonne recherche dans vos CDR :)


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

Re: [FRnOG] [BIZ] Alerte au démarchage en masse par un call-center en Afrique du Nord pour le compte d'Orange

2016-02-02 Par sujet Jonathan Leroy 
Le 2 février 2016 à 17:45, David Ponzone  a écrit :
> Afin de faire des recoupements avec des confrères, voilà une information qui 
> peut vous intéresser.
> Nous avons remarqué "par hasard" que depuis quelques temps, un call-center en 
> Tunisie appelle beaucoup de numéros que nous avons portés (attributaires 
> Orange) pour faire des devis Orange à nos clients, en se présentant comme 
> Orange.
> Il est probable qu’Orange ait lancé une campagne sur les numéros d’anciens 
> clients.

C'est marrant, j'ai justement reçu un appel ce matin d'une personne au
fort accent portugais (?) concernant un vieux 0 811 que je n'utilise
quasiment plus : https://1fichier.com/?k108j0pl23

L'appel provenait du 0186229002 (DirectVox, http://www.directvox.fr/).

Ce n'est pas la première fois qu'un opérateur douteux m'appelle
concernant ce numéro, mais ils appellent toujours sur mon portable
perso, qui n'est utilisé nulle part... sauf chez Keyyo (l'opérateur
chez lequel se trouve ce numéro).
Comment peuvent-ils récupérer ce numéro ? Auprès de l'ARCEP ? C'est légal ?

-- 
Jonathan Leroy.


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

Re: [FRnOG] [TECH] Boitier Conférence Skype ?

2016-02-02 Par sujet Alain Bieuzent 
Le 01/02/2016 17:26, SIMANCAS Hugo a écrit :
> Bonjour,
>
> Connaissez-vous un boitier sympa pour de la réunion éloignée sous Skype ou 
> autre ?
> Caméra intelligente grand Angle + interface d'appel ?
>
> Merci d'avance
>
> Hugo
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
Si la vidéo n'est pas indispensable et que tu veut l'utiliser aussi pour
du SIP, je vient de commander ça :
http://www.ipandgo.com/fr/audio-conference/971-grandstream-gac2500.html
je la reçoit dans 48h00 ...

Alain


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