Thursday, March 18, 2010

Blue Coat ProxySG VIP and Cisco Switches Need Multicast Enabled

March 30, 2008 by Greg Ferro · 2 Comments 


About VIP and SGOS

If you decide to use VIP for high avail­ab­il­ity on Blue Coat ProxySG, then you need to under­stand how it works. It is very sim­ilar to VRRP. That is, both units are con­figured to share the same IP address, and a pri­or­ity is con­figured on each unit to define which ProxySG will be the mas­ter. They use mul­tic­ast to broad­cast their status.

You want to have two Blue Coat ProxySG, so you con­nect them to two switches so that redund­ancy is improved. Like so:

bctmcast01.png

Both ProxySG will then send mul­tic­ast pack­ets to advise the other ProxySG that it is up and the pri­or­ity is con­tained in the mul­tic­ast packet, along with the IP address of the VIP and so on. If you are going to have mul­tiple VIPs in a single Layer 2 LAN seg­ment, make sure you use dif­fer­ent mul­tic­ast addresses for each VIP cluster. Note also you can have some inter­est­ing design oppor­tun­it­ies using three or four VIP per ProxySG for a active/​active/​backup design (maybe an art­icle for another day, leave a com­ment if you are interested.).

Because you are using IP Multicast (2) your switch must be able to handle IP Multicast. There are two ways for a switch to handle IP Multicast, one is broad­cast it to every port like a hub would, or to use Internet Group Multicast Protocol (IGMP). When broad­cast­ing to every port, every host on that broad­cast seg­ment has to listen to the pack­ets, receive into the IP buf­fer and read them before dis­card­ing the information.

bctmcast02.png

This causes sig­ni­fic­ant CPU cycles to be lost to unwanted traffic flows. IGMP is pro­tocol that is enabled on the switch that mon­it­ors mul­tic­ast packet for cer­tain inform­a­tion and decides whether to enable or dis­able the mul­tic­ast flows on switch ports. To join a Multicast flow the host or end­point will issue an IGMP join mes­sage for a given IP address, the switch will record this and any responses from other hosts and make sure that those ports will not be closed for that Multicast IP address. After some time, other ports that do not request to be part of the Multicast address will have the Multicast traffic for that address blocked. (3)

By default, Cisco switches have IGMP enabled (4) and they will build an IGMP snoop­ing table for all ports on the switch. Consider the fol­low­ing diagram:

bctmcast03.png
  • Step 1 — both ProxySG issue a IGMP mem­ber­ship to their switches
  • Step 2 — switches record mem­ber­ship of the mul­tic­ast group

What the Cisco switches do not do is notify their neigh­bour that they should for­ward the mul­tic­ast traffic between SW1 and SW2. Which is exactly NOT what you would expect. The IGMP pack­ets have been ter­min­ated by the switch and not for­war­ded. As a res­ult, mul­tic­ast traffic is not for­war­ded between the switches.

When using Blue Coat ProxySG you will know you have this prob­lem because both VIPs will show as master.

bctmcast04.png

Cisco switches need a Multicast router (mrouter)

The best solu­tion to this prob­lem is to setup a IOS device some­where as Multicast router. When the switch gets an IGMP report it will then relay the noti­fic­a­tion to the mrouter. The mrouter will then send IGMP mes­sages that notify all switches about their Multicast group mem­ber­ship and everything will be well.

Sample IOS configuration

inter­face Vlan1
ip address 198.18.1.10 255.255.255.0
ip pim sparse-​​dense-​​mode
end

Switch1#show ip igmp snoop­ing mrouter
vlan ports
— – + —  —  —  —  —  —  —  —  —  —  —  —  — -
1 Router

Use MPLS VRF to cre­ate a Multicast only interface

Use an MPLS VRF to cre­ate a com­pletely isol­ated IP inter­face and enable IP on that interface.

!
!enable mul­tic­ast rout­ing
!
ip multicast-​​routing
!
!this cre­ates a stan­dalone vrf
!
ip vrf proxy
rd 100:104
!
!now cre­ate an inter­face that is in the VLAN that the ProxySG are using.
!
inter­face Vlan3502
ip add 198.18.1.1 255.255.255.0
ip vrf for­ward­ing proxy
ip pim sparse-​​dense-​​mode
!

