IPv6 Multicast MGID's

Greetings,
At my work we have recently introduced iPads and Apple TV's onto our campus WLAN. In order to get the Airplay to work I am utilizing the VLAN Select and Multicast VLAN features on the controller. Although it is working beautifully, I am noticing a rather large number of IPv6 Multicast MGID's are being generated when I go to the Monitor --> Multicast tab. These only appear when I enable MLD Snooping on the controller. I tried to disable MLD snooping, but if that happens I cannot use the Multicast VLAN Feature to forward the bonjour traffic to the AP's. I tried to create an IPv6 ACL on the controller to block this traffic (with the destination address of FF02::) but for some reason I cannot apply it to the interface, the drill down option doesnt show the ACL I just created. Are these IPv6 MGID's a problem? I am not really noticing any significant performance issues on the wireless network, but it is worrisome to see so many MGID's being generated.
I understand this may be a new and complex issue in the world of wireless, I myself do not completely understand it. But any advice you may have would be helpful.
Here is where I got a lot of my information on how to make the Apple TV's work.
http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_tech_note09186a0080bb1d7c.shtml
Thank you.
Chris.

it shouldn't be an issue to have the IPv6 MGID.  The iPad is capable of using IPv6 so it would make sense that you would see them, if it decided to use itps v6 address over it's v4 address.
If you want to block v6 with your ACL, you would go to the WLAN > Avanced Tab, and use the Override Interface ACL option there. 
HTH,
Steve
Please remember to rate useful posts, and mark questions as answered

