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).