This is a classic MTU mismatch scenario. A la 1500 B Ethernet II frame vs 4000 B Token Ring frame. I would assume and expect that the routing stack would handle the 9000 B to 1500 B just the same as it would 4000 B to 1500 B. I think this means that the TCP packet in the 9000 B Jumbo Ethernet frame would be fragmented and sent as multiple 1500 B Ethernet frames. Assuming that the Don’t Fragment bit is not set. If it were set, I’d expect the router to return an ICMP error indicating that fragmentation is needed. I would be shocked if routing from 9000 B to 1500 B didn’t just work. N.B. I’m assuming that you’re using standard CIDR routing and not trying to use anything like proxy ARP. Though even that theoretically should work in that the P.A. router will frag / ICMP need frag as necessary to send TCP packets that will fit in the 1500 B frame. I think ~> expect. -- Grant. . . . unix || die > On Nov 23, 2022, at 5:15 PM, L A Walsh <lartc@xxxxxxxxx> wrote: > > My computers and switches handle 9k jumbo packets and file transfers go faster > between 2 computers using them, however, ran into a slight snag -- IOT (Internet of Things): things like media devices, TV, receiver, disc player -- all talk ethernet > @ 1.5k packet size. > > So I'm wondering, if I setup the devices on a separate subnet and route traffic from > my desktop into my server, and have a route to the devices that uses 1.5k packets, will the networking stack automatically marshal the 9k into 1.5k packets for data that gets sent to the 1.5k subnet? I'm guessing it won't automatically do the reverse, but that's not so important, since sending 1.5k packets to a 9k destination will just use the smaller packets -- its only when I send from a 9k packet enabled > network port to a 1.5k-talking device that I think problems occur (occasional random data loss and connection resets). Does it sound like that would work? > > I currently have a bridge on the server between 2 networks, one w/9k packets and the other with 1.5k packets and that seems to work fine -- I'm hoping that's not a coincidence(?) > > Thanks! > > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
