I had to make a quick purchase and I was limited by the dimensions that the wall hutch would allow, a width of 38 3/4″. I did some research and landed on the Vizio 39″ LED TV sold by Best Buy – yes, I still frequent Best Buy and enjoy having a brick and mortar store that I can run down to in a pinch and pickup an item. I decided to pickup a third Google Chromecast already having two others elsewhere in the house.

HDMI-CEC

With Consumer Electronics Control (CEC) you can simultaneously turn on your TV and Chromecast and even change the TV to the correct HDMI input without ever touching your TV remote. I had to enable this feature in the Vizio TV, it was automatically enabled in my 40′ Samsung LED TV, but it makes using the Chromecast very user friendly. You just select the Chromecast on your smart phone, tablet or laptop and it turns on the TV, changes to the correct HDMI input and starts showing your content.

The Chromecast supports 2.4Ghz 802.11bg wireless networks although a 5Ghz version is rumored to be in the works. There’s a deployment guide from Cisco that details how the Chromecast works and what settings are needed in an enterprise wireless network. There’s a little known tidbit about which data rate Multicast traffic is transmitted at;

Multicast applications, such as Chromecast, require special consideration when being deployed over a wireless network because a multicast in 802.11 is sent out as a broadcast so that all clients can hear it. The actual data rate used by the AP in order to transmit the Chromecast frames is the highest mandatory rate configured within that band. For 2.4 GHz, the default rate is 11 Mbps.

In order to optimize the delivery of these frames, it is important to tune the 802.11 data rates within the controller to allow multicast to be delivered at the highest rate that the coverage model of the network can support. For networks with a low density of APs, it may be necessary to keep the data rates at the default. For a network that does not have any requirement to support 802.11b clients, tuning the data rate to 12 Mbps mandatory and lower rates disabled will help to reduce multicast airtime utilization.

I’ve run into similar issues in my enterprise wireless network with Apple TVs as opposed to Google Chomecast, but the same issues apply.

There’s a great article from How-To Geek that details how you can stream your browser tabs and even your entire desktop to the Chromecast. There’s also a dizzying array of applications that now support Chromecast.

Cheers!

Note: This is a series of posts made under the Network Engineer in Retail 30 Days of Peak, this is post number 28 of 30. All the posts can be viewed from the 30in30 tag.

The WS5100 would intermittently come under extreme load for 5-30 minutes, so much load that ultimately the entire wireless network would collapse as the Access Ports started experiencing watchdog resets and would just continually reboot themselves. This problem would come and go throughout the day or night, we could go 12 hours without an issue and then go the next 12 hours with issues every 30 minutes. The problem was affecting both the primary and secondary WS5100 so I eliminated the hardware almost out of the gate. I have first hand experience running v3.3.5.0-002R software on a large number of WS5100s and have never had an issue with that software release so I really didn’t suspect the software. This wireless solution had been in place for more than 18 months without any major issues or problems. The local engineers reported that there had been no changes, no new devices. So what was causing this problem? I immediately suspected an external catalyst but how would I find it?

As with most highly technical problems it wasn’t until I could get my hands on some packet traces and I had time to dissect those packet traces that I could start to fully understand and comprehend what was actually going on.

Topology

A pair of Motorola WS5100 Wireless LAN Switches with 30 AP300 running software release v3.3.5.0-002R in a cluster configuration with one running as primary and the other running as secondary. The network was comprised of a single Cisco Catalyst 4500 with around ten individual Cisco Catalyst 2960S switches at the edge each trunked to the core in a simple hub and spoke design. The entire network was one single flat VLAN. The WS5100s were attached to the Cisco Catalyst 4500 via a single 1Gbs interface, one arm router style. The peak number of wireless devices was around 200, the total number of MAC addresses on the network was around 525 (this includes the wireless devices).

Symptoms

The initial problem report centered around poor wireless performance and sure enough I quickly found 30-40% packet loss while just trying to ping the WS5100. When I finally got logged into the WS5100 I could see that the CPU was running at 100%. The SYSLOG data showed me that the APs were rebooting because of watchdog timeouts. PTRG was showing me that here was a huge traffic surge being received from the WS5100. I quickly realized that the traffic spikes in the graph correspond to events that users were experiencing problems.

