Affichage des articles dont le libellé est MPLS. Afficher tous les articles
Affichage des articles dont le libellé est MPLS. Afficher tous les articles

mardi 6 septembre 2016

Projet Universitaire : Accès Internet

Considérons maintenant l'accès Internet des différents bâtiments.

Je n'ai malheureusement pas de bonnes solutions à proposer .... Je vais vous expliquer pourquoi.


Plan A :


On pourrait concevoir une architecture comme celle-ci :


Le routeurs IPv6/IPv4 seraient les points d'entrée du réseau avec une configuration NAT et ZBF par exemple. Le problème ici est que IBGP et VRF ne fonctionnent correctement sur un routeur qu'à partir d'une version 15.4 d'IOS; en effet la commande neighbor internal-vpn-client est implémentée.
N'ayant qu’une version 15.2, je me retrouve bloqué ....


Voici le plan B : 



On considère que le service Internet provient d'une autre AS.
La configuration de BGP dans ce cas se fait bien .


Configuration de PE1 :

router bgp 4294
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
.......
 neighbor 172.168.2.2 remote-as 4294
 neighbor 172.168.2.2 transport multi-session
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
........
 exit-address-family
 !
 address-family vpnv6
.......
 exit-address-family
 !
 address-family ipv4 vrf INTERNET
  neighbor 172.168.2.2 remote-as 4295
  neighbor 172.168.2.2 transport multi-session
  neighbor 172.168.2.2 activate
  neighbor 172.168.2.2 next-hop-self
 exit-address-family


L'interface f1/1 étant configurée dans la CRF Internet, la désignation du neighbor distant va s'effectuer dans address-family ipv4 vrf INTERNET.


Configuration de IPv4/IPv6 :

 router bgp 4295
 bgp log-neighbor-changes
 neighbor 172.168.2.1 remote-as 4294
 neighbor 172.168.2.1 transport multi-session
 !
 address-family ipv4
  network 82.82.82.82 mask 255.255.255.255
  neighbor 172.168.2.1 activate
 exit-address-family


Dans le cas de ce routeur rien de particulier. J'ai créé une interface de loopback 82 pour pouvoir visualiser la propagation du réseau à travers le réseau MPLS.

Si on observer un CE comme Data Center :

      82.0.0.0/32 is subnetted, 1 subnets
D EX     82.82.82.82
           [170/2560002816] via 172.168.2.1, 00:20:30, FastEthernet0/0

      100.0.0.0/32 is subnetted, 1 subnets
D EX     100.100.100.100
           [170/2560002816] via 172.168.2.1, 00:20:30, FastEthernet0/0
      172.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.168.2.0/30 is directly connected, FastEthernet0/0
L        172.168.2.2/32 is directly connected, FastEthernet0/0




La relation EBGP entre PE1 et IPv4/IPv6 est donc opérationnelle.
Cela amène néanmoins un problème. En effet, nos routeurs CE ne doivent pas contenir la totalité des tables de routage d'Internet ! Étant des machines limitées physiquement, il nous faut trouver une parade.

Nous configurons une route statique pointant vers PE2 sur le routeur A_S_A.

ip route 0.0.0.0 0.0.0.0 209.168.35.2

De plus, nous retirons la redistribution de protocole existante de BGP dans chaque process EIGRP.



Mais où configurer le NAT ?

Il n'y a ici pas le choix, il doit être configuré sur les CE. Cela implique un changement d'adresse, il faut en effet que celle ci soit publique entre le PE et le CE. J' ai expliqué précédemment que de part l'utilisation de VRF, cette adresse pouvait être identique sur toutes les liaisons PE-CE, ici avec le NAT ce ne sera plus le cas.

Par flemme, je ne vais reconfigurer qu'un nombre restreint de routeurs.

Voici la configuration de A_S_A :




interface FastEthernet0/0
 description Vers_PE2
 ip address 209.168.35.1 255.255.255.252
 ip nat outside
 ip virtual-reassembly in
 duplex full
