Pfsense not responding to large packet pings
-
@johnpoz said in Pfsense not responding to large packet pings:
but causing a problem by sending large pings to pfsense is prob not related to the problem..
...though I would expect it to work with arbitrarily sized packets. I have never tried 64K though. Until now.
[2.5.2-RELEASE][admin@t70.stevew.lan]/root: ping -s 65500 172.21.16.246 PING 172.21.16.246 (172.21.16.246): 65500 data bytes 65508 bytes from 172.21.16.246: icmp_seq=0 ttl=64 time=1.942 ms 65508 bytes from 172.21.16.246: icmp_seq=1 ttl=64 time=1.825 ms 65508 bytes from 172.21.16.246: icmp_seq=2 ttl=64 time=1.878 ms 65508 bytes from 172.21.16.246: icmp_seq=3 ttl=64 time=1.764 ms ^C --- 172.21.16.246 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.764/1.852/1.942/0.066 msA similar test to another device in my network fails:
[2.5.2-RELEASE][admin@t70.stevew.lan]/root: ping -s 2000 172.21.16.185 PING 172.21.16.185 (172.21.16.185): 2000 data bytes ^C --- 172.21.16.185 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet lossThe difference there is that 172.21.16.185 is behind a PoS TP-Link switch which doesn't pass packet fragments. Because.... no clue!
But bad switches aside it should work.
Steve
-
@stephenw10 said in Pfsense not responding to large packet pings:
PoS TP-Link switch which doesn't pass packet fragments.
What kind of shit switch? Yeah that belongs in the trash!
So what I have been able to duplicate.. Is if I try it "through" pfsense it fails.. But if on the same L2 network then works
$ ping -l 65500 ntp Pinging ntp.local.lan [192.168.3.32] with 65500 bytes of data: Request timed out. Request timed out.root@pi-hole:/# ping -s 65500 ntp PING ntp.local.lan (192.168.3.32) 65500(65528) bytes of data. 65508 bytes from ntp.local.lan (192.168.3.32): icmp_seq=1 ttl=64 time=12.1 ms 65508 bytes from ntp.local.lan (192.168.3.32): icmp_seq=2 ttl=64 time=12.1 ms 65508 bytes from ntp.local.lan (192.168.3.32): icmp_seq=3 ttl=64 time=12.1 msAn intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
Same one that loves VLAN 1.
Yeah, needs recycling!
Just for reference here's two 3100s on different subnets routed through a 2.5.2 box:
[21.05.1-RELEASE][admin@fw1.stevew.lan]/root: ping -s 65500 -c 3 3100-2.fire.box PING 3100-2.fire.box (192.168.10.103): 65500 data bytes 65508 bytes from 192.168.10.103: icmp_seq=0 ttl=63 time=3.832 ms 65508 bytes from 192.168.10.103: icmp_seq=1 ttl=63 time=3.512 ms 65508 bytes from 192.168.10.103: icmp_seq=2 ttl=63 time=3.583 ms --- 3100-2.fire.box ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.512/3.642/3.832/0.137 msThat's also through some VLANs over a LAGG just for fun.
Steve
-
Odd so through pfsense seems largest I can get is 34276
$ ping -l 34276 ntp Pinging ntp.local.lan [192.168.3.32] with 34276 bytes of data: Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63 Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63$ ping -l 34277 ntp Pinging ntp.local.lan [192.168.3.32] with 34277 bytes of data: Request timed out. Request timed out.problem is I think if you loose like 1 packet - you run into problem where they all have to be transmitted again..
$ ping -l 34276 ntp -t Pinging ntp.local.lan [192.168.3.32] with 34276 bytes of data: Request timed out. Request timed out. Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63 Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63 Reply from 192.168.3.32: bytes=34276 time=8ms TTL=63 Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63 Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63 Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63 Request timed out. Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63 Reply from 192.168.3.32: bytes=34276 time=7ms TTL=63An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
That's between local subnets? The ping time is very high compared with what I'm seeing at double the packet size. So presumably twice the number of fragments.
Unable to replicate here.
-
@stephenw10 yeah that is between 2 local segments..
Its to a pi, so the pi might have some issues with reassembly that is slowing up the response?
I do see sub ms response normal sized pings
C:\tools>hrping ntp This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de Source address is 192.168.9.100; using ICMP echo-request, ID=fc2f Pinging ntp [192.168.3.32] with 32 bytes data (60 bytes IP): From 192.168.3.32: bytes=60 seq=0001 TTL=63 ID=f41c time=0.931ms From 192.168.3.32: bytes=60 seq=0002 TTL=63 ID=f42d time=0.808ms From 192.168.3.32: bytes=60 seq=0003 TTL=63 ID=f45b time=0.829ms From 192.168.3.32: bytes=60 seq=0004 TTL=63 ID=f481 time=0.820ms Packets: sent=4, rcvd=4, error=0, lost=0 (0.0% loss) in 1.511180 sec RTTs in ms: min/avg/max/dev: 0.808 / 0.847 / 0.931 / 0.049 Bandwidth in kbytes/sec: sent=0.158, rcvd=0.158edit: You know what also could be contributing?? Pi is only connected at 100, while my pc is at gig.. hmmmm
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
I can do 25100 to the pfsense , 25200 fails
$ ping -s 25100 fw-01 PING fw-01 (10.17.11.1) 25100(25128) bytes of data. 25108 bytes from fw-01 (10.17.11.1): icmp_seq=1 ttl=64 time=3.40 msI do 25200 wo probs to my RasPi3 , on another subnet.
$ ping -s 65500 raspi3 PING raspi3. (192.168.17.34) 65500(65528) bytes of data. 65508 bytes from raspi3. (192.168.17.34): icmp_seq=1 ttl=63 time=24.0 msTests done via wifi C2702i , and passing two HP 1820 switches (No Jumbo)
-
ping -l 65500 192.168.2.2
Where 192.168.2.2 is an ancient Linksys E1200 access point, cabled up with 100 Mb - not 1 Gb.
This device is 10,12 years old.I ping from 192.168.1.15, a windows 10 on LAN, through pfSense, to the other network 192.168.2.0.
From 192.168.2.2Ā : bytes=65500 time=15 ms TTL=63
"15 ms" probably because the10x slower "192.168.2.x network.
Windows - the ping command, doesn't allow me to use values above "65500".
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
Well this sure seems like a crazy rabbit hole to have gone down ;) hehehe
So my 2 pis can ping each other at 65500, but neither can ping pfsense interface on that same network.. But my PC can ping pfsense on my lan can ping just fine at 65500
but a vm I have on a different vlan can ping pfsense IP on its vlan just fine with 65500..
Yeah this is a crazy rabbit hole ;)
-
@johnpoz said in Pfsense not responding to large packet pings:
Well this sure seems like a crazy rabbit hole to have gone down ;)
Ha, indeed! 64K packets.... who knew.
-
@gertjan said in Pfsense not responding to large packet pings:
Jumbo frame cram out that extra zero dot x % speed gain.
Actually, it's due to the way switches handle the data. Switch specs talk about frames, not bits, as it takes them just as much effort to handle a small frame as a big one. The buffer receives the data, triggers the switch to move it and sends it to the appropriate port and it does this an entire frame at a time. So, the bigger the frame, the more data is handled each time.
-
@johnpoz said in Pfsense not responding to large packet pings:
What kind of shit switch?
Your favourite, TP-Link.
-
@johnpoz said in Pfsense not responding to large packet pings:
problem is I think if you loose like 1 packet - you run into problem where they all have to be transmitted again..
That depends on the software. TCP can recover from missing pieces, without starting from the beginning of a packet. However, it depends on the particular version. I don't know that UDP or ICMP can recover.
-
@gertjan said in Pfsense not responding to large packet pings:
Windows - the ping command, doesn't allow me to use values above "65500"
That's because 65K is the maximum packet size. So, that would be 65536 less overhead.
-
Well, that is the maximum allowed for IP.
-
Good morning guys.
I'm so sorry for sending you all down the rabbit hole :-DWell I tried some things in the weekend too...
-Upgraded to 2.5.2
-Tried unchecking the "disable hardware offload" options.
-Disabled suricata and pfBlockerNG
-Pinging various other devices in different directionsBasically, nothing helps. It's only pfSense I have a problem with. All other devices can ping 65500 in any direction with almost zero latency.
It's connected with 2 glass fibre cables (sorry I stated this wrong before).
1 glass fibre from the ISP and the other glass fibre going to a 10gb/s switch.Even just trying to send a large ping packet to the directly-connected switch, over fibre, is impossible. Works up to about 20,000 which give a (broken) response in about 1.8 seconds (not milliseconds!). Above 20k it just fails.
I can ping the pfsense from itself using it's own IP, which is successful (doesn't go out over the network I suppose).
I'm running all good hardware. The NIC is connected via direct passthrough from the VM Host to the pfSense box so the VM has complete control of it.
Something just isn't right though.
I'm not using Jumbo packets by the way, just 1500. I expect the switch the just fragment any large packets.
Anyone got anymore ideas?
Thanks
MattPS: anyone know how to reload the Menu after using the shell in pfsense?
-
Your pfSense runs from a VM ?
So, for you the 'how many bytes per packet' is hard coded in the NIC device driver. And the VM "virtual" NIC driver.
The smallest wins, of course.My pfSense, 2.5.2 CE, a bare bone install, using a quad Intel NIC card, works fine.
@gemeenaapje said in Pfsense not responding to large packet pings:
I can ping the pfsense from itself using it's own IP
Aha : the local - for pfSense - NIC driver is used, the transport stays purely 'in software' to physical or VM rules don't apply. Again : go bare bone and you have your 'close to "65535"'.
@gemeenaapje said in Pfsense not responding to large packet pings:
PS: anyone know how to reload the Menu after using the shell in pfsense?
Console ? SSH ?
This menu :
0) Logout (SSH only) 9) pfTop 1) Assign Interfaces 10) Filter Logs 2) Set interface(s) IP address 11) Restart webConfigurator 3) Reset webConfigurator password 12) PHP shell + pfSense tools 4) Reset to factory defaults 13) Update from console 5) Reboot system 14) Disable Secure Shell (sshd) 6) Halt system 15) Restore recent configuration 7) Ping host 16) Restart PHP-FPM 8) Shell?
Press Enter an it shows up.
When you entered the 8 or Shell option just type "exit" + enter.
-
I'd still love to know why you're trying to send such huge packets. I've never seen anyone attempt that. Though I agree, I expect it to work.
Try looking atnetstat -s. Do you see fragments dropped?[22.01-DEVELOPMENT][root@6100.stevew.lan]/root: netstat -sp ip ip: 1139040 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 1135659 packets for this host 3070 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 10 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 1181042 packets sent from this host 4 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 15 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in headerSteve
-
Morning guys. Thanks again for the replies.
I am not using the VM NIC or drivers for them. I'm using the Linux drivers for the real card (see link above to information and specs).
I see 0 fragments dropped when I check using that command.
tcp: 83035 packets sent 36238 data packets (41227594 bytes) 582 data packets (243226 bytes) retransmitted 6 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 38414 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 3 window update packets 7969 control packets 74803 packets received 32446 acks (for 41228656 bytes) 600 duplicate acks 0 acks for unsent data 29375 packets (14627752 bytes) received in-sequence 26 completely duplicate packets (2050 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 11 out-of-order packets (5806 bytes) 0 packets (0 bytes) of data after window 0 window probes 10 window update packets 11 packets received after close 304 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to full reassembly queue 550 connection requests 6711 connection accepts 0 bad connection attempts 0 listen queue overflows 83 ignored RSTs in the windows 7261 connections established (including accepts) 4975 times used RTT from hostcache 4975 times used RTT variance from hostcache 247 times used slow-start threshold from hostcache 7452 connections closed (including 466 drops) 4703 connections updated cached RTT on close 4703 connections updated cached RTT variance on close 30 connections updated cached ssthresh on close 0 embryonic connections dropped 29794 segments updated rtt (of 15066 attempts) 2225 retransmit timeouts 179 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 1855 correct ACK header predictions 22033 correct data packet header predictions 6712 syncache entries added 19 retransmitted 32 dupsyn 0 dropped 6711 completed 0 bucket overflow 0 cache overflow 1 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 6712 cookies sent 0 cookies received 116 hostcache entries added 0 bucket overflow 29 SACK recovery episodes 59 segment rexmits in SACK recovery episodes 84944 byte rexmits in SACK recovery episodes 563 SACK options (SACK blocks) received 125 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window 0 packets with matching signature received 0 packets with bad signature received 0 times failed to make signature due to no SA 0 times unexpected signature received 0 times no signature provided by segment 0 Path MTU discovery black hole detection activations 0 Path MTU discovery black hole detection min MSS activations 0 Path MTU discovery black hole detection failures TCP connection count by state: 0 connections in CLOSED state 6 connections in LISTEN state 0 connections in SYN_SENT state 0 connections in SYN_RCVD state 1 connection in ESTABLISHED state 0 connections in CLOSE_WAIT state 0 connections in FIN_WAIT_1 state 0 connections in CLOSING state 3 connections in LAST_ACK state 0 connections in FIN_WAIT_2 state 3 connections in TIME_WAIT state udp: 783358 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 12958 with no checksum 464 dropped due to no socket 560538 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 222356 delivered 1574821 datagrams output 0 times multicast source filter matched sctp: 0 input packets 0 datagrams 0 packets that had data 0 input SACK chunks 0 input DATA chunks 0 duplicate DATA chunks 0 input HB chunks 0 HB-ACK chunks 0 input ECNE chunks 0 input AUTH chunks 0 chunks missing AUTH 0 invalid HMAC ids received 0 invalid secret ids received 0 auth failed 0 fast path receives all one chunk 0 fast path multi-part data 0 output packets 0 output SACKs 0 output DATA chunks 0 retransmitted DATA chunks 0 fast retransmitted DATA chunks 0 FR's that happened more than once to same chunk 0 output HB chunks 0 output ECNE chunks 0 output AUTH chunks 0 ip_output error counter Packet drop statistics: 0 from middle box 0 from end host 0 with data 0 non-data, non-endhost 0 non-endhost, bandwidth rep only 0 not enough for chunk header 0 not enough data to confirm 0 where process_chunk_drop said break 0 failed to find TSN 0 attempt reverse TSN lookup 0 e-host confirms zero-rwnd 0 midbox confirms no space 0 data did not match TSN 0 TSN's marked for Fast Retran Timeouts: 0 iterator timers fired 0 T3 data time outs 0 window probe (T3) timers fired 0 INIT timers fired 0 sack timers fired 0 shutdown timers fired 0 heartbeat timers fired 0 a cookie timeout fired 0 an endpoint changed its cookiesecret 0 PMTU timers fired 0 shutdown ack timers fired 0 shutdown guard timers fired 0 stream reset timers fired 0 early FR timers fired 0 an asconf timer fired 0 auto close timer fired 0 asoc free timers expired 0 inp free timers expired 0 packet shorter than header 0 checksum error 0 no endpoint for port 0 bad v-tag 0 bad SID 0 no memory 0 number of multiple FR in a RTT window 0 RFC813 allowed sending 0 RFC813 does not allow sending 0 times max burst prohibited sending 0 look ahead tells us no memory in interface 0 numbers of window probes sent 0 times an output error to clamp down on next user send 0 times sctp_senderrors were caused from a user 0 number of in data drops due to chunk limit reached 0 number of in data drops due to rwnd limit reached 0 times a ECN reduced the cwnd 0 used express lookup via vtag 0 collision in express lookup 0 times the sender ran dry of user data on primary 0 same for above 0 sacks the slow way 0 window update only sacks sent 0 sends with sinfo_flags !=0 0 unordered sends 0 sends with EOF flag set 0 sends with ABORT flag set 0 times protocol drain called 0 times we did a protocol drain 0 times recv was called with peek 0 cached chunks used 0 cached stream oq's used 0 unread messages abandonded by close 0 send burst avoidance, already max burst inflight to net 0 send cwnd full avoidance, already max burst inflight to net 0 number of map array over-runs via fwd-tsn's ip: 87076069 total packets received 0 bad header checksums 0 with size smaller than minimum 1 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 70 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 23 packets reassembled ok 844447 packets for this host 0 packets for unknown/unsupported protocol 48034746 packets forwarded (12779678 packets fast forwarded) 2157 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 983998 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 810 output datagrams fragmented 2826 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 6483 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: echo reply: 3139 destination unreachable: 6464 time exceeded: 19 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 82 destination unreachable: 63 echo: 3139 time exceeded: 51 3139 message responses generated 0 invalid return addresses 0 no return routes ICMP address mask responses are disabled igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 2 membership reports sent ipsec: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 spd cache hits 0 spd cache misses 0 clusters copied during clone 0 mbufs inserted during makespace ah: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets dropped; bad authentication detected 0 packets dropped; bad authentication length 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures esp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 packets dropped; bad ilen 0 replay counter wraps 0 packets dropped; bad encryption detected 0 packets dropped; bad authentication detected 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures ipcomp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 packets sent uncompressed; size < compr. algo. threshold 0 packets sent uncompressed; compression was useless pim: 0 messages received 0 bytes received 0 messages received with too few bytes 0 messages received with bad checksum 0 messages received with bad version 0 data register messages received 0 data register bytes received 0 data register messages received on wrong iif 0 bad registers received 0 data register messages sent 0 data register bytes sent carp: 0 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 0 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error pfsync: 0 packets received (IPv4) 0 packets received (IPv6) 0 clear all requests received 0 state inserts received 0 state inserted acks received 0 state updates received 0 compressed state updates received 0 uncompressed state requests received 0 state deletes received 0 compressed state deletes received 0 fragment inserts received 0 fragment deletes received 0 bulk update marks received 0 TDB replay counter updates received 0 end of frame marks received /0 packets discarded for bad interface 0 packets discarded for bad ttl 0 packets shorter than header 0 packets discarded for bad version 0 packets discarded for bad HMAC 0 packets discarded for bad action 0 packets discarded for short packet 0 states discarded for bad values 0 stale states 0 failed state lookup/inserts 0 packets sent (IPv4) 0 packets sent (IPv6) 0 clear all requests sent 0 state inserts sent 0 state inserted acks sent 0 state updates sent 0 compressed state updates sent 0 uncompressed state requests sent 0 state deletes sent 0 compressed state deletes sent 0 fragment inserts sent 0 fragment deletes sent 0 bulk update marks sent 0 TDB replay counter updates sent 0 end of frame marks sent 0 failures due to mbuf memory error 0 send errors arp: 2989 ARP requests sent 47409 ARP replies sent 203553 ARP requests received 1558 ARP replies received 205111 ARP packets received 2481 total packets dropped due to no ARP entry 1229 ARP entrys timed out 0 Duplicate IPs seen ip6: 23482557 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 atomic fragments 0 packets reassembled ok 160041 packets for this host 17515875 packets forwarded 0 packets not forwardable 959 redirects sent 866221 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 959 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 108127 multicast packets which we don't join Input histogram: hop by hop: 13610 TCP: 14062747 UDP: 9169861 fragment: 959 ESP: 36 ICMP6: 235344 Mbuf statistics: 480 one mbuf two or more mbuf: lo0= 27250 23454827 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 282 failures of source address selection source addresses on an outgoing I/F 273468 link-locals 559008 globals source addresses on a non-outgoing I/F 3431 globals 282 addresses scope=0xf source addresses of same scope 273468 link-locals 318195 globals source addresses of a different scope 244244 globals Source addresses selection rule applied: 835907 first candidate 282 same address 562439 appropriate scope icmp6: 955 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: unreach: 951 time exceed: 4 echo reply: 5 router solicitation: 2 router advertisement: 27400 neighbor solicitation: 64021 neighbor advertisement: 29642 MLDv2 listener report: 16 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: unreach: 1 echo: 5 router solicitation: 2339 router advertisement: 32621 neighbor solicitation: 29642 neighbor advertisement: 60940 Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 941 address unreachable 10 port unreachable 0 packet too big 4 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 959 redirect 0 unknown 5 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes ipsec6: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 spd cache hits 0 spd cache misses 0 clusters copied during clone 0 mbufs inserted during makespace rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams outputMaybe it's a bad driver?
Not sure if the driver is loaded in VM Esxi or in pfSense now. I can't remember and I also don't know many linux commands. I think it might have been loaded in VM and the esxi passes the device through to the VM. -
@gemeenaapje
Do you avoid the "Why do you need 65K packets" question intentionally
/Bingo
