tcpdump and bonded network cards

[DWillis]

I am trying to do some packet checking to ensure some of my data is properly being sent and received.

However, when using tcpdump I am running into the problem of needing to specify the network card interface on which it is supposed to listen on. I have 4 network cards in my machines bonded to operate as 2 cards, so it's almost impossible to figure out which card the data is actually going to come in on.

How can I use tcpdump to properly watch packets?

Thanks in advance.

[anomie]

I did some quick reading to understand what you're talking about.

I don't intend to bond/trunk two NICs just to answer this question, so what is the output of:
# tcpdump -D
?

I'm curious to see if that displays bond interfaces or physical interfaces (or both).

[DWillis]

Here's the response:


1.eth0
2.bond0
3.eth1
4.bond1
5.eth2
6.eth3
7.any (Pseudo-device that captures on all interfaces)
8.lo


So, I guess it does show the bonds.

[DWillis]

So does this mean that I should be able to simply watch those and it should work?

[anomie]

Yes, I'd choose the interface based on what traffic you're interested in...

It's nice that it allows you to select physical and/or bond interfaces.

Also note that you can watch all interfaces (which will likely have a high signal to noise ratio).

[DWillis]

Thanks. I'll try this tomorrow morning and see how it goes. I'm hoping to capture on both sides..

tcpdump has a ton of commands and this is the first time I'm using it, so I'm kinda fumbling around quite a bit...

[anomie]

The manpages for tcpdump(1) are thorough, but also complex.

Post here if you can't get it figured out.

[DWillis]

Ok, I'm using this command on the machine which is to be receiving the data (in the form of an snmptrap):

tcpdump -s0 -vni bond0 udp port 161 and 172.16.254.51

and then I'm sending a trap from that ip to the machine which I'm running the tcpdump command. However, it's never coming across that I'm receiving the trap... Am I setting up this tcpdump command properly?

[anomie]

To pick that apart and make sure we're on the same page:

• -s0 (snarf 0, to make sure you get the full packet)
• -vni bond0 (verbose / no hostname resolution / interface bond0)
• udp port 161 and 172.16.254.51 (self explanatory, except I'd note that source or dest port may be 161)

------------------------

Anyway, with that behind us, I tested a very similar invocation on my own network, and it does not work. I don't know why at the moment, but the and 172.16.254.51 directive is not working properly. As soon as I added a similar directive in, the whole thing was borked and not capturing the packets I wanted.

I'd recommend trying this instead (which I tested and found to work):
# tcpdump -s0 -vni eth0 tcp port 161 and src host 10.0.0.3

Except substitute values for your own situation (i.e. change to bond0, udp and proper IP).

That should work. If it does not work, what I would do is:

1. Make sure you're sending the packets correctly in the first place.
2. Widen the tcpdump net until it does work, and then figure out which directive is causing trouble.

[DWillis]

Well, I'm finally back to tackling this task after a few things and your initial command suggestion doesn't pick up any packets.

So what I did is removed the port/host combination in an attempt to simply see if I could get tcpdump to work, and I'm finally seeing udp packets flowing across the screen.

I figured the next step would be to confirm the ports the data being passed through but when reviewing the packet data it doesn't have a port number in the data.

here's an example:

14:33:52.003850 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 191) 172.16.64.2.161 > 172.16.128.52.36688: [udp sum ok]  { SNMPv1 C                   = { GetResponse(144) R=525988813  .1.3.6.1.2.1.2.2.1.10.7=960872700 .1.3.6.1.2.1.2.2.1.11.7=46166100 .1.3.6.1.2.1.2.2.1.13.7=0 .1.3.6.                   1.2.1.2.2.1.14.7=0 .1.3.6.1.2.1.2.2.1.16.7=3995681917 .1.3.6.1.2.1.2.2.1.19.6=0 .1.3.6.1.2.1.2.2.1.20.6=0 } }
14:33:52.004529 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 134) 172.16.128.52.36687 > 172.16.128.251.161: [udp sum ok]  { SNMPv                   1  { GetNextRequest(89) R=871940933  .1.3.6.1.4.1.9.2.2.1.1.9.10144 .1.3.6.1.4.1.9.2.2.1.1.26.10144 .1.3.6.1.4.1.9.2.2.1.1.27.10144                    .1.3.6.1.2.1.31.1.1.1.18.10144 } }

I suppose my next step is to figure out what ports the monitoring stuff is really using (snmp) which I thought were ports 161 and 162, but when I try and sit on those ports I receive no packet data...