Find information about NIC in Linux

Hi All,
          In some scenarios, we want to find out the performance factors of our NIC card attached. Because, if we are working on network for doing some work, then surely we need to transfer data from one system to other. Maximum performance depends on the configuration of NIC Card we are using.

                          
           So here are some command Line tools in Linux to find out useful info.
1.) ethtool
2.) mii-tool
3.) dmesg

1.) ethtool:

[root@server199 ~]# ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000001 (1)
        Link detected: yes

2.) mii-tool:

[root@server199 ~]# mii-tool -v eth1
SIOCGMIIREG on eth1 failed: Input/output error
eth1: negotiated 100baseTx-FD flow-control, link ok
  product info: vendor 00:50:43, model 11 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

3.) dmesg:

 [root@server199 ~]# dmesg | grep -i eth1
e1000e: eth1 NIC Link is Down
e1000e: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
eth1: 10/100 speed: disabling TSO
e1000e: eth1 NIC Link is Down
e1000e: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
eth1: 10/100 speed: disabling TSO

Some Terms:

Half-Duplex:
                      A half-duplex (HDX) system provides communication in both directions, but only one direction at a time (not simultaneously).

Full-Duplex:
                      A full-duplex (FDX), or sometimes double-duplex system, allows communication in both directions, and, unlike half-duplex, allows this to happen simultaneously.



   !Hope You will Enjoy

Kuldeep Sharma

Moving Iptables logs to different file

Dear All,
              Today I am going to post regarding the Iptable logs. I was getting iptable in /var/log/messages, so its getting difficult to check other messages from /var/log/messages as iptables generates a huge bulk of logs.

           So for that I decided to move iptables log to different directory. For this we have to do changes in foolowing configuration files.
1.) /etc/syslog.conf
In the above file append the following line.
kern.warning                                            /home/log/iptables.log

Also as before I was getting all iptables log in /var/log/messages, So need to do some more changes in syslog.conf file as change below line...

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none         /var/log/messages

               to.....................

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;kernel.warning         /var/log/messages

Now just restart the syslogd daemon.

[root@gateway ~]# /etc/init.d/syslog restart
Shutting down kernel logger:                               [  OK  ]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
Starting kernel logger:                                    [  OK  ]
[root@gateway ~]#



You can now see all iptables message logged to /home/log/iptables.log file:

[root@gateway ~]# tailf /home/log/iptables.log
Oct  4 00:33:06 gateway last message repeated 2 times
Oct  4 00:33:06 gateway kernel: IN=eth1 OUT=


   !Enjoy Linux
Kuldeep Sharma

How DHCP Server Works?

Hi Friends,
                 Here I am going to post the whole process about the Interaction between DHCP Client and DHCP Server(How a DHCP client communicate with DHCP Server to get an IP Address).

                         DHCP is a very common protocol and we often here about it. DHCP is much more complex than it looks. DHCP IP address assignment process goes through a few steps explained in this article.
            DHCP stands for Dynamic Host Configuration Protocol and is used to automatically assign IP configuration to hosts connecting to a network. The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP)A DHCP client makes a request to a DHCP server that may or may not reside on the same subnet. The automatic distribution of IP configuration information to hosts eases the administrative burden of maintaining IP networks. In its simplest form, DHCP distributes the IP address, subnet mask and default gateway to a host, but can include other configuration parameters such as name servers and netbios configuration.
A DHCP client goes through six stages during the DHCP process. These stages are:

• Initializing
• Selecting
• Requesting
• Binding
• Renewing
• Rebinding 

DHCP Client and DHCP Server Interaction

                            
          The DHCP client starts the DHCP process by issuing a DHCPDISCOVER message to its local subnet on UDP port 67. Since the client does not know what subnet it belongs to, a general broadcast is used (destination address 255.255.255.255). If the DHCP server is located on a different subnet, a DHCP-relay agent must be used. The DHCP-relay agent can take several forms. The ip-helper IOS command is used to set up a DHCP-relay agent on a Cisco router.

         The DHCP-relay agent forwards the DHCPDISCOVER message to a subnet that contains a DHCP server. Once the DHCP server receives the DHCPDISCOVER message, it replies with a DHCPOFFER message. The DHCPOFFER message contains the IP configuration information for the client. THE DHCPOFFER message is sent as a broadcast on UDP port 68. The client will know that the DHCPOFFER message is intended for it because the client's MAC address is included in the message. If the client is on a different subnet than the server, the message is sent unicast to the DHCP-relay agent on UDP port 67. The DHCP-relay agent broadcasts the DHCPOFFER on the client's subnet on UDP port 68.

           After the client receives the DHCPOFFER, it sends a DHCPREQUEST message to the server. The DHCPREQUEST message informs the server that it accepts the parameters offered in the DHCPOFFER message. The DHCPREQUEST is a broadcast message, but it includes the MAC address of the server, so that other DHCP servers on the network will know which server is serving the client.

            The DHCP server will send a DHCPACK message to the client to acknowledge the DHCPREQUEST. The DHCPACK message contains all the configuration information that was requested by the client. After the client receives the DHCPACK, it binds the IP address and is ready to communicate on the network. If the server is unable to provide the requested configuration, it sends a DHCPNACK message to the client. The client will resend the DHCPREQUEST message. If the DHCPREQUEST message does not return a DHCPACK after four attempts, the client will start the DHCP process from the beginning and send a new DHCPDISCOVER message.

           After the client receives the DHCPACK, it will send out an ARP request for the IP address assigned. If it gets a reply to the ARP request, the IP address is already in use on the network. The client then sends a DHCPDECLINE to the server and sends a new DHCPREQUEST. This step is optional, and is often not performed.

         Since the DHCP works on broadcast, two pc which are on different networks (or VLANs) cannot work on the DHCP protocol. Does that mean we should have one dedicated server of DHCP in each vlan? No … in Cisco devices IP helper-address command helps to broadcast DHCP messages from one vlan to other vlan.

       Regards
Kuldeep Sharma