Enable IGMP Querier Feature on a Layer 2 Catalyst Switch

From the Cisco web site

“IGMP quer­ier is a rel­at­ively new fea­ture on Layer 2 switches. When a network/​VLAN does not have a router that can take on the mul­tic­ast router role and provide the mrouter dis­cov­ery on the switches, you can turn on the IGMP quer­ier fea­ture. The fea­ture allows the Layer 2 switch to proxy for a mul­tic­ast router and send out peri­odic IGMP quer­ies in that net­work. This action causes the switch to con­sider itself an mrouter port. The remain­ing switches in the net­work simply define their respect­ive mrouter ports as the inter­face on which they received this IGMP query.”

Switch2(config)#ip igmp snoop­ing querier

Switch2#show ip igmp snoop­ing quer­ier
Vlan IP Address IGMP Version Port
— —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — -
1 1.1.1.2 v2 Switch

I don’t want to use Multicast.

If you have some pas­sion­ate gripe about not enabling Multicast on a single inter­face, you can cre­ate static ARP entries for the Multicast MAC address on every switch that is in the data patch. If you have mul­tiple data paths, remem­ber to con­fig­ure that on every switch in all pos­sible data paths.(5)(6).

I would only recom­mend this in small networks.

Switch1(config)#mac-address-table static 0100.5e6f.efef vlan 1 inter­face gig­abiteth­er­net 246 gig­abiteth­er­net 248

!— Note: This com­mand should be on one line.

Switch1#show mac-​​address-​​table mul­tic­ast vlan 1

vlan mac address type learn qos ports
— – + —  —  —  —  — + —  —  – + —  – + — + —  —  —  —  —  —  —  —  —  — –
1 0100.5e18.010a static Yes  —  Gi2/46,Gi2/48

Switch2(config)#mac-address-table static 0100.5e18.010a vlan 1 inter­face
gig­abit 147

!— Note: This com­mand should be on one line.

Switch2#show mac-​​address-​​table mul­tic­ast vlan 1
Vlan Mac Address Type Ports
—- — —  — – —- —–
1 0100.5e18.010a USER Gig1/​47

Disable IGMP Snooping on All the Switches

If you dis­able IGMP snoop­ing, all switches treat mul­tic­ast traffic as a broad­cast traffic. This floods the traffic to all the ports in that VLAN, regard­less of whether the ports have inter­ested receiv­ers for that mul­tic­ast stream.

Switch1(config)#no ip igmp snooping

Switch2(config)#no ip igmp snooping

Please rate this post:

  Why Rate Posts?
1 Star - It\\\'s Crud2 Stars - It\\\'s Tosh3 Stars - Something\\\'s missing4 Stars - Needs works5 Stars - Good Enough6 Stars - Good7 Stars - Excellent8 Stars - Brilliant9 Stars - Astonishing10 Stars - Awesomely Godlike? (No Ratings Yet)
Loading ... Loading ...

Comments

2 Responses to “Blue Coat ProxySG VIP and Cisco Switches Need Multicast Enabled”
  1. Brian says:

    Hmm. Interesting usage of VRFs. If using all Cisco switches, why not just setup one L3 switch or router as a PIM-​​Sparse-​​mode RP, and listen for IGMP Membership reports from IGMP-​​enabled switches?

  2. Greg Ferro says:

    This comes back to the ‘I am scared of mul­tic­ast’ debate. For many people, enabling mul­tic­ast as global com­mand is a scary thing.

    In big com­pan­ies, the secur­ity and change con­trol teams will fall into par­oxysms of joy­ous con­dem­na­tion of how insec­ure /​ risky it is. Which, of course, is mostly cor­rect and in high secur­ity net­works using a VRF is an effect­ive way to solve this problem.

    In nor­mal net­works (which should be just about every­one, just use the code in the sec­tion “Cisco switches need a Multicast router (mrouter)” to keep it simple.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!