!
interface FastEthernet1/0
 ip address 192.168.10.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 duplex full
 speed auto
!
router eigrp 20
 network 192.168.10.0
 network 209.168.35.0 0.0.0.3

!
ip nat inside source list NAT interface FastEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 209.168.35.2
!
ip access-list standard NAT
 permit 192.168.1.0 0.0.0.255


Pour résumer :



Dernier point de détail

Comme vous pouvez le voir dans la conf, le réseau du Lan du bâtiment (192.168.10.0/24) est annoncé sur MP-BGP. Pour éviter que celui-ci "sorte sur Le Net", nous filtrons les MAJ BGP de PE1 vers IPv4/IPv6.

router bgp 4294
 bgp log-neighbor-changes
.....
 !
 address-family ipv4

 !
 address-family vpnv
.......

 !
 address-family vpnv6
.........
 !
 address-family ipv4 vrf INTERNET
  neighbor 172.168.2.2 remote-as 4295
  neighbor 172.168.2.2 transport multi-session
  neighbor 172.168.2.2 activate
  neighbor 172.168.2.2 next-hop-self
  distribute-list LAN out
 exit-address-family
 !
 address-family ipv6 vrf INTERNET
......
!
ip access-list standard LAN
 deny   192.168.0.0 0.0.255.255
 permit any


On interdit aux réseaux LAN d'être annoncés à l'extérieur.

Du point de vue de IPv4/IPv6, on observe :

Gateway of last resort is not set

      82.0.0.0/32 is subnetted, 1 subnets
C        82.82.82.82 is directly connected, Loopback82
      172.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.168.2.0/30 is directly connected, FastEthernet0/0
L        172.168.2.2/32 is directly connected, FastEthernet0/0
      209.168.35.0/30 is subnetted, 2 subnets
B        209.168.35.0 [20/0] via 172.168.2.1, 01:36:11
B        209.168.35.4 [20/0] via 172.168.2.1, 00:45:02
      211.12.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        211.12.1.0/30 is directly connected, FastEthernet1/0
L        211.12.1.2/32 is directly connected, FastEthernet1/0

Seules les adresses RSO de NAT apparaissent
En vert : j'ai fais la même manip avec le routeur Data Center.


Test depuis Client 1

On test notre surf en pingant une adresse de loopback 82.82.82.82 :



Voilà pour cette "solution" Internet. Comme annoncé en début d'article, je n'en suis pas particulièrement content, le design étant selon moi un pourri.

Si jamais vous avez des idées .....

La prochaine fois nous clôturons cette série d'articles par la mise en place de tunnels VPN entre le routeur A_S_A et Data Center.


Architecture GNS3/Concepts généraux
Mise en place du Cloud MPLS
VRF
Routage, IPV6 et addess-familly
Mise en Place de MP-BGP
Les trucs qui fâchent



Bon clic à tous,


lundi 2 mai 2016

Projet universitaire : Configuration de MP-BGP

Nous y sommes presque !


Petite récap : Nous avons configuré le protocole MPLS entre nos différents routeurs du Cloud, configuré EIGRP entre nos PE et nos clients, mis en place nos VRF sur nos PE.

On va maintenant configurer un tunnel VPN grâce à MP-BGP à travers notre cloud MPLS. Pour rappel, on pourra faire transiter de l'IPv4 mais aussi du V6 comme demandé dans le sujet.



Sur le schéma :


En vert les routeurs PE on l'on va configurer MP-BGP
En bleu un routeur MPLS du Cloud pour qui MP-BGP sera transparent
Nos clients A_S_A et B_S_A qui vont pouvoir communiquer entre eux. Pour ce faire je configure une interface de loopback 100 sur A_S_A et je déclare celle-ci dans mon process EIGRP. Je configure également une adresse de loopback sur A_F_S.


