DNS reading list

• Configure BIND as a slave DNS server

Debug DHCP troubles, see exactly what the DHCP server is sending me

Scenario: Trouble with DHCP on a client machine. User claims that the DHCP server is not sending the right information. Need to see exactly what DHCP server is sending.

System: openSUSE 13.1

Set up Linux box as a router

Ingredients:

1. one Linux box with multiple Ethernet interfaces
2. at least two networks with segments assigned
3. a desire to make the Linux box route packets between the networks

Simple host scan with nmap

Sometimes it's useful to quickly scan for hosts in a given range. This is easily achieved with nmap.

1. RTFM: Host Discovery chapter in nmap book
2. Know which range I want to scan -- e.g., 192.168.5.0/24
3. Check which version of nmap I'm using:
   

   # # This is on a SLES 11-SP3 box
   # nmap --version
   
   Nmap version 4.75 ( http://nmap.org )
   
   # # This is on openSUSE 13.1
   # nmap --version
   
   Nmap version 6.40 ( http://nmap.org )
   Platform: x86_64-suse-linux-gnu
   [snip]
   

4. Run the command:
   

   # # on nmap version 4.75
   # nmap -sP 192.168.5.0/24
   ...wait for output...
   
   # # on nmap version 6.40
   # nmap -sn 192.168.5.0/24
   ...wait for output...
   

IPv6 troubleshooting basics

The bare minimum I need to know is in the IPv6-ready test/debug programs section of the Linux IPv6 HOWTO.

For example, when pinging link-local addresses, the interface must be specified because link-local addresses on each interface share the same address space.

Cisco SG300: useful commands

Presumably these commands apply to the SF300 series, too.

Set switch IP address

The SG300 can have its own IP address:

swfoo#show ip interface


  Gateway IP Address        Activity status       Type
----------------------- ----------------------- --------


    IP Address         I/F       Type       Status
------------------- --------- ----------- -----------
192.168.10.111/24   vlan 15   Static      Valid

Set the IP address of VLAN 12:

(config)#interface vlan 12
swfoo(config)#ip address 10.100.5.5 255.255.192.0

Add/remove VLANs

swfoo#config
swfoo(config)#vlan database
swfoo(config-vlan)#vlan 2             (add)
swfoo(config-vlan)#no vlan 20         (remove)
swfoo(config-vlan)#exit
swfoo(config)#exit
swfoo#

Configure switchports

Configure a single switchport

swfoo#config
swfoo(config)# interface gi52
swfoo(config-if)# ...commands...
swfoo(config-if)#exit
swfoo(config)#exit
swfoo#

Configure a range of switchports:

swfoo#config
swfoo(config)# interface range gi1-51
swfoo(config-if-range)# ...commands...
swfoo(config-if-range)#exit
swfoo(config)#exit
swfoo#

Set up a switchport (range) for untagged VLAN ("access" mode)

interface gigabitethernet47
description Bar-Baz-mgmt0-b
switchport mode access 
switchport access vlan 15 

Set up a switchport (range) for untagged VLAN as "Native VLAN" on "Trunk"

interface gigabitethernet47
description foobar
switchport mode trunk
switchport trunk native vlan 15

Set up a switchport (range) for tagged ("Allowed")/untagged ("Native") VLAN

interface gigabitethernet47
description foobar2
switchport mode trunk
switchport trunk allowed vlan add 15
switchport trunk native vlan 2

Remove the native VLAN from a switchport:

swfoo(config-if)# no switchport trunk native vlan

Configure SNMP

Three commands to look at:

show snmp
snmp-server server
snmp-server community public ro

Show configuration information

Display the entire running-config to the screen: show running-config

Display the entire startup-config to the screen: show startup-config

Review switchport descriptions (for all switchports)

swfoo#show inter description

Port      Description
-------   -----------
gi1       
gi2
... etc. etc. ....

Show description of an individual switchport

swfoo#show inter desc gi26
Port      Description
-------   -----------
gi26      barbaz

Review VLAN-to-switchport assignments

swfoo#show vlan

Vlan       Name                   Ports                Type     Authorization 
---- ----------------- --------------------------- ------------ ------------- 
 1           1                    Po1-8              Default      Required    
 15         15                   gi51-52              static      Required    
 20         20                   gi1-52               static      Required    

The above summary does not tell you about access/trunk/native/allowed. To find this information, look at the individual switchport:

swfoo#show interfaces switchport gi52
Port : gi52
Port Mode: Trunk
Gvrp Status: disabled
Ingress Filtering: true
Acceptable Frame Type: admitAll
Ingress UnTagged VLAN ( NATIVE ): 20
 
Port is member in: 
 
Vlan               Name               Egress rule Port Membership Type 
---- -------------------------------- ----------- -------------------- 
 15                 15                  Tagged           Static        
 20                 20                 Untagged          Static        

...[etc.]...

Troubleshooting: the SG300 maintains internal counters of packets, CRC errors, etc. for each switchport. CRC errors are not logged to syslog! The following command shows the counters for switchport $N:

swfoo#show interfaces counters gi$N

Show firmware and boot image versions:
M/

swfoo#show bootvar
Image  Filename   Version     Date                    Status
-----  ---------  ---------   ---------------------   -----------
1      image-1    1.3.7.18    12-Jan-2014  18:02:59   Not active
2      image-2    1.3.7.18    12-Jan-2014  18:02:59   Active* 

"*" designates that the image was selected for the next boot

Password complexity, password expiry, password aging

Password complexity settings - see section 16.16 of the Cisco 300 Series Managed Switches Command Line Interface
Guide Release 1.2.5/1.2.7.

Password aging settings - see section 16.16 of the Cisco 300 Series Managed Switches Command Line Interface
Guide Release 1.2.5/1.2.7.

Cheatsheet - disable password aging:

sg300# config
sg300(config)#passwords aging 0
sg300(config)#exit

Now the SG300 will no longer say:

Your password has exceeded the maximum lifetime. Please change the password 
for better protection of your network.
Do you want to change it now (Y/N)[N] ?

Show the passwords configuration:

sg300# show passwords configuration

Save the running configuration

labf2sr1sw1#copy running-config startup-config
Overwrite file [startup-config].... (Y/N)[N] ?Y
28-Jan-2014 18:13:17 %COPY-I-FILECPY: Files Copy - source URL running-config destination URL flash://startup-config
28-Jan-2014 18:13:21 %COPY-N-TRAP: The copy operation was completed successfully
Copy succeeded

Cisco SG300: Initial setup (Management VLAN, SSH access)

We recently got our hands on some Cisco SG300 52-port "top-of-rack" switches, and I have started taking some "baby steps" with them. Here are some notes on how I got started provisioning the switches.

VLANs: tagged, untagged -- what's the difference?

I know this topic has probably been beaten to death elsewhere. . . What can I say? I can't help myself.

When there is an untagged VLAN on a switch or port, it means the VLAN information is private to the switch. No VLAN information is added to packets leaving the switch. This has a lot of important implications. A machine connecting to an untagged VLAN port does not need to know (and will not know) what VLAN it is in. If I'm connecting two switches together using a cable connected to untagged VLAN ports, each end of the cable could be in a different VLAN and the switches will not care. So, for example, I could send untagged VLAN 1 from one switch and bring it into another switch as untagged VLAN 20.

Tagged VLAN means that the switch does insert the VLAN information into the header of each packet. In fact, this information is called a "tag", hence the term "tagged VLAN", which means "VLAN where packets contain VLAN tags". Assuming I'm sending tagged VLAN packets (and no untagged ones) on a port, if I connect the eth0 interface of a vanilla-installed PC to that port, and give the interface an address in the tagged VLAN's range, the network will not work over that interface. Of course, I will be able to 'see' the packets using wireshark or tcpdump, but I won't be able to make TCP, UDP, ICMP, etc. connections.

Use port forwarding to selectively grant access to machines behind firewall/NAT

Port forwarding is a networking technique that can be used to give limited outside access to a machine that, due to its location behind a firewall or NAT setup, would not otherwise be accessible from the outside.

Promiscuous mode and Avahi

This morning after updating my workstation, which is currently running openSUSE 12.3, I was unpleasantly surprised to see a continuously elevated network load of 80-100KiB/s (down) on eth0. Using wireshark, I looked at the traffic that was going over the interface. There seemed to be a lot more traffic than I should normally see here on the LAN.

At first I thought the interface might be in promiscuous mode. Googling on the net, I found several seemingly credible sources that advised me to do this:

# netstat -i
Kernel Interface table
Iface   MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0   1500   0   270555      0    738      0    15408      0      0      0 BMRU
lo    65536   0     1936      0      0      0     1936      0      0      0 LRU

and look at the flags (last column: Flg). According to the sources, the M flag indicates promiscuous mode. Don't believe it. That flag actually means Multicast mode. And you can get the same information that netstat -i provides, but in a more verbose format, using one (or both) of these commands:

# ip a s
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 5c:f9:dd:6b:97:29 brd ff:ff:ff:ff:ff:ff
    inet 10.100.12.15/18 brd 10.100.63.255 scope global eth0
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 5C:F9:DD:6B:97:29  
          inet addr:10.100.12.15  Bcast:10.100.63.255  Mask:255.255.192.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:271495 errors:0 dropped:757 overruns:0 frame:0
          TX packets:15859 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:106828593 (101.8 Mb)  TX bytes:2158179 (2.0 Mb)
          Interrupt:20 Memory:e1500000-e1520000 

This shows what the netstat -i flags (BMRU) actually mean:

B == BROADCAST
M == MULTICAST
R == RUNNING
U == UP

None of this, of course, has any bearing whatsoever on promiscuous mode, and the elevated network load I was seeing was actually caused by Avahi.

Avahi Daemon

Avahi is one of these new-fangled services that are pooh-poohed by old geezers like myself. What it is, is an implementation of Multicast DNS (mDNS), which provides DNS-like services without any configuration. The idea being that you simply plug a bunch of computers running Avahi into a LAN segment (i.e., a switch) and they automatically learn about eachother. Avahi running on each computer finds out what services that computer is configured to provide and broadcasts that information over the network. The other Avahi instances running on the other computers do the same. The result can easily be seen by running:

# zypper in avahi-utils
# avahi-browse -a

Anyway, all of this is moot. The only reason Avahi (or avahi-daemon) was running on my computer was because openSUSE 12.3 installs it by default. I don't know, or care, why it suddenly started causing that elevated network load. The problem disappeared when I stopped the avahi-daemon process:

# rcavahi-daemon stop

For good measure, I also did:

# zypper rm avahi

And what about promiscuous mode

If you really want to turn promiscuous mode on and off, you can use, e.g., ifconfig as follows:

# ifconfig eth0 promisc    # turn promiscuous mode on
# ip a s
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 5c:f9:dd:6b:97:29 brd ff:ff:ff:ff:ff:ff
    inet 10.100.12.15/18 brd 10.100.63.255 scope global eth0
# ifconfig eth0 -promisc   # turn promiscuous mode off

Wide-open NAT firewall script using iptables

A couple years ago, I was trying to set up NAT on my home network's firewall/router using iptables, and I was desperate. It seemed that nothing I could do would convince "it" to work. (Hmm, maybe that's why they used to call it a "notwork" on alt.sysadmin.recovery . . . ) In desperation, I posted to a forum and good denizen Sum1 sent me this handy script, which I reproduce here in good will, but without his/her explicit permission:

#!/bin/sh
#
# Sum1's "wide-open, last-resort" NAT firewall
#
# Breathe, step away for a few, have a snack, and let the frustration level
# decline. You are not alone; I definitely know how you feel.
#
# I reserve the following rules for when I face utter frustration and meltdown:

IPTABLES="/usr/sbin/iptables"
LAN_INTERFACE="eth1"
INET_INTERFACE="eth0"
SUBNET1="192.168.0.0/24"

$IPTABLES -t filter -A INPUT -i $LAN_INTERFACE -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LAN_INTERFACE -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $INET_INTERFACE -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $LAN_INTERFACE -s $SUBNET1 -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $LAN_INTERFACE -o $INET_INTERFACE -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $INET_INTERFACE -o $LAN_INTERFACE -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $INET_INTERFACE -s $SUBNET1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

# Everything is now wide open and this is NOT SECURE, but it should allow
# any/every ethernet device on the subnet to access the internet.
#
# If it works, now add the following rule and see if it still does:

$IPTABLES -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# If you still cannot ping eth1, eth0, and also your primary DNS address, then
# there's more issues to address like static ip's, dhcp servers, and icmp
# stuff.

By the way, the solution to my problem was hinted at in Sum1's last sentence - the problem with the NAT setup was not in the iptables script at all, it was in the DHCP server configuration. It's all inter-related, you see.

Running Firefox remotely via SSH with X forwarding

We all love the neat trick of running X applications remotely:

$ ssh remote.host.org -XC
remote.host.org$ xeyes

Today I tried to do the same with Firefox to debug an issue where people from outside our office were getting "403 Forbidden" on one of our webservers. I ssh'ed to the remote machine so I could try to reproduce the problem. But I couldn't reproduce it. Looking in the Apache logs, I saw that the connections I was initiating were originating from my local machine, not the remote host.

After "staring into the abyss" for a long time, a colleague of mine suggested closing all my local Firefox windows. Suddenly it started to work. The reason is that the remote Firefox instance detected the local instance and decided to save network bandwidth by opening a window locally, instead of remotely as I was expecting.

Turns out this behavior can be disabled by running Firefox with the -no-remote option:

remote.host.org$ firefox -no-remote

There's a discussion of this issue at askubuntu.com

Find out MAC address from IP address

Find out MAC address from IP address:

# ping -c 1 $IP_ADDR ; /sbin/arp -n | grep $IP_ADDR

openSUSE: How to change hostname

Procedure for changing hostname on openSUSE 12.2:

1. Run YaST
2. Network devices -> Network settings
3. (If you get "Warning: Network is currently controlled by NetworkManager", just click "OK")
4. Open the Hostname/DNS tab
5. Fill in the desired hostname
6. Check "Change Hostname via DHCP" if desired
7. click "OK"

Even after doing that, though, the old hostname was still displayed on the XDM login screen. Annoying. So I decided to run a search for the old hostname over all ordinary text files in the /etc tree (see Basic usage of GNU find and GNU grep):

# find /etc -type f -exec grep -H oldhostname {} \;
./NetworkManager/NetworkManager.conf:hostname=oldhostname

Sure enough, after editing that file, the XDM login screen displayed the correct hostname.

NFS: How to remove stale entries in 'showmount -a' ?

The showmount -a command lists all NFS clients (by IP address) along with the NFS mount they have mounted.

If you run an NFS server, you may notice that stale entries can build up in the showmount listing. This is because entries remain there until explicitly unmounted by the client. If the client crashes or otherwise disappears, its entry remains in showmount forever. If you don't believe me, read the following excerpt from man rpc.mountd:

The rmtab File

The rpc.mountd daemon registers every successful MNT request by adding an entry to the /var/lib/nfs/rmtab file. When receivng a UMNT request from an NFS client, rpc.mountd simply removes the matching entry from /var/lib/nfs/rmtab, as long as the access control list for that export allows that sender to access the export.

Clients can discover the list of file systems an NFS server is currently exporting, or the list of other clients that have mounted its exports, by using the showmount(8) command. showmount(8) uses other procedures in the NFS MOUNT protocol to report information about the server's exported file systems.

Note, however, that there is little to guarantee that the contents of /var/lib/nfs/rmtab are accurate. A client may continue accessing an export even after invoking UMNT. If the client reboots without sending a UMNT request, stale entries remain for that client in /var/lib/nfs/rmtab.

Removing these stale entries is easy. Just clean out the rmtab file. In recent versions of SUSE Linux Enterprise Server (e.g. SLES11-SP2), the file is located at /var/lib/nfs/rmtab. If you can't find it there, consult the NFS server documentation for your vendor's system. (For example, on AIX the file is located at /etc/rmtab.)

Edit the file and remove the stale entries. Then try showmount -a again. You may need to restart the NFS server for the changes to take effect. On SLES11-SP2 this wasn't necessary.

Use SSH to run a non-X program or command remotely

If you're trying to run an X program remotely, you'll find lots of help on-line. But what if you want to remotely execute a script, program, or command-line command in regular old text mode? Where's the HOWTO for that?

There is none, because it's so obvious.

The 'ssh' command takes two arguments: a hostname (or IP address) and, optionally, a command. The command is run remotely on the host specified by hostname. For example, the following command executes the 'ls' command as 'root' on the host 'mysrv':

$ ssh root@mysrv ls
Password:
bin
inst-sys

DHCP via dnsmasq: client machine not receiving nameserver

Last night I set up dnsmasq on the Western Digital My Book World Edition, a NAS that acts as a server at our home.

I ran up against a problem: one of the client machine (my laptop) was not changing its nameserver settings. It would get an IP address via DHCP just fine, but the nameserver settings were either not being transmitted or not being received properly.

If I had been in my right mind, I would have tried a different machine as client to find out if the problem was on the server side or on the client side. As it stood, I kept examining the server side, but found nothing wrong there.

Nevertheless, it eventually occurred to my clouded mind that I could look in the log on the client side. Eureka!

Nov 17 20:45:34 r400 dns-resolver: ATTENTION: You have modified 
/etc/resolv.conf. Leaving it untouched...
Nov 17 20:45:34 r400 dns-resolver: You can find my version in 
/etc/resolv.conf.netconfig

True, I had modified /etc/resolv.conf -- no argument there. And when I looked in /etc/resolv.conf.netconfig, I saw that the nameserver settings from dnsmasq were there, but of course ineffectual.

The problem went away when I deleted /etc/resolv.conf (my modified version) and then disconnected/reconnected the network cable to the laptop. This let NetworkManager did its thing. After that, a new /etc/resolv.conf appeared with the correct nameserver settings.