Packet Traces

I directed the team to setup a SPAN port to capture the traffic that was flowing between the WS5100 and the Cisco Catalyst 4500 switch. This would provide me a better idea of what was actually on the wire and might provide a clue as to what was transpiring. The team setup Wireshark to continually capture to disk using a 100MB file size and allowing the file to wrap 10 times for a total of 1GB of captured data. The next time the problem occurred I was alerted within 15 minutes by the help desk and users but I found that we missed the start of the event. There was so much traffic Wireshark only had the past 3 minutes available on disk so we had to increase the filesize to 300MB and the number of wrap files to 25 giving us a total capacity of 7.5GB. That configuration would eventually allow me to capture the initial events along with the time needed to get to the laptop and copy the data before it was overwritten. While I waited for the problem to occur I took to setting up SWATCH to alert myself and the team when the problem started so we could quickly gather all the data points during the start of the event.

Using the data from the packet traces we were able to identify and locate two HP desktops that were apparently intermittently flooding the network with ICMPv6 Multicast Listener Reports.

We removed those HP desktops from the network and everything has been stable since.

Analysis

Here’s the current working theory which I believe is fairly accurate. The HP desktops were intermittently flooding the network with ICMPv6 Multicast Listener Reports. Those packets were reaching the WS5100 and because the network at this location is a single flat VLAN the WS5100 needs to bridge those packets over to the wireless network. It does this by encapsulating them in MiNT in a fashion very similar to CAPWAP  or LWAPP. The issue here is the number of packets and the number of access points or access ports. In this case we had 30 APs connected to the WS5100 so let’s do some rough math;

41,000 ICMPv6 Multicast packets * 2 HP desktops = 82,000 packets * 30 APs = 2,460,000 packets

This explains the huge amount of traffic the WS5100 is transmitting. For every ICMPv6 Multicast packet (or broadcast packet for that matter) received by the WS5100, it needs to encapsulate and send a copy of that packet to each and every AP. If there are 30 APs then the WS5100 needs to copy each and every packet 30 times. Now multiply that by the number of ICMPv6 packets that were being received by the WS5100 and you have a recipe for disaster.

A quick search of Google will reveal a number of well documented issues with Intel NICs.

The HP desktops turned out to be HP ProDesk 600 G1s running Windows 7 SP1 with Intel I217-LM NICs driver v12.10.30.5890 with sleep and WoL enabled.

Summary

There were a few lessons learned here;

1. The days of the single flat network are gone. It’s very important to follow best practice when designing and deploying both wired and wireless infrastructures. In this case if the wireless infrastructure had dedicated VLANs both for the wireless client traffic and for the AP traffic this problem would have never impacted the WS5100. It may have impacted the Cisco Catalyst 4500 somewhat but it wouldn’t have caused the complete collapse of the wireless infrastructure. Unfortunately in this case everything was on VLAN 1, wired clients, APs, wireless clients, servers, IP phone systems, routers, everything.
2. The filtering of IPv6 along with Multicast and broadcast traffic from the wireless infrastructure is especially important. I posted back in September 2013 how to filter IPv6, multicast and broadcast packets from a Motorola RFS7000, the same applies to the WS5100. Unless you are leveraging IPv6  in your infrastructure, or have some special multicast applications you should definitely look into filtering this traffic from your wireless network.
3. Validate those desktop and laptop images, especially the NIC drivers and WNIC drivers. In the early days of 802.1x I can remember documenting a long list of driver versions and Microsoft hotfixes required for Microsoft Windows XP (pre SP2) in order to get 802.1x authentication (Zero Wireless Configuration) to work properly.

Conclusion

Wireshark saved this network engineer’s holiday – Thanks!

Cheers!

Note: This is a series of posts made under the Network Engineer in Retail 30 Days of Peak, this is post number 27 of 30. All the posts can be viewed from the 30in30 tag.

