Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My switches are all Netgear® GS-108T Managed 10/100/1000 8-port switches.
I could look at the web consoles of each box, but I don't know how to interpret what I see. ASIDE -- I'm not seeing "errors" or "collisions" which I think is a good thing.
Those switches should allow you to monitor loads. One thing that they also do is allow you to configure what data you want to have priority possibly. QOS and maybe vlans could increase speeds.
More Follow-up:
While reading articles about wire-LANs and switches in general, the term flood or flooding appeared describing multicast operations. Packets that enter at one port get sent, or "flood," all the other ports on the same switch.
In addition, the term storm seems to mean situations where there are an abnormally large number of packets or messages of a given type. A "storm" is usually the result of some malfunction or equipment or configuration. They are sometimes the result of malicious denial-of-service attacks.
I wanted to learn more about this IGMP business so I started with Wikipedia™ at IGMP Protocol.
I also found this article about IGMP Snooping in general.
Lastly, I found an article about Video Streaming using IPTV. I have not found confirmation that U-Verse, in fact, uses that standard or in a standard way.
Follow-up:
This page Switches for U-Verse has a discussion of how AT&T uses IGMP for IPTV distribution over a wire network.
Do I understand that because of this, all switches that might carry IPTV traffic need to
support IGMP snooping as a feature
have that feature enabled
Switches could then snoop the traffic, detect IPTV, direct traffic to ports that want that content, prevent IPTV from going to the remaining ports. Do I understand things correctly?
Last edited by SaintDanBert; 08-20-2014 at 10:51 AM.
Sam S reply to Oedipus
I was looking into that one, but based on a few threads I read over the past few days, I don't think the GS108T or even v2 will do proper IGMP snooping. Adding an Ethernet Switch to the Residential Gateway?
Also, according to the product sheet, the GS108Tv2 only supports IGMP snooping v1/v2. U-verse IPTV/multicast needs v3. GS108Tv2 Product Sheet
NOTE -- Content edited to preserve embedded links.
Since all of my switches are this GS108Tv2, I might have found my problem.
Can anyone confirm that AT&T U-verse requires IGMPv3 snooping?
Can anyone tell me about an newbie guide to Wireshark or similar so that I might watch what is going on?
Wireshark is usually only a way to monitor traffic at the port on the computer. Switches can be configured to mirror or monitor traffic to some port(s) on the switch for you to watch traffic and record it. It's pretty easy when you see wireshark. Making a monitor on the switch would be slightly more difficult.
I found this article about how the ATT Uverse cable boxes work: http://www.firepowr.net/?p=3162
it is an interesting read and may help.
Quote:
Luckily, the AT&T RG is smart enough to know if there is an active STB attached to its ports and only stream to those ports. So a possible solution is to isolate your STBs on one port of the RG and the non-STBs devices on another port by using two switches or routers. If you’re network savvy you can buy a managed switch or a smart switch and use multiple VLANs to separate your devices.
Quote:
Q: Can’t I just use an IGMP Snooping supported switch instead?
A: In theory IGMPv3 support switches should be able to prevent those unnecessary multicast packets on other ports like what the RG currently does, but from experience many of those switches work for about 10 seconds before your TV or internet stops or freezes. It seems that AT&T uses some sort of proprietary stream that can’t be captured by the IGMP Snooping, or the switches I used were too weak or dumb to handle the large amount of multicast data.
As I suspected all along ...
Quote:
Originally Posted by Scott
As long as the switch properly supports IGMPv2 snooping, it should work at isolating the multicast traffic to just the STB ports. What I found is that when I initially connected my switch that it seemed the RG was confused and began flooding all the multicast traffic down both the connection to the STB VLAN I created and the link to my router. I ended up shutting down the outside interface on my router and reenabling it and then the RG appeared to clean itself up and stop flooding. So, the RG’s do not appear to be foolproof at their own IGMP snooping. It is possible you might have to give it a kick in the pants, as well.
In conclusion, the system ATT uses is a horrible proprietary mess that even they have a hard time dealing with. You can try to setup a system as recommended and see if it works, if it doesn't you can try another system, but don't expect any help or advice from ATT.
Last edited by metaschima; 08-20-2014 at 03:21 PM.
... Originally Posted by Scott
As long as the switch properly supports IGMPv2 snooping, it should work at isolating the multicast traffic to just the STB ports.
...
I've mentioned several threads and articles in some of my other postings. These items seem to say that AT&T U-verse needs/uses IGMPv3. In addition, they also say that many of the IGMPv2 implementations fail to behave properly for whatever it is that U-verse does.
Technically there is no guarantee that any switch (IGMPv2 or 3) will handle ATT's proprietary mess. Only way to know is trial and error.
(blush) Quite right. Then again, who is to say that anyone plays by the standards and protocols that are accepted and deployed everywhere?
That said, since AT&T admits to using IGMPv3 -- even if they are fast and loose with the details -- shouldn't we ought to try and play on that same pitch if not with those rules?
I would NOT go spend money on new switches. First I would try using the switches you already have, and try to isolate the cable boxes by connecting them all to a separate port on the modem/router (which BTW has a IGMPv3 switch built-in).
I would NOT go spend money on new switches. First I would try using the switches you already have, and try to isolate the cable boxes by connecting them all to a separate port on the modem/router (which BTW has a IGMPv3 switch built-in).
Given the physical deployment of my wire LAN, I don't see that additional wire is an option. If this IGMPv3 issue is the true problem, then it seems that deployment of virtual-LAN configuration might be my best option. (grimace) That presumes that AT&T will play well with others.
My home has at least one "home run" CAT-6 pulled from the wire-closet into each room. (Large rooms might have two drops.)
There are three switches (GS-108T) in the wire closet in addition to the gateway (Moto ???). SWITCH-1 connects to the RG to expand on the four ports provided by the RG. A printer and various A/V devices connect to SWITCH1.
The house drops enter the wire closet through a break-out cabinet where there are SWITCH-2 and SWITCH-3 (both GS-108T). These, in turn, connect to SWITCH-1.
Out in the several rooms, the STB usually connects directly to the drop. In some cases, there is a small switch so that the smart player has access to the Internet.
My office has SWITCH-4 (DD-WRT) where there are workstations, servers, printers, NAS boxes along with a STB.
Follow-up:
After more research, it seems that a virtual LAN (or VLAN) offers a higher probability of long time success compared to simple IGMP snooping. I found this paper that describes a VLAN in reasonable terms. Virtual LAN Overview While this is a paper from a University, I did not find it overly geek-ish. It does discuss networking and, as such, is pretty technical in its own right.
I continue to hammer on this situation and wonder if anyone sees something helpful for the next layer of the problem.
This deployment creates a vast improvement in the LAN performance for all of the other data use.
I've created a VLAN that starts with my first managed switch connected (input) to the UVerse Motorola gateway wire ethernet port. It includes another port on the same switch (output). I've done the same thing to other managed switches extending out into the home office wire plant so that the VLAN includes an input and an output port. Eventually, an output port connects to a UVerse box by wire drop.
So how does plain olde data traffic (PODT) reach the internet? It must connect to the UVerse gateway using a second head-end switch port that is not part of the VLAN. SHAZZAM! All of that UVerse junk floods the data network again. Follow-Up: A deep reading of the Motorola® NVG589 "Administrators Handbook" v9.1.0 reveals that this box supports IEEE 802.1q VLAN-tagging. This WiKi article gives an overview of what that means as far as networking in general. More specifically, one form of tagging is protocol specific. Others are port specific.
Where my specific problem(s) are concerned, it means that the Moto-box will let me tag its output ports to join any VLAN that I create with my Netgear boxes.
Now, I just need to know which protocols are the UVerse video services.
If I knew the protocols used by UVerse, I might be able to filter those packets off of the PODT part of the LAN unless that requires special and expensive network hardware? Remember, I have Netgear® GS108T managed switches.
~~~ 0;-/ Dan
Last edited by SaintDanBert; 10-13-2014 at 05:56 PM.
DISCLAIMER
As I learn the technical details about AT&T U-Verse, I post them to this thread so that others might share what I know. I try to stay on topic with my original post and questions. However, I include anything that I think offers meaningful details to others.
AT&T delivers U-verse TV via IPTV from the headend to the consumer's receiver, required for each TV. Transmissions use digital H.264 (MPEG-4 AVC) encoding, compared to the existing deployments of MPEG-2 codec and the discontinued analog cable TV system. The receiver box does not have a RF tuner, but is an IP multicast client that requests the channel or "stream" desired. U-Verse TV supports up to four active streams at once. The system uses individual unicasts for video on demand, central time shifting, start-over services and other programs.
...
At best, the 2Wire/Pace routers support DMZ+ mode, while the Motorola devices support IP Passthrough.
...
I also found this document AT&T U-Verse Service. While it is a record of one family's information and experience. I found it very informative. It says, in part:
Code:
The VDSL can be carried by a single regular inside wiring cable pair (ideally in a Cat 5e cable), perhaps part of the subscriber’s existing interior wiring. The pair however must be “clean”: it must have no bridged taps inside (e.g., must not run to an RJ-11 jack in each of several rooms) and ideally does not pass through any RJ-11 patch panels such as are often found in the telecommunication wiring panel in modern homes.
...
An Ethernet connecting cord can be used from the RG to a nearby STB, or in fact the path can be run through Ethernet wiring (presumably in Cat 5e cable) to another location in the residence. The Ethernet path is connected to the RG through one of its four Ethernet jacks (8P8C, often, but improperly, called “RJ-45”). If more than one STB is connected this way, each is connected to a separate Ethernet jack on the RG. At the STB, the path enters via an Ethernet connector (8P8C, so-called “RG-45”).
...
The signal can be led to an STB over an existing inside wiring pair.
The protocol used is the pair form of the HPNA 3.1 protocol (G.9994).
...
Connection of computers to the RG (for Internet access) can be done in (at least) these two ways.
== Ethernet. Connection to the RG is made into any of the four Ethernet jacks (not already occupied by links to STBs).
== Wireless. Regular IEEE 802.11 wireless operation is supported. The network has a default SSID of the form {MAKER}{NUMBER} where {MAKER} is an allusion to the manufacturer of the RG and the {NUMBER} is the last three digits of the RG serial number.
...
A stream is scored as “HD” only if the programming being carried is in an HD format. Merely receiving an SD (standard definition) TV program over a “service” (channel) with HDTV capabilities (such as a digital broadcast TV channel) does
not require an HD stream and does not count toward the HD stream limit.
...
If you have trouble with phone-speak, the first part says that the wire that enters your home from whichever box you have outside, must connect directly to your gateway box with unbroken, CAT-5e, wire and without any phone-line connectors or patch panels. {NOTE -- CAT-6 would work too, but is not mentioned in the article.}
The second part says that they expect each set-top-box to have a direct, CAT-5e, connection to one of the four ports on their gateway box.
I included other content as extracts from the article, but commend the entire article for you to read in detail.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
"QOS and maybe vlans could increase speeds."
