If neither ARP or ethers returns a result, Wireshark tries to convert the first 3 bytes of an ethernet address to an abbreviated manufacturer name, which has been assigned by the IEEE e.
The following topics are covered: NPort will indicate a valid connection to the Ethernet in This chapter includes the following sections: Obtain a valid IP address for your NPort from your network administrator.
Type 2 to select Network settings, and then press Enter. Type 1 to select IP address and then press Enter. Press any key to continue. Type m and then press Enter to return to the main menu. Input the password when prompted. Note that this page will only appear when the NPort has been set up for password protection.
Start configuring the IP address under Network Settings. Refer to step 4 in the Telnet Console section for instructions on how to configure the rest of the IP settings. After choosing the proper operation mode in this chapter, refer to Chapter 5 for detailed configuration parameter definitions.
Your computer can access, manage, and configure remote facilities and equipment over the Internet from anywhere in the world. In UDP mode, you can unicast or multicast data from the serial device to one or multiple host computers, and the serial device can also receive data from one or multiple host computers, making this mode ideal for message display applications.
This chapter introduces the Web Console function groups and function definitions. Open your browser with the cookie function enabled. To enable your browser for cookies, right click on your desktop Internet Explorer icon, select Properties, click on the Security tab, and then select the three Enable options as shown in the figure below. Examples shown in this chapter use the Factory Default IP address The NPort homepage will open. In some cases, you may want to Disable one or both of these console utilities as an extra precaution to prevent unauthorized users from accessing your NPort Your network system administrator should provide you with an IP address and related settings for your network.
An IP address is a number assigned to a network device such as a computer as a permanent address on the network. Computers use the IP address to identify and talk to each other over the network.
A domain name is an alphanumeric name, such as moxa. Reports generated by the Auto report function will be automatically sent to this IP address. The optimal Force transmit timeout depends on your application, but it must be at least larger than one character interval within the specified baud rate. The connection is closed if there is no incoming or outgoing data through the serial port during the specific Inactivity time.
Disable the force transmit timeout. To prevent the unintended loss of data due to the session being disconnected, it is highly recommended that this value is set large enough so that the intended data transfer is completed.
Therefore, you should set Force transmit timeout to be larger than 8. To avoid conflicts with standard TCP ports, the default is set to TCP alive check time Refer to the following table for more configuration examples. Allowable Hosts Any host The Auto warning function may not work properly if it is not configured correctly.
If the NPort is unable to send an e-mail message to the mail server within 15 seconds, NPort will reboot anyway, and abort the e-mail auto warning. Leave the password boxes blank to erase the password. If the password is erased, then NPort will not have password protection. Configuring Windows Administrator Chapter 6 The following topics are covered in this chapter: Windows Administrator provides five function groups that ease the installation process, allows off-line COM mapping, and provides monitoring and IP location server functions.
Click on Next to install program files in the default directory, or select an alternative location. Click on Next to install the program using the default program name, or select a different Click on Install to proceed with the installation. The Installing window reports the progress of the installation. Click on Next to proceed with the installation. The top part is the function list and online help area. Windows NT does not support this. The left part lists the five Administrator function groups.
When the search is complete, the Broadcast Search window closes, and the NPort s that were located are displayed in the right pane of the Administrator window. If you found more than one server connected to this network, refer to the MAC address sticker on your server s to determine which servers are the ones you wish to configure.
If the NPort is password protected, then you will not be able to use the right click method to open the configuration page. Administrator will keep this NPort in the Unlock status throughout this Administrator session.
The meanings of the six states are as follows note that the term Fixed is borrowed from the Input the password to Unlock the NPort Right click on a specific NPort and select configure to start the configuration. You may want to back up your kernel config before you do this.
Once this is done go back into the ipvs directory and run. Most notably, the ksyms. If your kernel was built from an existing source tree and you did not run 'make mrproper' first, odds are the files in the forementioned directory are stale.
Be sure to state that versions should be assigned to module symbols in the kernel configuration before doing so. The you turned on some options, like say netfilter, in a tree that had alredy been built and some object files didn't get rebuilt even though they should have been, and thus some symbols are missing. I remember seeing this a lot with 2. Fortunately its easy, though a little time consuming to solve.
Setup an LVS with two networks here For the test, don't have any other IPs on the machines. The VIP on the ethernet alias eth0: There should be no default routes, and all interfaces on the The client won't be able to connect to anything till the VIP is enabled on the director.
You must have two networks for this setup to work. Here one NIC is used on the director you can use two if you like, but you'll have to change the setup yourself. If you want all machines on the one network It removes the default gw for the director which should be the local router. You'll have to add this back by hand. One of the big traps in setting up a LVS-NAT LVS is that you have to make the director the default route for the realservers the script does this for you - it won't work if you don't do this.
Now telnet from the client to You will get the login prompt from one of the realservers note which one. Then on the director re-run ipvsadm. Open another window on the client and telnet to You should get the login prompt for the other realserver.
You are now connected to the realservers by a telnet session. Make sure the realservers are serving http with each realserver listening to port 80 on its own IP the RIP, e. Make the 2 webpages a little different so that you can tell which machine you have connected to. Change the conf file by uncommenting the http line and commenting out the telnet line in the conf file.
Rerun the configure script on the new conf file, rerun the rc. For configuration by hand, substitute http for telnet in the director script - you don't need to run the realserver script again. Direct your http client to If you get the expected webpage, shift-reload a few times for netscape , watching the webpages alternate between realservers. In some circumstances, presumably due to http persistance, the connection will persist on one realserver. In this case use lynx, curl or telnet to Unlike telnet there are no ActiveConn seen even though you have a webpage displayed on the client.
The http protocol disconnects after 15secs changing the connections to InActConn. These expire in about 2 mins re-run ipvsadm after 2mins and see that InActConn drops to 0. The template timeout can be seen by invoking ipchains -L -M -n for 2. Setup an LVS with a single network here The IPs on ethernet aliases eg eth0: There should be no default routes and all machines should be able to ping each other. I only turned it off because you don't need it on for LVS-DR, and turning it off makes the machine more secure.
You can turn it on if you have other reasons to do so. If you have tcpwrappers running around telnet on the realservers, the login will be delayed by an interval between 7secs Slackware and 3mins RedHat. You can fix this by changing the line in inetd. If you have a pam-ified telnetd and login, you may never be able to fix this delay RedHat 6.
After logging in, the telnet session behaves normally. This delay is only a minor nuisance, but it is difficult to differentiate from a hung connection due to an LVS misconfiguration which hopefully would have been picked up when running the configure script. Open another window on the client and telnet again to You are now connected to the realservers be a normal telnet session.
Make sure the httpd on the realservers are listening to VIP: The connection from the lvs client will arrive at VIP: You will need the VIP setup on lo: You also can have the httpd listening on the RIP, here Make the webpage on each realserver a little different so that you can tell which realserver you have connected to.
Rerun the configure script on the conf file, rerun the rc. You don't need to rerun the script on the realservers. Connect your http client to If you get the expected webpage, shift-reload a few times, watching the webpages alternate between realservers. In this case use lynx or telnet to The http protocol disconnects after 15secs max. The connections change to InActConn and expire in about 2 mins. If you then re-run ipvsadm the InActConn will drop to 0. If you have any questions, join the mailing list.
The original posting is at lvs mailing list archives. Okay, this is the last time I post on this, I promise. I hope that it may be of use to someone sometime. Directors are running 2. Squid did not work with 2.
Firstly I created the director. I used instructions written by Dan Browning above to configure the kernel Note, I only used the kernel config bit, I've edited it for 2. For the real servers I just repeated the above process but with the default kernel 2. The ipvsadm patch isn't necessary but what the hell, that's what I did. It would probably work without the ipvsadm patch and just the hidden patch.
Initially I decided to set up an http LVS using 1 director and 3 http realservers. Http purely because it's easier to ascertain as to whether it's working or not. So I setup apache on the three machines, making the root index page to just say the name of the machine. Then I used Joe Mack's configure script with my config to generate the rc. I then chose the closest match to my network of the 12 or so example configs and edited it to look like this.
IPs etc deleted for convenience. At this point by typing ipvsadm at the prompt you should get something like this showing that your LVS is running. Then to test it go to a browser on another box and type http: This will only happen with RR scheduling but it proves the point nicely. And ran the resulting rc. In the meantime I discovered that if I restarted the network on the realservers after the rc. Also during this time whilst Joe was working on the alterations to the configure script I set about testing the Squid LVS and writing scripts to handle realserver failure and set about introducing a backup director.
At this stage I had a squid LVS which was using rr scheduling, it soon became apparent that rr scheduling wasn't going to work on it's own. I have found that wlc with a persistence of seconds works beautifully. This ensures that requests from a particular client are sent to the same realserver for 6 minutes that's a rolling 6 minutes. The timeout can be increased, but most banking facilities will timeout a connection if inactivity exceeds a few minutes.
It's possible to setup two boxes as a fully functional failover LVS. When one box is the director, it is also serving as a realserver with localnode and the other box is another realserver. The two boxes run failover code to allow them to swap roles as directors. This is more complicated than you'd want for one of your first setups, and in practice there are problems handling the failover. You probably installed a kernel binary and when you try to compile ipvsadm , you get error messages about missing header files.
You should also remove ipchains support from your kernel so that no-one else can fall into the same trap. You may have forgotten to compile the new version of ipvsadm after rebooting the computer following loading the LVS-patched kernel and you're using an old ipvsadm.
Setting up an LVS from scratch for the first time requires some thinking, is somewhat tedious and non-obvious and there are many ways of getting it wrong. Confounding the problem, there are several ways in which the LVS appears to work, but you are just connecting directly to the realservers rather than forwarding packets through the director. Understanding how an LVS works will require some investment in time. Our answer till now has been to try to translate your posting into our language and then figure out what you've done wrong.
We haven't seen any new problems in setting up a basic LVS since the early days, but replying to the same requests does take a lot of time. There are still plenty of postings about how an LVS does or doesn't work that no-one has thought about, which we are interested in. Occasionally after 10 exchanges with 3 people on the mailing list trying to help figure out what's wrong, the original poster will suddenly remember that they have filter rules which they'd "checked out thoroughly" and were sure were working that they "forgot to tell us about".
If you don't want to use a configure script, there is enough information here for you to setup a working LVS from the command line. If you can't setup an LVS, with 1 or 2 realservers serving telnet or httpd , then rather than getting us to figure out what you've done wrong, how about you use the tools we've provided, to setup the basic LVS.
Once you have a working basic LVS, then you can branch out and try to set it up your own way. If you can't get the scripts to work, then we'll try to fix those. If you need to contact us, first look at the problem report information HOWTO needed to solve problems. The machine that receives the request packet is replying that it is not listening for that service. Possible reasons for this are with help from Ratz.
The packets from the client are getting to the realserver, but replies are not getting back to the client. Is there a route from the realserver to the client? If packets weren't making it to the realserver, the client would get icmp packets showing "no route to host" or "connection refused". If your LVS is working and you have connections that disconnect like with http , by the time you've downloaded your page, the connection will be in the InActConn state. See httpd is stateless and normally closes connections http: Connections being in InActConn state is a diagnostic only if the connection is hanging i.
Simplest thing is to stop your service on the realserver from calling the identd server on the client i. Another problem, which causes slowness in any situation, is DNS timing out on a call. However if you have DNS, make sure there are entries for all IPs on that machine if you have multiple interfaces and any machine that you'll be calling. To check, run commands that need name resolution e. If either of these pause, rerun them in the form which doesn't need name resolution netstat -an , route -n to locate the entries forcing the pause - these don't have name resolution.
I've had trouble with this once when my routing was wrong and ICMP had to figure it out for me. Another possibility is a delay from DNS lookup. This delay seems symptomatic of Apache or the application it's providing doing a reverse lookup for the calling IP, and timing out. Subsequent connections in the same session will then be fine as the resolver libraries will cache the negative or failed response until some time later.
Alternatively, does the application need to do some sort of callback? The most likely explanation is that you haven't solved the arp problem http: To check that you've handled the arp problem you can test the interface on the realserver http: First take your realserver offline pull the network cable and start the service listening on RIP: Check that the service initially telnet is running netstat -an.
Then use your usual client a web browser say. Make sure your service can do all the things that you expect the client on the internet to be able to do. Check that ipvsadm shows your realserver: Then connect to the VIP: Then use your usual client for the service eg a webbrowser. If your connection requests aren't connecting, then you need to see where the packets are being stopped. You can watch packets with tcpdump or netstat -an to see whether the request has left one node or arrived at another and to see if replies have been made.
Joseph Mack jmack at wm7d dot net. Table of Contents 1. Location of this document 1. What an LVS does 2. Initial service for testing should be telnet or netcat 2. Test without filter iptables rules 2. Use the standard kernel 3. Use standard utilities not ifup 3.
Realserver OS by forwarding method 3. Do you need to handle the arp problem? Methods of handling the arp problem 3. Configure scripts, tools 3. Install - General 3. Director kernel - build it yourself 3. How do I check to see if my kernel has the ip-vs patch installed? Listing symbols in the kernel 3. Setup using the configure script 4. Setup by hand 4. VS-DR for the service telnet 5. Setup by hand 5. How users have done it 6.
Jezz Palmer, setup of LVS squid 6. Two Box LVS 7. What if there are problems 7. Can't compile ipvsadm 7. My LVS doesn't work 7. The client says "connection refused" 7. Netmask for VIP wrong 7. My LVS doesn't loadbalance, the client always goes to the same realserver 7. My LVS still doesn't work: Location of this document. What an LVS does. The director can forward packets by 3 methods. The realserver just has to have a tcpip stack - even a network printer will do. Choose number of networks.
The network that the director's VIP is on. The client connects to the the VIP and must be able to route to it. In the examples here, the VIP is on a private network, for convenience of testing. The network that the realservers are on. In general these will be private IPs, since the client doesn't connect to the realservers directly and doesn't need to know that the realservers even exist the client only thinks there is one machine at the IP of the VIP.
Note The VIP is usually on an ethernet device e. However dec at rm-f dot net 01 Jun put it on lo and the LVS worked just fine. Choose number of NICs on director. Initial service for testing should be telnet or netcat. Test without filter iptables rules. Use the standard kernel. Use standard utilities not ifup. Note Do not run make patchkernel on the 2. These kernels are already patched with LVS. Despite its name make patchkernel is replacing files, rather than patching them and the command will succeed but produce a kernel which will not compile.
It's probably best to skip 2. A tar ball which you can use to build LVS outside or inside the kernel tree. And a patch which can only be used to build LVS inside the kernel tree. Note Make sure you get the ipvsadm for your kernel series. The various kernel verions 2. However there is only one numbering series for versions of ipvsadm. You can't tell the target kernel from the ipvsadm verion number e. If you just get the latest ipvsadm Jan is v1. This will require you to remember that after you boot to your new kernel, you still have one more step, of compiling and installing ipvsadm.
Realserver OS by forwarding method. Since only one IP is needed, anything with a tcpip stack is OK. You can use a networked printer as a realserver. LVS-Tun - only linux. You need the tunl0 device to decapsulate the ipip packets turn on in the kernel configuration under "Network options". Windows had tunneling for a short while in their later versions, but then dropped it. No kernel patches needed.
There are no patches in the kernel to handle the arp problem. The risk is that other hosts can probe for VIP using unicast packets which the hidden flag always replies. I'll continue to support the hidden flag for 2.
Methods of handling the arp problem. You patch by doing realserver: You don't have to patch the kernel, you just load the module. Maurizio's module acts on the IP, not the device, so you can make the VIP noarp while letting other IPs on the same device reply to arp requests. This is currently Feb available for 2. This would appear to be the simplest way of handling the problem, except that people are wary of writing iptables rules. No-one seems to be using this method.
The realservers must be on the same network as the director the realservers and director can arp each other. VS-NAT, lower throughput, higher latency. Realserver only needs tcpip stack ie any OS, even a network printer.
Works for multiple instances of services i. VS-Tun, Linux only realservers. Needed if realserver on different network to director eg in another location. Joe wrote configure script for all LVS types, which does a lot of sanity checking on setup but doesn't handle director failover single director only. The configure script will setup mon to handle failure of services on realservers. Note the configure script tests and uses the links between all machines - the network should be working already.
I never released v0. Installing the configure script. It assumes there is only one director. Test with something else eg http.
What you'll be doing. I downloaded the kernel from kernel. I downloaded the ipvs patch use the single patch I downloaded the hidden patch.
Don't apply each patch more than once! If it didn't work following these steps and you have RH 7. If you must, put the cd back in the drive, and do an "upgrade", and install the tools necessary If that isn't it, make sure your gcc is up to date.
An easy way of doing this is by downloading red-carpet from Ximian. It is an Xwindows updater. You do not have to have gnome to run this anymore.
Director kernel - build it yourself. Note This is the preferred method. Get a fresh kernel from ftp. Note The instructions below are for an early 2. Note I have removed the ipchains option here. From there check the loaded modules with lsmod. Listing symbols in the kernel. Check that you really are in the new patched kernel. Note ipvsadm doesn't have strong version testing capabilities.
Handling the prepatched RedHat kernel. You can do this by examining the patches that are provided with the kernel src. Compile the kernel - a few minor things may fail. Again this is the "way of pain". You will need to make modifications to the source to get this to work, but they should be minor. From the toplevel directory of your kernel source. You have edited your. Use make menuconfig or make config unless you really know what is going on. This can be resolved most reasily be rebooting into your new kernel.
Warning You must have two networks for this setup to work. Setup using the configure script. VS-DR for the service telnet. How users have done it. Jezz Palmer, setup of LVS squid. What if there are problems. Note LVS is part of the kernel now. You don't need to patch it anymore. Are you using the standard kernel? My LVS doesn't work. The client says "connection refused". There cannot be any other path from the realservers to the client, except through the director.
Note Billy ntadmin at reachone dot com 18 Mar If your LVS is working and you have connections that disconnect like with http , by the time you've downloaded your page, the connection will be in the InActConn state. If you want any sort of speed in your application, it can't be doing DNS lookups. The packet arrives with the CIP already known. See if you can do with that and not the name. Netmask for VIP wrong. My LVS doesn't loadbalance, the client always goes to the same realserver.
Note no matter what service you'll run in production, as a test telnet is a much easier service to debug. I know you want your try out your superduper shockwave webserver with java applets, but you can get that to run later. Try with telnet first OK? It will save you a round of questions on the LVS mailing list. The VIP is usually on an ethernet device e. Do not run make patchkernel on the 2. Make sure you get the ipvsadm for your kernel series. BEGIN failed--compilation aborted at. This is the preferred method.
ICMP masquerading Protocol-specific masquerading support will be built as modules. TCP syncookie support disabled per default IP: If you don't know about the martian modification, you aren't using it. For example, these commands establish two tunnels tunl0 and tunl1 to two virtual server addresses To prevent real servers, rather than the active router, from intercepting ARP broadcasts, you also need to hide tunnels from ARP broadcasts.
For example, these commands hide tunnels tunl0: