single interface multiple networks + broadcast to all networks
in [Linux Networking]
|
From: David Werner on 2 Feb 2005 22:38 Hello, I have a machine which is in one network say 192.168.1.0. But we have here a configuration where two networks 192.168.1.0 and 192.168.2.0 are local and directly available. So I had to set up two routes to the local networks. Now this machine should be a cups-server to both networks and broadcast his cups-information into both networks. I seems that I can sent only broadcast-packets to the network where the host belongs. Is it so uncommon to sent broadcast into the other network? Or must be the source of a broadcast packet originate in the same network? Do I have to enable something under /proc/sys/net/... Or is just cups broken? Greetings, David
From: prg on 2 Feb 2005 23:35 David Werner wrote: > Hello, > > I have a machine which is in one network say 192.168.1.0. > But we have here a configuration where two networks 192.168.1.0 > and 192.168.2.0 are local and directly available. > So I had to set up two routes to the local networks. > Now this machine should be a cups-server to both networks > and broadcast his cups-information into both networks. > I seems that I can sent only broadcast-packets to the network > where the host belongs. > Is it so uncommon to sent broadcast into the other network? Routers -- unlike switches -- are broadcast boundaries. Ie., broadcasts do not propogate beyond the local subnet. > Or must be the source of a broadcast packet originate in the same network? If I understand your question, yes. The most common broadcast will be in regard to arp requests for normal traffic. > Do I have to enable something under /proc/sys/net/... To be able to route any packets from one interface to another you must set: [root]# echo 1 > /proc/sys/net/ipv4/ip_forward > Or is just cups broken? Not much we can confidently suggest without info about -- all your nics (ifconfig -a), -- all your route tables ($ route -n), -- how you are trying to set up cups, and -- confirmation that you have flushed your iptables rules when testing (ie., firewall issues?) Just how are you trying to access the cups printer? prg email above disabled
From: David Werner on 3 Feb 2005 09:52 On 2005-02-03, prg <rdgentry1(a)cablelynx.com> wrote: > David Werner wrote: >> Hello, >> >> I have a machine which is in one network say 192.168.1.0. >> But we have here a configuration where two networks 192.168.1.0 >> and 192.168.2.0 are local and directly available. >> So I had to set up two routes to the local networks. >> Now this machine should be a cups-server to both networks >> and broadcast his cups-information into both networks. >> I seems that I can sent only broadcast-packets to the network >> where the host belongs. >> Is it so uncommon to sent broadcast into the other network? > > Routers -- unlike switches -- are broadcast boundaries. Ie., > broadcasts do not propogate beyond the local subnet. I'm not speaking of routers. > >> Or must be the source of a broadcast packet originate in the same > network? > > If I understand your question, yes. The most common broadcast will be > in regard to arp requests for normal traffic. > >> Do I have to enable something under /proc/sys/net/... > > To be able to route any packets from one interface to another you must > set: > [root]# echo 1 > /proc/sys/net/ipv4/ip_forward > >> Or is just cups broken? > > Not much we can confidently suggest without info about > -- all your nics (ifconfig -a), > -- all your route tables ($ route -n), > -- how you are trying to set up cups, and > -- confirmation that you have flushed your iptables rules when testing > (ie., firewall issues?) What ifconfig -a me gives: eth0 Link encap:Ethernet HWaddr 00:E0:18:98:C5:C8 inet addr:129.69.98.105 Bcast:129.69.98.255 Mask:255.255.255.0 inet6 addr: fe80::2e0:18ff:fe98:c5c8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8369789 errors:0 dropped:0 overruns:0 frame:0 TX packets:7188752 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1786347940 (1703.5 Mb) TX bytes:1268345025 (1209.5 Mb) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2198 errors:0 dropped:0 overruns:0 frame:0 TX packets:2198 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:198318 (193.6 Kb) TX bytes:198318 (193.6 Kb) What netstat -nr says: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 129.69.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 129.69.49.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 129.69.98.254 0.0.0.0 UG 0 0 0 eth0 Here iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination No firewall seems to be active. As you see the Net 49 is local. Now what I want to do in cups to broadcast into that net too. What I originally do not wanted to do is to set another ifalias of the host in the 49er network, as it seems to me to take another ip-number for nothing. And what I also not intended to do is to set up some relay-host for the browsing in the 49er network. What works on the cups server is: --------------------------------- - Broadcast to the local network with BrowseAddress 129.69.98.255 - Broadcast to some other host in 49er network like BrowseAddress 129.69.49.10 - global Broadcast. If I rely on the routers we could use that. BrowseAdress 255.255.255.255 What not works is: ------------------ - Broadcast to the other 49er local network BrowseAddress 129.69.49.255 - Broadcast to the whole class B network with BrowseAddress 129.69.255.255 I checked these cases with tcpdump on another host so I assume that it not so much a problem of the receiving host, but currently of the sending. > > Just how are you trying to access the cups printer? with ipp. Thank you, David > prg > email above disabled >
From: prg on 3 Feb 2005 18:51 David Werner wrote: [snip the garbled Google ifconfig -a. I pasted it elsewhere for reading] > > What netstat -nr says: > > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 129.69.98.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 129.69.49.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 129.69.98.254 0.0.0.0 UG 0 0 0 eth0 [snip] > As you see the Net 49 is local. > Now what I want to do in cups to broadcast into that net too. > What I originally do not wanted to do is to set another > ifalias of the host in the 49er network, as it seems to me to > take another ip-number for nothing. And what I also > not intended to do is to set up some relay-host for the browsing > in the 49er network. I'm not sure about your setup here. An alias on eth0:x 129.69.49.x? You do have a route entered on that interface (eth0) but that doesn't make it "local" in any sense I'm familiar with. > What works on the cups server is: > --------------------------------- > > - Broadcast to the local network with > BrowseAddress 129.69.98.255 Because this _is_ local, ie., on the subnet of eth0. > - Broadcast to some other host in 49er network like > BrowseAddress 129.69.49.10 This is actually a unicast to the host 129.69.49.10, I believe. > - global Broadcast. If I rely on the routers we could use that. > > BrowseAdress 255.255.255.255 Linux doesn't like you using this address -- it will normally change this to the local subnet broadcast address. Similar problem occurs with DHCP clients (like Win) that boot up with this broadcast. The "solution" in that case is to add a "host" address (on the dhcpd box) similar to: # route add -host 255.255.255.255 dev eth0 But I don't think it will help you :( Worth a try? > What not works is: > ------------------ > > - Broadcast to the other 49er local network > > BrowseAddress 129.69.49.255 Because it's not the local subnet. CUPS only broadcasts to the local subnet and I doubt you can trick it into seeing multiple networks as one. > - Broadcast to the whole class B network with > > BrowseAddress 129.69.255.255 As above -- your networks' prefix length (/24) doesn't match (/16). > I checked these cases with tcpdump on another host so I assume that > it not so much a problem of the receiving host, but currently > of the sending. As near as I can tell, it's built into the cupsd _not_ to broadcast unsolicited packets beyond the local subnet. The closest candidate I could locate in cupsd.conf was: #BrowseRelay @IF(src) @IF(dst) to force the packects out a particular interface (?), but an intervening router won't forward the broadcast dst 255.255.255.255. The built-in restriction makes sense as a wayword router could "flood" a server broadcast onto other networks. It's also why routers don't forward broadcasts. I'm unclear on your network layout and the position of the cups print server in that network. You could, I think, get a server to broadcast out each _physically_ attached interface onto the interfaces' subnets. Otherwise, I don't think you will "trick" it into broadcasting farther than that. That's really the purpose of BrowsePoll and BrowseRelay: provide a means of crossing router broadcast constraints. In fact, that's the only way I've used cups in a multiple, routed, subneted network. It's also the mechanism that cups uses to "find" internet printers (which obviously could not "broadcast" their presence). Your situation may not "fit" the cupsd default behavior and I don't know if slp is a reasonalbe/effective solution for your needs. Cups (according to cupsd.conf) supports it, but I'm sot sure of the details. You can check out openslp here: http://www.openslp.org/ hth, prg email above disabled
From: David Werner on 4 Feb 2005 11:20 On 2005-02-03, prg <rdgentry1(a)cablelynx.com> wrote: > > David Werner wrote: > [snip the garbled Google ifconfig -a. I pasted it elsewhere for > reading] >> >> What netstat -nr says: >> >> Kernel IP routing table >> Destination Gateway Genmask Flags MSS Window > irtt Iface >> 129.69.98.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth0 >> 129.69.49.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth0 >> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 > 0 lo >> 0.0.0.0 129.69.98.254 0.0.0.0 UG 0 0 > 0 eth0 > [snip] >> As you see the Net 49 is local. >> Now what I want to do in cups to broadcast into that net too. >> What I originally do not wanted to do is to set another >> ifalias of the host in the 49er network, as it seems to me to >> take another ip-number for nothing. And what I also >> not intended to do is to set up some relay-host for the browsing >> in the 49er network. > > I'm not sure about your setup here. An alias on eth0:x 129.69.49.x? > You do have a route entered on that interface (eth0) but that doesn't > make it "local" in any sense I'm familiar with. No alias, but just a route I think. > >> What works on the cups server is: >> --------------------------------- >> >> - Broadcast to the local network with >> BrowseAddress 129.69.98.255 > > Because this _is_ local, ie., on the subnet of eth0. > >> - Broadcast to some other host in 49er network like >> BrowseAddress 129.69.49.10 > > This is actually a unicast to the host 129.69.49.10, I believe. > >> - global Broadcast. If I rely on the routers we could use that. >> >> BrowseAdress 255.255.255.255 > > Linux doesn't like you using this address -- it will normally change > this to the local subnet broadcast address. Similar problem occurs > with DHCP clients (like Win) that boot up with this broadcast. The > "solution" in that case is to add a "host" address (on the dhcpd box) > similar to: Here actually it seems to do it. Maybe anyways not to recommendable as it can happen that this changes. > # route add -host 255.255.255.255 dev eth0 > > But I don't think it will help you :( Worth a try? > >> What not works is: >> ------------------ >> >> - Broadcast to the other 49er local network >> >> BrowseAddress 129.69.49.255 > > Because it's not the local subnet. CUPS only broadcasts to the local > subnet and I doubt you can trick it into seeing multiple networks as > one. > >> - Broadcast to the whole class B network with >> >> BrowseAddress 129.69.255.255 > > As above -- your networks' prefix length (/24) doesn't match (/16). > >> I checked these cases with tcpdump on another host so I assume that >> it not so much a problem of the receiving host, but currently >> of the sending. > > As near as I can tell, it's built into the cupsd _not_ to broadcast > unsolicited packets beyond the local subnet. I suppose so too now. > > The closest candidate I could locate in cupsd.conf was: > #BrowseRelay @IF(src) @IF(dst) > to force the packects out a particular interface (?), but an > intervening router won't forward the broadcast dst 255.255.255.255. Yes, it seems now to me the right choice to setup another interface (ipalias) and use that. > > The built-in restriction makes sense as a wayword router could "flood" > a server broadcast onto other networks. It's also why routers don't > forward broadcasts. > > I'm unclear on your network layout and the position of the cups print > server in that network. You could, I think, get a server to broadcast > out each _physically_ attached interface onto the interfaces' subnets. > Otherwise, I don't think you will "trick" it into broadcasting farther > than that. Yes, this might be a choice. I think to setup an real ipalias and broadcast onto that. But, I haven't tested it now, > > That's really the purpose of BrowsePoll and BrowseRelay: provide a > means of crossing router broadcast constraints. In fact, that's the > only way I've used cups in a multiple, routed, subneted network. It's > also the mechanism that cups uses to "find" internet printers (which > obviously could not "broadcast" their presence). Yes, I made a setup with BrowseRelay but viewed from the point of reliability its one service more which can break. I even thought of making an iptable which catches the broadcast packet and rewrite it's address and sending it out again, like NAT, but I think its not worth to make such a difficult setup. > > Your situation may not "fit" the cupsd default behavior and I don't > know if slp is a reasonalbe/effective solution for your needs. Cups > (according to cupsd.conf) supports it, but I'm sot sure of the details. > You can check out openslp here: > http://www.openslp.org/ Yes, I have had enabled it testwise, but it's packets looked strange to me :) I'll consider it again. Greetings and many thanks for your help, David > > hth, > prg > email above disabled >
|
Pages: 1 Prev: Can't get KPPP to work for dial-up Internet connection... Next: Problems with PCI card |