SLES11 SP2 with 2 NIC’s. Each NIC has its own (private) ip and each NIC is physically attached to a different network. A quick network diagram:
|sles11 server|–nic 1 192.168.123.3—192.168.123.x network switch (unmanaged)–trusted port of sonicwall\
|___________|–nic 2 192.168.124.3—192.168.124.x network switch (unmanaged)–opt port of sonicwall----/
This server has a default gateway of 192.168.124.2 which is the sonicwall OPT interface.
I spent days (and money) making sure it was not the sonicwall. From a device on the LAN, you can access other devices on the OPT side and OPT to LAN works fine. When it comes to this multihomed server, the problems arise.
Using the (rough) diagram above, when (specifically) 192.168.123.3 sends a requests to 192.168.124.3, it fails (whether a ping, telnet to port 25, https or anything). So i added a route on the sles11 server: route add -net 192.168.123.0 netmask 255.255.255.0 gw 192.168.124.2 (i know this is not persistent and will address this at a later time when the correct fix is found). This route add now allow a device on the LAN to access the 192.168.124.3 via ping, telnet port 25 and https. But a server on the LAN, 192.168.123.3, can not access 192.168.124.3. This server is not multihomed and is also a SLES11 server.
What i believe is happening is when a request is sent to 192.168.124.3, the request makes it to 192.168.124.3 server but comes out from 192.168.123.x and the requestor is not looking for an ACK from 192.168.123.x but from 192.168.124.x and therefore drops the packet. First, does that sound right to you? Then if that is right, how do i keep ACK’s (request sent back to the requestor) so it returns from the right NIC?
In an effort to give as much needed info as possible, here is the bigger sketch of what is going on:
When you go to https://mail.domain.tld (i will give you this info privately if you want it) it goes to the sonicwall which sends 443 requests to a private ip of 192.168.123.3. That sles11 server(LAN) is running apache and via proxypass statements will send the request to 192.168.124.3(OPT) which is the multihomed sles server. I am sure the proxypass statement works fine as i have had apache guru’s verify its correct. If you would like to look at anything related to this, i will be happy to share.
To verify this is a dual NIC issue, i disabled the 192.168.123.3 NIC. Then access https://mail.domain.tld=works, ping 192.168.124.3 from 192.168.123.3=works and telnet from LAN to 192.168.124.3=works.
We have to have this 192.168.123.3 NIC however. How do i successfully use both NIC’s in this environment?
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I am trying to make a script that run at boot to run the ip route commands. Here is what i have done so far: made a script, iproute.sh. I have added the following to that file:
#! /bin/sh
Author: Chris A
/etc/init.d/apache2
BEGIN INIT INFO
Provides: IP Route Tables
Required-Start: $local_fs $remote_fs $network
Should-Start:
Should-Stop:
Required-Stop: $local_fs $remote_fs $network
Default-Start: 3 5
Default-Stop: 0 1 2 6
Short-Description: IP Route Commands
Description: Adds IP Route Tables for Multi-NIC’s
END INIT INFO
ip route add 192.168.123.0/24 dev eth0 src 192.168.123.4 table T1
ip route add default via 192.168.123.1 dev eth0 src 192.168.123.4 table T1
ip rule add from 192.168.123.3 table T1
ip route add 192.168.124.0/24 dev eth1 src 192.168.124.3 table T2
ip route add default via 192.168.124.2 dev eth1 src 192.168.124.3 table T2
ip rule add from 192.168.124.3 table T2
Do I need the init info section? Where do i put this file so it runs at boot, in /etc/init.d or a /etc/rc.d folder?
the init info section is helpful when using this as an init script and have it managed by the system rutines.
“Provides” should be a single word i.e. “iprt”.
Once in place, you can call “insserv iprt” to have the symbolic links in /etc/rc*.d/ created for you, according to the dependencies described in the various init sections. “insserv -r iprt” disables the service.
So you should place your script in /etc/init.d and let the magic behind “insserv” etc. do its magic.
[QUOTE=jmozdzen;12249]
Once in place, you can call “insserv iprt” to have the symbolic links in /etc/rc*.d/ created for you, according to the dependencies described in the various init sections. “insserv -r iprt” disables the service.[/quote]
I run insserv iproute.sh and get:
insserv: Service nss has to exists for service ncp2nss
insserv: Service network is missed in the runlevels 4 to use service openslp
I have placed the file in /etc/init.d and made it executable.
If I understand your problem correctly, you can try the following:
in the file /etc/sysctl.conf add the following line
“net.ipv4.conf.allrp_filter=0”
That allowed me to ping/ssh etc to each nic on seperate vlans from either of
the 2 vlans.
Good luck
John
[color=blue][color=green][color=darkred]
On 17 February 2013 at 17:34, in message[/color][/color][/color] carnold6.5qwxmn@no-mx.forums.suse.com,
carnold6carnold6@no-mx.forums.suse.com wrote:
[color=blue]
SLES11 SP2 with 2 NIC’s. Each NIC has its own (private) ip and each NIC
is physically attached to a different network. A quick network diagram:
|sles11 server|–nic 1 192.168.123.3—192.168.123.x network switch
(unmanaged)–trusted port of sonicwall\
|___________|–nic 2 192.168.124.3—192.168.124.x network switch
(unmanaged)–opt port of sonicwall----/
This server has a default gateway of 192.168.124.2 which is the
sonicwall OPT interface.
I spent days (and money) making sure it was not the sonicwall. From a
device on the LAN, you can access other devices on the OPT side and OPT
to LAN works fine. When it comes to this multihomed server, the problems
arise.
Using the (rough) diagram above, when (specifically) 192.168.123.3
sends a requests to 192.168.124.3, it fails (whether a ping, telnet to
port 25, https or anything). So i added a route on the sles11 server:
route add -net 192.168.123.0 netmask 255.255.255.0 gw 192.168.124.2 (i
know this is not persistent and will address this at a later time when
the correct fix is found). This route add now allow a device on the LAN
to access the 192.168.124.3 via ping, telnet port 25 and https. But a
server on the LAN, 192.168.123.3, can not access 192.168.124.3. This
server is not multihomed and is also a SLES11 server.
What i believe is happening is when a request is sent to 192.168.124.3,
the request makes it to 192.168.124.3 server but comes out from
192.168.123.x and the requestor is not looking for an ACK from
192.168.123.x but from 192.168.124.x and therefore drops the packet.
First, does that sound right to you? Then if that is right, how do i
keep ACK’s (request sent back to the requestor) so it returns from the
right NIC?
In an effort to give as much needed info as possible, here is the
bigger sketch of what is going on:
When you go to https://mail.domain.tld (i will give you this info
privately if you want it) it goes to the sonicwall which sends 443
requests to a private ip of 192.168.123.3. That sles11 server(LAN) is
running apache and via proxypass statements will send the request to
192.168.124.3(OPT) which is the multihomed sles server. I am sure the
proxypass statement works fine as i have had apache guru’s verify its
correct. If you would like to look at anything related to this, i will
be happy to share.[/color]
insserv: Service nss has to exists for service ncp2nss
insserv: Service network is missed in the runlevels 4 to use service openslp
these are messages resulting from insserv’s dependency checks, independent from your new script (afaict). You might see these messages even without your script, as soon as you use “insserv” to add/delete services.
It basically says that in the script providing “ncp2nss”, there’s a requirement for “nss” documented in the LSB header section of that script - but no script could be found with the corresponding “Provides:” header. This could point to potential trouble, but otoh these LSB sections are not always to be taken too seriously
The other message is similar, stating that openslp (/etc/init.d/slpd) has runlevel 4 defined as one of the run levels it should be activated or deactivated in… and requires “network”… but /etc/init.d/network is not declaring that it should even be started in rl 4. Which is no problem, because in /etc/inittab, rl 4 is commented on as “not used”.
After the insserv run, were the corresponding symlinks to your script created in the rc*.d directories?
