NX-OS Bash Shell DNS Configuration

Introduction

This document describes the steps used to configure DNS servers within Bash to allow for the resolution of DNS hostnames to IP addresses.

Cisco Nexus 3000 and 9000 series devices allows access to NX-OS's underlying Linux system through Bash (Bourne-Again SHell). Bash enables system management and monitoring through a Linux environment. For more information about Bash on NX-OS, refer to the Bash chapter of the Cisco Nexus 9000 Series NX-OS Programmability Guide.

It may be necessary to translate human-friendly domain names into numeric IP addresses while performing normal tasks in the Bash shell. Such tasks include using the curl or wget utilities to access resources from a web server, or downloading Docker images using the docker pull command.

Prerequisites

Requirements

This document requires the Bash shell to be enabled on your Cisco Nexus device. Refer to the "Accessing Bash" section of the Bash chapter in the Cisco Nexus 9000 Series NX-OS Programmability Guide for instructions to enable the Bash shell.

Components Used

The information in this document is based on these software and hardware versions:

• Nexus 9000 platform starting from NX-OS Release 6.1(2)I2(1)
• Nexus 3000 platform starting from NX-OS Release 6.0(2)U4(1)

The information in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Bash Shell DNS Configuration

The Linux environment accessed through the Bash shell utilizes the /etc/resolv.conf file to store DNS configuration, similarly to most other Unix-like operating systems.

1. Log into the Bash shell as the root user through the run bash sudo su - command.

Nexus# run bash sudo su -
root@Nexus#whoami
root

2. View the current contents of the /etc/resolv.conf file. In the below example, the file is empty.

root@Nexus#cat /etc/resolv.conf
root@Nexus#

3. Open the /etc/resolv.conf file for editing using the vi text editor.

root@Nexus#vi /etc/resolv.conf

4. Press the i key to enter INSERT mode, then enter your desired configuration. Refer to the "/etc/resolv.conf File Format" section of this document for more information about how the format of configuration within the /etc/resolv.conf file.

5. After modifying the file as desired, press the ESC key to exit INSERT mode, then enter :x to save all changes to the file and close it.

Bash Shell DNS Verification

After making changes to the Bash shell's DNS configuration, one should verify that the changes result in successful domain name resolution. The simplest method of testing domain name resolution is through using the ping utility using a domain hostname as a target. This document will demonstrate how to verify valid DNS configuration using a test host of "test.cisco.com" and DNS servers of 192.168.2.1 and 192.168.2.2.

1. Verify use of a valid network namespace to test.

By default, the Bash shell uses the "default" network namespace unless instructed otherwise. Network namespaces are logically equivalent to NX-OS VRFs, and the ip netns command will display a list of namespaces that are available to the Bash shell, as demonstrated below:

root@Nexus#ip netns
EXAMPLE-VRF (id: 2)
management (id: 1)
default (id: 0)

A valid network namespace to test with is one that has IP connectivity to the DNS nameservers configured in the /etc/resolv.conf file, as well as IP connectivity to the IP address that your test host resolves to.

One can utilize the ip netns exec {namespace} {desired-command} command to execute a command {desired-command}in the namespace {namespace}. Alternatively, one can execute the Bash shell within the context of a specific namespace with the ip netns exec {namespace} bash command. The former methodology is used in the below example, where it is verified that the "management" namespace has IP connectivity with the IP address owned by the test.cisco.com host (which is 192.168.2.100) and both DNS servers (192.168.2.1 and 192.168.2.2).

root@Nexus#ip netns exec management ping 192.168.2.100 -c 5
PING 192.168.2.100 (192.168.2.100) 56(84) bytes of data.
64 bytes from 192.168.2.100: icmp_seq=1 ttl=59 time=0.277 ms
64 bytes from 192.168.2.100: icmp_seq=2 ttl=59 time=0.284 ms
64 bytes from 192.168.2.100: icmp_seq=3 ttl=59 time=0.280 ms
64 bytes from 192.168.2.100: icmp_seq=4 ttl=59 time=0.274 ms
64 bytes from 192.168.2.100: icmp_seq=5 ttl=59 time=0.297 ms

--- 192.168.2.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.274/0.282/0.297/0.017 ms

root@Nexus#ip netns exec management ping 192.168.2.1 -c 5
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=59 time=0.277 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=59 time=0.284 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=59 time=0.280 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=59 time=0.274 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=59 time=0.297 ms

--- 192.168.2.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.274/0.282/0.297/0.017 ms

root@Nexus#ip netns exec management ping 192.168.2.2 -c 5
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
64 bytes from 192.168.2.2: icmp_seq=1 ttl=59 time=0.277 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=59 time=0.284 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=59 time=0.280 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=59 time=0.274 ms
64 bytes from 192.168.2.2: icmp_seq=5 ttl=59 time=0.297 ms

--- 192.168.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.274/0.282/0.297/0.017 ms

2. Verify functioning DNS resolution using the test host's hostname.

Use the ping utility with a target of the test host's hostname. If ICMP Replies are received from the test host, and the IP address contained within the ICMP Replies is the IP address we expect the hostname to resolve to, then DNS resolution is confirmed to be working within the Bash shell.

The below example demonstrates how the ping utility can be used within the "management" namespace to verify correct DNS resolution. Note how the domain hostname of "test.cisco.com" resolves to "192.168.2.100", which is the IP address we expect that hostname to resolve to.

root@Nexus#ip netns exec management ping test.cisco.com -c 5
PING test.cisco.com (192.168.2.100) 56(84) bytes of data.
64 bytes from test.cisco.com (192.168.2.100): icmp_seq=1 ttl=59 time=0.617 ms
64 bytes from test.cisco.com (192.168.2.100): icmp_seq=2 ttl=59 time=0.341 ms
64 bytes from test.cisco.com (192.168.2.100): icmp_seq=3 ttl=59 time=0.310 ms
64 bytes from test.cisco.com (192.168.2.100): icmp_seq=4 ttl=59 time=0.379 ms
64 bytes from test.cisco.com (192.168.2.100): icmp_seq=5 ttl=59 time=0.296 ms

--- test.cisco.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 0.296/0.388/0.617/0.119 ms

If the namespace used to test DNS resolution has IP connectivity to the Internet, one can ping "cisco.com" to verify that external domain names can be resolved in addition to internal domain names. This is particularly important if one needs to use utilities such as curl and wget against public web servers. The below example demonstrates how the ping utility can be used within the "management" namespace (which has IP connectivity to the Internet) to verify correct external DNS resolution.

root@Nexus#ip netns exec management ping cisco.com -c 5
PING cisco.com (72.163.4.161) 56(84) bytes of data.
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=1 ttl=239 time=29.2 ms
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=2 ttl=239 time=29.2 ms
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=3 ttl=239 time=29.3 ms
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=4 ttl=239 time=29.2 ms
64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=5 ttl=239 time=29.2 ms

--- cisco.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 29.261/29.283/29.335/0.111 ms

/etc/resolv.conf File Format

Some common configuration parameters are explained and demonstrated below. Be sure to modify all configuration parameters to match your environment.

• domain {domain-name.tld} - Defines a default domain name {domain-name.tld} to append to hostnames that do not end with a period. There can only be one domain entry within the /etc/resolv.conf file.
• search {domain-name-1.tld} [domain-name-2.tld...] - Defines a space-delimited list of domain names ({domain-name-1.tld} and, optionally, [domain-name-2.tld]) to append to hostnames. 

Note: The domain and search entries are mutually exclusive - only one can be in use at a time. If both entries are included in the /etc/resolv.conf file, the entry that appears last in the file will be used.

• nameserver {address-1} - Defines an IP address {address-1} for a DNS server where DNS resolution requests are forwarded to. Multiple nameserver entries are allowed within a single file, up to a maximum of three.

Examples

The following example shows the contents of the /etc/resolv.conf file where the default domain of the environment is "cisco.com", and DNS servers within the environment have IP addresses of 192.168.2.1 and 192.168.2.2. In this scenario, if the Bash shell needs to resolve the IP address for a device with a hostname of "foo", it will append "cisco.com" to the end of the hostname such that the FQDN (Fully Qualified Domain Name) of the host is "foo.cisco.com".

domain cisco.com
nameserver 192.168.2.1
nameserver 192.168.2.2

The following example shows the contents of the /etc/resolv.conf file where either the "cisco.com" or the "bar.com" domain names may be used to resolve DNS hostnames. DNS servers within the environment have IP addresses of 192.168.2.1 and 192.168.2.2. In this scenario, if the Bash shell needs to resolve the IP address of a device with a hostname of "foo", it will attempt to resolve "foo.cisco.com" first, then attempt to resolve "foo.bar.com" next if the resolution for "foo.cisco.com" fails.

search cisco.com bar.com
nameserver 192.168.2.1
nameserver 192.168.2.2

Related Information

• Cisco Nexus 9000 Series NX-OS Programmability Guide, Release 9.x
• Cisco Nexus 9000 Series NX-OS Programmability Guide, Release 7.x
• Cisco Nexus 9000 Series NX-OS Programmability Guide, Release 6.x
• Cisco Nexus 3000 Series NX-OS Programmability Guide, Release 9.x
• Cisco Nexus 3000 Series NX-OS Programmability Guide, Release 7.x
• Cisco Nexus 3000 Series NX-OS Programmability Guide, Release 6.x
• Cisco Nexus 3500 Series NX-OS Programmability Guide, Release 9.x
• Cisco Nexus 3500 Series NX-OS Programmability Guide, Release 7.x
• Cisco Nexus 3500 Series NX-OS Programmability Guide, Release 6.x
• Cisco Nexus 3600 Series NX-OS Programmability Guide, Release 9.x
• Cisco Nexus 3600 Series NX-OS Programmability Guide, Release 7.x
• Programmability and Automation with Cisco Open NX-OS