BGP est compliqué à souhait et je dois avouer ne pas en maîtriser tous les rouages. Pour de plus amples informations, consulter cet excellent site :

Top du Top sur MP_BGP

Vous serez incollables sur la théorie de MPLS, VRF, MP_BGP ..... 

Configuration de PE2

 

 

 L'AS BGP est 4294
On défini dans un premier temps nos voisins, avec la source des MAJ (ici la loopback 20)

On configure ensuite une addresse-family vpnv4 : comme son nom l'indique, elle sert à définir les tunnels VPN entre nos routeurs PE.

On configure des address-family liées à nos VRF pour pouvoir redistribuer EIGRP dans BGP.

router bgp 4294
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.10.10.10 remote-as 4294
 neighbor 10.10.10.10 update-source Loopback20
 neighbor 30.30.30.30 remote-as 4294
 neighbor 30.30.30.30 update-source Loopback20
 neighbor 40.40.40.40 remote-as 4294
 neighbor 40.40.40.40 update-source Loopback20
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
  neighbor 30.30.30.30 activate
  neighbor 30.30.30.30 send-community extended
  neighbor 40.40.40.40 activate
  neighbor 40.40.40.40 send-community extended
 exit-address-family
 !
 address-family vpnv6
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
  neighbor 30.30.30.30 activate
  neighbor 30.30.30.30 send-community extended
  neighbor 40.40.40.40 activate
  neighbor 40.40.40.40 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf A_F_S
  redistribute eigrp 20 metric 1000
 exit-address-family
 !
 address-family ipv6 vrf A_F_S
  redistribute eigrp 20 metric 1000
 exit-address-family
 !
 address-family ipv4 vrf A_S_A
  redistribute eigrp 20 metric 1000
 exit-address-family



On retrouve exactement le même principe sur PE1,3 et 4.
Une redirection de BGP est configurée dans EIGRP sur les PE.

On observe :


PE2#sh ip bgp vpnv4 all
BGP table version is 7, local router ID is 20.20.20.20
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 2:1 (default for vrf A_S_A)
 *>  100.100.100.100/32
                       172.168.2.2           1000         32768 ?
 r>i 172.168.2.0/30   30.30.30.30              0    100      0 ?
 r                    0.0.0.0                  0         32768 ?
Route Distinguisher: 2:2
 *>i 172.168.2.0/30   30.30.30.30              0    100      0 ?
Route Distinguisher: 3:1 (default for vrf A_F_S)
 *>  172.168.2.0/30   0.0.0.0                  0         32768 ?
 *>  200.200.200.200/32
                       172.168.2.2           1000         32768 ?


Voici les tables de routages de PE2 :


PE2(config-router)#do sh ip route

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 192.168.1.13, 00:21:12, FastEthernet0/0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/2] via 192.168.1.17, 00:21:02, FastEthernet1/0
      20.0.0.0/32 is subnetted, 1 subnets
C        20.20.20.20 is directly connected, Loopback20
      30.0.0.0/32 is subnetted, 1 subnets
O        30.30.30.30 [110/3] via 192.168.1.17, 00:21:02, FastEthernet1/0
                     [110/3] via 192.168.1.13, 00:21:02, FastEthernet0/0
      40.0.0.0/32 is subnetted, 1 subnets
O        40.40.40.40 [110/3] via 192.168.1.17, 00:21:02, FastEthernet1/0
                     [110/3] via 192.168.1.13, 00:21:02, FastEthernet0/0
      192.168.1.0/24 is variably subnetted, 11 subnets, 2 masks
O        192.168.1.0/30 [110/2] via 192.168.1.17, 00:21:02, FastEthernet1/0
                        [110/2] via 192.168.1.13, 00:21:12, FastEthernet0/0
