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

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Suse network configuration

News

Linux Networking Suse

Recommended Books

Recommended Links

 Networking Links

Linux Networking

Linux route command

Linux ifconfig Routing Linux route command netstat Traceroute Nmap ntop martian source
Suse /etc/sysconfig
/network/route file
Suse NFS NTP VNC SSH Telnet Protocol   Network Utilities
 FTP Pure FTP configuration Sendmail SMTP Mail

Postfix

Rsync Samba SNMP
Ethernet Protocol ethtool Autonegotiation Suse RC Scripts   Horror Stories 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.  For example, permanently to change MTU (you can change it "on the fly" via ifconfig, but this change does not survive reboot)  you need edit the MTU line in the interface file, for example /etc/sysconfig/network/ifcfg-eth0 and then restart network layer with

service network restart

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

The /etc/sysconfig/network directory contain a half-dozen of files (both "active files" and backups created by YAST (they have extension YaST2save) and four subdirectories. For example for Suse 11 SP1 :

-rw-r--r-- 1 root root 13243 2012-10-04 17:34 config
-rw-r--r-- 1 root root  6481 2012-10-04 17:34 dhcp
-rw------- 1 root root   194 2013-02-26 11:29 ifcfg-eth0
-rw------- 1 root root   190 2012-10-04 17:34 ifcfg-eth0~
-rw------- 1 root root   190 2012-10-04 17:34 ifcfg-eth1
-rw------- 1 root root   174 2012-04-19 20:33 ifcfg-lo
-rw-r--r-- 1 root root 27909 2012-04-19 20:33 ifcfg.template
drwxr-xr-x 2 root root  4096 2012-10-04 17:34 if-down.d/
-rw-r--r-- 1 root root   239 2012-04-19 20:33 ifroute-lo
drwxr-xr-x 2 root root  4096 2012-10-04 17:34 if-up.d/
drwx------ 2 root root  4096 2010-05-05 10:04 providers/
-rw-r--r-- 1 root root    72 2012-01-12 15:16 routes
-rw-r--r-- 1 root root    26 2012-01-12 15:16 routes.YaST2save
drwxr-xr-x 2 root root  4096 2012-10-04 17:34 scripts/

The first important files are ifcfg-eth*  files. Each of them corresponds to an installed Ethernet interface. In suse 10 they used to have suffixes equal to MAC addresses, but this unique to Suse arrangement was dropped in Suse 11. 

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

BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='10.101.105.9/24'
MTU=''
NAME='NetXtreme II BCM5709 Gigabit Ethernet'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'

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 might be useful for reducing CPU load but whether the game worth the candles can be determined only by measurements. A properly setup gigabit host should see better file transfer rates (by a small percentage) on a jumbo frames enabled host and router (router should be able to accept jumbo frames too and need to be configured this way). If you are not starved for CPU on you server you probably can ignore their existence. Jumbo frames might make sense for high bandwidth, high latency connections (WAN links), but for the local LAN they are less attractive (see proper way to introduce jumbo frames into lan).

If you are young, smart, adventitious and rich you can try juble frame size just for fun. 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 get a lot of headache with little (or no) return on investment.  But WAN connections can  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 an example from SLES 10:

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.

Static routing

You specify static routing using route command. 

To make routing entries permanent you need to put them into a static table of static routes that will be read on boot. It is stored in /etc/sysconfig/network/route file

For more information see Linux route command

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.

Top updates

Bulletin Latest Past week Past month
Google Search


NEWS CONTENTS

Old News ;-)

[Feb 25, 2013] Linux MTU Change Size

... ... ...

Changing the MTU size with ifconfig command

In order to change the MTU size, use /sbin/ifconfig command as follows:

ifconfig ${Interface} mtu ${SIZE} up
ifconfig eth1 mtu 9000 up

Note this will only work if supported by both the network interface card and the network components such as switch.

Changing the MTU size permanently under CentOS / RHEL / Fedora Linux

Edit /etc/sysconfig/network-scripts/ifcfg-eth0, enter
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
Add MTU, settings:
MTU="9000"
Save and close the file. Restart networking:
# service network restart
... ... ...

[Feb 18, 2011] 14.5. Routing in SUSE LINUX

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 entries in the routing configuration files look like this:

DESTINATION           GATEWAY NETMASK   INTERFACE [ TYPE ] [ OPTIONS ]
DESTINATION           GATEWAY PREFIXLEN INTERFACE [ TYPE ] [ OPTIONS ]
DESTINATION/PREFIXLEN GATEWAY -         INTERFACE [ TYPE ] [ OPTIONS ]

To omit GATEWAY, NETMASK, PREFIXLEN, or INTERFACE, write - instead. The entries TYPE and OPTIONS may just be omitted.

The following scripts in the directory /etc/sysconfig/network/scripts/ assist with the handling of routes:

ifup-route
for setting up a route
ifdown-route
for disabling a route
ifstatus-route
for checking the status of the routes

 

[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

 




Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2014 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. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 18, 2014