On 2013/07/10 12:40, Christopher Zimmermann wrote: > Hi, > > I'm still struggeling with my IPsec settup and routing. > This time I'm wondering how the third cloned route below was created. > > 172.26.153.0/28 link#1 UC 0 0 - 4 em0 > 172.26.153/24 link#5 UCS 1 0 - 9 > vether0 > 172.26.153.1 link#5 UHLc 3 180 - L 9 > vether0 > > The system works fine for hours with > > 172.26.153.1 00:0d:b9:24:60:40 UHLc 0 1 - 4 em0 > > as you would expect, then suddenly network connection breaks due to the > wrong routing decision you see above. Why? > > Christopher >
I believe this is pmtu blackhole detection, if you're losing packets on TCP then the stack disables path MTU discovery which I think shows up like this. (L in the MTU column = locked). One option for a workaround might be to totally disable pmtu. net.inet.ip.mtudisc=0 Not sure why it's cloning from the /24 rather than /28 but in general supernetting of connected interfaces is going to involve codepaths which aren't particularly well used..