O        192.168.1.4/30 [110/2] via 192.168.1.13, 00:21:12, FastEthernet0/0
O        192.168.1.8/30 [110/2] via 192.168.1.17, 00:21:02, FastEthernet1/0
C        192.168.1.12/30 is directly connected, FastEthernet0/0
L        192.168.1.14/32 is directly connected, FastEthernet0/0
C        192.168.1.16/30 is directly connected, FastEthernet1/0
L        192.168.1.18/32 is directly connected, FastEthernet1/0
O        192.168.1.20/30 [110/2] via 192.168.1.13, 00:21:02, FastEthernet0/0
O        192.168.1.24/30 [110/2] via 192.168.1.17, 00:21:02, FastEthernet1/0
O        192.168.1.28/30 [110/2] via 192.168.1.13, 00:21:02, FastEthernet0/0
O        192.168.1.32/30 [110/2] via 192.168.1.17, 00:21:02, FastEthernet1/0


PE2#sh ip route vrf A_S_A

      100.0.0.0/32 is subnetted, 1 subnets
D        100.100.100.100
           [90/2662400] via 172.168.2.2, 00:23:00, FastEthernet2/0

      172.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.168.2.0/30 is directly connected, FastEthernet2/0
L        172.168.2.1/32 is directly connected, FastEthernet2/0


PE2#sh ip route vrf A_F_S

      172.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.168.2.0/30 is directly connected, FastEthernet2/1
L        172.168.2.1/32 is directly connected, FastEthernet2/1
      200.200.200.0/32 is subnetted, 1 subnets
D        200.200.200.200
           [90/103040] via 172.168.2.2, 00:34:14, FastEthernet2/1


Sur notre client :





 B_S_A#sh ip route

      100.0.0.0/32 is subnetted, 1 subnets
D EX     100.100.100.100
           [170/2560002816] via 172.168.2.1, 00:13:15, FastEthernet0/0

      172.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.168.2.0/30 is directly connected, FastEthernet0/0
L        172.168.2.2/32 is directly connected, FastEthernet0/0


....... l'adresse IP de la loopback configurée sur A_S_A ..... mais pas la 200.200.200.200 configurée sur A_F_S .....


C'est pas mal ..... mais il est possible de faire mieux. Comme on peut le voir, notre route est marquée comme Externe avec un métric très élevé. Nous allons modifier les numéros d'AS EIGRP configurées sur PE3 de 30 à 20.

PE3 :


router eigrp 30
 !
 address-family ipv4 vrf B_F_L autonomous-system 30
  redistribute bgp 4294 metric 1 1 1 1 1
  network 172.168.2.0 0.0.0.3
 exit-address-family
 !
 address-family ipv4 vrf B_S_A autonomous-system 20
  redistribute bgp 4294 metric 1 1 1 1 1
  network 172.168.2.0 0.0.0.3
 exit-address-family


Attention !!!!! Ici la commande router eigrp 30 fait référence au process nommé 30 ! Je créer alors 2 AS différentes dans ce process la 20 et la 30. 

On modifie également notre configuration sur B_S_A : 


router eigrp B_S_A
 !
 address-family ipv4 unicast autonomous-system 20
  !
  topology base
  exit-af-topology
  network 172.168.2.0 0.0.0.3
 exit-address-family

 

Si on observe maintenant notre table de routage :



B_S_A#sh ip route

      100.0.0.0/32 is subnetted, 1 subnets
D        100.100.100.100
           [90/153600] via 172.168.2.1, 00:09:01, FastEthernet0/0

      172.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.168.2.0/30 is directly connected, FastEthernet0/0
L        172.168.2.2/32 is directly connected, FastEthernet0/0


Le Ex a disparu et ce grâce à l'utilisation du même numéro d'AS à la fois sur A_S_A et B_S_A. C'est d'ailleurs plus logique si l'on considère comme transparente toute la bulle MPLS aux yeux du client .


On peut maintenant se focaliser sur l'accès Internet de l'université !


Architecture GNS3/Concepts généraux
Mise en place du Cloud MPLS
VRF
Routage, IPV6 et addess-familly
Mise en Place de MP-BGP
Les trucs qui fâchent

