Configuration note: Microsoft uPNP
Last updated 05/13/04
Also documented via CSCee50541 
-----------------------------------------------------------------------------

Problem:

  Cisco IOS edge routers enabled for IP multicast in enterprise, DSL or other
  access environments directly or indirectly connected to large numbers of 
  hosts running for example Windows-XP show a large number of IP multicast
  routing entries for group 239.255.255.250. This amount of state is so large
  that it can impact the ease of troubleshooting IP multicast operations
  and may also impact performance.

Analysis:

  This behavior is not a bug or problem in Cisco IOS:

  Group 239.255.255.250 is used by a protocol (ms-pnp) which is part of
  Microsofts UPnP (Universal Plug and Play). UPnP is a system by which
  PCs and network appliances (routers, printers, etc..) can detect each
  other and by which also PCs can configure/use features on such network
  appliances.  Network appliances and PCs send and receive packets for
  group 239.255.255.250. Some systems, like Windows-XP do send packets with
  an IP Time-To-Live (TTL) of 4, resulting in routers less than 3 hops 
  away from the host to create state.

Workaround:

  There are two alternatives available in Cisco IOS to filter this or any
  similar IP multicast groups traffic that is unwanted:
  
  a) Filtering at the control plane:

     access-list 1 deny 239.255.255.250
     access-list 1 permit any

     ! Configure on all physical interfaces connected to hosts or
     ! on virtual-template interfaces:

     interface ethernet 0
       ip multicast boundary 1
       ip igmp access-group 1
     
     The command "ip multicast boundary" will inhibit traffic for filtered
     groups to pass across the interface. If a source S to a filtered group G
     (eg: 239.255.255.250) is present on the interface, the router will
     still create (S,G) state but the OIF list will always be kept empty,
     so traffic for this state will never be forwarded. If a PIM or IGMP
     receiver for a filtered group G is present on the interface, the router
     ignore the request and not create multicast routing state. "ip multicast
     boundary" can thus also be used not only on interfaces directly connected
     to sources or receivers, but also between intermediate routers.

     "ip multicast boundary" does not inhibit storing of received IGMP
     membership reports in the IGMP cache as shown via commands like
     "show ip igmp group", "show ip igmp membership". To filter received
     IGMP membership reports to go into the IGMP cache, use "ip igmp access-group".

     The combination of "ip multicast boundary" and "ip igmp access-group"
     allows to filter traffic for multicast groups without impacting
     the performance of forwarding for unaffected unicast and multicast
     traffic. This comes at the expense that the above mentioned empty
     multicast routing state is being created when sources to filtered
     groups are directly connected to the router. This combination is
     called "filtering at the control plane" and it recommended for platforms
     up to and including Cisco-7200/7500 that use software forwarding
     (because it does not impact forwarding performance).
     and the router will not create (*,G) or 

  a) Filtering at the forwarding plane

     ...
     ip access-list 100 deny   ip any  host 239.255.255.250
     ip access-list 100 permit ip any  any

     interface ethernet 0
       ip access-group 100 in 
       ip multicast boundary 1
       ip igmp access-group 1
     
     To avoid any creation of state on a router connected to a source
     sending to a group that is to be filtered, you must include the
     group into a filter for inbound ip packets, as shown above via the
     "ip access-group <> in" command. You still need to maintain
     the "ip igmp access-group" command to inhibit IGMP membership reports,
     and you _may_ want to maintain the "ip multicast boundary" command
     to inhibit potential received PIM join messages for the filtered group.

     Using "ip access-group" to filter packets may have a performance
     impact and you need to check for your particular platform if that
     impact is acceptable in your application. This solution is in general
     preferred for platforms using hardware acceleration for IP unicast/multicast
     forwarding - like Cisco-7600/10000/12000.
     

.