Apr 13 11:51:12 WAN 212.69.63.51 224.0.0.13 PIM
Apr 13 11:51:18 WAN 212.69.63.51 224.0.0.1 IGMP
My firewall is blocking this traffic, what is it and why is IDnet trying to send Multicast traffic to me?
I've seen things about BBC's Multicast service and IDnet supporting it. Is there any benefit to enabling Multicast on my side when using BBC iPlayer for example?
Are you viewing any online video content at present?
Does youtube count? Not BBC's iPlayer afaik.
I don't think Youtube multicasts but will fire up wireshark when I get home and have a look.
I use a pfsense firewall and the blocked packets are never ending for pim and igmp... from that IP address.
:welc: :karma:
Give support a call, someone there should be able to tell you why you are receiving the multicast traffic.
Is the BBC Multicast trial still active?
Thanks.
However I'm pottering around sorting out my new connectivity etc while on numerous conf calls and other real work stuff. Don't have the time right now to be calling support at the moment, was hoping someone here might know.
I'm sure there will be a some people along shortly that may know.
:welc: :karma: I think your going to have to direct that question to support.
:welc: :karma:
Well I've just called support and the guy dismissed it as just random traffic that may be floating around... He then continued that it may be responses to my DNS queries. Clearly I was being fobbed off with gumpf.
- Simple client DNS queries do not use multicast at all
- My firewall is not configured for multicast and as such drops all such traffic in or out (running packet capture just to be sure)
- He denied IDnet having anything when I mentioned Google searches turning up references to "a BBC Multicast service"
So it seems the mystery deepens... you may have guessed, I don't like being being told to not worry about it w/o some proper explanation.
Thank you for all the welcome messages! :) I've moved over from Be* and I love the IRC channel they have there, always great to receive quick answers.
Packet captures show no out bound Multicast. They did tell me what kind of Multicast packets I receive from IDnet.
The PIM packets are sent every 30 seconds: PIMv2 Hello
The IGMP packets are sent every 60 seconds: V2 Membership Query, general
Are we any the wiser though? I'm not. ;D
Neither am I and I'm not holding my breath waiting for an answer to my email to support either :-\
Are we just seeing an IGMP enabled router(IDNet) but no actual multicast service.
I'm currently figuring out how to get pfSense to proxy Multicast traffic so I can query the machine :) If I can join I might be able to see what groups it has on offer. IGMPv1 though so not expecting anything.
Not that I know anything but can you ask to "leave" or does that have to be done by the IDNet router?
That's just Multicast adjacency traffic and can be safely ignored. Applications such as Virgin Radio would use it and the BBC were using Multicast but I think they've stopped now as they're concentrating on iPlayer.
Simon_idnet,
That's nice to know, thank you. Why though is it still enabled on the CPE side if it's currently not used?
/me goes to figure out how to drop these messages from pfsense's logging...
There are other uses (e.g. Virgin Radio) and it doesn't hurt anything to leave it there as a service for any customers who want to use it.
Is there documentation on this and how to make use of it?
No doubt it's one of those services and systems that needs a huge outlay just to buy the documentation! :eek4:
Virgin mulitcast seems to be now Absolute radio http://www.multicast.org.uk/absoluteradio/
http://www.bbc.co.uk/multicast/radio/
Multicast is used mainly for broadcast traffic that does not require acknowledgement and is designed to reduce network load by allowing the router to replicate the packets so only one upstream connection is made for bandwidth heavy traffic.
Unless you want to broadcast something you would not normally need to think about multicast.
Multicast only works well if a client can indicate to the network that it wants to receive a multicast stream. So knowing what streams are supported -if any- and how to correctly hook into (use) the network are key elements a client needs to use multicast streams. So saying that a user only needs to know about multicast when wanting to broadcast is incorrect, the emphasis being on the word 'only'.
Quote from: Steve on Apr 13, 2011, 17:34:04
Not that I know anything but can you ask to "leave" or does that have to be done by the IDNet router?
Quote from: WikipediaIGMPv2 improves over IGMPv1 by adding the ability for a host to signal desire to leave a multicast group
@steve, IDnet uses IGMPv1 as far as I can tell.
Don't get me wrong. IDnet does not forward any multicast streams to me. What is announced is the presence of multicast by means of IGMPv1 and PIM packets.
PIM: http://en.wikipedia.org/wiki/Protocol_Independent_Multicast
Most likely PIM-SM will be used: http://en.wikipedia.org/wiki/PIM_Sparse_Mode
Quote from: WikipediaMulti-cast clients
A router receives explicit Join/Prune messages from those neighboring routers that have downstream group members.
In order to join a multi-cast group, G, a host conveys its membership information through the Internet Group Management Protocol (IGMP).
The router then forwards data packets addressed to a multi-cast group G to only those interfaces on which explicit joins have been received.
IGMP: http://en.wikipedia.org/wiki/IGMP
This page has a good image (http://en.wikipedia.org/wiki/File:IGMP_basic_architecture.png) detailing where PIM and IGMP are used.
(http://upload.wikimedia.org/wikipedia/en/c/c9/IGMP_basic_architecture.png)
So, to draw some conclusions:
- To use Multicast streams I don't need to see PIM hello packets as I would only be using IGMP to indicate that I want to join a stream
- If I had multicast enabled network equipment then PIM could be useful to prevent the need of an IGMP-proxy. For example pfSense does not support PIM but does have an IGMP-proxy, on the other hand my cisco 877 ADSL2+ router does fully support PIM and would happily form an adjacency with another PIM router such as 212.69.63.51 (my FTTC PE (http://en.wikipedia.org/wiki/Provider_edge) router, or more commonly called "default gateway")
- In essence it looks like IDnet supports IGMP on their PE and they don't mind customers joining their multicast network using PIM either.
Would be nice if the PIM bit was documented though. IGMP is pretty standard so needs little explanation, imho.
Looks like something that needs a bit of time and effort to get your head round the terminology. I'm not sure what relevance it has though to the home end user - if we look at the BBC multicast radio streams they seem to have been turned off so we lose potentially high quality audio streams in favour of iPlayer.
Virgin radio still uses it apparently. IMHO if that's all it was used for and nobody uses it then turn the stuff off.
I work with ISP's and their network infrastructure. if you don't use a feature, turn it off. It's safer, less chance of hitting bugs and avoids getting weird questions from guys like me... ;)
And saves bandwidth/workload. A perfect example is in servers that turn off ping requests. It's a tiny thing, but can save them a lot of hassle.
Multicast is not going to kick off unless it's supported. Honestly, I'm surprised it was not used for TV services or similar. Would it reduce the strain of BBC live on the internet back bone if used?
Quote from: dmgeurts on Apr 14, 2011, 09:46:43
Multicast only works well if a client can indicate to the network that it wants to receive a multicast stream. So knowing what streams are supported -if any- and how to correctly hook into (use) the network are key elements a client needs to use multicast streams. So saying that a user only needs to know about multicast when wanting to broadcast is incorrect, the emphasis being on the word 'only'.
I take your point.
Quote from: Technical Ben on Apr 14, 2011, 15:56:01
And saves bandwidth/workload. A perfect example is in servers that turn off ping requests. It's a tiny thing, but can save them a lot of hassle.
Multicast is not going to kick off unless it's supported. Honestly, I'm surprised it was not used for TV services or similar. Would it reduce the strain of BBC live on the internet back bone if used?
Most stuff from the BBC (the on demand iPlayer stuff anyway) streams from Akamai's cache servers rather than the BBC infrastructure so it can come from several locations:
From the Akamai cache servers integrated into the ISP's network.
The cache servers colocated at an exchange point such as LINX or LoNAP
As I believe these are session based multicast would probably not make a lot sense in this case.
Multicast may not be used a lot currently but it maybe in the future so while turning it off may have its merits leaving it enabled saves a potential call and reconfiguration in the future should someone wish to use it.
BBC iPlayer is mostly (only in my case) used for on demand viewing. Multicast is only useful for real time traffic, aka live streaming. Maybe better put, where many people want to receive the same packets all at the same time.
IDnet uses IGMPv1, which is not future proof. IGMPv2 has enhancements but for IPv6 IGMPv3 is required. Each of these iterations would require (ideally lab) testing and documentation so I fail to see the point in leaving something old turned on because one might use an out of date protocol in the future... my .02ct anyway ;)
Akamai is a system used for distributing content and serving it as close to the user as possible. Advantage being that content can be served faster (latency) and potentially there is bandwidth to be saved at peering points ($$$). The down side being that it's a paid service (for those hosting content), not sure if ISP's have to pay as well (probably), and I'm not sure how quickly updates to content are distributed within Akamai's network.
Mind you many companies use Multicast, it's just that I don't expect ISP's that don't deliver their own content (as opposed to Sky, Virgin etc) to use it.
Which is why I only mentioned BBC Live broadcasts. ;)
I'll admit that I've not looked into it a great deal but then again I just get my phone from IDNet and get my broadband from elsewhere that allow me to impose a cap on the data transfer.
This is somewhat annoying that on a completely unused connection I am getting constant PIM Packets from 212.69.63.99 using up my bandwidth allowance for something I have no need for. My first annoyance with IDNet.
Umm... welcome to the forum.
Quote from: Going_Digital on Aug 23, 2011, 22:48:26
This is somewhat annoying that on a completely unused connection I am getting constant PIM Packets from 212.69.63.99 using up my bandwidth allowance for something I have no need for. My first annoyance with IDNet.
And how much bandwidth is that then?
Quote from: Gary on Aug 24, 2011, 00:07:46
And how much bandwidth is that then?
I have no way to isolate the traffic, but judging by the monitoring I have done packets are being sent to me at least every 30 seconds. Now some of the traffic will be the usual internet rubbish like port scans but in a week with an unused connection it has racked up half a GB. Seeing as how IDNet's FTTC bandwidth caps are pretty low this is a big chunk of the bandwidth being used by unwanted traffic.
Are you using multicast? If so, could it be the client is just checking whether you're active or not. IAC, downloads are not counted towards your allowance, so unless your router is sending a lot of bytes in response, you shouldn't have a problem.
I think you mean uploads, Rik ;)
And you'd be very right. :)
No this is with the Openreach modem connected to a firewall left completely unused, example entires in the firewall log....
Aug 24 11:00:16 IDNET 212.69.63.99 224.0.0.13 PIM
Aug 24 11:00:46 IDNET 212.69.63.99 224.0.0.13 PIM
Aug 24 11:00:54 IDNET 212.69.63.99 224.0.0.1 IGMP
Aug 24 11:01:15 IDNET 212.69.63.99 224.0.0.13 PIM
Aug 24 11:01:45 IDNET 212.69.63.99 224.0.0.13 PIM
Aug 24 11:01:55 IDNET 212.69.63.99 224.0.0.1 IGMP
Aug 24 11:02:14 IDNET 212.69.63.99 224.0.0.13 PIM
I've had a word with support on your behalf. If you're sure your network is secure, ie no-one is piggy-backing, the only thing they can suggest is that you have run a multicast which has logged your IP address and is pinging you with a heartbeat every half minute or so. If it continues, give them a ring (or drop them an email) and they'll change your IP address for you, which should stop the problem. Your usage is well below .5GB, btw.
Thanks for the suggestions Rik, but I am somewhat confused. The connection was newly installed about 10 days ago and for the first few days was left disconnected, i.e openreach modem had nothing connected to it. Then about a week ago I connected it to an unused wan port on the firewall not configured to use the connection at all. So essentially siting there idle, the connection has never been used to access any sort of multicast in fact even now when it is in use it has one purpose only that is to allow incoming connections on port 80. No outward bound connections are allowed as all network traffic from client machines on the network is sent through the slower but unlimited Be connection. So any requests for multicasts would only ever happen over the Be connection. So I have no idea why this gateway is continually polling me, changing the IP address seems a somewhat unwieldy solution that I imagine would not solve the problem as if this gateway polls an IP address in perpetuity if an IP has ever accessed a multicast then it will be hard to find an address that is not being polled.
My suspicion here is that all addresses are being polled but very few people notice it as they are not monitoring firewall logs for their connections. Seems an awful waste of bandwith for these polls to be going all the time. BTW IDNET reports my bandwidth usage as 0.35GB so it is a little lower than the counter on the firewall but that is probably just a difference in what is recorded.
I'm sure your correct regarding the fact that all addresses are been polled,and seems to contradict the advice given to Rik. Early posts in this thread from Simon_IDNet confirmed the presence of this multicast adjacency traffic.
My firewall log
Aug 24 21:12:43 home user.info kernel: HackAttack: [SPI:Illegal connection state attack] ICMP packer from [ppp_0_0_38_1] 212.69.36.217 to 212.69.45.xxx
Aug 24 21:12:50 home user.info kernel: HackAttack: [SPI:Illegal connection state attack] ICMP packer from [ppp_0_0_38_1] 212.69.36.217 to 212.69.45.xxx
Aug 24 21:12:52 home user.info kernel: HackAttack: [SPI:Illegal connection state attack] ICMP packer from [ppp_0_0_38_1] 212.69.36.217 to 212.69.45.xxx
Aug 24 21:13:01 home user.info kernel: HackAttack: [SPI:Illegal connection state attack] ICMP packer from [ppp_0_0_38_1] 212.69.36.217 to 212.69.45.xxx
As a separate point if interest, you make a point of saying that your outbound traffic goes over an unlimited connection. Are you aware that outbound traffic (uploads) on IDNet does not count towards your bandwidth allowance?
Quote from: Lance on Aug 24, 2011, 23:39:27
As a separate point if interest, you make a point of saying that your outbound traffic goes over an unlimited connection. Are you aware that outbound traffic (uploads) on IDNet does not count towards your bandwidth allowance?
Yes, thanks, I think I wasn't being terribly clear in my description. What I mean is that all general internet access from the local network is done through the Be connection. So when I said outbound I meant all requests are sent over the Be link and not the IDNet one. The IDNet connection is configured just to respond to requests on port 80 to make use of the unlimited upload allowance and avoid other activities from slowing down access to the web server.