In this specific case all the routing was being performed by a number of high-end Cisco ASA firewalls which didn’t have PIM routing configured or enabled so I took the easy approach of just disabling IGMP snooping across the Cisco Catalyst 6504 and 4948 switches and the problem was solved. The cleaner solution would have been to setup an Mutlicast Router (mrouter) on the VLAN to properly handle all the IGMP requests and reports.

As pointed out by a colleague you can use a great little Python script written by RedHat for testing Multicast on your Linux servers.

Cheers!

Note: This is a series of posts made under the Network Engineer in Retail 30 Days of Peak, this is post number 3 of 30. All the posts can be viewed from the 30in30 tag.

Reference;
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/68131-cat-multicast-prob.html
http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/route_multicast.html

I originally calculated that the broadcast and multicast traffic was accounting for between 40Kbps and 60Kbps of traffic on our wireless network. However, looking at the traffic graphs right after the change I was shocked at the delta. I performed the change just before noon and you can see a delta of Mbps not Kbps. I would estimate that the changes are saving us 5Mbps of traffic to/from our wireless network.

That’s a lot of needless background noise that ultimately leads to airtime issues which eventually results in retransmissions, delayed packets, jitter and packet loss which can severely impact application performance.

Over the past few weeks I’ve been working to deploy some filters on our Motorola RFS 7000 Wireless LAN Switches  (v4.4.2) so I thought I would share them as a best practice in any medium to large scale wireless deployment. If you only have 10 APs then you probably don’t need to worry about filtering the broadcast and multicast traffic. If you have 500 APs then you definitely need to be paying attention to all the needless noise being generated on your wireless network. In the example below I also took the opportunity to block IPv6 frames since we’re still utilizing only IPv4 on our wireless networks.

enable
config t

firewall enable

no firewall stateful-packet-inspection l2

mac access-list extended ARP-ALLOW-ACL
deny any any type ipv6 rule-precedence 10
permit any any type arp rule-precedence 20
permit any any type ip rule-precedence 30

ip access-list extended WLAN-FILTER-BCMC-ACL
permit udp any any range 67 68 rule-precedence 10
deny udp any range 137 138 any range 137 138 rule-precedence 20
deny udp any eq 17500 any eq 17500 rule-precedence 40
deny ip any host 255.255.255.255 rule-precedence 50
deny ip any 224.0.0.0/4 rule-precedence 60
permit ip any any rule-precedence 70

wlan-acl <wlan idx> WLAN-FILTER-BCMC-ACL in
wlan-acl <wlan idx> ARP-ALLOW-ACL in
wlan-acl <wlan idx> WLAN-FILTER-BCMC-ACL out
wlan-acl <wlan idx> ARP-ALLOW-ACL out

You’ll notice that the firewall needs to be enabled. And you need to verify that Layer 2 inspection is disabled.

If you are utilizing VRRP you may need to enable ARP trust on the interfaces relieving the VRRP packets, if you don’t you may see errors such as the following;

sw-wireless.store.acme.org*#Sep 12 11:27:00 2013: %DATAPLANE-4-ARPPOISON: ARP CACHE POISONING: Conflicting ethernet header and inner arp header :Ethernet Src Mac: 00-21-62-E3-XX-XX, Ethernet Dst Mac: 00-15-70-82-XX-XX, ARP Src Mac: 00-00-5E-00-01-C8, ARP Dst Mac: 00-15-70-82-XX-XX, ARP Src IP: 10.1.255.1, ARP Target IP: 10.1.255.19

sw-wireless.store.acme.org*#Sep 12 11:27:25 2013: %DATAPLANE-4-ARPPOISON: ARP CACHE POISONING: Conflicting ethernet header and inner arp header :Ethernet Src Mac: 00-21-62-E3-XX-XX, Ethernet Dst Mac: 00-15-70-82-XX-XX, ARP Src Mac: 00-00-5E-00-01-C8, ARP Dst Mac: 00-15-70-82-XX-XX, ARP Src IP: 10.1.255.1, ARP Target IP: 10.1.255.19

