[clue] a networking riddle

[Quentin Hartman]

Well, what do the logical groupings of servers have to do with the network
topology? What exactly lies between server A and B? Are there any weird
tunnels? Do all the switches support jumbo frames? All the routers
correctly translating between networks?

MTU is a fiddly thing, and if every device in the path isn't correctly
configured you will get weird behavior.

QH


On Mon, Oct 14, 2013 at 3:57 PM, Mike Bean <beandaemon at gmail.com> wrote:

> Well, I don't mean OU in the windows sense, I mean logical groupings of
> servers.  Clusters.   I'm trying to get my head around this, because
> intuitively, it just doesn't make any sense.
>
> If you're coming home from the grocery store, and you have more groceries
> then you can carry, you make multiple trips to the car.
>
> but I don't think it's quite that simple.  Think networks aren't as smart
> as I think they are,  intuitively, something configured to send as 1500,
> should be able to receive 1500 only, not necessary 9000, but something
> that's configured as 9000 should be able to send and receive as 9000 or
> 1500.   (scratches head.)
>
> In actuality, B (9000) can send to A (1500)
> and A (1500) can send to B (9000)
>
> but if we set A to 9000, it can no longer send to B (9000)
> (scratches head)
>
> Boy, if you know someone who's in school looking for a secure job, tell
> them to become a network person.    REALLY GOOD network people are worth
> their weight in gold.
>
>
> On Mon, Oct 14, 2013 at 3:26 PM, Quentin Hartman <qhartman at gmail.com>wrote:
>
>> By OU, do you mean broadcast domain? ie - two LANs connected by a router?
>> If so, it sounds like you have the (usually default) MTU of 1500 set on
>> side A, but the 9000 set on B, and your router isn't correctly doing MTU
>> management when crossing from one to the other.
>>
>> Going the other way works because the fragments are already small enough
>> to be handled correctly at the other end. The complexity of making this
>> work reliably is the primary reason so few people bother to use jumbo
>> frames, even though they technically are better most of the time anymore.
>>
>> The wikipedia article on MTU is actually pretty good:
>> http://en.wikipedia.org/wiki/Maximum_transmission_unit
>>
>> QH
>>
>>
>> On Mon, Oct 14, 2013 at 3:15 PM, Mike Bean <beandaemon at gmail.com> wrote:
>>
>>>
>>> So I've been scratching my head for a long time trying to understand
>>> this, and it makes no sense to me.   We have to discrete OU's.   SCP
>>> transmissions of any real size tend to fail from A to B, but not from B to
>>> A.
>>>
>>> My colleagues have been arguing that the fix is to set the MTU at side B
>>> to 1500.  And Lo, and behold, when we do, it works, increase the MTU to
>>> 9000, and it fails again.
>>>
>>>
>>> http://unix.stackexchange.com/questions/14187/why-does-scp-hang-on-copying-files-larger-than-1405-bytes
>>>
>>> What I have difficulty understanding, is if a jumbo frame carries, say,
>>> 9000 bytes, and hypothetically, if it's a 5,000 bytes file + your MTU =
>>> 1500, which means you split it up into 3 transmissions.
>>>
>>> Same size transmission; capped packet size,  more packets.   So I would
>>> naturally conclude that at an MTU of 9000 it could get done in 1 what an
>>> MTU of 1500 would do in 3?
>>>
>>> (scratches head)
>>>
>>> _______________________________________________
>>> clue mailing list: clue at cluedenver.org
>>> For information, account preferences, or to unsubscribe see:
>>> http://cluedenver.org/mailman/listinfo/clue
>>>
>>
>>
>> _______________________________________________
>> clue mailing list: clue at cluedenver.org
>> For information, account preferences, or to unsubscribe see:
>> http://cluedenver.org/mailman/listinfo/clue
>>
>
>
> _______________________________________________
> clue mailing list: clue at cluedenver.org
> For information, account preferences, or to unsubscribe see:
> http://cluedenver.org/mailman/listinfo/clue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20131014/4fccd9b6/attachment-0001.html