Multicast traffic from 212.69.63.51

[dmgeurts]

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'.

[dmgeurts]

Not that I know anything but can you ask to "leave" or does that have to be done by the IDNet router?

IGMPv2 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

Multi-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 detailing where PIM and IGMP are used.



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 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.

[Steve]

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.

[dmgeurts]

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... 

[Technical Ben]

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?

[pctech]

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.

[pctech]

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.

[dmgeurts]

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.

[Technical Ben]

Which is why I only mentioned BBC Live broadcasts.

[pctech]

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.

[Going_Digital]

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.

[Simon]

Umm... welcome to the forum.

[Gary]

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?

[Going_Digital]

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.

[Rik]

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.

[Lance]

I think you mean uploads, Rik 

[Rik]

And you'd be very right.

[Going_Digital]

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

[Rik]

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.

[Going_Digital]

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.

[Steve]

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
 

[Lance]

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?

[Going_Digital]

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.