sw-wireless.store.acme.org*#Sep 12 11:27:48 2013: %DATAPLANE-4-ARPPOISON: ARP CACHE POISONING: Conflicting ethernet header and inner arp header :Ethernet Src Mac: 00-21-62-E3-XX-XX, Ethernet Dst Mac: 00-15-70-82-XX-XX, ARP Src Mac: 00-00-5E-00-01-C8, ARP Dst Mac: 00-15-70-82-XX-XX, ARP Src IP: 10.1.255.1, ARP Target IP: 10.1.255.19

Just enable ARP trust on the interface connected to the routers/switches running VRRP;

enable
config t

interface ge1
ip arp trust
exit

Cheers!

While running through the initial configuration I realized that you must have an Advanced License to enable PIM-SM on the Ethernet Routing Switch 5000 series. Since I don’t have any “spare” Advanced Licenses I downloaded the evaluation license from Avaya’s support website and loaded it on my test switch.

Here’s the configuration I used for the Ethernet Routing Switch 5520;

interface vlan 100
ip address 192.168.100.1 255.255.255.0 2
ip pim enable
interface vlan 200
ip address 192.168.200.1 255.255.255.0 3
ip pim enable
exit
ip pim enable
ip pim static-rp
ip pim static-rp 239.255.1.1/32 192.168.200.1

With PIM-SM configured I setup VLC on the Windows XP desktop (192.168.200.10) to Multicast the video stream to 239.255.1.1. I then setup the Windows XP laptop (192.168.100.10) to receive the Multicast stream on udp://239.255.1.1:1234. It took me a few minutes to work through some of the new menus on VLC but I eventually got it working.

I was able to confirm everything was working properly with the “show ip pim mroute” command.

5520-48T-PWR(config)#show ip pim
PIM Admin Status:  Enabled
PIM Oper Status:  Enabled
PIM Boot Strap Period:  60
PIM C-RP-Adv Message Send Interval:  60
PIM Discard Data Timeout:  60
PIM Join Prune Interval:  60
PIM Register Suppression Timer:  60
PIM Uni Route Change Timeout:  5
PIM Mode:  Sparse
PIM Static-RP:  Enabled
Forward Cache Timeout:  210

5520-48T-PWR(config)#show ip pim static-rp
Group Address   Group Mask      RP Address      Status
--------------- --------------- --------------- -------
239.255.1.1     255.255.255.255 192.168.200.1   Valid

5520-48T-PWR(config)#show ip pim mroute
 Src: 0.0.0.0       Grp: 239.255.1.1  RP: 192.168.200.1 Upstream: NULL
 Flags: WC RP
 Incoming  Port: Vlan200-null,
 Outgoing Ports: Vlan100-21
 Joined   Ports:
 Pruned   Ports:
 Leaf     Ports: Vlan100-21
 Asserted Ports:
 Prune Pending Ports:
 Assert Winner Ifs:
 Assert Loser Ifs:
TIMERS:
  Entry   JP   RS  Assert
    178    0    0       0
 VLAN-Id:   100   200
  Join-P:     0     0
  Assert:     0     0
  Src: 192.168.200.10  Grp: 239.255.1.1  RP: 192.168.200.1 Upstream: NULL
 Flags: SPT CACHE SG
 Incoming  Port: Vlan200-31,
 Outgoing Ports: Vlan100-21
 Joined   Ports:
 Pruned   Ports:
 Leaf     Ports: Vlan100-21
 Asserted Ports:
 Prune Pending Ports:
 Assert Winner Ifs:
 Assert Loser Ifs:
TIMERS:
  Entry   JP   RS  Assert
    179    0    0       0
 VLAN-Id:   100   200
  Join-P:     0     0
  Assert:     0     0

Total Num of Entries Displayed 2
Flags Legend:
        SPT = Shortest path tree
        WC = (*,Grp) entry
        RP = Rendezvous Point tree
        CACHE = Kernel Cache
        ASSERTED = Asserted
        SG = (Src,Grp) entry
        FWD_TO_RP = Forwarding to RP
        FWD_TO_DR = Forwarding to DR
        SG_NODATA = SG Due to Join
        IPMC_ERR = IPMC Add Failed

Cheers!

