Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

Suse network configuration

News

Suse

Recommended Books

Recommended Links

 Networking Links

Linux Networking

Linux route command

SMTP Mail Postfix Suse NFS VNC on Linux Network Utilities SSH Telnet Protocol
 FTP Pure FTP configuration Apache configuration NTP Rsync Samba SNMP
Ethernet Protocol ethtool Autonegotiation netstat Suse RC Scripts Humor

Etc

In recent versions of SUSE, the persistent naming of Ethernet devices is handled  through the udev kernel device management subsystem. If you want that the devices eth0, eth1, to be named in the way you get used to them in Red Hat, look in the directory /etc/udev/rules.d/. Here you will find a file with a name similar to 70-persistent-net.rules (the numerical prefix in this filename may vary). In this file, the network devices are listed, with their PCI identifiers in a comment above each one, and with the MAC (hardware) address. By editing the associated NAME variable, you can force the kernel to give the device a different name at the next reboot.

An example of this file, /etc/udev/rules.d/70-persistent-net.rules is shown here:

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules fil e.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x14e4:0x1677 (tg3)
SUBSYSTEM=="net", DRIVERS==" ?*", ATTR{address}==" 00:15:c5:0c:2f:5a", NAME="eth0"
# PCI device 0x8086:0x4223 (ipw2200)
SUBSYSTEM=="net", DRIVERS==" ?*", ATTR{address}==" 00:16:6f:6f:62:30", NAME="eth1"
 

If you want the wireless card to be called wlan0 in the future, you can simply replace NAME="eth1"
with NAME=" wlan0" in the second line. Or you can even choose to name the interfaces fred0 and
fred1 if you want to.

Interface configuration

All network interfaces are activated with the script /sbin/ifup. To halt the interface, use ifdown. To check its status, use ifconfig  or ifstatus.

SuSE stores the configuration of all network interfaces in way too many files, but mostly in /etc/sysconfig/network directory.  YaST  accepts manual changes from valid files.

