Airport wifi problems with uverse and gigabit switch resolved

Question

Level 1

0 points

Airport wifi problems with uverse and gigabit switch resolved

I think there is a bug in airport firmware 7.6 with how spanning tree works in addition to problems with the Uverse router. Having an Airport with a uverse 2wire 3801 and gigabit switch will not work. Putting the extreme in NAT mode with DMZ plus behind the uverse resolved the problem.

Network configuration:

Uverse 2wire 3801 router

3801 provides prioritization for upstream traffic so skype and VoIP work better when doing a lot of stuff on Internet

Airport extreme firmware 7.6

two airport express 802.11n hardwired to extreme. Set up in bridge mode. All access points have same SSID "create a network" to enable roaming. Ignore anything to do with extending a network. firmware 7.6

two gigabit switches

Netgear GS608 - 8 port gigabit switch

Trendnet TEG-S80g - 8 port gigabit switch

100BT 5 port switch - did not figure into problem

Three Uverse set top boxes wired on Ethernet. They have to be wire directly to the 2wire box to work correctly. See: http://forums.att.com/t5/Features-and-How-To/At-amp-t-U-Verse-modem-setup-Airpor t-Extreme/td-p/2300785

However, you need to be careful to place your own PCs and other internet devices on the network created by your gear (airport extreme in your case), but keep AT&T's set top boxes for the IPTV services IN FRONT of your own router - so they remain on AT&T's provided network.

So it would work like this ...

Network 1: 2wire RG (4 lan ports) -> Any Set tops, and to the WAN port on your AirportExtreme

Network 2: Airport Extreme LAN ports -> to any computers or internet devices (but not AT&T set top boxes).

The RG prioritizes the traffic for your Uverse Voice and your Uverse TV ahead of internet data traffic, as it rationalizes data heading out of your home. If you place your own equipment in that equation (like putting AT&T set top boxes behind your Airport Extreme) the performance and function of your AT&T set top boxes could really flake out on you.

Symptom:

Everything would be working fine, then intermittently all my wifi access points would stop working. ~6,000 ms latency, dropped packets. Ethernet worked fine. Here is an example of my macbook pinging the extreme when associated with the extreme over wifi with a strong signal.

ping: sendto: Host is down

Request timeout for icmp_seq 23

Request timeout for icmp_seq 24

64 bytes from 192.168.1.64: icmp_seq=25 ttl=255 time=267.051 ms

Request timeout for icmp_seq 26

Request timeout for icmp_seq 27

Request timeout for icmp_seq 28

64 bytes from 192.168.1.64: icmp_seq=26 ttl=255 time=3402.599 ms

Request timeout for icmp_seq 30

Request timeout for icmp_seq 31

Request timeout for icmp_seq 32

64 bytes from 192.168.1.64: icmp_seq=30 ttl=255 time=3060.673 ms

64 bytes from 192.168.1.64: icmp_seq=34 ttl=255 time=24.115 ms

64 bytes from 192.168.1.64: icmp_seq=35 ttl=255 time=31.056 ms

64 bytes from 192.168.1.64: icmp_seq=36 ttl=255 time=39.828 ms

Root cause:

It looks like the 2wire 2801 router has a problem with spanning tree when interoperating with gigabit switches and airports. There is interplay with the airport.

I did not have this problem until the 7.6 airport firmware. I had been using the Netgear hub for about a year with the extreme in bridge mode. I added the Trendnet hub and upgraded airport firmware at the same time which made fault isolation difficult.

Problem recreation:

Set up airport expresses hard wired to extreme

Connect gigabit switch anywhere to network

Everything OK

Dettach one computer from wifi then reattach, then all wifi stops working. It takes a few seconds for the problem to propagate.

Ethernet still works fine

Problem Resolution:

Connect to 2wire with ethernet

Set 2wire route to have subnet as 192.168.2.x

Set extreme in NAT mode behind 2wire. It will complain about double NAT. Override the warning. Set the subnet to 192.168.1.x so you don't have to change any static IP addresses. Note that 2wire uses 192.168.1.254 as default route whereas airport uses 192.168.1.1.

I set DHCP to start at .10 to leave the lower addresses for assigning static IP addresses to computers I want to expose outside the firewall.

Go into firewall settings. Select airport extreme. Select the bottom setting which is "DMZ Plus". When you go into the airport extreme settings, you will now see that it has the uverse public IP address on its WAN port. NAT port mappings work fine on the extreme behind the 2wire router.

Posted on Nov 18, 2011 10:14 AM

Reply

Answer 1

Nov 18, 2011 9:18 PM in response to snowyogi