In large campus networks with SMLT topologies where multicast routing protocols (such as PIM) have been provisioned and scaled to large amounts of multicast senders and receivers, it has been observed that high CPU utilization
(sometimes combined with high CPU buffer utilization) leading to IST instability may occur during re-convergence of the multicast routing protocols after failures.

Additional information;

Release 5.1.3.0 has been modified with changes that were originally introduced in release 7.0.0.0. These changes allow IST protocol messages to be processed even under high CPU utilization. This is achieved by checking to see if IST control messages are queued up (but not yet processed) before deciding that the IST session has timed out and needs to be brought down. Each line card recognizes and counts IST control messages when they arrive and before they are sent to the CP, and the IST message processing logic on the CP will check for outstanding IST control messages before deciding the IST needs to be brought down due to inactivity.

Cheers!

I took a few minutes and threw together a quick diagram to help layout the topology (a picture is truly worth a thousand words). There are two core ERS 8600 switches (a switch cluster as Nortel likes to call it these days). There are three VLANs bridged across all four switches in the diagram, VLAN 55, 56 and 200. There is a fourth VLAN, 57, that is routed from ERS 8600 C. The ERS 5520 in the diagram will only be used as a Layer 2 even though it could potentially be used as a Layer 3 device (router).

I’m going to review two possible configurations. The first scenario will be for a client device (VLC Client A) in a VLAN routed by the core ERS 8600s. The second scenario will be for a client device (VLC Client B) in a VLAN routed by a closet ERS 8600.

Lets get on with configuring some ERS 8600 switches. First lets enable PIM globally;

ERS8600-A# config ip pim enable
ERS8600-A# config ip pim fast-joinprune enable

Then we’ll enable PIM on the specific VLANs;

ERS8600-A# config vlan 55 ip pim enable
ERS8600-A# config vlan 56 ip pim enable
ERS8600-A# config vlan 200 ip pim enable

We need to create a CLIP interface to use for PIM routing, we don’t want to tie the PIM routing to a physical interface in case that interface goes down for whatever reason. We’re already using CLIP 1 for our OSPF router ID of 10.1.0.5/32.

ERS8600-A# config ip circuitless-ip-int 2 create 10.1.0.15/255.255.255.255
ERS8600-A# config ip circuitless-ip-int 2 ospf enable
ERS8600-A# config ip circuitless-ip-int 2 pim enable

We need to add a candidate Rendezvous Point Router (RP) pointing it to our CLIP address.

ERS8600-A# ip pim candrp add grp 239.255.1.1 mask 255.255.255.255 rp 10.1.0.15

We need to set the priority of the Bootstrap Router (BSR) for dynamic PIM routing.

ERS8600-A# ip pim interface 10.1.0.15 cbsrpreference 100

Then on the second core ERS 8600 switch;

ERS8600-B# config ip pim enable
ERS8600-B# config ip pim fast-joinprune enable
ERS8600-B# config vlan 55 ip pim enable
ERS8600-B# config vlan 56 ip pim enable
ERS8600-B# config vlan 200 ip pim enable
ERS8600-B# config ip circuitless-ip-int 2 create 10.1.0.16/255.255.255.255
ERS8600-B# config ip circuitless-ip-int 2 ospf enable
ERS8600-B# config ip circuitless-ip-int 2 pim enable
ERS8600-B# config ip pim candrp add grp 239.255.1.1 mask 255.255.255.255 rp 10.1.0.16
ERS8600-B# config ip pim interface 10.1.0.16 cbsrpreference 50

That’s really all there is to configure with the two core ERS 8600 switches.

ERS5520 Switch (Edge)
In the case of the ERS 5520 switch there really isn’t anything you need to configure per say. You could enable IGMP (generally disabled by default) to filter the multicast traffic from ports that are not subscribing to any multicast groups. Since the ERS8600s are performing the routing the ERS5520 acts just like a Layer 2 switch.

VLC Client A (10.1.56.50) should now be able to connect to the multicast group 239.255.1.1 from the ERS 5520 which will be sourced from the VLC Server (10.1.55.50).

ERS8600 C Switch (Edge)
In the case of the ERS 8600 switch (edge) you need to configure and enable PIM. We’ll using VLAN 200 to interface with the upstream ERS8600 switches

