Multicasting in a home setting.

[Daniel Mckibbin]

I have a 3640 connected to a 3550 with an AP attached for my home network. My PC is in a wireless VLAN and XBOX on the wired. When both are on the wired they are able to discover each other and I am able to stream videos from my PC to my XBOX. When on different subnets they are unable to discover each other. I believe the xbox uses multicast group 239.255.255.250 (Which I believe is UPnP) to discover other devices. I enabled multicast routing on my 3640 and PIM dense mode on the wired and wireless vlans with no success. Multicasting is by far the most confusing topic to me. How could I get this to work?

[Daniel Mckibbin]

IGMP is showing they are both joined to the same group, but they can't discover each other. 172.16.1.37 is the xbox and 172.16.1.8 is the wireless PC.

Internet_Router>show ip igmp groups
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
239.255.255.250  FastEthernet0/0.300      00:15:32  00:02:34  172.16.1.37
239.255.255.250  FastEthernet0/0.200      00:17:47  00:02:27  172.16.1.8
224.0.1.40       FastEthernet0/0.200      00:07:27  00:02:30  172.16.1.1

[Daniel Mckibbin]

The PC is finding the XBOX:

2011-03-30 22:08:28 - Started media sharing

2011-03-30 22:08:29 -Detected XBOX 360 at IP address: 172.16.1.37

The XBOX is finding the PC, but when I try to connect via the XBOX the connection times out. I have my firewall disabled. Any ideas?

[Eugene Lau]

Hey Daniel,

Have you got PIM dense mode enabled on all your sub-interfaces?

I thought the PIM address 224.0.1.40  would appear on your .300 interface as well.

If it is, what does the #sh ip mroute

Look like?

Eugene.

[Daniel Mckibbin]

Eugene,

I just have it enabled on the wireless and wired subinterfaces. I have 2 more, management, and servers, but I don't think it's necessary to involve thos two vlans. I don't even know why 224.0.1.40 is showing at all. Isn't that used with sparse mode to find an RP? Here is the mroute output as requested. It's been a year or more since I've studied multicasting so the output is confusing me right now

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 01:05:47/00:01:26, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0.300, Forward/Dense, 00:04:37/00:00:00
    FastEthernet0/0.200, Forward/Dense, 01:05:38/00:00:00

(*, 224.0.1.40), 1d22h/00:02:29, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:

[Eugene Lau]

Hey Daniel,

That's cool, just doing the Sanity checking We should be able to ignore 224.0.1.40 in Dense mode. RP discovery is on by default.

Multicast routing in Dense mode should be pretty simple. If you have a source and a client who's requesting the multicast via IGMP, it should work We can see from the OIL (Output Input List) that the router would forward 239.255.255.50 to all VLAN's. the FLAG DC is also expected.

