tcpdump -c 200000 -w output.pcap -i any
tcpdump -r output.pcap -s 384 -i any -nnq -tttt ‘tcp port 80 and (((ip[2:2] – ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)’ > 80.txt
cut -c 12-21 port80.txt |awk ‘{print $1}’ | sort | uniq -c | awk ‘{print $2 ” ” $1}’ > packets_per_sec.txt
You can use the Test TCP utility (TTCP) to measure TCP throughput through an IP path. In order to use it, start the receiver on one side of the path, then start the transmitter on the other side. The transmitting side sends a specified number of TCP packets to the receiving side. At the end of the test, the two sides display the number of bytes transmitted and the time elapsed for the packets to pass from one end to the other. You can then use these figures to calculate the actual throughput on the link. For general information on TTCP, refer to Network Performance Testing with TTCP .
The TTCP utility can be effective in determining the actual bit rate of a particular WAN or modem connection. However, you can also use this feature to test the connection speed between any two devices with IP connectivity between them.
Server:./ttcp -r -s -p 9999
Client: ./ttcp -s -p 9999 < /boot/vmLinuz
this tools is to measure network performance. Iperf was originally developed by NLANR/DAST as a modern alternative for measuring TCP and UDP bandwidth performance
Server:
iperf -s -p 9999
Client:
iperf -c 192.168.122.150 -p 9999
Iperf features:
TCP
Measure bandwidth
Report MSS/MTU size and observed read sizes.
Support for TCP window size via socket buffers.
Multi-threaded if pthreads or Win32 threads are available. Client and server can have multiple simultaneous connections.
UDP
Client can create UDP streams of specified bandwidth.
Measure packet loss
Measure delay jitter
Multicast capable
Multi-threaded if pthreads are available. Client and server can have multiple simultaneous connections. (This doesn’t work in Windows.)
Where appropriate, options can be specified with K (kilo-) and M (mega-) suffices. So 128K instead of 131072 bytes.
Can run for specified time, rather than a set amount of data to transfer.
Picks the best units for the size of data being reported.
Server handles multiple connections, rather than quitting after a single test.
Print periodic, intermediate bandwidth, jitter, and loss reports at specified intervals.
Run the server as a daemon.
Run the server as a Windows NT Service
Use representative streams to test out how link layer compression affects your achievable bandwidth.
ping -c 2 -n -R linux4you.tk
It work only for 4-5 hops for me, so its better use traceroute -n
DEV=venet0
tc filter add dev $DEV parent 1: protocol ip prio 20 u32 match u32 1 0x0000 police rate 2kbit buffer 10k drop flowid :1
DEV=venet0
tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 100mbit
tc class add dev $DEV parent 1: classid 1:1 cbq rate 256kbit allot 1500 prio 5 bounded isolated
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst X.X.X.X flowid 1:1
tc qdisc add dev $DEV parent 1:1 sfq perturb 10
dhclient -r
dhclient
or
ifrenew
When you execute a traceroute command (http://www.linuxhow.tk), your machine sends out 3 UDP packets with a TTL (Time-to-Live) of 1. When those packets reach the next hop router, it will decrease the TTL to 0 and thus reject the packet. It will send an ICMP Time-to-Live Exceeded (Type 11), TTL equal 0 during transit (Code 0) back to your machine – with a source address of itself, therefore you now know the address of the first router in the path.
Next your machine will send 3 UDP packets with a TTL of 2, thus the first router that you already know passes the packets on to the next router after reducing the TTL by 1 to 1. The next router decreases the TTL to 0, thus rejecting the packet and sending the same ICMP Time-to-Live Exceeded with its address as the source back to your machine. Thus you now know the first 2 routers in the path.
This keeps going until you reach the destination. Since you are sending UDP packets with the destination address of the host you are concerned with, once it gets to the destination the UDP packet is wanting to connect to the port that you have sent as the destination port, since it is an uncommon port, it will most like be rejected with an ICMP Destination Unreachable (Type 3), Port Unreachable (Code 3). This ICMP message is sent back to your machine, which will understand this as being the last hop, therefore traceroute will exit, giving you the hops between you and the destination.
The UDP packet is sent on a high port, destined to another high port. On a Linux box, these ports were not the same, although usually in the 33000. The source port stayed the same throughout the session, however the destination port was increase by one for each packet sent out.
One note, traceroute actually sends 1 UDP packet of TTL, waits for the return ICMP message, sends the second UDP packet, waits, sends the third, waits, etc, etc, etc.
If during the session, you receive * * *, this could mean that that router in the path does not return ICMP messages, it returns messages with a TTL too small to reach your machine or a router with buggy software. After a * * * within the path, traceroute will still increment the TTL by 1, thus still continuing on in the path determination.
ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
curl -IL “URL”
this will send a HEAD request (-I), follow through all redirects (-L), and display some useful information in the end.
you can get more with GET request:
curl -sL -w "%{http_code} %{url_effective}\\n" "URL" -o /dev/null
ip is faster and have more configuration options, so your choice should be ip.
time ifconfig -a >/dev/null
real 0m0.010s
user 0m0.001s
sys 0m0.008s
time ip addr show >/dev/null
real 0m0.004s
user 0m0.000s
sys 0m0.002s
cd /etc/sysconfig/network-scripts
ls ifcfg-eth0-range*
If you already have a range file, you will need to create a new one for the new range of IPs you are adding, eg ‘nano ifcfg-eth1-range1` . If you have one named range1, name the next range2 and so on.
ifcfg-eth0-range1
Place the following text in the file:
IPADDR_START=192.168.0.10
IPADDR_END=192.168.0.110
CLONENUM_START=0
Note: CLONENUM_START defines where the alias will start. If this is the second range file, you will need to set CLONENUM_START to a value higher than the number of IP addresses assigned. To check what you currently have used, you can run ‘ifconfig –a | grep eth0’. This will list devices such as eth0:0, eth0:1, eth0:2, and so on. If you are currently using upto eth0:16, you will need to set CLONENUM_START to 17 to assign the IPs correctly.
Increasing ring buffer for rx should fix this issue:
# ethtool -G eth0 rx 512
To have this settings persistent make sure you add this command to /etc/rc.local script.
If your server in under ddos, sometimes tcpdump is quit useful:
time tcpdump -tnn -c 20000 -i em1 | awk -F "." '{print $1 "." $2 "." $3 "." $4}' | sort | uniq -c | sort -nr | awk '$1 > 100'
This is because limitation in TCP/IP stack where the port number field is just 16bit size. So we get only 2^16(2 to the power of 16) ports which are equal to 65536 available ports.