ERS8600-C:5# config ip pim enable
ERS8600-C:5# config vlan 57 ip pim enable
ERS8600-C:5# config vlan 57 ip pim interface-type passive
ERS8600-C:5# config vlan 200 ip pim enable

Since there won’t be any other Layer 3 PIM switches on VLAN 57 we set the PIM interface to passive (much like the OSPF equivalent of passive).

VLC Client B (10.1.57.50) should now be able to connect to the multicast group 239.255.1.1 from the ERS 8600 C which will be sourced from the VLC Server (10.1.55.50).

We can dump the multicast (PIM) routing table with the following command from the edge ERS8600 switch;

ERS8600-C:5# show ip pim mroute

================================================================================
Pim Multicast Route
================================================================================
Src: 0.0.0.0 Grp: 230.0.0.2 RP: 10.1.0.5 Upstream: 10.1.200.5
Flags: WC RP CACHE
Incoming Port: Vlan200-1/1,
Outgoing Ports: Vlan127-2/42,
Joined Ports:
Pruned Ports:
Leaf Ports: Vlan127-2/42,
Asserted Ports:
Prune Pending Ports:
Assert Winner Ifs:
Assert Loser Ifs:
TIMERS:
Entry JP RS Assert
151 1 0 0
VLAN-Id: 200
Join-P: 0
Assert: 0
——————————————————————————–
Src: 10.1.233.30 Grp: 230.0.0.2 RP: 10.1.0.5 Upstream: 10.1.200.5
Flags:
SPT CACHE SG
Incoming Port: Vlan200-1/1,
Outgoing Ports: Vlan127-2/42,
Joined Ports:
Pruned Ports:
Leaf Ports: Vlan127-2/42,
Asserted Ports:
Prune Pending Ports:
Assert Winner Ifs:
Assert Loser Ifs:
TIMERS:
Entry JP RS Assert
64 4 0 0
VLAN-Id: 200
Join-P: 0
Assert: 0
——————————————————————————–

Total Num of Entries Displayed 2
Flags Legend:
SPT = Shortest path tree, WC=(*,Grp) entry, RP=Rendezvous Point tree, CACHE=Kernel Cache, ASSERTED=Asserted, SG=(Src,Grp) entry, PMBR=(*,*,RP) entry, FWD_TO_RP=Forwarding to RP, FWD_TO_DR=Forwarding to DR, SG_NODATA=SG Due to Join, CP_TO_CPU=Copy to CPU, STATIC_MROUTE=Static Mroute, MRTF_SMLT_PEER_SG=Peer SG On Non-DR For SMLT
——————————————————————————–

Troubleshooting

Here are some basic commands that should help you troubleshoot any PIM issues;

ERS8600-A:5# show ip pim neighbor

================================================================================
Pim Neighbor
================================================================================
INTERFACE ADDRESS UPTIME EXPIRE
——————————————————————————–
Vlan55 10.1.55.6 31 day(s), 00:09:53 0 day(s), 00:01:40
Vlan56 10.1.56.6 31 day(s), 00:09:53 0 day(s), 00:01:40
Vlan200 10.1.200.6 31 day(s), 00:09:53 0 day(s), 00:01:34

Total PIM Neighbors = 3

We can see that all three VLAN interfaces have PIM neighbors with the ERS 8600 B switch. Lets just check the RPs and make sure we have the correct multicast groups (addresses).

ERS8600-A:5# show ip pim rp-set

================================================================================
Pim RPSet
================================================================================
GRPADDRESS GRPMASK ADDRESS HOLDTIME EXPTIME
——————————————————————————–
230.0.0.1 255.255.255.255 10.1.0.15 150 137
230.0.0.2 255.255.255.255 10.1.0.15 150 137
239.255.1.1 255.255.255.255 10.1.0.15 150 137

The multicast addresses of 230.0.0.1 and 230.0.0.2 listed above are used for Nortel’s Contact Center (formerly Symposium Call Center software). Here’s how we can list the candidate RPs;

ERS8600-A:5# show ip pim candidate-rp