I am having no luck with my config similar to yours, either in bridged or in "router behind router" dmzplus mode. I have 2 airport extremes and my first setup was using the dmzplus and using one of the extremes as a router and then extending the network by ethernet to the other extreme. Followed Apple support doc to the tee. With that setup I basically had unuseable internet. On a uverse 20+mb circuit I would drop to 250k or less speeds. Unplug the extreme functioning as a router and everyting would work fine. I then went to trying both extremes in bridged, both hard wired. Now I just get intermintent drops, hanging web pages and weird network issues, like not being able to see my sonos music device. I previously had this same setup on cable where I had a block of public IP's and everything worked just fine. I'm pulling my hair out. Any thoughts?

Reply

Answer 2

snowyogi Author

Level 1

0 points

Nov 21, 2011 7:39 AM in response to jdjohnston

I isolated my problem by adding one element at a time and trying to figure out if I could recreate the problem. I assume you started from a reset to defaults on both extremes and updated to latest firmware. Did you try swapping the extremes? Does it matter what client you use for the speed test (wifi or wired). Try using iperf to test the speed of the network between various points in the network with various configurations. You could have a problem of one of the ethernet links not negotiating properly. There can also be a spanning tree problem. Hope these ideas help.

Reply

Answer 3

XPtoMBP

Level 1

4 points

Jan 13, 2013 1:31 PM in response to snowyogi

Keeping this very short here is a summary of the actual problem and solution to allow your Apple Airport Extreme to run in Bridge mode on the same subnet as your uVerse settop boxes (if your Layer 2 switch is configurable).

Devices: Uverse, Cisco SG300, and Airport Extreme

uVerse uses Multicast to broadcast video streams between the uVerse network to the settop box, and from settop box to settop box.
X number of Multicast Groups are created based on X number of settop boxes you have. You can see the multicast definitions by logging into the webinterface of the iNid. Each settop box is a member and can choose to display a broadcasted TV stream or not.
Multicast membership is setup by the use of ICMP messages for IPv4 (MLD for IPv6). Each of the settop boxes become members of each others multicast group by reporting up to the iNid (MultiCast Proxy).
In an ideal world a layer 2 switch will track these memberships and only forward a broadcast packet to the ports on the switch to which the settop boxes are connected to. The switch would do these via snooping on the ICMP packets. Most switches by default do not do this by default and simply forward the broadcast packett out every one of it's switch ports.
Here in lies the problem. Problem is that the Apple AES doesn’t do ICMP snooping / filtering and floods the wireless network with these broadcast streams.
In order to fix this you must turn on ICMP snooping and filtering on the switch (or buy a switch that does this). I have a Cisco SG300 and list out the configuration below.

Other notes:

Ensure that all Media renderers (settop boxes) and servers are wired directly off the switch and not attached to any of the Airport Express ports. This way no media transverses the Airport (only control point traffic goes through the WiFi - which is fine). Obviously if the IGMP snooping switch sees any client requesting Multicast streaming traffic on the same port as the WAP, it will add that Multicast address to the forwarding table for that port, and then, yes it could get flooded.
Remember, you need to allow some Multicast traffic through your WAP to allow UPnP discovery to work (assuming that you will be using Wireless control points.)
Read the Multicast chapter in the SG 300 switch Admin Guide as it explains things very well.

Setting up multicast on the SG300s using the WebUI:

1. Multicast/Properties/

Tick enable Bridge Multicast Filtering Status for VLAN 1, and
set the Forwarding Method to IP Group Address for both IPv4 & IPv6.

2. Multicast/ IGMP snooping/

Tick enable IGMP snooping status then select and edit the entry and ensure that IGMP querier status is ticked.
It's essential for IGMP snooping to work that there must be at least one active IGMP querier on the network - if more than one is enabled, they will carry out an "election" to decide which one should be active (normally the one with the lowest IP address.)

3. Multicast Router Port

Set whichever port that is connected to the uVerse iNid to Status which means that it the uVerse router connected to this port is the Multicast Router

4. Multicast/ Unregistered Multicast

set all ports to Filtering. (The default is Forwarding.)

There are a lot of other variables within all the above - the defaults are OK, you should probably leave them alone!

In the config file you would then expect to see the above appearing as something like this:

ip igmp snooping

ip igmp snooping vlan 1

ip igmp snooping vlan 1 immediate-leave

interface vlan 1

bridge multicast mode ipv4-group

bridge multicast ipv6 mode ip-group

interface range gi1-10

bridge multicast unregistered filtering

ip igmp snooping vlan 1 querier

ip igmp snooping vlan 1 querier address <IP-Addr>

Reply