I have below configuration on open vswitch ovsbr0.8-qemu
ovs-ofctl -O OpenFlow15 add-flow ovsbr0.8-qemu "table=0,priority=10,in_port=eth3.8,dl_vlan=2000,actions=pop_vlan,resubmit(,1)"
ovs-ofctl -O OpenFlow15 add-flow ovsbr0.8-qemu "table=1,priority=5,mpls,mpls_label=99,mpls_bos=1,actions=pop_mpls:0x0800,resubmit(,2)"
ovs-ofctl -O OpenFlow15 add-flow ovsbr0.8-qemu "table=2,priority=5,ip,nw_dst=81.174.0.0/24,actions=mod_dl_dst=9a:c1:a0:e7:69:f9,mod_nw_src=81.174.0.13,output:6049f4f7b8584_l"
I need to test correctness of all rules among three tables and I am experimenting with command ovs-appctl ofproto/trace
Thanks to comment of #junka, I have used ovs-tcpundump command to obtains hex sequence of packet that must be processed.
ovs-appctl ofproto/trace ovsbr0.8-qemu in_port=eth3.8 2c9aa4aaaafe2c9aa4f20eee810007d08847000631404500008b279b40004011c6ee0a28effe51ae0004ac5f06a500775468c802006f.....(contine packet)....
Flow: mpls,in_port=7,dl_vlan=2000,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=2c:9a:a4:f2:0e:ee,dl_dst=2c:9a:a4:aa:aa:fe,mpls_label=99,mpls_tc=0,mpls_ttl=64,mpls_bos=1
bridge("ovsbr0.8-qemu")
-----------------------
0. in_port=7,dl_vlan=2000, priority 10
pop_vlan
resubmit(,1)
1. mpls,mpls_label=99,mpls_bos=1, priority 5
pop_mpls:0x0800
Final flow: ip,in_port=7,vlan_tci=0x0000,dl_src=2c:9a:a4:f2:0e:ee,dl_dst=2c:9a:a4:aa:aa:fe,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
Megaflow: recirc_id=0,eth,mpls,in_port=7,dl_vlan=2000,dl_vlan_pcp=0,mpls_label=99,mpls_bos=1
Datapath actions: pop_mpls(eth_type=0x800),pop_vlan,recirc(0x112)
It seems that correctly two rules match during processing and last one is missing. Reading ofproto/trace stdout it seems that
nw_src=0.0.0.0,nw_dst=0.0.0.0
but it is strange because packet contains ip layer correctly filled with defined values.
Any idea on reason because ovs-appctl ofproto/trace command is missing ip layer information?
Regards
Vincenzo
For the command above, mpls means 0x8847 ether type and ip means 0x0800 ether type. You can not combine them directly.
see https://manpages.ubuntu.com/manpages/focal/man1/ovs-tcpundump.1.html
The ovs-tcpundump program reads tcpdump -xx output from stdin, looking for hexadecimal packet data, and dumps each Ethernet as a single hexadecimal string on stdout. This format is suitable for use with the ofproto/trace command supported
Related
I'm not sure, why executing below command on ubuntu terminal throws error. tcpprep syntax and options are mentioned as per in help doc, still throws error.
root#test-vm:~# /usr/bin/tcpprep --cachefile='cachefile1' —-pcap='/pcaps/http.pcap'
tcpprep: Command line arguments not allowed
tcpprep (tcpprep) - Create a tcpreplay cache cache file from a pcap file
root#test-vm:~# /usr/bin/tcpprep -V
tcpprep version: 3.4.4 (build 2450) (debug)
There are two problems with your command (and it doesn't help that tcpprep errors are vague or wrong).
Problem #1: Commands out of order
tcpprep requires that -i/--pcap come before -o/--cachefile. You can fix this as below, but then you get a different error:
bash$ /usr/bin/tcpprep —-pcap='/pcaps/http.pcap' --cachefile='cachefile1'
Fatal Error in tcpprep_api.c:tcpprep_post_args() line 387:
Must specify a processing mode: -a, -c, -r, -p
Note that the error above is not even accurate! -e/--mac can also be used!
Problem #2: Processing mode must be specified
tcpprep is used to preprocess a capture file into client/server using a heuristic that you provide. Looking through the tcpprep manpage, there are 5 valid options (-acerp). Given this capture file as input.pcapng with server 192.168.122.201 and next hop mac 52:54:00:12:35:02,
-a/--auto
Let tcpprep determine based on one of 5 heuristics: bridge, router, client, server, first. Ex:
tcpprep --auto=first —-pcap=input.pcapng --cachefile=input.cache
-c/--cidr
Specify server by cidr range. We see servers at 192.168.122.201, 192.168.122.202, and 192.168.3.40, so summarize with 192.168.0.0/16:
tcpprep --cidr=192.168.0.0/16 --pcap=input.pcapng --cachefile=input.cache
-e/--mac
This is not as useful in this capture as ALL traffic in this capture has dest mac of next hop of 52:54:00:12:35:02, ff:ff:ff:ff:ff:ff (broadcast), or 33:33:00:01:00:02 (multicast). Nonetheless, traffic from the next hop won't be client traffic, so this would look like:
tcpprep --mac=52:54:00:12:35:02 —-pcap=input.pcapng --cachefile=input.cache
-r/--regex
This is for IP ranges, and is an alternative to summarizing subnets with --cidr. This would be more useful if you have several IPs like 10.0.20.1, 10.1.20.1, 10.2.20.1, ... where summarization won't work and regex will. This is one regex we could use to summarize the servers:
tcpprep --regex="192\.168\.(122|3).*" —-pcap=input.pcapng --cachefile=input.cache
-p/--port
Looking at Wireshark > Statistics > Endpoints, we see ports [135,139,445,1024]/tcp, [137,138]/udp are associated with the server IPs. 1024/tcp, used with dcerpc is the only one that falls outside the range 0-1023, and so we'd have to manually specify it. Per services syntax, we'd represent this as 'dcerpc 1024/tcp'. In order to specify port, we also need to specify a --services file. We can specify one inline as a temporary file descriptor with process substitution. Altogether,
tcpprep --port --services=<(echo "dcerpc 1024/tcp") --pcap=input.pcapng --cachefile=input.cache
Further Reading
For more examples and information, check out the online docs.
I am using Apache Kafka. I use KafkaProducer to produce data and KafkaConsumer to consume data. My config data is:
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.CLIENT_ID_CONFIG, "DemoProducer");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.IntegerSerializer");
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
The consumer config is the same. How do I view the whole TCP packet details which are being sent and received by the producers and consumers?
After you installed Wireshark, you must go to Edit->Prefrences or press Ctrl + Shift + P. In the new window open protocols tree and find Kafka in the list. After selecting Kafka you must set the Kafka broker port numbers(It's by default 9092). And Also check Show length for string and bytes fields in the protocol tree checkbox as shown in blew image:
and click ok to dismiss the window. And then you can view all Kafka APIs calls:
You can use tshark with a Kafka dissector already available.
sudo apt-get update
sudo apt-get install tshark
sudo tshark -V -i lo -o 'kafka.tcp.port:9092' -d tcp.port=9092,kafka -f 'dst port 9092'
More details here Using the kafka dissector in wireshark/tshark 1.12
I have a process using https. I found its PID using ps and used the command lsof -Pan -p PID -i to get the port number it is running on.
I need iftop to see the data transfer. The filter I am using now is
iftop -f "port http 57787".
I don't think this is giving me the right output.
Can someone help me the right filter to use with iftop so that I know the traffic going through only this port?
I can see 2 problems here:
1/ Is that a typo? The correct option for filtering is -f (small "f"). -F (capital "F") option is for net/mask.
2/ Though not explicitly stated by iftop documentation, the syntax for filtering seems to be the pcap one from the few examples given (and using ldd I can see that yes, the iftop binary is linked with libpcap). So a filter with http is simply not valid. To see the doc for pcap filtering syntax, have a look at pcap-filter (7) - packet filter syntax man page. In your example, a filter such as "tcp port 57787" would be OK. pcap does not do layer 5 and above protocol dissection such as http (pcap filters are handled by BPF in the kernel, so above layer 4 you're on your own, because that's none of the kernel business).
All in all, these looks like iperf bugs. It should refuse your "-F" option, and even with "-f" instead exit with an error code because pcap will refuse the filter expression. No big deal, iftop is a modest program. See edit bellow.
EDIT:
I just checked iftop version 1.0pre4 source code, and there is no such obvious bug from a look at set_filter_code() and its caller packet_init() in iftop.c. It correctly exit with error, but...
Error 2, use the "-f" option, but your incorrect filter syntax:
jbm#sumo:~$ sudo iftop -f "port http 57787"
interface: eth0
IP address is: 192.168.1.67
MAC address is: 8c:89:a5:57:10:3c
set_filter_code: syntax error
That's OK.
Error 1, the "-F" instead of "-f", there is a problem:
jbm#sumo:~$ sudo iftop -F "port http 57787"
(everything seems more or less OK, but then quit the program)
Could not parse net/mask: port http 57787
interface: eth0
IP address is: 192.168.1.67
MAC address is: 8c:89:a5:57:10:3c
Oops! "Could not parse net/mask: port http 57787"! That's a bug: it should exit right away.
Can we made a network with multiple switches without any controller in mininet .
I mean that we manually control the switches by "dpctl"
I made the topology like this:
s2
/ \
h1---s1/ \s3--h2
\ /
\s4/
and I want to send from h1 to h2.
first of all that I turn on the floodlight, and I extract the switch port number from there. after that I want to add flows manually that I encountered to an error.
mininet#mininet-vm:~$ dpctl add-flow tcp:127.0.0.1:40566 in_port=1,actions=output:2
dpctl: failed to send packet to switch: Connection refused
how can i fix it??
thanks a lot
dpctl add-flow tcp:127.0.0.1:6634in_port=1,actions=output:2
Port number will be 6634.
Controller is at Port number 6633 and from 6634 you have port for dpctl.
i need to find the host name of a UNIX host whose IP is known with out login to that UNIX host
Use nslookup
nslookup 208.77.188.166
...
Non-authoritative answer:
166.188.77.208.in-addr.arpa name = www.example.com.
You can do a reverse DNS lookup with host, too. Just give it the IP address as an argument:
$ host 192.168.0.10
server10 has address 192.168.0.10
Another NS lookup utility that can be used for reversed lookup is dig with the -x option:
$ dig -x 72.51.34.34
; <<>> DiG 9.9.2-P1 <<>> -x 72.51.34.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12770
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1460
;; QUESTION SECTION:
;34.34.51.72.in-addr.arpa. IN PTR
;; ANSWER SECTION:
34.34.51.72.in-addr.arpa. 42652 IN PTR sb.lwn.net.
;; Query time: 4 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Fri Jan 25 21:23:40 2013
;; MSG SIZE rcvd: 77
or
$ dig -x 127.0.0.1
; <<>> DiG 9.9.2-P1 <<>> -x 127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11689
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 10 IN PTR localhost.
;; Query time: 2 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Fri Jan 25 21:23:49 2013
;; MSG SIZE rcvd: 63
Quoting from the dig manpage:
Reverse lookups -- mapping addresses to names -- are simplified by the
-x option. addr is an IPv4 address in dotted-decimal notation, or a colon-delimited IPv6 address. When this option is used, there is no
need to provide the name, class and type arguments. dig automatically
performs a lookup for a name like 11.12.13.10.in-addr.arpa and sets
the query type and class to PTR and IN respectively.
For Windows ping -a 10.10.10.10
For Windows, try:
NBTSTAT -A 10.100.3.104
or
ping -a 10.100.3.104
For Linux, try:
nmblookup -A 10.100.3.104
They are almost same.
It depends on the context. I think you're referring to the operating system's hostname (returned by hostname when you're logged in). This command is for internal names only, so to query for a machine's name requires different naming systems. There are multiple systems which use names to identify hosts including DNS, DHCP, LDAP (DN's), hostname, etc. and many systems use zeroconf to synchronize names between multiple naming systems. For this reason, results from hostname will sometimes match results from dig (see below) or other naming systems, but often times they will not match.
DNS is by far the most common and is used both on the internet (like google.com. A 216.58.218.142) and at home (mDNS/LLMNR), so here's how to perform a reverse DNS lookup: dig -x <address> (nslookup and host are simpler, provide less detail, and may even return different results; however, dig is not included in Windows).
Note that hostnames within a CDN will not resolve to the canonical domain name (e.g. "google.com"), but rather the hostname of the host IP you queried (e.g. "dfw25s08-in-f142.1e100.net"; interesting tidbit: 1e100 is 1 googol).
Also note that DNS hosts can have more than one name. This is common for hosts with more than one webserver (virtual hosting), although this is becoming less common thanks to the proliferation of virtualization technologies. These hosts have multiple PTR DNS records.
Finally, note that DNS host records can be overridden by the local machine via /etc/hosts. If you're not getting the hostname you expect, be sure you check this file.
DHCP hostnames are queried differently depending on which DHCP server software is used, because (as far as I know) the protocol does not define a method for querying; however, most servers provide some way of doing this (usually with a privileged account).
Note DHCP names are usually synchronized with DNS server(s), so it's common to see the same hostnames in a DHCP client least table and in the DNS server's A (or AAAA for IPv6) records. Again, this is usually done as part of zeroconf.
Also note that just because a DHCP lease exists for a client, doesn't mean it's still being used.
NetBIOS for TCP/IP (NBT) was used for decades to perform name resolution, but has since been replaced by LLMNR for name resolution (part of zeroconf on Windows). This legacy system can still be queried with the nbtstat (Windows) or nmblookup (Linux).
python -c "import socket;print(socket.gethostbyaddr('127.0.0.1'))"
if you just need the name, no additional info, add [0] at the end:
python -c "import socket;print(socket.gethostbyaddr('8.8.8.8'))[0]"
The other answers here are correct - use reverse DNS lookups.
If you want to do it via a scripting language (Python, Perl) you could use the gethostbyaddr API.
If you are specifically looking for a Windows machine, try below command:
nbtstat -a 10.228.42.57
You can use traceroute command as well.
http://linux.die.net/man/8/traceroute
just use the traceroute it will show you the routing path with host names (IPs resolved)
In most cases, traceroute command works fine. nslookup and host commands may fail.