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

[Dragan Jovicic]

Large packet reaching smaller MTU is simply discarded.

If you establish BGP session over large MTU links, and then session
reroutes over smaller MTU link, you might see BGP Updates not passing
trough - while session is established due to smaller sized keepalives.
PMTU works only when establishing session. Therefore it is crucial to know
all possible paths your session might pass trough.

On Wed, Feb 24, 2016 at 12:13 PM, Dan Peachey <dan at peachey.co> wrote:

> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>