When setting up virtual network interfaces in CentOS 6, many administrators encounter a puzzling scenario where simply copying ifcfg-eth0 to ifcfg-eth0:1 doesn't work as expected. The core issue manifests when the connection becomes unstable despite having PREFIX=24 defined, only to stabilize after adding NETMASK=255.255.255.0.

Examining the ifconfig output shows the critical difference:

// Unstable configuration
eth0:1    inet addr:69.64.93.x  Bcast:69.255.255.255  Mask:255.0.0.0

// Stable configuration after adding NETMASK
eth0:1    inet addr:69.64.93.x  Bcast:69.64.93.255  Mask:255.255.255.0

While PREFIX and NETMASK should theoretically represent the same network configuration (with /24 being equivalent to 255.255.255.0), there are important implementation differences:

• PREFIX is a newer notation that's part of the iproute2 toolkit
• NETMASK is the traditional subnet mask format
• Some legacy network scripts may not properly interpret PREFIX values

For guaranteed stability in CentOS 6 virtual interfaces, consider these approaches:

// Option 1: Use both PREFIX and NETMASK
DEVICE="eth0:1"
IPADDR=69.64.93.x
PREFIX=24
NETMASK=255.255.255.0

// Option 2: Convert to CIDR notation completely
DEVICE="eth0:1"
IPADDR=69.64.93.x/24

To verify your virtual interface configuration:

# Check current configuration
ifconfig eth0:1

# Test connectivity
ping -c 4 69.64.93.1
traceroute 8.8.8.8

# Verify routing table
route -n

While this specific issue occurs in CentOS 6, understanding the PREFIX/NETMASK relationship remains important because:

• Legacy systems still exist in production environments
• Migration scripts might need to handle both formats
• The knowledge helps troubleshoot similar issues in newer systems

For most reliable virtual interface setup in CentOS 6:

# /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE="eth0:1"
BOOTPROTO=none
ONBOOT=yes
IPADDR=69.64.93.x
NETMASK=255.255.255.0
GATEWAY=64.150.183.1
DNS1=69.64.66.11
DNS2=69.64.66.10

When working with virtual network interfaces in CentOS 6, I encountered an interesting case where using PREFIX=24 alone resulted in unstable connectivity, while explicitly adding NETMASK=255.255.255.0 stabilized the connection. Let's examine why these seemingly equivalent parameters behave differently.

Here's the unstable configuration (ifcfg-eth0:1):

DEVICE="eth0:1"
NM_CONTROLLED="yes"
ONBOOT=yes
HWADDR=00:26:18:24:4D:xx
TYPE=Ethernet
BOOTPROTO=none
IPADDR=69.64.93.x
PREFIX=24
GATEWAY=64.150.183.1
DNS1=69.64.66.11
DNS2=69.64.66.10
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0:1"

And the stable version with the added NETMASK:

NETMASK=255.255.255.0

The key difference appears in the ifconfig output:

// Unstable version
eth0:1    Link encap:Ethernet  HWaddr 00:26:18:24:4D:xx  
          inet addr:69.64.93.x  Bcast:69.255.255.255  Mask:255.0.0.0

// Stable version
eth0:1    Link encap:Ethernet  HWaddr 00:26:18:24:4D:xx  
          inet addr:69.64.93.x  Bcast:69.64.93.255  Mask:255.255.255.0

The issue stems from how the network subsystem interprets these parameters differently:

• PREFIX=24: Sometimes gets misinterpreted by older network scripts or certain network manager versions
• NETMASK=255.255.255.0: Provides explicit and unambiguous network configuration

For reliable virtual interface configurations in CentOS/RHEL 6:

# Recommended minimal configuration for alias interface
DEVICE="eth0:1"
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.1.100
NETMASK=255.255.255.0

If you still experience issues, consider these diagnostic steps:

# Check active configuration
ip addr show eth0:1

# Verify routing table
route -n

# Test network manager's interpretation
nmcli dev show eth0:1

Remember that consistency is key when working with network configurations - being explicit with NETMASK parameters often provides more reliable results than relying on PREFIX notation in older systems.