How To Confirm Which NIC a Failed telnet

Attempt is Going Out Using Wireshark

I was troubleshooting why a FIX session was failing to connect over the Internet, when it worked the previous night.  Initially I thought that the connection was going out the incorrect interface.  Recently, I’d added a virtual NIC to the virtual machine, and realized that some traffic that was previously going over the NIC with Internet connectivity was now going over the new NIC (which is connected to our internal management network).  I defined a route to ensure the traffic to the FIX session in question would go out the Internet-facing NIC, but wanted to confirm absolutely that the traffic was going out that interface (because otherwise, it would never reach the Internet).  I ran a continuous telnet test to the IP and port and fired up Wireshark.  I initially tried to filter in the port in question, but saw no traffic.  So, I tried several other Wireshark filters to try to see packets related to the failing telnet test:

• tcp.port==xxxxx
• udp.port==xxxxx
• telnet
• ip.addr==the IP I was trying to reach

No packets whatsoever in Wireshark.  What the heck?  Admittedly, I’m a relative networking newbie, so I don’t have a firm grasp of the protocols and packets used by a telnet connection attempt.  What was I finally able to use to figure out that the traffic was absolutely going out the Internet-facing NIC?  I filtered on the ARP protocol (Wireshark filter arp) on a whim, and was able to see that the request for the IP address in question was indeed going out that interface. In this example, the ARP "who has x.x.x.x?" told me the traffic was going out the correct interface.

ARP "who has x.x.x.x?" packets

Now to go find my firewall colleague to tell me if the traffic is indeed reaching the Internet. If it is, then the issue is likely at the site that I'm trying to connect to....

Why are my network interfaces not coming up at boot time on CentOS 6?!?!?

This has bugged me recently with a customer CentOS server that requires manual ifup of network interfaces following a reboot.  Well, thinking about it, it may be that I have to start the network service manually (service network start)....either way.    So many solutions to this issue related to not having ONBOOT=yes in the ifcfg file for the interface, but that was not the cause in this instance.  I finally discovered the cause today.  You can blame the fact that I'm a relative Linux newb to not finding this sooner.  Thanks to this forum post for enlightening me (see the answer by b13n1u):

CentOS 6.5 not bringing up network interface automatically after reboot [ifup eth0]

Here's the abridged version of chkconfig --list output from this server:

# chkconfig --list
NetworkManager  0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:off   3:off   4:off   5:off   6:off

So, the services NetworkManager and network are not set to start.  So, this should be the solution to the issue.  I'm rebooting it this weekend, so I guess we'll see how that works.

chkconfig network on

Wealth and Income Inequality - Bernie Sanders' Views

"Today, we live in the richest country in the history of the world, but that reality means little because much of that wealth is controlled by a tiny handful of individuals.

The issue of wealth and income inequality is the great moral issue of our time, it is the great economic issue of our time, and it is the great political issue of our time.

America now has more wealth and income inequality than any major developed country on earth, and the gap between the very rich and everyone else is wider than at any time since the 1920s.  
The reality is that since the mid-1980s there has been an enormous transfer of wealth from the middle class and the poor to the wealthiest people in this country. That is the Robin Hood principle in reverse. That is unacceptable and that has got to change."

That's how Bernie Sanders starts to outline his views on wealth and income inequality.  I'm firmly behind Bernie for President and hope you'll at least consider his views, even if you disagree.  Here's his whole outline on the issue from his website, which I agree with 110%.