================================================================================
Pim Candidate RP Table
================================================================================
GRPADDR GRPMASK RPADDR
——————————————————————————–
230.0.0.1 255.255.255.255 10.1.0.15
230.0.0.2 255.255.255.255 10.1.0.15
239.255.1.1 255.255.255.255 10.1.0.15

If we’re dynamically choosing a RP we need to make sure that there is a BSR active;

ERS8600-A:5# show ip pim bsr

================================================================================
Current BootStrap Router Info
================================================================================

Current BSR address: 10.1.0.15
Current BSR priority: 100
Current BSR HashMask: 255.255.255.252
Current BSR Fragment Tag: 44590
Pim Bootstrap Timer : 31

I may need to update this article to make it cleaner and clearer.

Cheers!

We have a few Nortel Contact Center (formerly Symposium) installations deployed throughout the organization. The Nortel Agent Desktop Display (ADD) utilizes multicast to distribute the information between the server and the individual clients. Unless the clients are in the same VLAN as the server (Application/Web server and Database server) you’re going to need a Multicast Routing Protocol to facilitate the multicast communications between VLANs. I should point out that at this point I’m only talking about making multicast traffic available between VLANs on a single Nortel Ethernet Routing Switch 8600.

Note: Nortel Contact Center 6.0 appears to use the following two Multicast addresses by default; 230.0.0.1, 230.0.0.2

Unfortunately I didn’t have a spare Contact Center server to test with so I needed to figure out how I could test multicast traffic ahead of time and then just schedule any changes that needed to be made to facilitate inter-VLAN multicast communications. I recalled that VideoLAN – VLC media player could stream audio/video via multicast.

In order to test I setup two laptops running Windows XP Service Pack 2, laptop A (10.1.55.50/24) on VLAN 55 (10.1.55.0/24) and laptop B (10.1.56.50/24) on VLAN 56 (10.1.56.0/24).

Laptop A will be the broadcast server and stream the video while laptop B will be the client.

Let’s setup the ERS 8600 switch;

ERS-8610:6# config vlan 55 create byport 1
ERS-8610:6# config vlan 55 ip address 10.1.55.5/24
ERS-8610:6# config vlan 55 ip ospf enable
ERS-8610:6# config vlan 55 ip vrrp 1 10.1.55.1
ERS-8610:6# config vlan 55 ip dvmrp enable
ERS-8610:6# config vlan 56 create byport 1
ERS-8610:6# config vlan 56 ip address 10.1.56.5/24
ERS-8610:6# config vlan 56 ip ospf enable
ERS-8610:6# config vlan 56 ip vrrp 1 10.1.56.1
ERS-8610:6# config vlan 56 ip dvmrp enable

And then some global settings;

ERS-8610:6# config ip dvmrp enable
ERS-8610:6# config ip ospf enable

Now we need to look at how to make VLC do what we need;

Once you install VLC and start the program you will be greeted by this lightweight frontend.

Click File -> Open File to bring up the Open dialog box.

Click on the Browse button to bring up a standard Windows file selection box. Select the file you want to play. Then click Open.

Your selection should appear in the text box next to the Browse button. Click the check box for Stream Output and then click the button Settings.

If you wish to view the video on the source laptop then check the box next to Play Locally under Output Methods. When streaming to another system you don’t have to play the file on the server, but you can use this option to visually confirm that our video is playing properly before trying to access the stream from another computer.

Check the box marked UDP and type in the Muticast address you want to stream the file to. You should use a local-scope multicast address between 239.0.0.0 – 239.255.255.255. You should also make sure that the Time-To-Live (TTL) is set to 2. Then click OK. The file is ready to play so click OK in the Open dialog box too.

The video or audio file should begin playing on the computer. The last thing to do before switching to the second laptop is to turn on VLC’s web interface by clicking Settings -> Add Interface -> Web Interface. This will help provide remote control over VLC if we should need it from the second laptop.

Open VLC on the second laptop.

Click on File -> Open Network Stream. Select UDP/RTP Multicast and use the same Multicast address you use on the server. Click the OK button and VLC will start playing your stream.