If IGMP is stable (I would expect this to be OK because you don't have intermittent behaviour) - ie. IGMP joins are seen in router and group also seen i nswitch and OIL is correct, I'd verify if the traffic was OK. eg TTL=1

#sh ip traffic -> bad hop counts

If this is incrementing while you're running the connectivity tests -> check the source traffic TTL.

Otherwise, will have to start debugging to work out what might be broken.

#sh ip mroute active

#sh ip mroute count

#debug ip mpacket

#debug ip mroute

Tools reference with outputs

http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080093f21.shtml

Some ideas on output here

http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094b55.shtml

Other steps I might try:

- statically configure IGMP snooping in switch to join the group

- statically joining the group on the router interface

- disabling IGMP snooping (if i thought it could be a snooping issue)

Eugene

[Daniel Mckibbin]

Eugene,

You set me in the right direction. Show ip traffic did show incrementing Bad Hop Counts when attempting to discover the multicast source. Before this I tried many things including some of your suggestions. I set up a SPAN session and forwarded the packets from my XBOX to my pc and sniffed the packets. Multicast packets sourced from my the XBOX were sent with a TTL of 1. Damn it! I have attached the capture if you'd like to take a look. I was looking to see if there was some way to modify the TTL value within the switch or router since I can't do it from the XBOX and all I could find was filtering packets by TTL. Do you know if this is possible?

Dan

[Eugene Lau]

That's great news mate! Next time it would be the first thing you'd check

Ultimately, it would be better if you could reconfigure the TTL on the XBOX/host. There's a command you could use to ignore the multicast TTL but would have to check if it's available in your IOS/platform/interface (not sure on the wireless side) via the IOS command reference for your version.

Interface level config

#ip multicast ttl-threshold

once configured, when a multicast packet is received on the interface, the router checks to see if the TTL of the mcast packet is higher than the threshold and forwards the packet.

Example:

http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_03.html#wp1067251

HTH

Eugene.

[Daniel Mckibbin]

The low TTL's are only being received on the wired side. The Windows 7 based PC is on wireless. I added the command to vlan 300 (wired), but there is no change, because the default setting is 0. Is there an alternate method for when the packet has already passed through the interface and the TTL decremented to 0?

Internet_Router(config)#interface fa 0/0.300
Internet_Router(config-subif)#ip multicast ttl-threshold 0
Internet_Router(config-subif)#end
Internet_Router#show run int fa 0/0.300
Building configuration...

Current configuration : 198 bytes
!
interface FastEthernet0/0.300
description Wired
encapsulation dot1Q 300
ip address 172.16.1.33 255.255.255.224
ip pim dense-mode
ip nat inside
ip virtual-reassembly max-reassemblies 24
end

Internet_Router#show ip multicast interface fa 0/0.300
FastEthernet0/0.300 is up, line protocol is up
  Internet address is 172.16.1.33/27
  Multicast routing: enabled
  Multicast switching: fast
  Multicast packets in/out: 773/1117
  Multicast TTL threshold: 0
  Multicast Tagswitching: disabled

[Eugene Lau · Accepted solution]

Apologies Daniel.

It looks like I'm mistaken and the command is not to be used in this fashion (more for controlling the mcast boundry). I checked a few sources and The router will still govern the incoming TTL=1 frame, decrement and drop. No logic to pass it over to the outgoing interface.

In this light, there does not appear to be a way to re-write the TTL to route this traffic (checked for NAT, PBR, ip options type features)

Possible solutions

a. Something that you've tested - is to bridge the wireless to the wired - same VLAN (depending on the requirement for splitting the L2 domain)

b. I'm not sure if it's possible in the XBOX but if it can be a broadcast instead of multicast, it maybe possible to use ip directed broadcast.

look at some type of proxy but At this point, can't think of anything else

Eugene

[Daniel Mckibbin]

Eugene,

With the assistance from an Engineer at work we were able to get it to work by bridging traffic between vlan's:

bridge irb
bridge-group 10 ---on  fa0/0.200
bridge-group 10 input-address-list 700  --- on  fa0/0.200
bridge-group 10 ---on  fa0/0.300
bridge-group 10 input-address-list 700 ---on  fa0/0.300
bridge 10 protocol ieee

Bridge address access list 700
    permit 4c0f.6e8f.a311   0000.0000.0000 (428 matches)
    permit 0025.aec2.62ef   0000.0000.0000         - not matched because it's not powered on
    permit 0000.0000.0000   ffff.ffff.ffff (4 matches)

This works fine when the pc's have static addresses or their dhcp binding hasn't expired, but I noticed that if I reboot my PC it can't find a DHCP server. I clear ip dhcp server stats and it shows no DHCP Discovers or anything. 0's across the board. I would think that the broadcast from each VLAN even though bridged would make it to the DHCP server. I thought maybe it was the access list and the MAC of the default gateway would have to be allowed, but when removing the access-list still nothing. When an IP address is statically configured everything works great though. I wonder what the problem is... I was thinking maybe the DHCP server was seeing the request from both VLAN's and seeing a loop, but after enabling debug ip dhcp server events and ip dhcp server packets nothing appears. The second the bridge group is removed their is a flood of output, and an address is retrieved.

[Eugene Lau]

Hey Daniel.

What's the topology? I keep thinking there's a wireless module in the router but it's actually an AP connected to the same switch or different switch? When I mentioned bridging the wired to wireless, I was thinking of keeping the wired and wireless in the same VLAN.

Where's the DHCP service located? on the router?

Let me ask this - What is the requirement to have two separate VLAN's? I'm trying to understand the constraints the solution has to adhere to, possibly physical cabling etc

When you configure bridge irb then everything is bridged within the  bridge group by default. Routing for IP will need to be configured  explicitly using the brige route ip command - requiring a BVI to act as the default gateway.

http://www.cisco.com/en/US/tech/tk389/tk815/technologies_tech_note09186a0080094663.shtml

I suspect that you've kept the IP's on the sub-interface. Personally, in this case, I would prefer that Wired and wireless be on the same VLAN without IRB, but if you wanted to give it a go, try the BVI if the DHCP service is on the 3620.

Eugene.

[Daniel Mckibbin]

I ended up changing the configuration of my access point so that Wireless and Wired is in the Same VLAN, even though that isn't what I wanted.

3640 ---- Trunk for vlans 100, 200, 300, 400 - 3550 switch - AP connected to fa 0/47

That's part of the challenge I wanted to keep them in different vlans and only permit those two host to communicate to each other or be bridged between vlans. The DHCP server is located on the router for both vlans 200 and 300. Their are no contraints or requirements. I just wanted to seperate the wireless from wired traffic except for these two hosts.With a BVI both vlans 200 and 300 would have to be within the same subnet. It seems you can't configure subinterfaces on a BVI to specify 2 default gateways, one for vlan 200 and one for  vlan 300.

Thanks for the help, all is working when they are on the same vlan. I just thought it would be cool to bridge the two vlans.

[Eugene Lau]

Cools Daniel.

Tinkering is a good enough reason! I was going to throw private VLAN's into the mix but luckily the 3550 doesn't support it, so no need to break anything again

Take care for now.

Eugene