[c-nsp] transport path-mtu-discovery - ME3600....too unpredictable to use?

[Dan Peachey]

On 24/02/2016 10:33, Nick Cutting wrote:
> Im an enterprise guy, so this is what I see for our clients.
>   I don't have exact info but if for example a TCP sessions stays up between two end hosts (whether they are routers or windows boxes whatever..) and a path changes from say a P2P to a routed VPN, quick enough that the tcp session between the endpoints doesn't time out (I hope so) - the MSS is NOT recalculated as, it is only set in the TCP handshake - which is what Adam is referring to when you set the MSS on the interface.
>
> The exact path mtu discovery technique doesn't seem to be well documented - the RFC is 26 years old - and unless your hosts are actively "checking" mtu using DF bit the whole time a session is up (for changes)  - I don't believe even half of  RFC-1191 is implemented in the real world.
>
> If someone has knowledge of how cisco routers do it exactly - I would love to hear.
>

They do appear to set DF bit on every IP packet (at least on a CSR1000v 
this is true).

Packet dump shows DF being set on BGP keepalives:

dan at fluff:~$ sudo tcpdump -i virbr13 -v 'ip && tcp port 179'
tcpdump: listening on virbr13, link-type EN10MB (Ethernet), capture size 
262144 bytes
11:06:36.922464 IP (tos 0xc0, ttl 63, id 1770, offset 0, flags [DF], 
proto TCP (6), length 59)
     172.16.0.6.59175 > 172.16.0.5.bgp: Flags [P.], cksum 0x4b81 
(correct), seq 3523842787:3523842806, ack 1374955837, win 16384, length 
19: BGP, length: 19
         Keepalive Message (4), length: 19
11:06:37.651918 IP (tos 0xc0, ttl 63, id 1771, offset 0, flags [DF], 
proto TCP (6), length 40)
     172.16.0.6.59175 > 172.16.0.5.bgp: Flags [.], cksum 0x4f89 
(correct), ack 20, win 16384, length 0
11:06:39.991295 IP (tos 0xc0, ttl 253, id 1831, offset 0, flags [DF], 
proto TCP (6), length 59)
     172.16.0.3.bgp > 172.16.0.5.53016: Flags [P.], cksum 0xe427 
(correct), seq 579671816:579671835, ack 1679671767, win 16384, length 
19: BGP, length: 19
         Keepalive Message (4), length: 19


Whether they act on receiving an ICMP Frag Needed packet by decreasing 
the MSS of the BGP TCP session is another question. When I get time I'll 
try and test it.

Cheers,

Dan