Now that the stream is successfully playing on your computer you can open up a web browser to control VLC remotely. Type http://10.1.55.10:8080/ into the address bar. The web browser will present you with all of the controls you need to manage playlists and playback remotely.

If you’ve setup the ERS8600 properly your video should start playing on the client laptop.

If you want to make sure that VLC is configured and working properly move both laptops to the same VLAN. If the video stream works then you know that VLC is working properly and you need to focus the network configuration.

Note: Windows XP defaults to IGMP v3 which is fine for this test.

You can use the following commands to troubleshoot the network pieces. In the examples below I had the laptops connected to an ERS 5520 switch which was uplink on port 1/1. That is why the port is reported as 1/1 throughout the different commands.

DVMRP

ERS-8610:6# show ip dvmrp info
==================================================================                        Dvmrp General Group
==================================================================

AdminStat               : enabled
Genid                   : 0x47c42ef1
Version                 : 3
NumRoutes               : 2
NumReachableRoutes      : 2

UpdateInterval          : 60
TriggeredUpdateInterval : 5
LeafTimeOut             : 125
NbrTimeOut              : 35
NbrProbeInterval        : 10
FwdCacheTimeout         : 300
RouteExpireTimeout      : 140
RouteDiscardTimeout     : 260
RouteSwitchTimeout      : 140
ShowNextHopTable        : disable
generate-trap            : disable
generate-log             : disable
PruneResend             : disable

ERS-8610:6# show ip dvmrp interface

================================================================================                        Dvmrp Interface
================================================================================                                         DEFAULT DEFAULT DEFAULT ADVERTISEIF        ADDR            METRIC OPERSTAT LISTEN  SUPPLY  METRIC  SELF
-------------------------------------------------------------------------------
Vlan55    10.1.55.1       1      up       enable  disable 1       enable
Vlan56    10.1.56.1       1      up       enable  disable 1       enable

2 out of 2 entries displayed

--------------------------------------------------------------------------------
IF        ADDR            IN-POLICY       OUT-POLICY      INTF TYPE
--------------------------------------------------------------------------------
Vlan55    10.1.55.1                                      ActiveVlan56    10.1.56.1                                      Active

2 out of 2 entries displayed

ERS-8610:6# show ip dvmrp route

================================================================================
                       Dvmrp Route
================================================================================
SOURCE          MASK            UPSTREAM_NBR    INTERFACE  METRIC EXPIRE
--------------------------------------------------------------------------------
10.107.55.0     255.255.255.0   0.0.0.0         Vlan55     1      155
10.107.56.0     255.255.255.0   0.0.0.0         Vlan56     1      155

2 out of 2 entries displayed

IGMP

ERS-8610:6# show ip igmp cache
================================================================================
                        Igmp Cache
================================================================================
GRPADDR         INTERFACE  LASTREPORTER    EXPIRATION V1HOSTTIMER  TYPE       STATICPORTS
--------------------------------------------------------------------------------
239.255.1.1     Vlan56     10.1.56.50    213        0            DYNAMIC NULL
239.255.255.250 Vlan55     10.1.55.50    214        0            DYNAMIC NULL
239.255.255.250 Vlan56     10.1.56.50    219        0            DYNAMIC NULL

3 out of 3 entries displayed

ERS-8610:6# show ip igmp group

================================================================================
                        Igmp Group
================================================================================
GRPADDR         INPORT          MEMBER          EXPIRATION TYPE
-------------------------------------------------------------------------------
239.255.1.1     V56-1/1         10.1.56.50      209        Dynamic
239.255.255.250 V55-1/1         10.1.55.50      210        Dynamic
239.255.255.250 V56-1/1         10.1.56.50      215        Dynamic

Total number of groups 3Total number of unique groups 2

ERS-8610:6# show ip igmp sender

================================================================================
                        Igmp Sender
===============================================================================
GRPADDR         IFINDEX    MEMBER          PORT       STATE
--------------------------------------------------------------------------------
239.255.1.1     Vlan 55    10.1.55.50      1/1        NOTFILTERED

1 out of 1 entries displayed

Hopefully I haven’t gone over the top on this one.

Please post any comments, corrections or suggestions.

Cheers!