6509 Core /w Sup 720
Edge Switches - 3560's w/ IP Services image
FWSM doesn't support multicast routing in multiple context mode
3560 doesn't support GRE Tunnels
I have a multicast sources directly connected to a 6509. I've configured multicast routing and have it working successfully for edge campuses that use ASAs for their firewall. Other campuses use a FWSM in the 6509 and have no ASA. They only have a 3560 at their site. Several VLANs are trunked from the 6509 to the 3560, routing first through the FWSM. For these sites I'm unable to get multicast routing to work. TAC informed me that the FWSM doesn't support multicast routing. I figured as much after the commands from the configuration guide weren't available in any of the FWSM contexts, even the admin context. TAC then suggested using GRE Tunnels to tunnel multicast traffic through the FWSM. This isn't an option as the 3560's at the edge don't support GRE.
I tried to route around the FWSM by creating another VLAN that trunks from the 6509 to the 3560 but doesn't pass through the FWSM. This would work, but I have overlapping networks hanging off the 6509 (not by choice and not something I can change - I'm looking for options *other* than re-ip'ing these networks). After trying to get a NAT configuration that would alleviate the overlapping IP address issue I was unsuccessful. Admittedly weak in IOS NAT'ing, I think the problem lies with the fact that two different interfaces have identially IP'd networks. This doesn't cause me a problem when going through the FWSM obviously, but does cause a problem when I route around it.
Are there any alternative solutions I haven't tried yet?
I need the multicast source(s) on the 6509 to reach devices at the edge, connected via trunk links and 3560's. Presumably this must be done via multicast routing.
>> Are there any alternative solutions I haven't tried yet?
We have used a transparent FWSM context + a specific monitor session to achieve multicast traffic to go through a FWSM
the FWSM context in our case is used to make communicate a VRF and the global routing table.
I don't know if this can be used in your scenario, given some limitations of transparent contexts.
Hope to help
Giuseppe, thanks for the quick reply.
I don't know enough about transparent contexts. What features do they lack as compared to a routed mode context? Each of the campuses is their own, autonomous entity, requiring full firewall functionality. Basically we want to mimic having an ASA on site as closely as possible.
first of all, I would say that solving IP address overlapping if all sites are under a single administration pays on the long term.
So I would talk with management to find a maintanance window to solve this.
If they are managed by different administrations NAT can be a solution but it is supported only on C6500 not on C3560.
limitations of transparent contexts on FWSM an overview of transparent context is here for version 4.0
see table 5-1 for limitations note the following row:
You can, however, allow multicast traffic through the FWSM by allowing it in an extended access list.
This is the key point for multicast and FWSM.
Hope to help
in case you are interested I add here some details of our solution
Type : Service Module Session
Modules allowed : 1-9
Modules active : 8
BPDUs allowed : Yes
this is the service module SPAN session that is used module 8 is FWSM.
This can be seen with sh monitor session all but not in supervisor configuration and it is created when configuring the transparent context
in the ACL there is an object-group for PIM traffic
object-group network PIM-MULTICAST
network-object host 184.108.40.206
network-object host 220.127.116.11
vlan617 and vlan618 are used with a bridge-group between them
in the ACL PIM is permitted
access-list VLAN617 extended permit pim object-group SUBNET-TRANSITO object-group PIM-MULTICAST
there is a similar line for ACL applied to the other vlan
access-list VLAN618 extended permit pim object-group SUBNET-TRANSITO object-group PIM-MULTICAST
on the two vlans SVIs on VRF and on GRT are present in your case there can be an external device like SVI on the C3560
and there is an ACL for non-IP traffic that handles STP
access-list NOTIP ethertype permit bpdu
on each vlan two ACLs are applied one for IP one for non IP traffic
access-group NOTIP in interface vlan617
access-group VLAN617 in interface vlan617
access-group NOTIP in interface vlan618
access-group VLAN618 in interface vlan618
description Bridge Vlan 617-618
ip address 10.82.8.104 255.255.255.240 standby 10.82.8.105
the two ACLs for IP traffic have other statements
to be noted it is the monitor session that actually forward multicast streams and the FWSM analyzes only PIM messages
Hope to help
Thanks for the reply. I'm going to have to take some time to digest all of that info. I'll post back here in a few days.
I ran over your config again and checked out the link you posted.
Where is the PIM router in your configuration? If I read the link that you posted correctly, in transparent mode the FWSM cannot be the PIM router; it's unsupported. Does that mean you have another PIM device elsewhere in your network?
sorry if I have been unclear, the PIM routers are the MSFCs of the two C6500 chassis with one side one SVI in global routing table and one side in VRF.
About traffic and IP subnets, the single IP subnet is a limit for management only in my understanding.
We have EIGRP running over the transparent FWSM context and multiple IP subnets are learned by in VRF SVIs so the limitation should not affect user traffic but only management of the context.
To be more accurate the FWSM transparent context bridges between two L2 vlans with same ip subnet, but that subnet acts as a transit IP subnet and does not limit IP subnets of traffic that goes through the context.
the SVIs in global routing table learn in EIGRP routes of remote site and the these are redistributed into IS-IS.
I mean no single IP subnet limit for user traffic.
Hope to help
I was able to use Giuseppe's solution. However, I was able to set up a GRE tunnel between a 3560 and 6500. I then enabled PIM across the GRE tunnel and despite a warning message displayed on the 3560 saying that wasn't supported, PIM works as does the multicast stream. All I had to do was poke a hole in the FWSM to allow GRE through.
Thanks for the help.
check cpu usage on the C3560 because I'm afraid traffic forwarded over the GRE tunnel is processed in software only (in cat6500 sup720 it is performed in HW). If so, the solution is good until multicast and unicast traffic volume over the GRE tunnel is moderate.
the GRE tunnel is in VRF on in GRT on the C3560 side? For example we noticed that on C4500 we could define GRE tunnels in VRF but then user traffic was not able to be CEF switched over it.
Hope to help
Your knowledge surpasses mine. So I'll try to answer as closely as I can.
The CPU usage does go up on the 3560, about %15 for each multicast stream. For now, this is acceptable. In the long term, who knows.
As for VRF, I don't know.
The 6500 may not route the GRE traffic in hardware; when I configured this last tunnel, it said it wasn't supported in hardware. However, the CPU usage on the 6500 remains low, around %5.
Thanks for your help.
You are a champion.
Also, I found this bit of info that concerns me:
"The FWSM does not support traffic on secondary networks; only traffic on the same network as the management IP address is supported"
Does that mean if I have a FWSM context in transparent mode that there can only be one network behind it? I can't have a VLAN'd network on a 3560 behind the FWSM context?