Bon clic à tous,



vendredi 22 avril 2016

Projet : configuration du Cloud

Le Cloud MPLS


Comme indiquer en intro, notre Cloud va supporter MPLS et pas mal d'autre protocoles.
Le soucis avec MPLS (en tous cas le mien) est que tout seul, ça ne fait pas grand chose. Dans ce projet, MPLS sera couplé à MP-BGP (transit des rd), LDP (pour les indicatifs) et OSPF.

Comme précisé plus haut ma configuration sera basée sur LDP et non pas sur RSVP (je verrais plus tard pour monter un autre Lab) qui se base lui même sur OSPF.

Quelques notions d'écriture :


P1 et P2 : routeurs du Cloud faisant transiter le trafic en utilisant les Labels MPLS. Très facile a configurer, ils sont complétement transparents par la suite pour MP-BGP

PE1,2... : Provider Edge Router. La majorité de la configuration va se faire sur ces équipements : VRF, MPLS,BGP, ...

A_S_A, ... : Customer Router. Ne participe pas a MPLSet VRF. Le protocole de routage configuré entre CE et PE dans ce lab et EIGRP.



Pour ceux qui veulent découvrir la théorie du complot, j ai trouve un excellent résumé du fonctionnement de MPLS à cette adresse :

http://www.memoireonline.com/03/11/4293/m_Mise-en-oeuvre-dun-coeur-de-reseau-IPMPLS7.html

Si vous voulez plus complet mais en anglais :

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t2/ftldp41.html



Voici les différents réseaux configurés entre les routeurs :

P1-P2 192.168.1.0/30
P1-PE1 192.168.1.4/30
P2-PE1 192.168.1.8/30
P1-PE2 192.168.1.12/30
P2-PE2 192.168.1.16/30
P1-PE3 192.168.1.20/30
P2-PE3 192.168.1.24/30
P1-PE4 192.168.1.28/30
P2-PE4 192.168.1.32/30

De plus on configure une interface de loopback sur chaque équipement
P1 : 1.1.1.1
P2 : 2.2.2.2
PE1 : 10.10.10.10
PE2 : 20.20.20.20
PE3 : 30.30.30.30
PE4 : 40.40.40.40

Ces valeurs seront les router_id des différents protocoles de routage. Elles ont été choisi de façon arbitraire et non pas de manière à privilégier tel ou tel é&équipement dans une fonction de DR.

Mise en place de l' IGP

Une petite aire 0 et hop, OSPF est configuré entre les différents PE et P. Oui bon, c'est un peu plus long car il y a pas mal d'interfaces à configurer ....

Voici la configuration de PE2 :

router ospf 10
 network 20.20.20.20 0.0.0.0 area 0
 network 192.168.1.0 0.0.0.255 area 0


Oui, la loopback est routée et vous verrez pourquoi un peu plus loin !

MPLS


On va vérifier que ip cef est bien actif sur chaque routeur via la commande ip cef. On prend aussi le temps de configurer ipv6 cef et ipv6 unicast routing sur les PE.

On va activer la prise en charge de MPLS via LDP grâce a la commande mpls label protocol ldp. On active dans un même temps la remontée de log via mpls ldp logging neighbors-change

On configure les interfaces participant à MPLS via la commande mpls ip
L'interface connectant le client ne participe PAS a MPLS, uniquement les liaisons intra backbone sont à configurer de la sorte.

Pour les accros a la sécurité il est possible de paramétrer un mot de passe pour le protocole LDP (mais non réalisé ici)

PE2 :


no ip domain lookup
ipv6 unicast-routing
ipv6 cef
!
multilink bundle-name authenticated
mpls label protocol ldp
!

crypto pki token default removal timeout 0
!
!
interface Loopback20
 ip address 20.20.20.20 255.255.255.255
 ipv6 enable
!
interface FastEthernet0/0
 description Vers_P1
 ip address 192.168.1.14 255.255.255.252
 duplex auto
 speed auto
 mpls ip



Nos voisins LDP sont ainsi découverts :


PE2#show mpls ldp discovery
 Local LDP Identifier:
    192.168.1.18:0
    Discovery Sources:
    Interfaces:
        FastEthernet0/0 (ldp): xmit/recv
            LDP Id: 192.168.1.13:0; no host route
        FastEthernet1/0 (ldp): xmit/recv
            LDP Id: 192.168.1.33:0; no host route




 !! Bon j'ai mal configuré PE2 .... le LDP identifier devrait être la loopback 20 !!! Cela vient du fait de l'oublie de la commande mpls ldp router-id loopback 20

Après rectification et un clear mpls ldp nei *, on arrive sur :

 Local LDP Identifier:
    20.20.20.20:0
    Discovery Sources:
    Interfaces:
        FastEthernet0/0 (ldp): xmit/recv
            LDP Id: 1.1.1.1:0
        FastEthernet1/0 (ldp): xmit/recv
            LDP Id: 2.2.2.2:0


PE2#sh mpls ldp nei
    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 20.20.20.20:0
        TCP connection: 1.1.1.1.646 - 20.20.20.20.40235
        State: Oper; Msgs sent/rcvd: 29/28; Downstream
        Up time: 00:10:36
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 192.168.1.13
        Addresses bound to peer LDP Ident:
          192.168.1.13    1.1.1.1         192.168.1.5     192.168.1.1
          192.168.1.21    192.168.1.29
    Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 20.20.20.20:0
        TCP connection: 2.2.2.2.646 - 20.20.20.20.62785
        State: Oper; Msgs sent/rcvd: 18/17; Downstream
        Up time: 00:01:21
        LDP discovery sources:
          FastEthernet1/0, Src IP addr: 192.168.1.17
        Addresses bound to peer LDP Ident:
          192.168.1.25    2.2.2.2         192.168.1.9     192.168.1.33
          192.168.1.17    192.168.1.2


Ainsi que les différents labels :



PE2#sh mpls ldp bin
  lib entry: 1.1.1.1/32, rev 28
        local binding:  label: 16
        remote binding: lsr: 1.1.1.1:0, label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 20
  lib entry: 2.2.2.2/32, rev 30
        local binding:  label: 17
        remote binding: lsr: 1.1.1.1:0, label: 16
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 20.20.20.20/32, rev 6
        local binding:  label: imp-null
        remote binding: lsr: 1.1.1.1:0, label: 20
        remote binding: lsr: 2.2.2.2:0, label: 19
  lib entry: 30.30.30.30/32, rev 12
        local binding:  label: 19
        remote binding: lsr: 1.1.1.1:0, label: 19
        remote binding: lsr: 2.2.2.2:0, label: 18
  lib entry: 40.40.40.40/32, rev 10
        local binding:  label: 18
        remote binding: lsr: 1.1.1.1:0, label: 18
        remote binding: lsr: 2.2.2.2:0, label: 17
  lib entry: 192.168.1.0/30, rev 24
        local binding:  label: 25
        remote binding: lsr: 1.1.1.1:0, label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: imp-null
  lib entry: 192.168.1.4/30, rev 22
        local binding:  label: 24
        remote binding: lsr: 1.1.1.1:0, label: imp-null
        remote binding: lsr: 2.2.2.2:0, label: 22


 .........

On peut voir le label affecté par l'LSR local, le numéro de révision et les labels des deux LSR distants. Le fait d'avoir configuré une interface loopback par élément actif facilite la lecture des entrées.


Première phase terminée, c’était loin d être la plus difficile. On s attaque maintenant à la définition des VRF sur nos routeurs PE.



Architecture GNS3/Concepts généraux
Mise en place du Cloud MPLS
VRF
Routage, IPV6 et addess-familly
Mise en Place de MP-BGP
Les trucs qui fâchent