RE: [squid-users] localhost multicast

Got it. udp_incoming_address works fine with peer sibling. Tried with but
can't communicate with mcast_group.

I need to understand about this:
icp_port 127.0.0.1 and mcast_group is 224.0.0.1, the multicast cant
broadcast or icp_port cant receive?

Assuming config: proxy1
cache_peer 224.0.0.1 multicast 3128 3130 name=mcast
cache_peer 127.0.0.2 sibling 3128 3130 multicast-responder
multicast-siblings
cache_peer_access mcast allow all
mcast_groups 224.0.0.1 # <- what happen to udp communications?
udp_incoming_address 127.0.0.1

proxy2
cache_peer 224.0.0.1 multicast 3128 3130 name=mcast
cache_peer 127.0.0.1 sibling 3128 3130 multicast-responder
multicast-siblings
cache_peer_access mcast allow all
mcast_groups 224.0.0.1 # <- what happen to udp communications?
udp_incoming_address 127.0.0.2

Correcty me If im wrong:
(proxy1)cache_peer 224.0.0.1 multicast 3128 3130 will broadcast and
(proxy2)mcast_group will receive and reply with (proxy2)icp_port to ip
224.0.0.1 or 127.0.0.1?

> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Wednesday, March 06, 2013 4:09 PM
> To: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] localhost multicast
>
> On 6/03/2013 8:20 p.m., jiluspo wrote:
> > http://www.squid-cache.org/Doc/config/udp_incoming_address/ was been
> buggy
> > and been around in ubuntu bug report.
> >
> > udp_incoming_address doesn't work.
>
> The only bug I see in Ubuntu about that directive is that it causes DNS
> packets to go to the address configured.
> Which is exactly the designed behaviour. Like I said it affects DNS as
> well as ICP so you need a recursive resolver / relay listening on
> localhost:53 and sending out where they should go.
>
>
> > Although it shows in cache.log
> > 2013/03/06 02:05:59| Accepting ICP messages at 127.0.0.1, port 3130,
> FD 13.
> >
> > Squid2 been deprecated so this will be hanging around. I'll debug
> them later
> > but for now I'll just off to multicast and use 2 instance peering.
>
> K.
>
> >> -----Original Message-----
> >> From: Amos Jeffries
> >> Sent: Wednesday, March 06, 2013 6:47 AM
> >> To: jiluspo
> >> Subject: Re: [squid-users] localhost multicast
> >>
> >> On 6/03/2013 1:44 a.m., jiluspo wrote:
> >>> Dead end With icp_port cant bind on ip/interface
> >> Ah. I was working on a patch to make all the *_port directives
> accept
> >> IP:port binding the way http_port does today.
> >> Thank you for the reminder, I need to get it back into the audit
> >> process
> >> for inclusion.
> >>
> >>
> >> For now you need to set udp_incoming_address to bind the listening
> >> address, icp+port to bind the port on that address.
> >> http://www.squid-cache.org/Doc/config/udp_incoming_address/
> >>
> >> Note that it affects DNS too so you may need a stub resolver to
> relay
> >> localhost DNS traffic to your actual resolvers.
> >>
> >> Amos
> >>
> >>> -----Original Message-----
> >>> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> >>> Sent: Tuesday, March 05, 2013 8:00 PM
> >>> To: squid-users_at_squid-cache.org
> >>> Subject: Re: [squid-users] localhost multicast
> >>>
> >>> On 5/03/2013 11:35 p.m., jiluspo wrote:
> >>>> Good day,
> >>>>
> >>>> Is there other way we can multicast in localhost without creating
> >>>> virtual Ethernet for additional ip?.
> >>> What do you mean by "virtual Ethernet"?
> >>>
> >>> If you mean ... eth0:0, eth0:1. It is wrong. They are one
> interface
> >>> with multiple IPs. Use the "ip" tools instead of the "ifconfig"
> tools
> >>> and you will see the proper NIC / interface configuration.
> > I'd love to see some examples.
> >
> >>> Amos
> >>>
> >>> Email secured by Check Point
> >>>
> >> Email secured by Check Point
>
> Email secured by Check Point
Received on Fri Mar 08 2013 - 09:03:29 MST