"Weekly Test"

Tutor

"Weekly Test"

I had Uverse installed on Saturday the 7th (pair bonded install). Starting on Monday through today, I am getting bombarded EVERY morning between about 8:00 and 9:30 AM with multicast packets from a 71.x.x.x address that comes back to SBCIS. In the packet is the text "Broadcast station or cable system has issued a *** Required weekly Test ***". While this occurring, the network is hammered so bad that DHCP no longer works and my WAP goes up and down.

It seems to me that if AT&T is going to do a "weekly" test, they should do it in the middle of the night and not do it daily.

Any thoughts?

 

2109iD2189C5D40C8503E

 

Message 1 of 9 (1,844 Views)
Expert

Re: "Weekly Test"

From the timing of the packets in your packet capture there, I see about 10 packets every 0.05 seconds.  That's 200 packets per second, and from the bottom display, each packet is about 270 bytes.

 

This works out to a data rate of 54 KB/sec, or around 420 kbps.

 

420 kbps is nothing by comparison to TV streams.  A single HD stream is 5700 kbps, over 10x as high.

 

So I highly doubt that this stream is responsible for any network difficulties you're having due to a bandwidth or utilization issue.  The destination IP and MAC address are multicast, and any normal host on the network that's not a member of that multicast group should ignore the packet at the hardware level.

 

The "Required Weekly Test" is related to the emergency broadcast system / emergency alert system (EAS).  This is the TV system used for severe weather, national disaster, etc.  This is probably the communication channel used from AT&T to tell the STBs to bring up that weather alert.  AT&T doesn't generate these alerts, they're forwarded from the weather centers, police departments, etc., and are required by law.  The required weekly test should not bring up an alert on the TV, only the monthly test is required to show an alert to the end user.

 

Message 2 of 9 (1,844 Views)
Highlighted
Tutor

Re: "Weekly Test"

That may be, but the net effect is that the RG gets so busy that it cannot give out DHCP addresses. This afternoon, it occured again and I was getting hit with the UDP broadcasts every 3 micro (yes, micro, not milli) seconds. Well, even AT&T level 3 service does not know why....

Message 3 of 9 (1,844 Views)

Re: "Weekly Test"

 


n6mon wrote:

That may be, but the net effect is that the RG gets so busy that it cannot give out DHCP addresses. This afternoon, it occured again and I was getting hit with the UDP broadcasts every 3 micro (yes, micro, not milli) seconds. Well, even AT&T level 3 service does not know why....


Level 3 service?  You're at level 3 service, the message boards.  You either get the front line agents or Tier 2,  that's as high as it goes.

 

” Auto racing, bull fighting, and mountain climbing are the only real sports … all others are games.”- Ernest Hemingway
Message 4 of 9 (1,844 Views)
Tutor

Re: "Weekly Test"

OK, this is still occurring EVERY morning. It appears to start before 7:00 AM Pacific anc usually continues for an hour or 2. I did a capture this morning and in a 1 minute capture, got 32566 multicast UDP frames (533/second). They are directed to 239.192.38.21. which the RG/iNID gateways to 192.169.0.104. Redardless of your comments that it should NOT affect performance, it does. When this is occuring, no one get an IP from the DHCP server on the RG/iNDID, my HomeManager devices loose IP connectivity and my secondary WAP is not able to allow connections. As soon as this traffic stops, the network returns to normal. Tier 2 cannot help, nor could an iNID specialist. When this starts, NO ONE is watching TV or using the network (and yes, I do realize that IPTV is UDP, but it is not multicast UDP, it is point to point).

 

Picture of capture attached.2224iAE07345C105C1832

Message 5 of 9 (1,844 Views)
Expert

Re: "Weekly Test"


n6mon wrote:

OK, this is still occurring EVERY morning. It appears to start before 7:00 AM Pacific anc usually continues for an hour or 2. I did a capture this morning and in a 1 minute capture, got 32566 multicast UDP frames (533/second). They are directed to 239.192.38.21. which the RG/iNID gateways to 192.169.0.104. Redardless of your comments that it should NOT affect performance, it does. When this is occuring, no one get an IP from the DHCP server on the RG/iNDID, my HomeManager devices loose IP connectivity and my secondary WAP is not able to allow connections. As soon as this traffic stops, the network returns to normal. Tier 2 cannot help, nor could an iNID specialist. When this starts, NO ONE is watching TV or using the network (and yes, I do realize that IPTV is UDP, but it is not multicast UDP, it is point to point).


 

 

Again, you're not understanding the system.

 

First of all, the IPTV most certainly is multicast.  It is not unicast as you've stated.

 

239.192.38.21 is the multicast IP address for channel 1003 (KNTV-HD-11 (NBC) San Jose, CA).

 

Your captured packets are 1374 bytes, coming in at 533 per second = 1374*533*8 = 5858736, or 5.85 Mbps, the exact data rate of an HD TV stream.

 

One of your STBs was tuned to this channel during this time period.  Possibly the DVR was the unit, it may have been recording even if no one was watching that TV.

 

If you have mixed TVs and computers on the same network, then that's why you're seeing this traffic.  To mix them together like this means you have a switch somewhere that has both STBs and computers connected to it.  That's the problem -- the switch is being overwhelmed with traffic that it can't handle because it has to treat multicast as broadcast.

 

You need to plug all STBs directly into the RG and only plug computers into the switch.  The RG will then be able to isolate the TV traffic away from the computers and the computers and the switch will never see that traffic.

 

Message 6 of 9 (1,844 Views)
Tutor

Re: "Weekly Test"

OK, I verified the box (the only one I have on Cat 5 on the switch), BUT WHY does this high data rate occur on only ONE HD channel. I tuned the STB to that stream and saw the traffice increase, as soon as I tuned the STB to another HD channel, the broadcast multicast packets were much lower and streaming from the DVR does not cause this..

Message 7 of 9 (1,844 Views)
Expert

Re: "Weekly Test"

It would help a lot if you would post the complete network architecture in your house, including switches, STBs, DVR, and all computers, and how everything is hooked together.

 

Message 8 of 9 (1,844 Views)
Tutor

Re: "Weekly Test"

The issue definitley seems to be the one STB that is on Cat5. Network diagram attached. The diagram shows 2 CAT5 attached STB's. One is te DVR and is attached directly to the 2-Wire embedded switch. The other one is downstream. We are re-doing that room and that STB will most likely end up on coax when done. Does not show up in the attached drawing, but Green connects are GigEthernet.

 

2484i04C4BE03A065AC10

Message 9 of 9 (1,844 Views)
Share this topic
Announcements

Welcome to the AT&T Community Forums!!! Stop by the Community How-To section for tips on how to get started.