Re: Why packets (from my ISP to me) on the WAN VC side of my router are twice the size of packets on the Ethernet (and a corresponding twice as many bytes)
rhkramer@gmail.com wrote:
><resend of my original mail, without the repetition>
>
> IIUC, data that I download from Earthlink is labeled "Data Out" on the
> WAN VC side, and is labeled "Data In" on my LAN / Ethernet side.
"Possibly". I don't have either that service or that modem. However,
in general terms (on a linux-based device),
- "IN" refers to packets entering the device on one interface,
destined to be sent out another interface (e.g. IN eth0 and then out
eth1).
- "OUT" refers to packets exiting a given interface.
So, in your example with "WAN_VC" and "LAN" ...
- "LAN_IN" and "WAN_VC_OUT" are the flows for packets that you're
uploading to the internet. Funny cat pictures, that email you send
yourself, whatever.
- If you have them, "WAN_VC_IN" and "LAN_OUT" would be the packets
that you are downloading from the internet.
>
> The "anomaly" that I see is that there are twice as many bytes
> (octets) coming in (Data Out) on the WAN VC side as are going out to
> my LAN (Data In) on the Ethernet / LAN side.
>
> Now, the number of packets are about the same, and the difference
> mainly is that the packet size on the VC WAN "Data Out" are about
> twice the size of the packets on the Ethernet / LAN side.
Don't forget that the routing device itself will be generating traffic,
such as DNS lookups for you LAN clients, DHCP requests, etc. In
addition, if it's an ISP-supplied device, it may be providing other
metrics to them (signal quality, etc.)
>
> Aside: On data in the other direction (that is, to Earthlink), the
> number of bytes (octets), packets, and size of the packets are all
> about the same for the VC WAN and the Ethernet LAN.
>
> My questions are:
>
> * Why are there twice as many bytes measured coming in (from
> Earthlink) measured on the WAN VC side of the router as measured
> on the Ethernet / LAN side of the router (or, I guess the analagous
> question is why are the packets twice as big? (I mean, is the
> information encoded differently there or something?)
If you're looking at the "IN" lines for each interface, this could be as
simple as you're comparing the wrong entries (see above for "IN" vs.
"OUT").
>
> * And, can I do something to change that?
Typically, no. Though it really depends on the nature of the traffic
(i.e. where it's coming from / going to).
The following has been pulled from the message with ID
t81Pr-3N7-5@gated-at.bofh.it, so as to consolidate the disparate threads
that cropped up due to the formatting issues the question initially had.
><the stuff that should probably be ignored:>
> So, I guess the possibility that this suggests to me seems
> backwards--that is, the opposite of what I am seeing. I mean, if
> somewhere a 1500 byte packet has to be packed into a 1452 byte packet,
> I suppose something might double the size of the 1452 byte packet and
> just waste the leftover bytes in the two packets (i.e., 1452 * 2 -1500
> = 1404), but the packets are coming in on the WAN side presumably at
> 1452 bytes and I would think they would fit fine in the 1500 byte
> packet on the LAN side.
No, it wouldn't be a "packet" (L3) that's getting messed with, but
rather it's being caused by additional required header information in
the pppoe connection.
Your LAN side has a 1500 (1518, or 1522 for VLANs) byte max frame size,
with 64 bytes of the frame being reserved for the header.
Your WAN side has a 1492 byte max frame size, with those extra 8 bytes
being required pppoe header information. That is, the pppoe header is
72 bytes, rather than 64 of standard ethernet.
Now, just because there is a 1500 (1492) byte MTU doesn't mean that
every frame will be 1500 bytes. In many cases, they're a lot smaller,
so as long as you're under the 1492-byte limit of your pppoe connection,
you will always be sending (LAN Side) + 8 bytes.
--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Reply to: