May someone explain to me how the "Firewall: inbound raw vs outbound encapsulated traffic" show that the encap data is bigger then the raw input ? may i misunderstand something ?
Ronen,
If you use the RAW firewall table to accept IPENCAP traffic, 3 major things happen:
- the RAW table accepts packets without the Kernel further processing them, basically, they should exit netfilter into kmod-ipip - if you use a program such as NetFLow (softflowd), it will not work - you must add the rule to the INPUT table (or otherwise mark them as tracked) if you wish to have records of the inbound outer headers - you will only see a firewall hit counter for the rule in the RAW table
Be advised that ampr-ripd running in raw mode also has this behavior, except that it skips netfilter on the outer header.
73,
- Lynwood KB3VWG
I've looked at the raw statistics and the differences are there; this is not a graphing error. I believe that the explanation is this:
Remember that encapsulating a packet makes it longer by the size of the added IP header, that is, by 20 bytes. The byte counts include the entire size of the packet, including all headers.
The outbound encap traffic packet count is slightly higher than the inbound that causes it because large incoming packets are fragmented into two packets after having grown in size by the addition of the second IPIP encapsulation header.
The byte count is significantly higher because the majority of the inbound traffic is connection requests i.e., packets that consist only of an IP and a UDP or TCP header, no data. Adding the IPIP header to this makes the packet significantly larger, increasing its byte count. - Brian
On Wed, May 17, 2017 at 08:25:26AM +0000, R P wrote:
May someone explain to me how the "Firewall: inbound raw vs outbound encapsulated traffic" show that the encap data is bigger then the raw input ? may i misunderstand something ?
On Wed, May 17, 2017 at 05:11:47AM -0700, Brian Kantor wrote:
I've looked at the raw statistics and the differences are there; this is not a graphing error.
The current numbers from the firewall statistics are
packets bytes rule - --------- ------------ --------------------------------------- 1 99130972 7130419875 divert 4444 ip from any to table(1) in 2 106320071 13106233508 allow ipencap from me to table(2) 3 37236164 39784403971 allow ipencap from table(2) to me 4 36966397 39023037420 allow ip from table(1) to any
Rule 1 is the inbound raw (unencapsulated) packets sent to the encapsulator.
Rule 2 is the outbound encapsulated packets coming out of the encapsulator.
Note the small increase in the number of packets between input and output, and the nearly doubling of the byte size. The graphs show this.
Rule 3 is the inbound encapsulated packets.
Rule 4 is the outbound raw (de-encapsulated) packets.
Note that the count and size of the output of rule 4 is slightly smaller than the input from rule 3. This is accounted for by the packets that are dropped in the router for errors in the packets. The graphs show this. - Brian
On Wed, May 17, 2017 at 05:39:10AM -0700, Brian Kantor wrote:
Note the small increase in the number of packets between input and output, and the nearly doubling of the byte size. The graphs show this.
Oops: I forgot: the outbound encap'd packets include the RIP transmissions which consist of 26 520 byte packets to each of 434 gateways every 5 minutes. - Brian
But what about the probbing from the internet and all the noise include to addresses that not registers in the ampr.org.dns ? is it filtered prior to the graphing and therefore not showd in the graphs ? if the answer yes can it be shown somehow also in a graph ?
________________________________
The byte count is significantly higher because the majority of the inbound traffic is connection requests i.e., packets that consist only of an IP and a UDP or TCP header, no data. Adding the IPIP header to this makes the packet significantly larger, increasing its byte count. - Brian
On Wed, May 17, 2017 at 08:25:26AM +0000, R P wrote:
May someone explain to me how the "Firewall: inbound raw vs outbound encapsulated traffic" show that the encap data is bigger then the raw input ? may i misunderstand something ?
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
It is rejected by the firewall and therefore shows up in the 'Inbound raw rejected' graphs. - Brian
On Wed, May 17, 2017 at 01:39:14PM +0000, R P wrote:
But what about the probbing from the internet and all the noise include to addresses that not registers in the ampr.org.dns ? is it filtered prior to the graphing and therefore not showd in the graphs ? if the answer yes can it be shown somehow also in a graph ?
Ronen, did you connect your camera and did its traffic show up in the graphs? - Brian
Yes Brian if you will look in the following graph
https://gw.ampr.org/router/encapinbytes.svg
the peak between 08-10 is from my camera ... it is strange that my one camera consume half of the bandwith of all the 44 net bandwith that is shown in the beginning till 18:00 in the graph ....
Thank U for all this valuable data
Ronen - 4Z4ZQ
________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Wednesday, May 17, 2017 7:02 AM To: AMPRNet working group Subject: Re: [44net] AMPR stats ...
(Please trim inclusions from previous messages) _______________________________________________ Ronen, did you connect your camera and did its traffic show up in the graphs? - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
________________________________ if the encap process add more bits and thats explain why inbond encap is bigger then then the inbond raw why it is not opposit in the following graph ?
https://gw.ampr.org/router/encapvsrawbytes.svg
the un encapped traffic (that goes out) shouldn't be without all the headers that come into it ? and in the graph they are almost same size input and encaped input ....
Ronen - 4Z4ZQ
------------------
Remember that encapsulating a packet makes it longer by the size of the added IP header, that is, by 20 bytes. The byte counts include the entire size of the packet, including all headers.
The outbound encap traffic packet count is slightly higher than the inbound that causes it because large incoming packets are fragmented into two packets after having grown in size by the addition of the second IPIP encapsulation header.
The byte count is significantly higher because the majority of the inbound traffic is connection requests i.e., packets that consist only of an IP and a UDP or TCP header, no data. Adding the IPIP header to this makes the packet significantly larger, increasing its byte count. - Brian
-
Brian Kantor -
lleachii＠aol.com -
R P