Problème de MTU/MSS…

  • Partie signficative de la configuration du routeur Cisco (C851-K9 juste pour information, cela n’a aucune importance dans la résolution du problème):
    CI-174-plop#sh run int vlan 1
    Building configuration...
    
    Current configuration : 169 bytes
    !
    interface Vlan1
     description **** LAN ****
     ip address 1.1.1.1 255.255.255.248
     no ip redirects
     no ip proxy-arp
     ip tcp adjust-mss 1420
     load-interval 30
    end
    
    CI-174-plop#sh run int dial 1
    Building configuration...
    
    Current configuration : 257 bytes
    !
    interface Dialer1
     mtu 1460
     ip address negotiated
     no ip redirects
     encapsulation ppp
     ip tcp adjust-mss 1420
     dialer pool 1
     dialer-group 1
     ppp authentication chap pap callin
     ppp chap hostname B8756-04515-781@fournisseur.wireless
     ppp chap password 0 032004439900435DFDF
    
    • 1.1.1.1/30 est un subnet d’adresses IP publiques (récemment alloué /8)
    • La session PPP s’établit correctement et aucun problème de transit n’est établit.

    La configuration du routeur Cisco ne peut être changée.

  • nas-plop est un routeur Linux de configuration :

    • Adresse IP : 1.1.1.2/30
    • Gateway : 1.1.1.1/30
    • Tunnel GRE opérationnel entre nas-X et core2
      nas-plop # ip addr show dev toCORE2
      5: toCORE2@NONE:  mtu 1476 qdisc noqueue
          link/gre 1.1.1.2 peer a.b.c.1
          inet 192.168.32.18/30 brd 192.168.32.19 scope global infosat
      nas-plop # ip route show table 102
      a.b.c.0/24 dev toCORE2  scope link
      nas-plop # ip rule
      0:      from all lookup local
      32763:  from 172.21.31.1/24 lookup 102
      32766:  from all lookup main
      32767: from all lookup default
      nas-plop # iptables -t nat -L -n -v
      Chain PREROUTING (policy ACCEPT 34M packets, 2374M bytes)
       pkts bytes target     prot opt in     out     source               destination
      
      Chain POSTROUTING (policy ACCEPT 270K packets, 20M bytes)
       pkts bytes target     prot opt in     out     source               destination
        22M 1418M SNAT       all  --  *      *       172.21.31.0/24    !a.b.c.0/24  to:1.1.1.2
      
      Chain OUTPUT (policy ACCEPT 58921 packets, 5450K bytes)
       pkts bytes target     prot opt in     out     source               destination
      
    • La connectivité IP vers le net est fonctionnel pour le LAN derrière le routeur nas-plop
  • La configuration du routeur core2 (routeur Linux lui aussi) est :

    • connectivité à internet bien entendue : OK
    • Tunnel entre core2 et nas-plop est opérationnelle
      core2 # ip addr show dev plop
      20: plop@NONE:  mtu 1476 qdisc noqueue
          link/gre a.b.c.1 peer 1.1.1.2
          inet 192.168.32.17/30 scope global plop
      core2 # ip route get 172.21.31.1
      172.21.31.1 dev plop  src 192.168.32.17
          cache  mtu 1476 advmss 1436 metric 10 64
      

L’ensemble fonctionne au niveau IP:

clucas@pluton:~$ ping 172.21.31.2
PING 172.21.31.2 (172.21.31.2) 56(84) bytes of data.
64 bytes from 172.21.31.2: icmp_seq=1 ttl=62 time=56.3 ms
64 bytes from 172.21.31.2: icmp_seq=2 ttl=62 time=59.9 ms
^C
--- 172.21.31.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 56.375/58.148/59.922/1.789 ms
clucas@pluton:~$ traceroute 172.21.31.2
traceroute to 172.21.31.2 (172.21.31.2), 64 hops max, 40 byte packets
 1  a.b.c.1  0 ms  0 ms  0 ms
 2  1.1.1.2  55 ms  39 ms  45 ms
 3  172.21.31  58 ms  52 ms  54 ms
clucas@pluton:~$

Néanmoins, les clients se plaignent que le service vers le subnet a.b.c.0/24 n’est pas optimal.

Que faire ? (Bien entendu j’ai une solution. Cette solution tient en trois commandes (deux sur le routeur feuille(nas-plop) et une sur core2).

12 comments on “Problème de MTU/MSS…

  • interface Vlan1
    description **** LAN ****
    ip address 1.1.1.1 255.255.255.248

    Attention, 1.0.0.0/8 vient d'être attribué par l'ICANN 😉

  • @shaddai: Ouais, je sais bien. Mais pas envie de mettre les véritables adresses IP. Et dans tous les cas, ceux sont des adresses IP publiques qui sont fournies et routées sur le routeur et donc vlan 1.
    Juste que ce n'est pas le véritable /29.

    Amicalement,
    Christophe

  • Mdr 🙂 J'en conclus qu'il n'y a pas bcp de lecteurs de ce blog!! Personne ne peut répondre ou en a envie 🙁

    A+ les gens,

  • je répondrais bien que pour la partie nas-plop il faut clamper le mss au mtu avec iptables pour le tunnel GRE.
    Après sur la partie core, je ne sais pas trop 🙂

  • Justement, quelle doit être la valeur du MTU du tunnel GRE ? A quelle valeur doit-on clamper le MSS ? au MTU ? Valeur fournie par notre fournisseur ?

  • Tu enlèves 20(IP) + 4(GRE) au MTU du tunnel GRE ? soit 1476 – 24 ? Dans ce cas de figure, cela ne fonctionnera pas, car 1476 > 1460 (MTU fixé par le fournisseur). Pour qu'il n'y ait pas de soucis (vérifier en pratique du moins), il faut que la MTU du tunnel GRE soit de 1460 – 20 – 4 = 1436.

    Soit sur le routeur feuille :
    1/ iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –set-mss 1420
    2/ ip link set toCORE2 mtu 1436

    Sur le routeur 'core2' :
    ip link set plop mtu 1436

    Désolé, il était un peu nul mon challenge 🙁

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.