Similar Messages

  • RSPAN does not put IPv6 multicast traffic into port

    Hi.
    There is two switches in the equation:
    WS-C2960-24TT-L    12.2(55)SE5           C2960-LANBASEK9-M
    and stack of
    Switch Ports Model              SW Version            SW Image
         1 12    WS-C3750G-12S      12.2(55)SE8           C3750-IPSERVICESK9-M
         2 12    WS-C3750G-12S      12.2(55)SE8           C3750-IPSERVICESK9-M
    *    3 24    WS-C3750G-24T      12.2(55)SE8           C3750-IPSERVICESK9-M
    3 is a master
    There is VTP domain with pruning off and RSPAN VLAN 1001
    core#sho vlan remote-span
    Remote SPAN VLANs
    1001
    there is RSPAN session on first:
    #sho monitor session 1
    Session 1
    Type                   : Remote Source Session
    Source Ports           :
        Both               : Fa0/11
    Dest RSPAN VLAN        : 1001
    Port Fa0/11 is in access mode, VLAN 303
    and on second:
    core#sho monitor session 1
    Session 1
    Type                   : Remote Destination Session
    Source RSPAN VLAN      : 1001
    Destination Ports      : Gi3/0/2
        Encapsulation      : Native
              Ingress      : Disabled
    Problem is that i can't see any IPv6 multicast traffic (like ICMPv6 RA or such) on Gi3/0/2 which is absolutely sure there, because if i remove monitoring session on core switch and put Gi3/0/2 into trunk mode, i can see packets i need in vlan 1001:
    # tcpdump -s0 -nnvei eth1 vlan 1001 and ip6
    tcpdump: WARNING: eth1: no IPv4 address assigned
    tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
    14:17:37.059045 50:57:a8:f0:72:1b > 33:33:ff:00:00:01, ethertype 802.1Q (0x8100), length 90: vlan 1001, p 0, ethertype IPv6, (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) 2abc:abc:1:600b::2 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2abc:abc:1:600b::1
              source link-address option (1), length 8 (1): 50:57:a8:f0:72:1b
    14:17:38.083266 50:57:a8:f0:72:1b > 33:33:ff:00:00:01, ethertype 802.1Q (0x8100), length 90: vlan 1001, p 0, ethertype IPv6, (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) 2abc:abc:1:600b::2 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2abc:abc:1:600b::1
              source link-address option (1), length 8 (1): 50:57:a8:f0:72:1b
    14:17:39.107068 50:57:a8:f0:72:1b > 33:33:ff:00:00:01, ethertype 802.1Q (0x8100), length 90: vlan 1001, p 0, ethertype IPv6, (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) 2abc:abc:1:600b::2 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2abc:abc:1:600b::1
              source link-address option (1), length 8 (1): 50:57:a8:f0:72:1b
    There is no such problem with usual unicast and broadcast traffic.
    Any suggestions?

    Interestingly, i've found bug CSCsr64007 which i stubmbled upon on one of my switches during troubleshooting. The effect of this bug was that RSPAN took IPv6 multicast packets from unrelated VLANs and forwarded them into monitor port.
    Looks like they have "fixed" it filtering IPv6 multicast completely.

  • IPv6 Multicast support for service providers 6PE / 6VPE

    Hi,
    Can anyone comment on the current state of development for IPv6 Multicast support for Service Providers who are using 6PE or 6VPE in their MPLS core.
    (6PE - SP is running MPLS in its IPv4 core, it uses IPv6-enabled provider edge (PE) routers to transport IPv6 traffic over an IPv4-only enabled core. 6PE does not support VPN,s it just provides a mechanism for tunneling IPv6 packets from ingress PE to egress PE routers)
    (6VPE - refers to a PE router capable of supporting IPv6 VPNs. A 6VPE solution can be used to provide IPv6 based layer 3 VPN services in a similar way to IPv4 based Layer 3 VPN services.)
    My understanding is that 6PE and 6VPE solution are unable to support IPv6 multicast traffic.
    Any further information on configuration, design or development work in the pipeline would be gratefully received,
    kind regards John

    Hi John,
    From our question I understand you are sking about the MVPN support for IPv6 multicast. It is actually supported on the XR platform as of now. Please refer:
    http://www.cisco.com/en/US/docs/routers/xr12000/software/xr12k_r4.0/multicast/configuration/guide/mc40mcst.html#wp2890031
    I hope this helps.
    Regards,
    Ruchir

  • IPv6 Multicasting

    Hello,
    I'm trying to get a simple multicasting example to work on Solaris. The general idea is that I would like the server to bind to a unicast address and then add
    itself to the group ff02::1. I would then like it to receive multicasts sent to ff02::1. The code below works on Mac OS X 10.5 (in fact, a server running on OS X gets multicasts sent from Linux clients), but I can't get the Solaris server side to work. It doesn't get any multicasts. If I change the code to bind to :: INADDR_ANY) rather than a unicast address (I've tried both link-local and global addresses), it does get the multicasts. I was wondering if someone could point out what I'm doing wrong.
    server:
       memset( &hint, 0, sizeof( hint ) );
       hint.ai_family = AF_INET6;
       hint.ai_socktype =  SOCK_DGRAM;
       // argv[1] is either a link-local or a global address
       err = getaddrinfo( argv[1], NULL, &hint, &info );
        if( err != 0 ) {
            perror( "getaddrinfo" );
            exit( 1 );
        struct sockaddr_in6 * addr = (struct sockaddr_in6*)info->ai_addr;
        //addr->sin6_addr = in6addr_any; // if this is uncommented, multicasts are received
        addr->sin6_port = htons( 7890 );
        s = socket( AF_INET6, SOCK_DGRAM, 0 );
        if( bind( s, (struct sockaddr*) addr, info->ai_addrlen ) != 0 ) {
            close( s );
            perror( "bind" );
            exit( 1 );
        if( getaddrinfo( "ff02::1", NULL, &hint, &multi ) != 0 ) {
            close( s );
            perror( "getaddrinfo" );
            exit( 1 );
        struct ipv6_mreq mreq;
        memset( &mreq, 0, sizeof(mreq) );
        memcpy( &mreq.ipv6mr_multiaddr,
                &((struct sockaddr_in6 *) multi->ai_addr)->sin6_addr,
                sizeof(mreq.ipv6mr_multiaddr) );
        mreq.ipv6mr_interface = 2; // 2 happens to be the interface ID; I've tried other values here
        freeaddrinfo( multi );
        if( setsockopt( s, IPPROTO_IPV6, IPV6_JOIN_GROUP, &mreq, sizeof(mreq) ) != 0 ) {
            close( s );
            perror( "IPV6_JOIN_GROUP" );
            exit( 1 );
        for( ; ; ) {
            char data[6];
            size_t len;
            len = recvfrom( s, data, 5, 0, NULL, NULL );
            data[5] = '\0';
            printf( "Received %s\n", data );
            if( strcmp( data, "exitt" ) == 0 ) {
                break;
        } The client code is as follows:
        memset( &hint, 0, sizeof( hint ) );
        hint.ai_family = AF_INET6;
        hint.ai_socktype =  SOCK_DGRAM;
        hint.ai_protocol = 0;
        err = getaddrinfo( "ff02::1", NULL, &hint, &info );
        if( err != 0 ) {
            perror( "getaddrinfo" );
            return 0;
        struct sockaddr_in6 * addr = (struct sockaddr_in6*)info->ai_addr;
        addr->sin6_port = htons( 7890 );
        addr->sin6_scope_id = 2; // 2 happens to be the interface ID
        s = socket( AF_INET6, SOCK_DGRAM, 0 );
        for( ; ; ) {
            char data[6];
            size_t len;
            scanf( "%5s", data );
            data[5] = '\0';
            printf( "Sending %s\n", data );
            if( sendto( s, data, 5, 0, info->ai_addr, info->ai_addrlen ) != 5 ) {
                printf( "Error sending\n" );
            if( strcmp( data, "exitt" ) == 0 ) {
                break;
        close( s );

    Hi,
    I'm having the same problem sending multicasts but only for Link Local addresses when i'm sending to Site Local there is no problem
    if you don't have to use a Link Local address i suggest that you add an Site Local (begins with "fec0") address to your net interface and use it instead.

  • WLC - AP Groups - Multicast - Bonjour - Apple TVv3

    Good Morning
    first off - Should start off by saying I have followed the Apple Bonjour deployment guide [except for interface group] portion
    I have searched high and low, here and there to no avail.
    http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_tech_note09186a0080bb1d7c.shtml
    I am aware that the bonjour gateway IOS may or may not come out in Oct/Nov 2012, which maybe my only option at this point.
    Is this not working because of my AP groups setup or have I misssed something
    I can only get bonjour to work if multicast - unicast mode is selected, but our network slowly grinds to a halt, so it is not an option
    when I first connect to the wireless I see 1 bonjour device for about 3 minutes and then disappears.
    I can not see the appletv at all with an ipad, airplay does not appear at all.
    We have the following setup.
    2 campuses - Campus 2 is simular setup, but WLCs higher model and ios 7.2 and clients and subnets are double
    Campus 1
    2 WLC 4404 ios 7.0.230.0
    30 AP groups mapped to 30 Interfaces using subnets with /23 bit subnetmasks
    multicast - multicast is set with multicast addresses of
    controller 1 239.239.5.1 and
    controller 2 239.239.5.2
    multicast is enabled
    IGMPsnooping as well
    On Switch multicast routing is enabled
    all AP group subnets and Mgmt vlans are PIM enabled dense mode
    set up a trunk to ubuntu server to act as a bonjour gateway, installed avahi and vlan
    mapped all AP and mgmt vlans to Ubuntu server.
    avahi see the following + more
    + eth0.136 IPv6 Apple TV                                      _airplay._tcp        local
    + eth0.136 IPv4 Apple TV                                      _airplay._tcp        local
    + eth0.134 IPv6 Apple TV                                      _airplay._tcp        local
    + eth0.134 IPv4 Apple TV                                      _airplay._tcp        local
    + eth0.132 IPv6 Apple TV                                      _airplay._tcp        local
    + eth0.132 IPv4 Apple TV                                      _airplay._tcp        local
    + eth0.130 IPv6 Apple TV                                      _airplay._tcp        local
    more goes on forever
    + eth0.136 IPv4 xyz Library                             Apple Home Sharing   local
    show ip multicast
      Multicast Routing: enabled
      Multicast Multipath: disabled
      Multicast Route limit: No limit
      Multicast Triggered RPF check: enabled
      Multicast Fallback group mode: Dense
    show ip multicast interface vlan 128
    Vlan128 is up, line protocol is up
      Internet address is x.x.128.1/23
      Multicast routing: enabled
      Multicast switching: fast
      Multicast packets in/out: 14671352/276693
      Multicast boundary: not set
      Multicast TTL threshold: 0
      Multicast Tagswitching: disabled
    Where do I go from here?

    Thanks Yahya and Stephen
    I have tried to simplify my config as much as possible.
    wlc 4404
    Ethernet Multicast Forwarding............... Enable
    Ethernet Broadcast Forwarding............... Enable
    AP Multicast/Broadcast Mode................. Multicast   Address : 239.239.5.1
    IGMP snooping............................... Enabled
    IGMP timeout................................ 60 seconds
    IGMP Query Interval......................... 20 seconds
    I have an interface created 10.x.x.x/23
    I have created a new SSID APPLETV - assigned Interface
    I have added the SSID to just 1 AP Group
    show network multicast mgid summary
    Layer2 MGID Mapping:
    InterfaceName                    vlanId   MGID
    2upadhoc                         136      27
    Layer3 MGID Mapping:
    Number of Layer3 MGIDs........................... 11
    My vlan does not show up here.
    I only have 2 devices in this vlan the AppleTV and IPAD
    checking the switch for all required vlans
    show ip multicast
      Multicast Routing: enabled
      Multicast Multipath: disabled
      Multicast Route limit: No limit
      Multicast Triggered RPF check: enabled
      Multicast Fallback group mode: Dense
    admin interface
    Management, AP-Manger
    Vlan12 is up, line protocol is up
      Internet address is x.x.x.1/24
      Multicast routing: enabled
      Multicast switching: fast
      Multicast packets in/out: 238489978/724352
      Multicast boundary: not set
      Multicast TTL threshold: 0
      Multicast Tagswitching: disabled
    AP vlan
    Vlan222 is up, line protocol is up
      Internet address is x.y.z.1/24
      Multicast routing: enabled
      Multicast switching: fast
      Multicast packets in/out: 11423/238338583
      Multicast boundary: not set
      Multicast TTL threshold: 0
      Multicast Tagswitching: disabled
    The test Apple TV Vlan
    Vlan136 is up, line protocol is up
      Internet address is x.xx.1/23
      Multicast routing: enabled
      Multicast switching: fast
      Multicast packets in/out: 156740/0
      Multicast boundary: not set
      Multicast TTL threshold: 0
      Multicast Tagswitching: disabled
    interface Vlan12
    ip pim dense-mode
    interface Vlan222
    ip pim dense-mode
    interface Vlan136
    ip pim dense-mode
    Show ip igmp groups
    Group Address    Interface                Uptime    Expires   Last Reporter
    224.0.1.39       Vlan136                  2d00h     00:02:35  x.x.x.1
    So just to recap
    Same subnet in a AP Group
    New SSID
    multicast enabled on WLC - using multicast multicast mode
    Broadcast forward enable
    Switch -Multicast routing enabled
    all vlans enabled for PIM
    2 devices - added Imac to see if I could home share through Itunes.
    end result
    no bonjour clients, no apple tv, no airplay
    Bonjour Gateway device - although same subnet it shouldn't be needed
    eth0.12   Link encap:Ethernet  HWaddr bc:30:5b:x:x:x 
              inet addr:x.x.x.244  Bcast:x.x.x.255  Mask:255.255.255.0
              inet6 addr: fe80::be30:5bff:fed6:a178/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:55005 errors:0 dropped:115 overruns:0 frame:0
              TX packets:23003 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:2776156 (2.7 MB)  TX bytes:11285256 (11.2 MB)
    eth0.136  Link encap:Ethernet  HWaddr bc:30:5b:x:x:x 
              inet addr:x.x.x.9  Bcast:x.x.x.255  Mask:255.255.254.0
              inet6 addr: fe80::be30:5bff:fed6:a178/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:42167 errors:0 dropped:115 overruns:0 frame:0
              TX packets:22340 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:3251242 (3.2 MB)  TX bytes:10373581 (10.3 MB)
    eth0.222  Link encap:Ethernet  HWaddr bc:30:5b:xx:xx:xx 
              inet addr:x.x.x.9  Bcast:x.x.x.255  Mask:255.255.255.0
              inet6 addr: fe80::be30:5bff:fed6:a178/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:152397 errors:0 dropped:115 overruns:0 frame:0
              TX packets:23768 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:12795709 (12.7 MB)  TX bytes:11318103 (11.3 MB)
    + eth0.222 IPv6 67665ACD317A45B0                              _appletv-v2._tcp     local
    + eth0.222 IPv4 67665ACD317A45B0                              _appletv-v2._tcp     local
    + eth0.136 IPv6 67665ACD317A45B0                              _appletv-v2._tcp     local
    + eth0.136 IPv4 67665ACD317A45B0                              _appletv-v2._tcp     local
    + eth0.12 IPv6 67665ACD317A45B0                              _appletv-v2._tcp     local
    + eth0.12 IPv4 67665ACD317A45B0                              _appletv-v2._tcp     local
    Should Bonjour work same subnet with these settings?
    I am going to have read more about the Interface groups and the Multicast vlan.

  • Multicast ip-pim-sparse mode

    Hi, my consideration are correct  for the multicast protocol ?
    As for the command "ip pim rp-address 173.17.2.1 VALID_GROUP" which is on the site of Padriciano I did a search and, practically, it automatically creates a tunnel interface.
      This thing, as I said, you need to create / enable multicast. Being something of CCNP R & S do not know the different syntax but "PIM" stands for Protocol-Independent Multicast.
      Because you do not have to do often directly with the multicast explain it to follow but it is as a reality check for me:
      Multicast uses the connectionless protocol UDP for transport (transport layer, Layer 4 - L4) and allows you to send, with just sending the same packet to multiple nodes; since UDP does not guarantee delivery. You can think of as a multicast broadcast changed.
      For example: if you have 6 nodes (node = router), for simplicity called ABCDEF, and the node A has to send a packet only to nodes BCDF (excluding the node E) then, with multicast, the packet is sent only once and is delivered to all hosts BCD F.
      That's the theory but in practice petty commands ip pim NOT know them being the subject of CCNP R & S.
    >> A concrete example of multicast: the election of the DR (Designated Router) and the Des BDR (Backup ignated Router) in multiaccess networks (such as Frame Relay networks) with OSPF.
      All routers in the network that are NOT DR or BDR are Drothers (read as DR-Others). The Drothers can only communicate with the DR (simultaneously with the BDR).
    This feature allows you to NOT flood the LSA (Link State Advertisement) to all routers in the network so that only the Drothers send their LSA to the DR and BDR using the multicast address 224.0.0.6 IPv4 or IPv6 multicast address ff02 :: 6.
      224.0.0.6 and ff02 :: 6 = all routers DR
      When the DR receives packets is responsible for forwarding these LSA to all other routers. The DR uses the multicast address 224.0.0.5 IPv4 or IPv6 multicast address ff02 :: 5. The end result is that there is only one router that does the flooding of all LSA in the multiaccess network.
    >> 224.0.0.5 and ff02 :: 5 = all OSPF routers
    ip multicast-routing
    interface GigabitEthernet0/1.134
     description LAN EDA
     encapsulation dot1Q 134
     ip address 134.1.192.31 255.255.255.240
     no ip redirects
     ip directed-broadcast
     standby 134 ip 134.1.192.33
     standby 134 timers msec 300 msec 950
     standby 134 priority 90
     standby 134 preempt delay reload 10
     no shutdown
    router ospf 1
     network 134.1.192.32 255.255.255.240 area 15    ! LAN PMU
    ! Avalaible Routing Multicast for LAN EDA
    ip multicast-routing
    interface GigabitEthernet0/0
     ip pim sparse-mode
    interface GigabitEthernet0/1.500
     ip pim sparse-mode
    interface Serial0/1/0.36 point-to-point
     ip pim sparse-mode
    interface GigabitEthernet0/1.134
     ip pim sparse-mode
     ip igmp join-group 224.0.224.1
    ip pim rp-address 173.17.2.1 VALID_GROUP
    ip access-list standard VALID_GROUP
     permit 224.0.224.1
    router ospf 1
     network 134.1.192.32 255.255.255.240 area 15    ! LAN PMU
    ! Avalaible Routing Multicast for LAN EDA
    ip multicast-routing
    interface GigabitEthernet0/0
     ip pim sparse-mode
    interface GigabitEthernet0/1.500
     ip pim sparse-mode
    interface Serial0/1/0.39 point-to-point
     ip pim sparse-mode
    interface GigabitEthernet0/1.134
     ip pim sparse-mode
     ip igmp join-group 224.0.224.1
    ip pim rp-address 173.17.2.1 VALID_GROUP
    ip access-list standard VALID_GROUP
     permit 224.0.224.1
    I did some tests simulated and I think I figured out why is assigned an IP address instead of another.
     Given that the interface Tunnel0 is created when you type the command "ip pim rp-address 173.17.2.1 VALID_GROUP", in the tests I've done, I Tunnel0 Bind to the IP address associated with the FastEthernet0/0.
    R-SCTI-PADRICIANO-1#sh ip int b
    >>     Interface                  IP-Address      OK? Method Status             Protocol
    >>     FastEthernet0/0            173.27.200.22   YES manual up                    up
    >>     FastEthernet0/1            unassigned      YES manual up                    up
    >>     FastEthernet0/1.20         172.27.195.118  YES manual up                    up
    >>     FastEthernet0/1.30         172.27.230.100  YES manual up                    up
    >>     FastEthernet0/1.31         173.27.254.118  YES manual up                    up
    >>     FastEthernet0/1.32         173.27.216.28   YES manual up                    up
    >>     FastEthernet0/1.134        134.1.192.33    YES manual up                    up
    >>     FastEthernet0/1.500        172.27.250.37   YES manual up                    up
    >>     Serial1/0                  unassigned      YES unset  administratively down down
    >>     Serial1/1                  unassigned      YES unset  administratively down down
    >>     Serial1/2                  unassigned      YES unset  administratively down down
    >>     Serial1/3                  unassigned      YES unset  administratively down down
    >>     Loopback0                  172.27.254.10   YES manual up                    up
    >>     Tunnel0                    173.27.200.22   YES unset  up                    down
    R-SCTI-PADRICIANO-1#conf t
    >>     R-SCTI-PADRICIANO-1(config)#int f0/0
    >>     R-SCTI-PADRICIANO-1(config-if)#sh
    >>     *Feb  6 16:09:31.439 CET: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
    >>     *Feb  6 16:09:32.439 CET: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
    >>     R-SCTI-PADRICIANO-1(config-if)#do sh ip int b
    >>     Interface                  IP-Address      OK? Method Status                Protocol
    >>     FastEthernet0/0            173.27.200.22   YES manual administratively down down
    >>     FastEthernet0/1            unassigned      YES manual up                    up
    >>     FastEthernet0/1.20         172.27.195.118  YES manual up                    up
    >>     FastEthernet0/1.30         172.27.230.100  YES manual up                    up
    >>     FastEthernet0/1.31         173.27.254.118  YES manual up                    up
    >>     FastEthernet0/1.32         173.27.216.28   YES manual up                    up
    >>     FastEthernet0/1.134        134.1.192.33    YES manual up                    up
    >>     FastEthernet0/1.500        172.27.250.37   YES manual up                    up
    >>     Serial1/0                  unassigned      YES unset  administratively down down
    >>     Serial1/1                  unassigned      YES unset  administratively down down
    >>     Serial1/2                  unassigned      YES unset  administratively down down
    >>     Serial1/3                  unassigned      YES unset  administratively down down
    >>     Loopback0                  172.27.254.10   YES manual up                    up
    >>     Tunnel0                    172.27.250.37   YES unset  up                    down
    >> 
    >> IP address Tunnel0 = IP address FastEthernet0/1.500

    Well, this is all looks like it is has to be. What confuses you?
    Tun0 created by pim process to decapsulate multicast traffic coming to RP from source router. It doesn't matter what ip used inside of this interface.

  • Problem about the jmf when working over IPV6

    I write a program about monitoring a RTP stream ,get the feedbacks about the stream by receving the RTCP reports and analysize the paramaters .Now the throny issues encountered is the code working perfect over the IPV4 network .but there are many exceptions when working over IPV6 the exceptions is as follows:
    Exception in thread "RTCP Reporter" java.lang.NullPointerException
    at com.sun.media.rtp.RTCPTransmitter.makereports(RTCPTransmitter.java:200)
    at com.sun.media.rtp.RTCPTransmitter.report(RTCPTransmitter.java:106)
    at com.sun.media.rtp.RTCPReporter.run(RTCPReporter.java:193)
    at java.lang.Thread.run(Thread.java:619)
    the session can be set up and can receive the stream .so I think it is ok of setting up the session with the IPV6 multicast address.strangely , the same particate in the session sends more than one feedbacks with different SSRC which is ought to be single.I cannot figure out.
    I wonder whether there is any special setting when JMF working on the IPV6 network.I did not find materials about the JMF working on IPV6 network in Microsoft xp pc.
    can any guys give me any tips?
    Edited by: judyw115 on Sep 4, 2010 6:08 AM

    judyw115 wrote:
    Is there anyone giving me any advices?You realize this is a free forum and not paid tech support, right?
    Drop the attitude and learn to be patient.

  • Imposible to deploy Ipv6 on lan with catalyst 2950t ?

    Is it imposible to deploy Ipv6 on Lan enviroment with catalyst 2950T access switch?
    Thanks

    [similar question was asked in "ask the expert" so posting the same answer here as well]
    - snip -
    Hello,
    This is a common question which comes quite often – What should I do with my old Layer2 switches (e.g. Catalyst 2900, 3900, 5000, etc.)? The simple answer is; IPv6 is transparent on L2 switches so no need to worry about it. However; there are couple cases where you would need to take a closer look.
    Rightly asked; one is MLD snooping. Yes, if you are planning to have real IPv6 Multicast deployment then you would need to have products which support MLD snooping at Layer2. If you are not deploying IPv6 Multicast then I would not worry about it much.
    Another one is when you have intelligent services on WLAN; may be it’s not Catalyst switch but it’s a AP where you are running intelligent services such as QoS, or ingress ACLs on AP or maybe actual controller based environment where you have thin APs and fat controllers in the back-end, but you have a distributed policy at the edge, if you are doing this and using IPv4 based protocols then you have to make sure that those products supports equivalent configurations for IPv6 capabilities or you would have serious road blocks.
    Simple “2 rules of thumb” which I always tell customers:
    There is no way you put 10lbs of sugar in a 5lb bag.
    Always have plan/testing/validation/pilot before introducing any new protocol/technology in your production network.
    Please take a look at http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/at_a_glance_c45-625859.pdf and lot of good information regarding Enterprise dual-stack case studies and recommendations at www.cisco.com/go/ipv6. I would recommend you to also work with your Cisco Account and Services teams for smooth Dual-Stack deployment.
    Regards,
    Salman

  • Catalyst 6500 IPv6 scalability

    Hi,
    There is an issue on Cat6500 (SUP720-3B) with a lot of IPv6 SVIs: %FM-4-TCAM_LABEL: Hardware TCAM label capacity exceeded.
    #sh tcam counts ipv6
               Used        Free        Reserved
    Labels:(in) 512           0
    Labels:(eg) 59         453
    Each IPv6 SVI consumes one label.
    #show platform software ipv6-multicast capability | include entries
    Directly-connected entries for IPv6 is supported using ACL-TCAM.
    #show platform software ipv6-multicast connected
    IPv6 Multicast Subnet entries
    Flags : H - Installed in ACL-TCAM
            X - Not installed in ACL-TCAM due to
                label-full exception
    Interface: Vlan3733 [ H ]
      S:0:2001:4860:241:B100::1 G:FF00::
      S:2001:4860:241:B100::1 G:FF00::
    Interface: Vlan3732 [ H ]
    <output omitted>
    Is it possible to increase amount of this labels or solve the problem somehow else?

    The IDSM-2 module is capable of both IDS (promiscuous mode) AND IPS (inline mode).
    So if you need IPS (inline mode) you still just buy the same IDSM-2 but configure it for InLine Interface Pair or InLine Vlan Pair mode instead of configuring for Promiscuous mode.

  • Multicasting for Flexconnect mode

    I have requirement to enable multicasting on wireless network.  AP s are on Flexconnect mode. Does Flexconnect mode be enabled for multicast traffic ? 

    In release 8.0, FlexConnect can join CAPWAP multicast group. The controller should be set to Multicast - Multicast mode for both AP Multicast mode and IPv6 AP Multicast mode.
    Note: FlexConnect mode APs will join IPv4 or IPv6 Multicast group if AP Multicast mode is configured as Multicast in release 8.0; however, there will be slight Data through-put degradation impact in the FlexConnect centrally switched scenario compared to AP Multicast mode configured as Unicast.
    Note: Smart AP image upgrade does not work on the 7500 controllers when the Master AP is connected over CAPWAPv6.
    The following IPv6 specific features are not supported in FlexConnect central switching mode:
    ■Layer 3 Mobility
    ■IPv6 VideoStream
    http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/IPV6_DG.html#pgfId-76826

  • Dual-Stack LNS - ppp negotiation fails if no ipv6 prefix assigned by Radius

    Hello,
    We have an LNS (asr1k), dual-stack CPE and Radius server.
    Everything works fine if both ipv4 and ipv6 prefix is assigned to CPE by Radius
    If we set Radius server not to assign v6 prefix, we expect to build up an ipv4-only session over ppp.
    This is not what happens. PPP negotiation fails with the following debug lines:
    IPv6 DHCP_AAA: No authorization data from SSS
    Vi2.2364 PPP DISC: Non-PPP hang up
    some config parts of LNS:
    no ipv6 source-route
    ipv6 unicast-routing
    ipv6 dhcp binding track ppp
    ipv6 dhcp pool IPv6_DHCP_POOL
    ipv6 dhcp pool POOL_DHCP_PD
    ipv6 multicast-routing
    ipv6 multicast rpf use-bgp
    interface Virtual-Template99
     mtu 1460
     ip unnumbered Loopback0
     ip tcp adjust-mss 1420
     no logging event link-status
     ipv6 enable
     no ipv6 nd prefix framed-ipv6-prefix
     no ipv6 nd ra suppress
     ipv6 dhcp server POOL_DHCP_PD allow-hint
     peer default ip address pool adslpool_1 adslpool_2
     ppp max-configure 3
     ppp authentication pap AAA_AUTHEN_PPP_noc3x
     ppp authorization AAA_AUTHOR_NET_noc3x
     ppp accounting AAA_ACCT_NET_noc3x
     ppp ipcp address required
     ppp ipcp address accept
     ppp ipcp no-renegotiation send-termreq
     ppp link reorders
     ppp timeout retry 5
     ppp timeout ncp 30
     ppp timeout authentication 30
    end
    Can anyone help?
    Regards,
    Antal

    Have opend a case with cisco. The solution for me is to put
    no ipv6 dhcp ppp terminate
    in to the global config.
    Hope that helps anyone who has the same problem.

  • 4506 and IPV6 Unicast

    Good morning - Recently I've had the pleasure of dealing with my corporate network ( and all remote sites) coming to a screeching halt.  It turns out that new Lenovo and HP laptops have a "bug" where they flood out multicast traffic when IPV6 is enabled.  When all of my sites started dropping, I checked my processor stats by running the sh processor cpu sorted | exec 0.0 command, and sure enough it was pegged at 99%. The top process was Cat4k Mgmt LoPri, and we later traced down the culprit.
    At any rate, as we do not use IPv6, I would really like to disable any and all ipv6 traffic on my core switch.  I've found a couple ways to go about doing this, but I thought I'd check here to see what the best approach is. As I stated earlier, we do not use IPv6 in any fashion, and I need a fail-safe in place in the event that ipv6 is not turned off when network devices are deployed...
    Thanks for any input!

    Hello,
    We are seeing a lot of customers experiencing this concern. The problem is not HP or Lenovo - it is the type of NIC you are using. If you look at the NIC details, you will find out that these are all Intel i217 NICs. It appears that every time these machines sleep, the NIC floods out IPv6 multicast packets (as you have rightly stated).
    Several workarounds at the source of the problem:
    1. Using power management, disable the sleep feature of these machines.
    2. Upgrade the driver for this NIC to the latest one (a new driver update was released a couple of weeks back I believe).
    In regards to Cisco switches, different platforms will have different tools available to stop this. A common one should be a VACL which drops these packets (packets destined to 3333.XXXX.XXXX). Of course, this is not a very good workaround if you're using IPv6 in your environment. In that case, stopping this at the source is most critical.
    Regards,
    Aninda

  • Link Local Unicast Addresses and Link Local Multicast Addresses

    I am trying to get a hold on Link Local Multicast addressing.  I know that Link Local Unicast Addressing is the equivalent of an APIPA address but can anyone tell me what Local Link Multicast addressing is used for and hopefully provide an example of
    it's use?  Beg your pardon if this is a stupid question.  Thanks.
    Michael T. Glenn

    Hi Michael,
    Obviously, this is not a stupid question.
    The link local multicast addresses are the equivalent of 224.0.0.0/24, which are reserved for the local subnet and are not forwarded by IP routers regardless of the Time to Live (TTL) in the IP header.
    They are used for routing protocol or other well-known multicast based communication.
    For detailed information, please refer to the link below,
    IPv6 Multicast Address Assignments
    http://tools.ietf.org/html/rfc2375
    Best Regards.
    Steven Lee
    TechNet Community Support

  • Broadcast/multicast counters does not increase on vlan interface

    Hi,
    on a Cat6500 we try to monitor interface packet statistics via snmp, in detail we want to get information about the relation between unicast, multicast and broadcast packet counter.
    What we found out is that while on physical l2 interfaces all counters (ifHCInUcastPkts, ifHCInMulticastPkts, fHCInBroadcastPkts, ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts) are filled, on vlan interfaces multicast in/out and broadcast out packets stay zero whole the time. We use arp, hsrp, ospf and other well know broadcast and multicast based protocols.
    Does anybody know why this counters do not increase?
    Attached you find an excel sheet which shows an example of interface counter vs. vlan counter.
    many thanks in advance,
    Thorsten Steffen

    Hi jon,
    belown the result of sh sdm prefer,so need i a licence ip service to apply the route-maap on the interface vlan,or just entrer the config"sdm prefer routing" and reboot the switch?
    SWBB0#sh sdm prefer
    The current template is "desktop default" template.
    The selected template optimizes the resources in
    the switch to support this level of features for
    8 routed interfaces and 1024 VLANs.
      number of unicast mac addresses:                  6K
      number of IPv4 IGMP groups + multicast routes:    1K
      number of IPv4 unicast routes:                    8K
        number of directly-connected IPv4 hosts:        6K
        number of indirect IPv4 routes:                 2K
      number of IPv6 multicast groups:                  64
      number of directly-connected IPv6 addresses:      74
      number of indirect IPv6 unicast routes:           32
      number of IPv4 policy based routing aces:         0
      number of IPv4/MAC qos aces:                      0.5K
      number of IPv4/MAC security aces:                 0.875k
      number of IPv6 policy based routing aces:         0
      number of IPv6 qos aces:                          0
      number of IPv6 security aces:                     60

  • SG220-26 MLD Snooping Stops IPv6

    I have configured a new SG220-26 switch. IPv4 IGMP snooping works nice. However when I enable MLD Snooping, I lose the IPv6 connectivity between the hosts connected to this switch. As soon as MLD Snooping is disabled (Multicast/Properties), IPv6 connectivity is reestablished. The problem seems to be similar to the one discussed some time ago for the SG200 switch:
    https://supportforums.cisco.com/discussion/11690546/sg-200-08-activating-mld-snooping-blocks-icmpv6-no-static-v6-multicast-macs
    I have upgraded the firmware to 1.0.0.18, however the problem remains. Unknown Multicast Action is configured to Drop as I need it so for IPv4 multicast. I could not find any other setting that would always allow essential IPv6 multicast (ICMPv6) to pass. Is this the correct place to report a problem?

    Ryan,
    The deny line in your ACL merely causes the DHCP traffic to be not processed in the ACPBR block 10. However, for this traffic, the processing of the route-map continues to block 20 with the set default interface Null0 command. This could be the cause of the drops you are seeing. Remember, the permit/deny in ACL here only select packets to be dealt with in the particular route-map block. However, it is the permit/deny in the route-map block header that determines whether the packet is going to be PBR-ed or normally routed.
    Assuming you want to keep the DHCP traffic to be normally routed, one of ways of doing that would be:
    ip access-list extended ACPBR_ACL deny udp any any eq bootps log permit ip 10.2.60.0 0.0.0.255 any!ip access-list extended ACPBR_DHCP permit udp any any eq bootps!route-map ACPBR permit 10 match ip address ACPBR_ACL set ip default next-hop 10.99.1.252!route-map ACPBR deny 15 match ip address ACPBR_DHCP!route-map ACPBR permit 20 set default interface Null0
    This configuration causes the DHCP traffic to be processed in block 15, and because of the deny action in the block header, the traffic should fall back to normal routing.
    While I am somewhat surprised that the PBR would affect broadcasts (it should not, and perhaps it affects only a part of the DHCP communication that does happen to be unicasted), I believe this modification of your config is worth trying.
    Best regards,
    Peter

Maybe you are looking for