We use a dual homed CentOS-6.3 host for our Internet gateway router. Its internal nic (eth1) is configured such that the address 192.168.0.1 is one of its aliases.
# cat /etc/sysconfig/network-scripts/ifcfg-eth1:192BOOTPROTO=none BROADCAST=192.168.255.255 DEVICE=eth1:192 IPADDR=192.168.0.1 IPV6INIT=no MTU="" NAME="LAN - Non-routable" NETMASK=255.255.0.0 NETWORK=192.168.0.0 ONBOOT=yes ONPARENT=yes
Internal packets routed to 192.168.209.41 are passing through this router out onto the network. I am afraid that the reason is not evident to me and I have been unable to locate an answer.
The primary address for eth1 has the following configuration:
# cat /etc/sysconfig/network-scripts/ifcfg-eth1 BOOTPROTO=none BROADCAST="" DEFROUTE=yes DEVICE=eth1 DOMAIN="hamilton.harte-lyne.ca harte-lyne.ca" GATEWAY=216.xxx.yyy.53 HWADDR=00:25:90:60:11:8D IPADDR=216.xxx.xxx.1 IPV4_FAILURE_FATAL=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6INIT=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes MACADDR="" MTU="" NAME="LAN Link - eth1" NETMASK="" NETWORK="" NM_CONTROLLED=no ONBOOT=yes PREFIX=24 TYPE=Ethernet UUID=9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04
What configuration setting am I missing that will cause packets to 192.168.ccc.ddd to stay on the LAN and not try and pass though the WAN interface?
On Tue, Sep 4, 2012 at 1:34 PM, James B. Byrne byrnejb@harte-lyne.ca wrote:
We use a dual homed CentOS-6.3 host for our Internet gateway router. Its internal nic (eth1) is configured such that the address 192.168.0.1 is one of its aliases.
# cat /etc/sysconfig/network-scripts/ifcfg-eth1:192BOOTPROTO=none
DEVICE=eth1:192
IPADDR=192.168.0.1 NETMASK=255.255.0.0
Internal packets routed to 192.168.209.41 are passing through this router out onto the network. I am afraid that the reason is not evident to me and I have been unable to locate an answer.
That netmask says the interface handles the range from 192.168.0.0-192.168.255.255. Maybe you meant 255.255.255.0?
On Tue, September 4, 2012 14:34, James B. Byrne wrote:
We use a dual homed CentOS-6.3 host for our Internet gateway router. Its internal nic (eth1) is configured such that the address 192.168.0.1 is one of its aliases.
per: Les Mikesell lesmikesell at gmail.com Tue Sep 4 15:01:18 EDT 2012
# cat /etc/sysconfig/network-scripts/ifcfg-eth1:192BOOTPROTO=none DEVICE=eth1:192 IPADDR=192.168.0.1 NETMASK=255.255.0.0
Internal packets routed to 192.168.209.41 are passing through this router out onto the network. I am afraid that the reason is not evident to me and I have been unable to locate an answer.
That netmask says the interface handles the range from 192.168.0.0-192.168.255.255. Maybe you meant 255.255.255.0?
There are presently two subnets on the lan, 192.168.209.0 and 192.168.209.0. I believe that the present netmask is correct in these circumstances.
On Tue, Sep 4, 2012 at 2:18 PM, James B. Byrne byrnejb@harte-lyne.ca wrote:
On Tue, September 4, 2012 14:34, James B. Byrne wrote:
We use a dual homed CentOS-6.3 host for our Internet gateway router. Its internal nic (eth1) is configured such that the address 192.168.0.1 is one of its aliases.
per: Les Mikesell lesmikesell at gmail.com Tue Sep 4 15:01:18 EDT 2012
# cat /etc/sysconfig/network-scripts/ifcfg-eth1:192BOOTPROTO=none DEVICE=eth1:192 IPADDR=192.168.0.1 NETMASK=255.255.0.0
Internal packets routed to 192.168.209.41 are passing through this router out onto the network. I am afraid that the reason is not evident to me and I have been unable to locate an answer.
That netmask says the interface handles the range from 192.168.0.0-192.168.255.255. Maybe you meant 255.255.255.0?
There are presently two subnets on the lan, 192.168.209.0 and 192.168.209.0. I believe that the present netmask is correct in these circumstances.
If the 192.168.209.x range is connected to this interface, then I don't think I understand the problem. I thought you were saying those addresses should not go out this interface.
On 09/04/12 12:18 PM, James B. Byrne wrote:
There are presently two subnets on the lan, 192.168.209.0 and 192.168.209.0. I believe that the present netmask is correct in these circumstances.
um, those are both the same? I assume you meant one of them to be different?
when you say therre are two subnets, whats the mask for those two 'subnets' ? if its /24 (255.255.255.0) then those subnets would not be able to reach the gateway at 192.168.0.1 without additional routing information.
On 09/04/12 12:18 PM, James B. Byrne wrote:
There are presently two subnets on the lan, 192.168.209.0 and 192.168.209.0. I believe that the present netmask is correct in these circumstances.
um, those are both the same? I assume you meant one of them to be different?
You are correct. I mistyped.
I have host A with eth0[aaa.bbb.ccc.A] and eth1[192.168.216.A]
I have host B with eth0[aaa.bbb.ccc.B] and eth1[192.168.209.B]
and I have host C as the gateway with eth0 being the WAN and eth1 being the LAN. Eth1 on C has the address [aaa.bbb.ccc.1] assigned to it and has the alias [192.168.0.1] as well.
I want traffic from 192.168.216.A addressed to 192.168.209.B to go to eth1 on B. Instead it goes to Eth0 on C where it dies as one would expect.
I am not terribly familiar with routing so I expect that I am doing something wrong that is obvious yet invisible to me. This is an experimental set up so that I can explore these issues before inflicting them on my unsuspecting users.
James B. Byrne wrote:
On 09/04/12 12:18 PM, James B. Byrne wrote:
There are presently two subnets on the lan, 192.168.209.0 and 192.168.209.0. I believe that the present netmask is correct in these circumstances.
um, those are both the same? I assume you meant one of them to be different?
You are correct. I mistyped.
I have host A with eth0[aaa.bbb.ccc.A] and eth1[192.168.216.A]
I have host B with eth0[aaa.bbb.ccc.B] and eth1[192.168.209.B]
and I have host C as the gateway with eth0 being the WAN and eth1 being the LAN. Eth1 on C has the address [aaa.bbb.ccc.1] assigned to it and has the alias [192.168.0.1] as well.
I want traffic from 192.168.216.A addressed to 192.168.209.B to go to eth1 on B. Instead it goes to Eth0 on C where it dies as one would expect.
I am not terribly familiar with routing so I expect that I am doing something wrong that is obvious yet invisible to me. This is an experimental set up so that I can explore these issues before inflicting them on my unsuspecting users.
could you show the result of the route command on host C?
On Tue, Sep 4, 2012 at 3:25 PM, James B. Byrne byrnejb@harte-lyne.ca wrote:
On 09/04/12 12:18 PM, James B. Byrne wrote:
There are presently two subnets on the lan, 192.168.209.0 and 192.168.209.0. I believe that the present netmask is correct in these circumstances.
um, those are both the same? I assume you meant one of them to be different?
You are correct. I mistyped.
I have host A with eth0[aaa.bbb.ccc.A] and eth1[192.168.216.A]
I have host B with eth0[aaa.bbb.ccc.B] and eth1[192.168.209.B]
and I have host C as the gateway with eth0 being the WAN and eth1 being the LAN. Eth1 on C has the address [aaa.bbb.ccc.1] assigned to it and has the alias [192.168.0.1] as well.
I want traffic from 192.168.216.A addressed to 192.168.209.B to go to eth1 on B.
That should happen directly without C's involvement if the netmask is 255.255.0.0 on A and B's eth1 interfaces.
Instead it goes to Eth0 on C where it dies as one would expect.
Why does C have both internet and LAN addresses on the same interfaces?
On Tue, September 4, 2012 16:51, Les Mikesell wrote:
That should happen directly without C's involvement if the netmask is 255.255.0.0 on A and B's eth1 interfaces.
It is not. The netmask on those interfaces is 255.255.255.0.
Instead it goes to Eth0 on C where it dies as one would expect.
Why does C have both internet and LAN addresses on the same interfaces?
I am experimenting to see if this arrangement is workable. I want to know if it is possible to have two separate 192.168.x subnets on the same network. Why? I do not have a purpose in mind. I am just checking out whether it can work or not.
If it is impossible then then I will discover why that is so, which I think will be useful in itself.
On 09/04/12 2:00 PM, James B. Byrne wrote:
I am experimenting to see if this arrangement is workable. I want to know if it is possible to have two separate 192.168.x subnets on the same network. Why? I do not have a purpose in mind. I am just checking out whether it can work or not.
If it is impossible then then I will discover why that is so, which I think will be useful in itself.
its possible, but its excessively complicated, and there had better be a darn good reason why to justify the complexity..
On Wed, Sep 5, 2012 at 9:00 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
On Tue, September 4, 2012 16:51, Les Mikesell wrote:
That should happen directly without C's involvement if the netmask is 255.255.0.0 on A and B's eth1 interfaces.
It is not. The netmask on those interfaces is 255.255.255.0.
Instead it goes to Eth0 on C where it dies as one would expect.
Why does C have both internet and LAN addresses on the same interfaces?
I am experimenting to see if this arrangement is workable. I want to know if it is possible to have two separate 192.168.x subnets on the same network. Why? I do not have a purpose in mind. I am just checking out whether it can work or not.
If it is impossible then then I will discover why that is so, which I think will be useful in itself.
IMO you need to configure the two subnets separately and set the netmask to 255.255.255.0. Then route traffic between the LANs via either the firewall or another routing device on the shared network.
I've done similar in the past to migrate from one IP range to another.
Having both networks connect to the firewall router is risky in case of a misconfiguration.
Cheers,
Cliff
On Tue, Sep 4, 2012 at 4:00 PM, James B. Byrne byrnejb@harte-lyne.ca wrote:
That should happen directly without C's involvement if the netmask is 255.255.0.0 on A and B's eth1 interfaces.
It is not. The netmask on those interfaces is 255.255.255.0.
Netmasks apply to (and describe) connected subnets, not individual interfaces. Linux will sort-of sometimes work with mismatched subnet masks but some things won't see arp broadcasts with the wrong broadcast address (which again is for the whole subnet).
Instead it goes to Eth0 on C where it dies as one would expect.
Why does C have both internet and LAN addresses on the same interfaces?
I am experimenting to see if this arrangement is workable. I want to know if it is possible to have two separate 192.168.x subnets on the same network.
Some things might work sometimes. You can overlay separate subnets on the same wire, each with a correct subnet mask, and a designated router between them, but random things will happen with mixed netmasks.
Why? I do not have a purpose in mind. I am just checking out whether it can work or not.
You would probably be better off using VLANs than overlays in any case.
If it is impossible then then I will discover why that is so, which I think will be useful in itself.
The broadcast address for a subnet is tied to the bits in the subnet mask, and ethernets need arp broadcasts to work.
-- Les Mikesell lesmikesell@gmail.com
I am still having some difficulty understanding what is going on with routing on 192.168.x.x.
I have removed the IP aliases from the gateway eth1 so that it only responds to aaa.bbb.ccc.1.
I have changed the netmask on Host B eth1 [192.168.209.43] to 255.255.0.0 and set its gateway to aaa.bbb.ccc.1; as I have on all of the guests that have eth1 active.
The network service on both hosts and guests has been restarted.
However, when I do a traceroute from Host C [aaa.bbb.ccc.25] to 192.168.209.43 it still goes directly to the gateway at aaa.bbb.ccc.1 and thence out to the eth0 i/f on the gateway, where it dies as before.
I note that Host C is a xen virtual host (used for some experiments several years ago but no longer hosting any active guests) and that it has the following virtual interface:
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
This has an address in the same network as 192.168.209.43 but with a different netmask. This seems to eb the case on the kvm virtual hosts as well.
6: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:a6:3f:49 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
So, is this the source of the problem when I try and connect to 192.168.209.43? Is the netblock 192.168.255.255 constrained to use a netmask of 255.255.255.0 because of its use by the virtual hosts?
On Thu, Sep 6, 2012 at 11:11 AM, James B. Byrne byrnejb@harte-lyne.ca wrote:
I am still having some difficulty understanding what is going on with routing on 192.168.x.x.
I have removed the IP aliases from the gateway eth1 so that it only responds to aaa.bbb.ccc.1.
I have changed the netmask on Host B eth1 [192.168.209.43] to 255.255.0.0 and set its gateway to aaa.bbb.ccc.1; as I have on all of the guests that have eth1 active.
The network service on both hosts and guests has been restarted.
However, when I do a traceroute from Host C [aaa.bbb.ccc.25] to 192.168.209.43 it still goes directly to the gateway at aaa.bbb.ccc.1 and thence out to the eth0 i/f on the gateway, where it dies as before.
I note that Host C is a xen virtual host (used for some experiments several years ago but no longer hosting any active guests) and that it has the following virtual interface:
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
This has an address in the same network as 192.168.209.43 but with a different netmask. This seems to eb the case on the kvm virtual hosts as well.
6: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:a6:3f:49 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
So, is this the source of the problem when I try and connect to 192.168.209.43? Is the netblock 192.168.255.255 constrained to use a netmask of 255.255.255.0 because of its use by the virtual hosts?
A 'route -n' should show you where any destination will head on the next hop. On host C, what is the line with the smallest matching destination/mask? Likewise, on the gateway host where you think it is being forwarded the wrong way?
On 09/04/12 1:25 PM, James B. Byrne wrote:
I have host A with eth0[aaa.bbb.ccc.A] and eth1[192.168.216.A]
I have host B with eth0[aaa.bbb.ccc.B] and eth1[192.168.209.B]
what are the subnet masks defined on 192.168.216.A and 192.168.209.B ?
and I have host C as the gateway with eth0 being the WAN and eth1 being the LAN. Eth1 on C has the address [aaa.bbb.ccc.1] assigned to it and has the alias [192.168.0.1] as well.
assuming the answer to my above question is 255.255.255.0, then noone has a route to this 192.168.0.1 as its in an entirely different subnet. you can't overlap subnets with different size masks without creating some serious messes.
I want traffic from 192.168.216.A addressed to 192.168.209.B to go to eth1 on B. Instead it goes to Eth0 on C where it dies as one would expect.
there's no route defined to do that, since 192.168.209.B is not in any network that A has knowlege of. A would need an IP in the B subnet, and B would need an IP in the A subnet for this to work.
why do you have two seperate LAN subnets? are you running two seperate LANs ? there have to be some really good reasons before I create anything this messy.
for instance...
host A with eth0[aaa.bbb.ccc.A] and eth1[192.168.216.A] and eth1[192.168.209.A] host B with eth0[aaa.bbb.ccc.B] and eth1[192.168.209.B] and eth1[192.168.216.B]
now A can reach B via its eth1 as it now has a route to 192.168.216/24
per: Nicolas Thierry-Mieg Nicolas.Thierry-Mieg at imag.fr Tue Sep 4 16:42:57 EDT 2012
could you show the result of the route command on host C?
[root@gway01 ~]# ip route 216.185.64.52/30 dev eth0 proto kernel scope link src 216.185.64.54 10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 172.16.0.0/24 dev eth1 proto kernel scope link src 172.16.0.1 169.254.0.0/24 dev eth1 proto kernel scope link src 169.254.0.1 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1 192.0.0.0/24 dev eth1 proto kernel scope link src 192.0.0.1 216.185.71.0/24 dev eth1 proto kernel scope link src 216.185.71.1 169.254.0.0/16 dev eth0 scope link metric 1002 169.254.0.0/16 dev eth1 scope link metric 1003 default via 216.185.64.53 dev eth0
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1 is wrong I think, but I cannot figure out what in the configuration file is causing it.
# cat /etc/sysconfig/networking/devices/ifcfg-eth1:192 BOOTPROTO=none NAME="" MACADDR="" IPV6INIT=no DEVICE=eth1:192 MTU="" NETMASK=255.255.0.0 ONPARENT=yes BROADCAST=192.168.255.255 IPADDR=192.168.0.1 NETWORK=192.168.0.0 ONBOOT=yes
Am 04.09.2012 um 20:34 schrieb James B. Byrne:
We use a dual homed CentOS-6.3 host for our Internet gateway router. Its internal nic (eth1) is configured such that the address 192.168.0.1 is one of its aliases.
# cat /etc/sysconfig/network-scripts/ifcfg-eth1:192BOOTPROTO=none BROADCAST=192.168.255.255 DEVICE=eth1:192
^^^^^^^^
IPADDR=192.168.0.1 IPV6INIT=no MTU="" NAME="LAN - Non-routable" NETMASK=255.255.0.0 NETWORK=192.168.0.0 ONBOOT=yes ONPARENT=yes
Internal packets routed to 192.168.209.41 are passing through this router out onto the network. I am afraid that the reason is not evident to me and I have been unable to locate an answer.
The primary address for eth1 has the following configuration:
# cat /etc/sysconfig/network-scripts/ifcfg-eth1 BOOTPROTO=none BROADCAST="" DEFROUTE=yes DEVICE=eth1
^^^^^^^^^
DOMAIN="hamilton.harte-lyne.ca harte-lyne.ca" GATEWAY=216.xxx.yyy.53 HWADDR=00:25:90:60:11:8D IPADDR=216.xxx.xxx.1 IPV4_FAILURE_FATAL=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6INIT=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes MACADDR="" MTU="" NAME="LAN Link - eth1" NETMASK="" NETWORK="" NM_CONTROLLED=no ONBOOT=yes PREFIX=24 TYPE=Ethernet UUID=9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04
What configuration setting am I missing that will cause packets to 192.168.ccc.ddd to stay on the LAN and not try and pass though the WAN interface?
Is it correct to set the internal net as alias on the public interface (216.xxx.xxx.1) - both via eth1? This is for sure not your intention. Maybe a typo ...
-- LF
I'm too settig up Hylafax and found ajhfc to be more user friendly than all the other cited fax frontend in the Hylafax repository.
Hylafax-Server 6.0.5-1rhel5.i386.rpm Hylafax-Client-6.0.5-1rhel5.i386.rpm
Centos 5.8
I downloaded and tried to install but failed yajhfc-0.5.2-1.noarch.rpm yajhfc-faxprinter-0.5.2-1.noarch.rpm
tried too with yum and the result was the same
I/m mising a dependency err6r as: [root@serveur 05-installe]# rpm -Uvh yajhfc-0.5* error: Failed dependencies: rpmlib(PayloadIsLzma) <= 4.4.6-1 is needed by yajhfc-0.5.2-1.noarch
On my system rpm is at level 4.4.2.3-28.el5_8 rpm froge-release is 0.5.2-2.el5.rf rpm-libs is at level 4.4.2.3-28.el5_8
I googled out all the afternoon without finding a solution to my problem. I can't find a place to get rpmlibs(PayloadIsLzma)
Thank's in advence to care my request
--- Michel Donais
On Tue, 4 Sep 2012 21:47:06 -0400 Michel Donais wrote:
I can't find a place to get rpmlibs(PayloadIsLzma)
Having never heard of your yajhfc program before, three minutes of Google searching has told me the following:
rpmlib(PayloadIsLzma) appears to be a Suse-ism. So your rpm is for Suse Linux, not any Red Hat distribution.
I downloaded the yajhfc-0.5.2-1.noarch.rpm and took a quick look at the contents. Not much there -- mostly just a jar file, a script and a ppd file (printer driver).
So you could just unpack that and sort the contents yourself, or simply download the jar file that's available on the same page as you downloaded the rpm file and use that.
So you could just unpack that and sort the contents yourself, or simply download the jar file that's available on the same page as you downloaded the rpm file and use that.
So must I understand that the RPM package is compressed and need 'rpmlib(PayloadIsLzma' just to be uncompressed?
--- Michel Donais
Hello Michel,
On Tue, 2012-09-04 at 21:47 -0400, Michel Donais wrote:
Hylafax-Server 6.0.5-1rhel5.i386.rpm Hylafax-Client-6.0.5-1rhel5.i386.rpm
rpmlib(PayloadIsLzma) <= 4.4.6-1 is needed by yajhfc-0.5.2-1.noarchOn my system rpm is at level 4.4.2.3-28.el5_8
This rpm is not suitable for use on CentOS-5, despite the version string suggesting it to be. The compression algorithm it uses is not available in the version of rpm used on C5. It is used in rpm on C6 and recent versions of Fedora. (Although SUSE initiated the move to lzma this got integrated into rpm and is not exclusive to their distros, see https://bugzilla.redhat.com/show_bug.cgi?id=441110 .) You could unpack the rpm on either of the aforementioned systems or get yourself a tarball instead. Perhaps you could notify the packager and inform him of his mistake.
Regards, Leonard.
On Wed, 2012-09-05 at 12:50 +0200, Leonard den Ottolander wrote:
(Although SUSE initiated the move to lzma this got integrated into rpm and is not exclusive to their distros, see https://bugzilla.redhat.com/show_bug.cgi?id=441110 .)
Actually it was a Mandriva developer.
Regards, Leonard.
Many thank's Frank, James and Leonard for your help.
--- Michel Donais
-
Cliff Pratt -
Frank Cox -
James B. Byrne -
John R Pierce -
Leon Fauster -
Leonard den Ottolander -
Les Mikesell -
Michel Donais -
Nicolas Thierry-Mieg