Subdirectory /etc/syconfig/hardware/*  contains a separate file for every device (network card). These files contain the configuration parameters (kernel module, start mode, script assocations, etc.).

 The /etc/sysconfig/network directory contain a half-dozen of files (both "active files" and backups created by YAST (they have extention YaST2save) and five subdirectories :

-rw-r--r-- 1 root root 9254 Aug 21 12:06 config
-rw-r--r-- 1 root root 6615 Aug 22 12:15 dhcp
drwxr-xr-x 2 root root 4096 May 3 2007 if-down.d
drwxr-xr-x 2 root root 4096 Aug 21 12:09 if-up.d

-rw-r--r-- 1 root root 266 Sep 19 14:55 ifcfg-eth-id-00:1e:c9:b5:28:45
-rw-r--r-- 1 root root 376 Nov 11 08:26 ifcfg-eth-id-00:1e:c9:b5:28:47
-rw-r--r-- 1 root root 141 Apr 21 2008 ifcfg-lo
-rw-r--r-- 1 root root 27701 Apr 21 2008 ifcfg.template
-rw-r--r-- 1 root root 239 Apr 21 2008 ifroute-lo
drwxr-xr-x 2 root root 4096 Aug 21 12:06 ifservices.template
drwx------ 2 root root 4096 May 3 2007 providers
-rw-r--r-- 1 root root 282 Nov 13 13:20 routes
-rw-r--r-- 1 root root 306 Nov 6 16:04 routes.YaST2save
drwxr-xr-x 2 root root 4096 Nov 4 09:48 scripts

The first important files are ifcfg-eth*  files. Each of them corresponds to an installed Ethernet interface. They have suffixes equal to MAC addresses, a feature unique to Suse and not found in other distributions like Red Hat. 

Each ifcfg-eth* file contains a set of variables, one variable in the line.  For example:

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='10.10.1.1'
MTU=''
NAME='Broadcom NetXtreme II BCM5708 Gigabit Ethernet'
NETMASK='255.255.255.0'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
UNIQUE='JNkJ.swy66v437tA'
USERCONTROL='no'
_nm_name='bus-pci-0000:03:00.0'

Each interface has to have an IP address. This address is stored in IPADDR variable.

All the SUSE system scripts use the ip command for network configuration. Most modern version of Suse (10 SP3 and 11) (with kernel > 2.6.17) support frames larger than 1500 bytes. Jumbo frames are really only useful for reducing CPU load . A properly setup gigabit host should see file transfer rates within a small percentage of a jumbo frames enabled host. If you are not already starved for CPU cycles on your network devices don't worry about them. Jumbo frames are also great for high bandwidth, high latency connections (WAN links) but for LAN needs just go gigabit with quality managed switches . (see proper way to introduce jumbo frames into lan  ).

If you are young, smart, adventitious and rich you can try nonstandadrd frma size. You need to  have a gigabit or 10 gigabit NIC with sophisticated driver for example Intel driver see Documentation that supports such frames and  jumbo-frames clean switch (such as Cisco Catalyst 4000/4500 Switches with Supervisor III or Supervisor IV ). Upper limit is 9000 bytes (jumbo frames). They make sense only between hosts with latency so never do it on LAN. You will a lot of headache with little on no return on investment.  But Wan connections can definitely benefit from this setup. Set the following configuration directive, which specifies the size of the frame in bytes:

MTU='9000'

Close and save the file. Restart the Interface eth0:

# /etc/init.d/networking restart

To confirm the MTU used between two specific devices. use ip command as follows:

# ip route get {IP-address}

You can also specify this parameter in ifconfig  command:

ifconfig eth0 mtu 9000

This setting is not saved across reboots.

Virtual interfaces

Virtual interfaces are typically used for Web or ftp sites, so that each customer has its own IP address despite limited number of read Ethernet interfaces on the server.

A virtual interface involves assigning more than one IP address to a real interface. You simply take one existing interface (which has to be real) and let it "listen" to additional IP addresses. This way, you can configure your Web server can distinguish between traffic directed to these different IPs and point the requests to separate document trees, depending on the IP address the request went to.
 
In Linux, virtual interfaces are specified by adding a colon (:) and a number to the device name of the real interface. For example,  eth0:1 for the second address, eth0:2 for the third, and so on. Nothing else is needed. You can use these devices just as you'd use any real device.. You must set up the real device (in this case, eth0) before setting up the virtual interfaces.  Here is how they are reflected in the ifcfg files:

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='10.29.129.8'
IPADDR1='10.29.129.13'
IPADDR2='10.29.129.17'
MTU=''
NAME='Broadcom NetXtreme II BCM5708 Gigabit Ethernet'
NETMASK='255.255.255.0'
NETMASK1='255.255.255.0'
NETMASK2='255.255.255.0'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
UNIQUE='rBUF.swy66v437tA'
USERCONTROL='no'
_nm_name='bus-pci-0000:07:00.0'

Virtual interfaces are also useful if your network is set up in such a way that different subnets share one network segment, and you like to have your host be part of both (or all) subnets. The conventional method requires that you have a separate Ethernet card for each subnet you want to participate, even if they run on the same wire. With the virtual interface option, you can configure one card to listen to each subnet by assigning it one address for each subnet. It's even possible to set this up for routing, or to masquerade from one subnet to the other so that hosts that don't support virtual interfaces can communicate to the host of another subnet through the Linux machine.

Setting up static routing

We've discussed network configurations and what routing is used for. Now you're ready for setting up routing in SuSE Linux. YaST allows you to specify a default router in the format that you used to configure an interface. This is fine for a leaf node in a simple network. However, if the network has more than one router, or you actually want to set up a router, you'll need more than this. You need to specify a routing table. Even if YaST doesn't provide a way to set up a routing table, the SuSE Linux distribution has a fairly easy way to do this.

The routing table is set up in SUSE LINUX via the configuration files /etc/sysconfig/network/routes and /etc/sysconfig/network/ifroute-*. All the static routes required by the various system tasks can be entered in the /etc/sysconfig/network/routes file: routes to a host, routes to a host via a gateway, and routes to a network. For each interface that needs individual routing, define an additional configuration file: /etc/sysconfig/network/ifroute-*. Replace * with the name of the interface.

The file routes contains a routing table, which will be set up by the script /sbin/init.d/route whenever a networking runlevel (by default runlevels two and three) is reached. For example: 

10.29.9.100 10.29.129.1 255.255.255.255 -
10.4.33.238 10.29.129.1 255.255.255.255 -
10.29.2.13  10.29.129.1 255.255.255.255 -
10.29.2.18  10.29.129.1 255.255.255.255 -
10.29.7.0   10.29.129.1 255.255.255.0   -
10.192.0.0  10.29.129.1 255.192.0.0     -
default     10.29.129.3 -               -
	
The first column specifies a destination. This can be either a network address, a host address, or the string default for the default gateway. Whether the given address is a host or a network is determined by the netmask given in the third column. The network mask for a host is always 255.255.255.255. Everything else specifies a network route. Network route means a route to a network, whereas a host route is a route to a single host.

The second column gives either the IP address of the router, which should be used to reach the destination given in the first column, or the special value 0.0.0.0, which means that all traffic headed to the destination will be given to1 the device specified in the last column. If a gateway address is given, the device specification is optional.

The third column contains netmask.

Configuration files

  1. /etc/sysconfig/network/ifcfg-*

    These are the systems's configuration files for every network interface where "*" can be the name of the inteface (eth0, eth1, lo, ppp0...), its MAC address (ex: 00c09f2dc8a4) or indicate what hardware is used (usb, pcmcia).

    The main parameters used in these files are:
    BOOTPROTO - Can be static (IP configured manually), dhcp (IP oubtained through DHCP)

    IPADDR BROADCAST NETMASK NETWORK - Define typical IP parameters: IP address, broadcast, netmask and network address

    MTU - Defines the Maximum Transfer Unit (the size of every IP packet). Default on ethernet devices is 1500.

    STARTMODE - Indicates the to activate the interface: onboot (at system's boot), hotplug (when a pluggable network device is inserted), manual (manually).
    Other parameters can be used and can vary according to the interface type.

  2. /etc/syconfig/hardware/hwcfg-*

    These files contain the hardware configurations of network cards and other devices. They contain the needed parameters, such as the kernel module, start mode, and script associations. Refer to the manual page of hwup for details. Regardless of the existing hardware, the hwcfg-static-* configurations are applied when coldplug is started.

     
  3. /etc/sysconfig/network/config Contains various, well commented, variables that are applied to every interface, they include also what actions can be done when the interface status is changed.

  4. /etc/sysconfig/network/dhcp, similarly, sets parameters related to dhcp use (logging, lease time, timouts, modification of system's settings, wait time at boot and so on).

  5. /etc/sysconfig/network/wireless sets and describes the various parameters that can be applied to wireless devices (wieless mode, essid, frequency, sensibility, encryption key...). As usual they can be used in the ifcfg files of the single wireless devices, but it's useful to know the options than can be used.

  6. /etc/sysconfig/network/routes Defines generic (same for all interfaces) static routes. It's possible to specify routes exclusively related particular interfaces using files /etc/sysconfig/network/ifroute-interface.

    The format of this file is:

    DESTINATION  GATEWAY  NETMASK|PREFIX INTERFACE [TYPE] [OPTIONS]
     

  7. /etc/resolv.conf Defines, as in most Unixes, the address of one of several DNS servers to be used by the system and list of domain used to append to unqualified names (keyword search)

    Multiple domain names can be specified in serach statement. When resolving a name that is not fully qualified, an attempt is made to generate one by attaching the individual search entries.

    Some services, like pppd (wvdial), ipppd (isdn), dhcp (dhcpcd and dhclient), pcmcia, and hotplug, modify the file /etc/resolv.conf by means of the script modify_resolvconf.

    If the file /etc/resolv.conf has been temporarily modified by this script, it contains a predefined comment giving information about the service that modified it, the location where the original file has been backed up, and how to turn off the automatic modification mechanism. If /etc/resolv.conf is modified several times, the file includes modifications in a nested form. These can be reverted in a clean way even if this reversal takes place in an order different from the order in which modifications were introduced. Services that may need this flexibility include isdn, pcmcia, and hotplug.

    If it happens that a service was not terminated in a normal, clean way, modify_resolvconf can be used to restore the original file. Also, on system boot, a check is performed to see whether there is an uncleaned, modified resolv.conf (e.g., after a system crash), in which case the original (unmodified) resolv.conf is restored.

    YaST uses the command modify_resolvconf check to find out whether resolv.conf has been modified and will subsequently warn the user that changes will be lost after restoring the file. Apart from this, YaST will not rely on modify_resolvconf, which means that the impact of changing resolv.conf through YaST is the same as that of any manual change. In both cases, changes have a permanent effect. Modifications requested by the above-mentioned services are only temporary.

     

  8. /etc/hosts As in most Unixes, in this file you can statically assign IP addresses to host names. You can also use /etc/networks for IP networks. The resolver by default first checks this file, before querying the DNS servers in /etc/resolv.conf. This order and other settings about how the system assigns names to resources can be changed (as in every Linux) in /etc/host.conf (old configuration file used by libc4 and libc5 linked programs) or /etc/nsswitch.conf (used by every recent program linked with glibc libraries).

    If name server is not used  all hosts to which an IP connection will be set up must be listed here.  It also makes sesnce to list here critical hosts connectivity to which needs to be preserved if DNS server is down (for example monitoring server)

  9. /etc/HOSTNAME Contains the hostname of the system, used by various startup scripts.
  10. /etc/networks

    Here, network names are converted to network addresses. The format is similar to that of the hosts file, except the network names precede the addresses

    loopback     127.0.0.0
    localnet     192.168.0.0
  11. /etc/nsswitch.conf

    The introduction of the GNU C Library 2.0 was accompanied by the introduction of the “Name Service Switch” (NSS). Refer to man 5 nsswitch.conf and The GNU C Library Reference Manual for details.

    The order for queries is defined in the file /etc/nsswitch.conf. Comments are allowed and start with # sign.

    passwd:     compat
    group:      compat
    
    hosts:      files dns
    networks:   files dns
    
    services:   db files
    protocols:  db files
    
    netgroup:   files
    automount:  files nis
    

    The “databases” available over NSS are listed below

     Databases Available via /etc/nsswitch.conf

    aliases Mail aliases implemented by sendmail; see man 5 aliases.
    ethers Ethernet addresses.
    group For user groups, used by getgrent. See also the man page for group.
    hosts For host names and IP addresses, used by gethostbyname and similar functions.
    netgroup Valid host and user lists in the network for the purpose of controlling access permissions; see man 5 netgroup.
    networks Network names and addresses, used by getnetent.
    passwd User passwords, used by getpwent; see man 5 passwd.
    protocols Network protocols, used by getprotoent; see man 5 protocols.
    rpc Remote procedure call names and addresses, used by getrpcbyname and similar functions.
    services Network services, used by getservent.
    shadow Shadow passwords of users, used by getspnam; see man 5 shadow.

    Configuration Options for NSS “Databases”

    files directly access files, for example, /etc/aliases
    db access via a database
    nis NIS
    dns can only be used as an extension for hosts and networks
    compat can only be used as an extension for passwd, shadow, and group
  12. /etc/nscd.conf

    This file is used to configure nscd (name service cache daemon). See man 8 nscd and man 5 nscd.conf. By default, the system entries of passwd and groups are cached by nscd. hosts is not cached by default, because the mechanism in nscd to cache hosts causes the local system to be unable to trust forward and reverse lookup checks. Instead of asking nscd to cache names, set up a caching DNS server.

    If the caching for passwd is activated, it usually takes about fifteen seconds until a newly added local user is recognized. Reduce this waiting time by restarting nscd with the command rcnscd restart.

Network Utilities

SuSE features GNU variants of standard network utilities ifconfig, route, netstat. Several linux specific commands like ipifstatus  are also installed by default.

Status of network daemon can be displayed of changed with the service. To register init script you ca use chkconfig script.  command.  Here is the list of useful commands:

Networking start-up Scripts

Apart from the configuration files described above, there are also various scripts that load the network programs while the machine is booting. These are started as soon as the system is switched to one of the multiuser runlevels

Some networking start-up scripts

/etc/init.d/network the configuration of the network hardware and software when the system is booted. Restaring this script lean to rereading of all network-related configuration files.
/etc/init.d/inetd Starts xinetd.  Used only if there are xinetd services for example telnet.
/etc/init.d/portmap Starts the portmapper needed for the RPC server, such as an NFS server.
/etc/init.d/nfsserver Starts the NFS server.
/etc/init.d/sendmail Controls the sendmail process.  Postfix is default in Suse 10
/etc/init.d/ypserv Starts the NIS server.
/etc/init.d/ypbind Starts the NIS client.

 

Old News ;-)

[May 14, 2010]   Chapter 10 SuSE's scheme of network configuration

Setting up static routing
  
192.168.0.0   0.0.0.0         255.255.255.128  eth0  
default       192.168.0.1

This routing table is typical for a simple network host. It could be any host in Network A from Figure 9-2. As you can see, comment lines start with a hash sign (#) in the first column. Comment lines and empty lines are ignored when the route script sets up the kernel routing table.
 
The other lines represent routing table entries. The format is very close to the output of the route command, as we demonstrate in Chapter 9.
 
The first column specifies a destination. This can be either a network address, a host address, or the string default for the default gateway. Whether the given address is a host or a network is determined by the netmask given in the third column. The network mask for a host is always 255.255.255.255. Everything else specifies a network route. Network route means a route to a network, whereas a host route is a route to a single host. The second column gives either the IP address of the router, which should be used to reach the destination given in the first column, or the special value 0.0.0.0, which means that all traffic headed to the destination will be given to1 the device specified in the last column. If a gateway address is given, the device specification is optional.
 
To clearly illustrate this, we refer back to Figure 9-2 and have a look at the entries of the routing tables of the hosts and routers in this network.

Hosts in Network A These hosts use the table shown above. They can reach the subnet 192.168.0.0/25 directly over their ethernet card, and send everything else to Router A/B at 192.168.0.1.

Hosts in Network B Here we have two routers, Router A/B for traffic to Network A, and Router B/C for everything else:

# route to local subnet 'Network B'  
192.168.0.128 0.0.0.0         255.255.255.128  eth0 

# route to 'Network A'  
192.168.0.0   192.168.0.130   255.255.255.128

# default gateway is 'Router B/C'  
default       192.168.0.129

This example illustrates a very important point. All router addresses must be within a network that can be reached directly through an interface of this machine. This seems to be pretty obvious, because how should a host send packages to a router if it is not in the same network segment? And yet, this is a common mistake that is made when one is setting up routing tables. The address used for Router A/B must be 192.168.0.130 and not 192.168.0.1, because the latter one is not part of this subnet.

Hosts in Network C Same situation as in Network A. One router gets all the traffic not destined to the local subnet:

# route to local subnet 'Network C'  
192.168.1.0   0.0.0.0         255.255.255.0    eth0

# default router is 'Router B/C'  
default 192.168.1.1  

Router A/B This machine is directly connected to two subnets and forwards all traffic destined to Router B/C:

# route to 'Network A' (local)  
192.168.0.0   0.0.0.0         255.255.255.128  eth0  

# route to 'Network B' (local)  
192.168.0.128 0.0.0.0         255.255.255.128  eth1  

  # default gateway is 'Router B/C' default 192.168.0.129

Router B/C This machine is your connection to the Internet. We assume that it uses an ISDN link (which also is a point-to-point connection) to some router located at the ISP. As we stated previously, this router has the IP address 204.179.13.1. So besides setting up the routes for the local environment, you need to set up a route to this machine and then you can use this machine as the default gateway:

# route to 'Network C' (local)  
192.168.1.0   0.0.0.0         255.255.255.0    eth1  

  # route to 'Network B' (local) 192.168.0.128 0.0.0.0 255.255.255.128 eth0
  # route to 'Network A' (via 'Router A/B') 192.168.0.0 192.168.0.130 255.255.255.128
  # route to ISP router 204.179.13.1 0.0.0.0 255.255.255.255 isdn0
  # default router is ISP's machine default 204.179.13.1

Again you can see that you first need a route to the default gateway before you can use it as a hop to other hosts. Because the ISDN connection is point-to-point, this route is a host route. The netmask for a route to a single host is 255.255.255.255, which means that all bits of the netmask are set. There are no bits left to distinguish between different hosts in this address because it points to only one machine.
 
The basic principle of routing is to forward packages not destined to a local subnet to another router which knows how handle them. The example shown doesn't reflect this strategy, that is, the hosts in Network B could send all packages that don't go to machines in the same subnet to Router B/C. This router knows that traffic for Network A has to go to Router A/B. So why do you need the extra entry in the routing table for Network A? Well, you don't really need it; the setup would work without it. As soon as a host from Network B sends packages for a host in Network A to Router B/C (you still know what's going on?), it would get an ICMP redirect from Router B/C that tells it to send those traffic directly to Router A/B.

[Nov 12, 2008] Suse Enterprise Linux server Set Network card (NIC) to Full duplex setting

Jul 12, 2007 |  nixcraft.com

Changing your Network Interface Speed, Duplex or Auto Negotiate settings on Suse Enterprise Linux server.

1 # Login as root user

2 # Change directory to /etc/sysconfig/network/scripts
 

Code:
cd /etc/sysconfig/network/scripts
3 # Create a file called eth0-setup
 

Code:

vi eth0-setup
4 # Set eth0 to 100 duplex full, add following config line:
 

Code:

#!/bin/sh
/usr/sbin/ethtool -s eth0 speed 100 duplex full autoneg off
5 # Softlink /etc/sysconfig/network/scripts/eth0-setup to /etc/sysconfig/network/if-up.d
 

Code:

ln -s /etc/sysconfig/network/scripts/eth0-setup /etc/sysconfig/network/if-up.d
6 # More information - read man page
 

Code:

man ethtool
Also chk out : Linux add ethtool duplex settings to a network card permanently | nixCraft

 

[Sep 06, 2005] Virtual PC Guy's WebLog Making networking more robust under SuSE 9.3 under Virtual PC

I do not know when this happened - but in the last couple of releases of SuSE Linux they have taken a weird dependency on the MAC address of the network card.  To be precise - once you have configured your network card under SuSE - changing it's MAC address will cause SuSE to not initialize that network card (unless you remove and reconfigure it through YAST).

This is quite painful because - as I outlined here - Virtual PC can and will change the MAC address of the virtual network card from time to time.  And in my case (as I regularly move my virtual machines between Virtual PC and Virtual Server on different physical computers) the MAC address is getting changed almost constantly.

Thankfully there is a relatively easy (though not intuitive) way to solve this.  What you need to do is to get to a command prompt and type in the following commands:

  1. cd /etc/sysconfig/network

     

  2. ls

    At this stage you should see a file called 'ifcfg-eth-id-00:03:ff:xx:xx:xx' (substitute the 'xx:xx:xx' appropriately).  This is the cause of the problem.

     

  3. sudo mv ifcfg-eth-id-00\:03\:ff\:xx\:xx\:xx ifcfg-eth0

    Once again you should substitute the 'x's appropriately

Once you have done this you should be able to reboot the virtual machine and have the networking continue to work no matter what the MAC address is of the virtual network card.

Cheers,
Ben

Published Tuesday, September 06, 2005 7:46 PM by Virtual PC Guy

Filed under:

SuSE Networking - Professional Sysadmin's OpenSource Documentation Project

This is actually Red Hat config...

Changing Hostname Temporarly

Example: hostname newhostname.com

Changing Hostname Permanently

Edit the file /etc/HOSTNAME and change the value in it, Save and exit
To avoid dns errors edit the file /etc/hosts and create a line as below
192.168.1.50 newhostname alias
Change ip with your server ip and newhostname and alias with anything you have setup

Changing/Setting main ip

Edit the file /etc/sysconfig/network/ifcfg-eth0 and change the value of IPADDR, NETMASK , NETWORK and BROADCAST
Example ifcfg-eth0 file:
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
IPADDR=192.168.1.50
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
USERCTL=no
PEERDNS=no
TYPE=Ethernet
Description: Dont forget to restart network after the change with below command
/sbin/rcnetwork restart
Connect again using new ip if all is well.

Adding more IPs

# Copy the config file to create an alias ip
cp /etc/sysconfig/network/ifcfg-eth0 /etc/sysconfig/network/ifcfg-eth0:1
#Now edit the new file /etc/sysconfig/network/ifcfg-eth0:1 and change "DEVICE=eth0" to "DEVICE=eth0:1" and change ip to the new ip you want to assign. Save and exit. Then use tbe below command to bring it live.
/sbin/rcnetwork restart

Recommended Links

14.5. Routing in SUSE LINUX

Linux Headquarters Network Configuration Using SuSE YaST

Network Performance Fine Tuning in openSUSE & SUSE SUSE & openSUSE

SuSE + network - SWiK

Table Of Contents

SuSE HowtoForge - Linux Howtos and Tutorials

 



Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Disclaimer:

Last modified: May 28, 2010