Section 3-4. Multicast Support

3-4. Multicast Support

To participate in forwarding and inspecting IP multicast traffic, a firewall can coexist with multicast routers running Protocol-Independent Multicast (PIM) sparse mode.

A firewall can operate as an IGMP proxy agent, also called a stub router. For all multicast-related operations, the firewall acts on behalf of the recipients. IGMP requests from recipient hosts on one firewall interface are intercepted, inspected, and relayed to multicast routers on another firewall interface.

Beginning with PIX 7.x, a firewall can also be configured to act as a PIM router so that it communicates with other PIM routers to build a complete multicast distribution tree.

After recipients join multicast groups, the firewall can intercept, inspect, and relay multicast traffic from the source on one interface to the recipients on another interface.

Multicast Overview

A network uses three basic types of IP traffic:

• Unicast Packets that are sent from one source host address to a single destination host address. Unicast packets are forwarded by finding the destination IP address in routing tables.

• Broadcast Packets that are sent from one source host address to a broadcast destination address. The destination can be all hosts (255.255.255.255), a directed broadcast to a subnet (that is, 192.168.10.255), or some portion of a subnet. A router or Layer 3 device does not forward these by default unless some method of relaying has been configured.

• Multicast Packets that are sent from one source host address to a special group-based destination address. The destination represents only the hosts that are interested in receiving the packets, and no others. A router or Layer 3 device does not forward these packets by default unless some form of multicast routing is enabled.

Two extremes are covered herea unicast, which travels from host to host, and a broadcast, which travels from one host to everyone on a segment. Multicast falls somewhere in the middle, where the intention is to send packets from one host to only the users who want to receive themnamely, those in the designated multicast group. Ideally, the recipients of multicast packets could be located anywhere, not just on the local segment.

Multicast traffic is generally unidirectional. Because many hosts receive the same data, it makes little sense to allow one of the hosts to send packets back toward the source over the multicast mechanism. Instead, a receiving host can send return traffic to the source as a unicast. Multicast traffic is also sent in a best-effort connectionless format. UDP (connectionless) is the commonly used format, whereas TCP (connection-oriented) is not.

Hosts that want to receive data from a multicast source can join or leave a multicast group dynamically. In addition, a host can decide to become a member of more than one multicast group at any time. The principal network task is then to figure out how to deliver multicast traffic to the group members without disturbing other uninterested hosts.

Multicast Addressing

Routers and switches must have a way to distinguish multicast traffic from unicasts or broadcasts. This is done through IP addressing by reserving the Class D IP address range, 224.0.0.0 through 239.255.255.255, for multicasting. Network devices can quickly pick out multicast IP addresses by looking at the 4 most-significant bits, which are always 1110.

How does a router or switch relate a multicast IP address to a MAC address? There is no ARP equivalent for multicast address mapping. Instead, a reserved Organizationally Unique Identifier (OUI) value is set aside so that multicast MAC addresses always begin with 0100.5e (plus the next-lower bit, which is 0). The lower 28 bits of the multicast IP address must also be mapped into the lower 23 bits of the MAC address by a simple algorithm.

Some of the IP multicast address space has been reserved for a particular use:

• Complete multicast space (224.0.0.0 through 239.255.255.255) The entire range of IP addresses that can be used for multicast purposes.

• Link-local addresses (224.0.0.0 through 224.0.0.255) Used by network protocols only on the local network segment. Routers do not forward these packets.

  This space includes the all-hosts address 224.0.0.1, all-routers 224.0.0.2, OSPF-routers 224.0.0.5, and so on. These are also known as fixed-group addresses because they are well-known and predefined.

• Administratively scoped addresses (239.0.0.0 through 239.255.255.255) Used in private multicast domains, much like the private IP address ranges from RFC 1918. These addresses are not routed between domains, so they can be reused.

• Globally scoped addresses (224.0.1.0 through 238.255.255.255) Used by any entity. These addresses can be routed across an organization or the Internet, so they must be unique and globally significant. (Think of this range as neither local nor private; it is the rest of the multicast range.)

Forwarding Multicast Traffic

IP multicast traffic must be forwarded from one network interface to another, just like any other Layer 3 packets are handled. The difference is in knowing where to forward the packets. For example, unicast IP packets have only one destination interface on a router or firewall (even if multiple paths exist). Multicast IP packets, however, can have many destination interfaces, depending on where the recipients are located.

Cisco firewalls running PIX 6.2 or 6.3 have a limited multicast capability. They can act only as a multicast forwarding proxy, also known as a stub multicast router (SMR), depending on other routers in the network to actually route the multicast packets. The firewalls can determine where the multicast recipients are located on their own interfaces. They must be statically configured to forward the multicast traffic between a source and the recipients.

Beginning with PIX 7.x, Cisco firewalls can participate in multicast routing by using the PIM routing protocol. This lets a firewall communicate with other PIM routers to distribute multicast traffic dynamically and along the best paths.

Multicast Trees

The routers in a network must determine a forwarding path to get multicast packets from the source (sender) to each of the recipients, regardless of where they are located. Think of the network as a tree structure. At the root of the tree is the source, blindly sending IP packets to a specific multicast address. Each router along the way sits at a branch or fork in the tree. If a router knows where all the multicast group recipients are located, it also knows which branches of the tree to replicate the multicast packets onto. Some routers have no downstream recipients, so they do not need to forward the multicast traffic. Other routers may have many downstream recipients.

This tree structure is somewhat similar to a spanning-tree topology because it has a root at one end and leaf nodes (the recipients) at the other end. The tree is also loop-free so that none of the multicast traffic gets fed back into the tree.

TIP

In multicast routing, the router nearest the multicast source is called the first-hop router. It is the first hop that multicast packets reach when they leave the source. Routers at the tree's leaf nodes, nearest the multicast receivers, are called last-hop routers. They are the last hop that multicast packets reach at the end of their journey.

Reverse Path Forwarding

Multicast routers usually have one test to perform on every multicast packet they receive. Reverse Path Forwarding (RPF) is a means to make sure packets are not being injected back into the tree at an unexpected location.

As a packet is received on a router interface, the source IP address is inspected. The idea is to verify that the packet arrived on the same interface where the source can be found. If this is true, the packet is actually proceeding out the tree's branches, away from the source. If this is not true, someone else has injected the packet on an unexpected interface, headed back down the tree's branches toward the source.

To perform the RPF test, a PIM router looks up the source address in its unicast routing table. If the next-hop interface used to reach the source address also matches the interface where the packet was received, the packet can be forwarded or replicated toward the multicast recipients. If not, the packet is quietly discarded.

IGMP: Finding Multicast Group Recipients

How does a router know of the recipients in a multicast group, much less their locations? To receive multicast traffic from a source, both the source and every recipient must first join a common multicast group, known by its multicast IP address.

A host can join a multicast group by sending a request to its local router. This is done through Internet Group Management Protocol (IGMP). IGMPv1 is defined in RFC 1112, and its successor, IGMPv2, is defined in RFC 2236. Think of IGMP as a means of maintaining group membership only on the local router.

When several hosts join a group by contacting their local routers, it is the multicast routing protocol (such as PIM) that "connects the dots" and forms the multicast tree between routers.

NOTE

Keep in mind that IGMP is always used on multicast routers and Cisco firewalls to interact with multicast hosts. In PIX 6.3 and earlier, Stub Multicast Routing offers IGMP for local group membership and IGMP forwarding so that multicast routers can use the IGMP information on a broader scale.

PIM is available only beginning with PIX 7.x. The firewall then becomes a true multicast router, running both PIM and IGMP.

IGMPv1

To join a multicast group, a host can dynamically send a Membership Report IGMP message to its local router (or firewall). This message tells the router what multicast address (group) the host is joining. The multicast address is used as the IGMP packet's destination IP address, as well as the group address requested in the message.

Every 60 seconds, one router on each network segment queries all the directly connected hosts to see if they are interested in receiving multicast traffic. This router is known as the IGMPv1 Querier. It functions simply to invite hosts to join a group.

Queries are sent to the 224.0.0.1 all-hosts multicast address for quick distribution. (By definition, every host must listen to the all-hosts address; no group membership is required.) If a host is interested in joining a group, or if it wants to continue receiving a group that it has already joined, it must respond to the router with a membership report.

Hosts can join multicast groups at any time. However, IGMPv1 does not have a mechanism to allow a host to leave a group if it is no longer interested in the group's content. Instead, routers age a multicast group out of an interface (network segment) if no membership reports are received for three consecutive query intervals. This means that, by default, multicast traffic is still sent onto a segment for up to 3 minutes after all the group members have stopped listening.

Notice that a router does not need to keep a complete host membership list for each multicast group that is active. Rather, it needs to record only which multicast groups are active on which interfaces.

IGMPv2

IGMP version 2 introduced several differences from the first version. Queries can be sent as General Queries to the all-hosts address (as in IGMPv1). They also can be sent as Group-Specific Queries, sent only to members of a specific group.

In addition, hosts are allowed to leave a group dynamically. When a host decides to leave a group it has joined, it sends a Leave Group message to the all-routers address (224.0.0.2). All routers on the local segment take note, and the Querier router decides to investigate further. It responds with a Group-Specific Query message, asking if anyone is still interested in receiving traffic for that group. Any other hosts must reply with a Membership Report. Otherwise, the Querier router safely assumes that there is no need to continue forwarding the group traffic on that segment.

NOTE

If any IGMPv1 routers are on a segment, all multicast routers on the segment must run IGMPv1. Otherwise, the IGMPv1 routers cannot understand the IGMPv2 messages.

IGMPv2 is enabled by default on Cisco router and firewall interfaces.

PIM: Building a Multicast Distribution Tree

PIM is a routing protocol that can be used to forward multicast traffic. PIM operates independently of any particular IP routing protocol. Therefore, PIM uses the IP unicast routing table and does not keep a separate multicast routing table. (The unicast routing table is itself routing protocol-independent because one or more routing protocols can be used to populate a single table.)

PIM can operate in two modes, depending on the density of the recipients in a multicast group. Cisco has developed a third hybrid mode as well. The PIM modes are as follows:

• PIM dense mode (PIM-DM) Multicast routers assume that multicast recipients are located everywhere, on every router and every router interface. After a tree is built, its branches are pruned if a multicast group has no active recipients.

• PIM sparse mode (PIM-SM) Multicast routers construct a distribution tree by adding branches only as recipients join a multicast group.

• PIM sparse-dense mode Multicast routers operate in dense or sparse mode, depending on how the multicast group is configured.

In addition, two versions of the PIM protocol can be used in a network: PIM version 1 and PIM version 2.

Cisco firewalls running PIX 7.x or later can operate only in PIM sparse mode, although they can coexist with other routers running PIM-SM or PIM sparse-dense mode.

PIM Sparse Mode

PIM sparse mode takes a "bottom-up" approach to constructing a multicast distribution tree. The tree is built by beginning with the recipients or group members at the end leaf nodes and extending back toward a central root point.

Sparse mode also works on the idea of a shared tree structure, where the root is not necessarily the multicast source. Instead, the root is a PIM-SM router that is centrally located in the network. This root router is called the rendezvous point (RP).

The tree from the RP to the group members is actually a subset of the tree that could be drawn from the source to the group members. If a multicast source anywhere in the network can register for group membership with the RP, the tree can be completed end-to-end. Because of this, the sparse mode tree is called a shared tree.

NOTE

Sparse mode multicast flows are designated by a (source,destination) pair. The letters S and G represent a specific source and group, respectively. An asterisk (*) can also be used to represent any source or destination. For example, multicast flows over the shared tree are described as (*,G) because the shared tree allows any source to send to a group G.

In PIM-SM, the shared tree is built using the following basic sequence of steps:

1.	A recipient host joins a multicast group by sending an IGMP Membership Report to the local router.
2.	The router adds an (*,G) entry in its own multicast routing table, where G represents the group IP address. The router also maintains a list of outbound interfaces where group recipients are located.
3.	The router sends a PIM Join request for (*,G) toward the RP at the tree's root.
4.	The neighboring PIM router receives the Join request, adds a (*,G) entry in its own table, and adds the arriving interface to its list of outbound interfaces for the group. The neighboring PIM router then relays the Join request toward the RP.
5.	When the RP finally receives the PIM Join request, it too adds a (*,G) entry and the arriving interface to its own table. The shared tree has now been built from a recipient host to the RP.

For example, consider the network shown in Figure 3-15. A firewall separates a public and private network and also acts as the RP for PIM multicast routing. Three receivers (end-user hosts) in the network join a single multicast group in preparation to receive traffic from a multicast source.

Figure 3-15. A Sample Network with PIM Multicast Routers

Figure 3-16 illustrates the group membership process. On the left side of the figure, the multicast receivers X, Y, and Z each send an IGMP membership request to join group address 239.0.0.1. Router B receives the request from Receiver X and also creates a multicast route entry (*,239.0.0.1) that points back toward the receiver. Router B also sends a PIM Join message for (*,239.0.0.1) toward the RP, which adds the link between it and the firewall to the multicast tree.

Figure 3-16. Building a Shared Multicast Tree with PIM

Router C takes similar steps for the IGMP request it receives from Receiver Y. Receiver Z is a slightly different case; the firewall receives its IGMP request directly because it is directly connected. The firewall adds a (*,239.0.0.1) multicast route entry to its table, pointing back toward the receiver on the inside interface.

Notice how all the IGMP membership reports terminate at the closest router (or firewall) while PIM Join messages travel from router to router. After the RP receives all the Join messages, the multicast tree is complete, as shown in the right portion of Figure 3-16. The network topology has been redrawn slightly to show how the RP (firewall) is at the root of the tree. This is called a PIM shared tree because it is used by all the devices participating in the multicast group. Routers that have no active multicast group receivers (Router A, for example) don't send a PIM Join message, so they don't become part of the tree.

A shared tree always begins with the RP at the root and progresses downward toward the leaf nodes, where the receivers are located. Only the PIM routers are shown, because they actually build and use the tree. PIM shared trees are always unidirectional. Multicast packets can only start at the RP and be sent toward the receivers.

Finally, a multicast source must also join the group so that traffic can flow toward the receivers. The left portion of Figure 3-17 illustrates this process, where the source is connected to Router C.

Figure 3-17. Adding a Multicast Source to PIM Trees

When a source joins a multicast group, the following steps take place:

1.	A source S begins sending traffic to the multicast group address (239.0.0.1 in the example). Up to this point, the multicast tree hasn't been extended to the source. In fact, notice that the source is sending traffic upstream toward the RP! In the unidirectional shared tree, this isn't allowed. This point is dealt with in the next few steps.
2.	The nearest PIM router receives the traffic destined for the multicast group and realizes that it is coming from a source. The router must register the source with the RP so that it can become a part of the tree. The multicast packets are encapsulated in PIM Register messages that are sent to the RP as unicasts.
3.	The RP unencapsulates the Register messages and sends the original multicast packets down the tree toward the receivers. The RP also sends an (S,G) PIM Join message downstream toward the source address so that a tree can be built from the source to the RP. In the example, this is a (S,239.0.0.1) multicast flow. The idea is to construct a path to carry multicast data from the source to the tree's root (the RP) so that it can flow downward toward the receivers. NOTE The tree built from the source to the RP is not a part of the PIM shared tree. Instead, it is called a shortest path tree (SPT) because it follows a path from a router (the RP in this case) directly to the source. Because the SPT is separate from the shared tree, multicast packets can travel upward toward the RP without interfering with packets traveling downward from the RP toward the receivers. In effect, these are two unidirectional trees with the RP always serving as the root.
4.	After the SPT has been built from the source to the RP, there is no need to keep encapsulating the source data as Register messages. The RP sends a PIM Register Stop message toward the source. When the leaf node router at the source receives this, it stops sending the Register messages and begins using the new SPT path.

The right portion of Figure 3-17 illustrates the resulting tree structures. The solid arrows show the PIM shared tree, from the RP down to the routers where receivers are located. The broken-line arrows represent the SPT that is built from the source up to the RP.

Although it is not shown in this example, last-hop PIM routers are allowed to perform an SPT switchover to attempt to build a more direct path to the multicast source. This process is very similar to the steps described previously, where specific (S,G) flows are added to the PIM routers along the path. After an SPT switchover occurs, the RP is no longer required to be at the root of the tree if a better path can be found.

To simplify the tree structure and improve efficiency, PIM can also support a bidirectional mode. If every PIM router supporting a multicast group is configured for bidirectional mode, a single multicast tree is formed to connect the multicast source to all its receivers.

Multicast packets can flow up or down the tree as necessary to disperse in the network. The PIM routers take on designated forwarder (DF) roles, deciding whether to forward multicast packets onto a network segment in the appropriate direction. Because a single bidirectional tree is used, the multicast source can join the group without the PIM source registration process.

PIM RP Designation

In PIM sparse mode, every PIM router must know the RP's identity (IP address). After all, each router has to send PIM Join/Prune messages toward the RP by using its unicast routing table to find the correct interface.

The simplest method of identifying the RP is to manually configure its address in each PIM router. If there aren't many PIM routers to configure, this method is very straightforward. However, if there are many PIM routers or if the RP address is likely to change in the future, manual configuration can be cumbersome.

NOTE

Beginning with PIX 7.x, static RP configuration is the only option available. Other more dynamic RP discovery methods are described in this section because they might be used on PIM routers in your network.

Cisco also provides a proprietary means to automatically inform PIM-SM routers of the appropriate RP for a group. This is known as Auto-RP. Routers that can potentially become an RP are configured as candidate RPs. These routers advertise their capability over the Cisco-RP-Announce multicast address 224.0.1.39.

These announcements are picked up by one or more centrally located and well-connected routers that have been configured to function as mapping agents. A mapping agent collects and sends RP-to-group mapping information to all PIM routers over the Cisco-RP-Discovery multicast address 224.0.1.40.

A mapping agent can limit the scope of its RP discovery information by setting the time-to-live (TTL) value in its messages. This limits how many router hops away the information will still be valid. Any PIM router within this space dynamically learns of the candidate RPs that are available to use.

The second version of PIM also includes a dynamic RP-to-group mapping advertisement mechanism. This is known as the bootstrap router method and is standards-based.

PIMv2 is similar to the Cisco Auto-RP method. First, a bootstrap router (BSR) is identified; this router learns about RP candidates for a group and advertises them to PIM routers. Only the BSR and candidate RPs have to be configured; all other PIM routers learn of the appropriate RP dynamically from the BSR.

These bootstrap messages permeate the entire PIM domain. The scope of the advertisements can be limited by defining PIMv2 border routers, which does not forward the bootstrap messages further.

NOTE

If Auto-RP is being used in your network, be aware that a firewall running PIX 7.x can't participate in the Auto-RP process. The firewall must have the PIM RP address statically configured.

However, the candidate RP announcements over 224.0.1.39 and the Router Discovery messages over 224.0.1.40 can pass through the firewall to reach PIM routers on the other side. Therefore, the Auto-RP mechanism can still work across the firewall, but the firewall can't directly benefit from the dynamic RP discovery itself.

Configuring PIM

Use the following steps to configure PIM multicast routing on a firewall running PIX 7.x or later. Keep in mind that you have to configure explicit access list rules to permit multicast host access through a firewall. All multicast traffic is subject to normal firewall inspection, with the exception of IGMP, PIM, OSPF, and RIPv2. You do not have to configure address translation for the multicast group addresses, however. The firewall automatically creates an internal identity NAT for addresses such as 239.0.0.1, 239.255.148.199, and so on.

1.

Enable multicast routing:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config)# multicast-routing

Enabling multicast routing brings up PIM and IGMP on every firewall interface.

TIP

You can verify the current PIM status on each interface by using the following command:

 Firewall# show pim interface {state-on | state-off} 

For example, a firewall with PIM enabled on its inside and outside interfaces produces the following output:

 Firewall# show pim interface state-on Address          Interface          PIM  Nbr   Hello  DR     DR                                          Count Intvl  Prior 192.168.198.1    inside             on   1     30     1      192.168.198.4 192.168.93.135   outside            on   1     30     1      this system Firewall# show pim interface state-off Address          Interface          PIM  Nbr   Hello  DR     DR                                          Count Intvl  Prior 192.168.77.1     dmz                off  0     30     1      not elected Firewall# 

2.

Identify the RP:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config)# pim rp-address ip_address [acl_name] [bidir]

The RP is located at ip_address. By default, it is used for all 224.0.0.0/4 multicast group addresses. You can use the RP for specific multicast addresses by configuring a standard access list named acl_name and applying it in this command.

For example, the following commands can be used to define an RP for group addresses 239.0.0.0 through 239.0.0.15:

 Firewall(config)# access-list MyGroups standard permit 239.0.0.0  255.255.255.240 Firewall(config)# pim rp-address 192.168.100.1 MyGroups 

TIP

Because the firewall can't participate in any dynamic RP discovery methods (Auto-RP or BSR), the RP address must be statically configured. If the firewall will act as the RP itself, use one of the firewall's own interface addresses as the RP address in this command. Then, for other routers, configure a static RP address using the address of the nearest firewall interface. Even though the firewall is configured with only one of its own interfaces as the RP address, it automatically supports the RP function for neighboring PIM routers on all other interfaces.

By default, the firewall operates in normal PIM sparse mode for the multicast groups and RP. You can add the bidir keyword if the RP and its associated PIM routers are operating in bidirectional mode. This allows multicast traffic to move toward and away from the RP in the sparse mode tree.

NOTE

If you configure bidirectional mode on one PIM router (or firewall) in your network, you must configure it on all of them. Otherwise, the bidirectional PIM routers introduce traffic.

3.

(Optional) Adjust PIM parameters on a firewall interface.

a. Specify an interface:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config)# interface if_name

The interface named if_name is selected.

b. (Optional) Disable multicast support on an interface:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-if)# no pim

If PIM is disabled on an interface and you need to re-enable it, you can use the pim interface configuration command.

c. (Optional) Set the PIM hello period:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-if)# pim hello-interval seconds

A firewall periodically sends PIM hello messages on each interface where PIM is enabled. By default, hellos are sent every 30 seconds. You can set the interval to seconds (1 to 3600).

NOTE

The PIM hello interval doesn't have to be configured identically on neighboring routers. This is because each router advertises its own holdtime, or the amount of time a neighbor should wait to receive a hello message before expiring the neighbor relationship. This is usually set to 3 times the hello interval, or a default value of 90 seconds.

The hello interval affects how quickly a PIM neighbor can be discovered and how quickly it is declared unreachable if it becomes unresponsive.

d. (Optional) Set the designated router (DR) priority:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-if)# pim dr-priority priority

PIM advertises an interface priority so that connected PIM routers can elect a designated router. By default, a DR priority of 1 is used. You can set this to priority (0 to 4294967295). A higher priority is more likely to win the election; in the case of a tie, the router interface with the highest IP address wins.

e. (Optional) Adjust the Join/Prune message interval:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-if)# pim join-prune-interval seconds

Multicast routers must send periodic PIM Join/Prune messages to their upstream neighbors to maintain their position in the multicast tree. The idea is to maintain the forwarding state to a multicast router (or firewall) only if it still has active participants connected; otherwise, the state might be stale and should be flushed.

By default, Join/Prune messages are sent every 60 seconds. You can set this interval to seconds (10 to 600) if needed.

TIP

If you decide to change the time interval, be aware that it should be configured identically on all multicast routers participating in PIM. If three Join/Prune messages are missed (180 seconds with the default 60-second interval), the forwarding state is removed. Therefore, all routers should agree on the basic Join/Prune time interval.

4.

(Optional) Filter PIM register messages.

PIM Register messages are sent by first-hop DRs to the RP to inform it that a multicast source exists. The original multicast packets sent by the source are encapsulated and sent as unicast Register messages.

You can filter the PIM register messages so that you have better control over where legitimate multicast sources or servers can be located and permitted to operate.

a. Define a filter:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config)# access-list acl_name extended {permit | deny} ip src_ip src_mask dest_ip dest_mask or [View full width] Firewall(config)# route-map map_name permit [sequence] Firewall(config-route-map)# match {interface if_name | ip address acl_name}

You can filter Register messages based on any combination of the source address (first-hop DR address) and destination address (RP). Keep in mind that PIM Register messages are unicast to the RP and are not sent to the multicast group address.

You can define the filter using an extended access list or route map. Only Register messages that are permitted by the ACL or route map are allowed to reach their destination at the RP.

b. Apply the filter to PIM:

FWSM 2.x
PIX 6.x
PIX 7.x	[View full width] Firewall(config)# pim accept-register {list acl_name | route-map map_name}

For example, you could use the following commands to allow the first-hop router 192.168.10.10 to register a directly connected multicast source with the RP located at 192.168.1.10:

 Firewall(config)# access-list RegFilter extended permit ip host   192.168.10.10 host 192.168.1.10 Firewall(config)# pim accept-register list RegFilter 

5.

(Optional) Prevent SPT switchover:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config)# pim spt-threshold infinity [group-list acl_name]

Multicast routers normally form a shared tree structure with the RP as the root. Multicast traffic must travel from the source through the RP and then on to the receivers.

By default, last-hop or leaf node routers with directly connected multicast receivers can (and do) join an SPT by sending a Join message directly to the multicast source. In effect, the resulting SPT has the fewest router hops from source to receiver and might not include the RP.

This can be useful if the RP is not located strategically or if the RP introduces latency with the multicast traffic passing through it. However, you might not want the tree structure to be altered for one or more multicast groups in your network. When the firewall is acting as a last-hop PIM router, you can prevent it from switching over to an SPT by using this command.

If you use the infinity keyword with no other arguments, the firewall must stay with the shared tree for all its groups. Otherwise, you can configure a standard access list that permits the specific multicast group addresses that should be kept on the shared tree. Apply the access list with the group-list acl_name keywords. The firewall is allowed to switch over to an SPT for all other groups.

6.

(Optional) Define a static multicast route to a source.

In normal operation, a firewall running PIM dynamically builds a table of multicast "routes" based on the PIM and IGMP membership requests it receives. Multicast routes (mroutes) represent how multicast traffic is forwarded to group addressesfrom a source address to a destination interface.

You can define static mroute entries to override or supplement the dynamic entries with the following command:

FWSM 2.x
PIX 6.x	Firewall(config)# mroute src smask in_if_name dst dmask out_if_name
PIX 7.x	Firewall(config)# mroute src mask in_if_name out_if_name [distance]

A static multicast route correlates a multicast source address with its Class D multicast group address. The firewall can then inspect and forward traffic from the source on one interface to recipients (and multicast routers) on another interface.

The multicast source is identified by its IP address src, subnet mask smask (usually 255.255.255.255), and the firewall interface named in_if_name where it connects. The multicast destination is the actual Class D group IP address dst, subnet mask dmask, and the firewall interface named out_if_name where recipients are located.

Beginning with PIX 7.x, only the out_if_name is given. Notice that this form of the command resembles a reverse path rather than a traditional unicast static route. In other words, the mroute is defined by its source and not by a destination. Its only function is to define how a multicast source can be reached, independent of the normal unicast routing information.

With PIX 7.x, you can also specify an administrative distance (0 to 255; the default is 0) to influence how the firewall performs its RPF check. Normally, RPF involves checking the unicast routing table on the firewall, but a static mroute configuration overrides that. You can prefer other sources of routing information by adjusting the mroute distance, where a lower distance is more trusted or preferable.

Table 3-3 lists the default administrative distance assigned to routes on a firewall.

Table 3-3. Default Administrative Distances by Route Type

Source	Distance
mroute static route default	0
Directly connected interface	0
Static route entry	1
OSPF	110
RIP	120

For example, if the unicast routes learned through static route commands or directly connected interface addresses should be trusted more than the mroute entry for RPF, you could use the following command:

 Firewall(config)# mroute 10.1.1.10 255.255.255.255 inside 10 

Here, the multicast source is located on the inside interface at 10.1.1.10, and all multicast receivers are located on the outside interface. The administrative distance of 10 still makes this entry more preferable for RPF than unicast routes learned through RIP or OSPF.

Configuring Stub Multicast Routing (SMR)

A firewall can be configured to participate as a stub multicast router. In this case, it acts as a proxy between fully functional PIM routers and multicast participants. Only IGMP messages are relayed between firewall interfaces; PIM routing is not used. In fact, as soon as SMR is configured, any existing pim rp-address commands for multicast routing are automatically removed from the configuration.

This is the only multicast function available in PIX release 6.3. It is optional in PIX release 7.x if PIM is undesirable. The steps for configuring SMR are as follows:

1.

Define the proxy agent (stub router).

a. Enable multicast support toward multicast routers:

FWSM 2.x
PIX 6.x	Firewall(config)# multicast interface if_name
PIX 7.x

The IGMP proxy agent becomes active on the firewall interface named if_name, where the multicast routers can be found. If a multicast source is on the outside, the outside interface should be used here. (This command is not necessary for IGMP proxy on a PIX 7.x platform.)

b. (Optional) Add static multicast routes if the multicast source is on the inside:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# mroute src smask in_if_name dst dmask out_if_name
PIX 7.x	Firewall(config)# mroute src mask in_if_name dense out_if_name [distance]

Use this command when a multicast source is on an internal firewall interface sending traffic to recipients on the outside. Because the firewall isolates any multicast routing between the recipients and the internal source, static routes must be configured.

A static multicast route correlates a multicast source with its Class D multicast group address. The firewall can then inspect and forward traffic from the source on one interface to recipients (and multicast routers) on another interface.

The multicast source is identified by its IP address src, subnet mask smask (usually 255.255.255.255), and the firewall interface named in_if_name where it connects. The multicast destination is the actual Class D group IP address dst, subnet mask dmask, and the firewall interface named out_if_name where recipients are located.

Beginning with PIX 7.x, you must provide the out_if_name along with the dense keyword. Notice that this form of the command resembles a reverse path rather than a traditional unicast static route. In other words, the mroute is defined by its source and not by a destination. In fact, the multicast destination address isn't specified.

With PIX 7.x, you can also specify an administrative distance (0 to 255; the default is 0) to influence how the firewall performs its RPF check. Normally, RPF involves checking the unicast routing table on the firewall, but a static mroute configuration overrides that. You can prefer other sources of routing information by adjusting the mroute distance, where a lower distance is more trusted or preferable.

Table 3-4 lists the default administrative distance assigned to routes on a firewall.

Table 3-4. Administrative Distance by Route Type

Source	Distance
mroute static route default	0
Directly connected interface	0
Static route entry	1
OSPF	110
RIP	120

For example, if the unicast routes learned through static route commands or directly connected interface addresses should be trusted more than the mroute entry for RPF, the following command could be used:

 Firewall(config)# mroute 10.1.1.10 255.255.255.255 inside dense outside 10 

Here, the multicast source is located on the inside interface at 10.1.1.10, and all multicast receivers are located on the outside interface. The administrative distance of 10 still makes this entry more preferable for RPF than unicast routes learned through RIP or OSPF.

2.

(Optional) Configure multicast support for the recipients.

a. Enable multicast support on an interface where recipients are located:

FWSM 2.x
PIX 6.x	Firewall(config)# multicast interface interface_name
PIX 7.x

The IGMP proxy agent becomes active on the firewall interface named interface_name. This is usually the "inside" interface, closest to the multicast recipients. You can also use this command to configure multicast support on other firewall interfaces. (This command is not necessary for IGMP proxy on a PIX 7.x platform.)

b. Enable the IGMP forwarding proxy:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# igmp forward interface if_name
PIX 7.x	Firewall(config)# interface in_if_name Firewall(config-if)# igmp forward interface if_name

The proxy agent listens for IGMP join and leave requests on the multicast interface and relays them to multicast routers on the interface named if_name. This is usually the outside interface, although you can repeat the command if recipients are located on other interfaces, too.

In PIX 7.x, this command is used in interface configuration mode on the interface (in_if_name, such as GigabitEthernet1) that will forward IGMP traffic to recipients on interface if_name (inside, for example). For instance, to forward IGMP from the inside interface (GigabitEthernet1) to recipients located on the outside interface (GigabitEthernet0), you would use the following commands:

 Firewall(config)# interface GigabitEthernet1 Firewall(config-if)# description Inside Firewall(config-if)# igmp forward interface outside 

Configuring IGMP Operation

IGMP is used on firewall interfaces to handle multicast group membership for directly connected hosts. You can use the following configuration steps to tune or change the IGMP operation:

1.

Select an interface to tune:

FWSM 2.x
PIX 6.x	Firewall(config)# multicast interface if_name
PIX 7.x	Firewall(config)# interface if_name

All subsequent IGMP configuration commands are applied to the interface you specify.

2.

(Optional) Disable IGMP on the interface:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-if)# no igmp

Beginning with PIX 7.x, IGMP is enabled on all firewall interfaces as soon as the multicast-routing command is used. You can use the no igmp command if you need to disable IGMP on the interface because no multicast hosts are present or allowed.

3.

(Optional) Set the IGMP version:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# igmp version {1 | 2}
PIX 7.x	Firewall(config-if)# igmp version {1 | 2}

By default, a firewall communicates with hosts using IGMP version 2. You can change this to version 1 if needed. The IGMP version should match the capabilities of the recipient hosts.

4.

(Optional) Tune IGMP query operation.

a. (Optional) Set the IGMP query interval:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# igmp query-interval seconds
PIX 7.x	Firewall(config-if)# igmp query-interval seconds

This specifies how often, in seconds, the firewall sends IGMP query messages to the hosts to determine group memberships. The seconds value can be 1 to 3600; the PIX 6.3 default is 60 seconds, and the PIX 7.x default is 125 seconds.

b. (Optional) Set the maximum query response time:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# igmp query-max-response-time seconds
PIX 7.x	Firewall(config-if)# igmp query-max-response-time seconds

This command is used to determine how long the router waits for a response from a host about group membership. The default is 10 seconds. If a host doesn't respond quickly enough, you can lengthen this time value to seconds (1 to 25).

c. (Optional) Set the querier response timer:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-if)# igmp query-timeout seconds

By default, the firewall waits 255 seconds to hear from the current IGMP querier before it takes over that role. You can adjust the query timeout to seconds (60 to 300).

5.

(Optional) Set limits on multicast group membership.

a. (Optional) Limit the number of hosts per multicast group:

FWSM 2.x
PIX 6.x
PIX 7.x	Firewall(config-if)# igmp limit number

By default, a firewall maintains the forwarding state of up to 500 multicast recipients per interface. You can limit this further to number (1 to 500) hosts.

b. (Optional) Limit the number of multicast groups supported:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# igmp max-groups number
PIX 7.x	Firewall(config-if)# igmp max-groups number

By default, up to 500 multicast groups can be supported on a firewall interface. You can change this limit to number (0 to 2000) groups if needed.

c. (Optional) Control the groups that hosts can join:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# igmp access-group acl_name
PIX 7.x	Firewall(config-if)# igmp access-group acl_name

When client hosts or multicast recipients attempt to join a multicast group, the firewall can filter the requests. If you place restrictions on groups, recipients can join only the group addresses that are permitted by the access list named acl_name.

TIP

You need to configure an access list before using this command. The access list should be of the following form:

FWSM 2.x
PIX 6.x	[View full width] Firewall(config)# access-list acl_name {permit | deny} ip any group_address group_mask
PIX 7.x	[View full width] Firewall(config)# access-list acl_name standard {permit | deny} group_address group_mask or [View full width] Firewall(config)# access-list acl_name extended {permit | deny} ip any group_address group_mask

Multicast groups are identified by their Class D multicast addresses, which can be given as a network address and subnet mask. With PIX 7.x, you can use either a standard or extended access list. In either case, the group_address and group_mask represent the multicast group.

For example, suppose multicast users on the inside interface should be allowed to join only group addresses 239.0.0.0 through 239.0.0.255. You would use the following commands:

PIX 6.x	[View full width] Firewall(config)# access-list AllowedGroups permit ip any 239.0.0.0 255.255.255.0 Firewall(config)# multicast interface inside Firewall(config-multicast)# igmp access-group AllowedGroups
PIX 7.x	[View full width] Firewall(config)# access-list AllowedGroups standard permit ip 239.0.0.0 255.255.255.0 Firewall(config)# interface GigabitEthernet1 Firewall(config)# description Inside Firewall(config-if)# igmp access-group AllowedGroups

6.

(Optional) Configure the firewall to become a member of a multicast group:

FWSM 2.x
PIX 6.x	Firewall(config-multicast)# igmp join-group group-address
PIX 7.x	Firewall(config-if)# igmp join-group group-address or Firewall(config-if)# igmp static-group group-address

The igmp join-group command allows you to specify a multicast group-address (a Class D multicast address) for the firewall interface to join. By joining a group, the firewall interface begins to accept packets sent to the multicast address. Therefore, it becomes a pingable member of the multicast groupsomething that can be a valuable testing tool.

As soon as the interface joins the group, the firewall also becomes a surrogate client so that multicast traffic can be forwarded to recipients that don't support IGMP. The interface group membership keeps the multicast path alive so that those hosts can continue to receive the traffic from the multicast source.

Beginning with PIX 7.x, you can use the igmp static-group command to cause the firewall interface to join a group without actually accepting the multicast traffic itself. Instead, packets sent to the multicast group-address are forwarded to any recipients on the interface.

Stub Multicast Routing Example

A firewall separates a multicast source from its recipients. The source is located on the outside interface, and the recipients are on internal networks found on the inside interface. Recipients can join multicast groups only in the 224.3.1.0/24 and 225.1.1.0/24 ranges. The PIX 6.3 configuration commands needed are as follows:

 Firewall(config)# access-list mcastallowed permit ip any 224.3.1.0 255.255.255.0 Firewall(config)# access-list mcastallowed permit ip any 225.1.1.0 255.255.255.0 Firewall(config)# multicast interface outside Firewall(config-multicast)# exit Firewall(config)# multicast interface inside Firewall(config-multicast)# igmp forward interface outside Firewall(config-multicast)# igmp access-group mcastallowed 

Now, consider the same example, where the source and recipients trade places. If the multicast source (192.168.10.1) is located on the inside of the firewall, with recipients on the outside, the configuration could look like the following:

 Firewall(config)# access-list mcastallowed permit ip any 224.3.1.0 255.255.255.0 Firewall(config)# access-list mcastallowed permit ip any 225.1.1.0 255.255.255.0 Firewall(config)# multicast interface inside Firewall(config-multicast)# igmp forward interface outside Firewall(config-multicast)# mroute 192.168.10.1 255.255.255.255 inside 224.3.1.0   255.255.255.0 outside Firewall(config-multicast)# mroute 192.168.10.1 255.255.255.255 inside 225.1.1.0   255.255.255.0 outside Firewall(config)# multicast interface outside Firewall(config-multicast)# igmp access-group mcastallowed 

PIM Multicast Routing Example

A Cisco firewall running release PIX 7.x is to be configured for PIM multicast routing between its inside and outside interfaces. The firewall acts as the RP for any multicast group address beginning with 239.

You could use the following PIX 7.x configuration commands:

 Firewall(config)# multicast-routing Firewall(config)# interface GigabitEthernet1 Firewall(config-if)# nameif inside Firewall(config-if)# security-level 100 Firewall(config-if)# ip address 192.168.198.1 255.255.255.0 Firewall(config-if)# exit Firewall(config)# access-list PIMgroups standard permit 239.0.0.0 255.0.0.0 Firewall(config)# pim rp-address 192.168.198.1 PIMgroups 

Verifying IGMP Multicast Operation

You can display the current multicast configuration on a firewall running PIX 6.3 with the show multicast command, as shown in the following example:

 Firewall# show multicast multicast interface outside   igmp access-group mcastallowed multicast interface inside   igmp forward interface outside   igmp access-group mcastallowed Firewall# 

As soon as multicast is configured and IGMP becomes active on some firewall interfaces, you can display IGMP activity with this EXEC command:

PIX 6.x	Firewall# show igmp [group] [detail]
PIX 7.x	Firewall# show igmp groups [group_address | if_name] [detail]

If you do not use any arguments, the output displays all firewall interfaces configured for multicast. Otherwise, you can specify a multicast group or an interface.

In addition, the output displays any currently active multicast groups. For example, the following multicast group addresses are shown to be active with receivers on the inside and outside interfaces of a PIX 7.x firewall:

 Firewall# show igmp groups IGMP Connected Group Membership Group Address    Interface            Uptime    Expires   Last Reporter 239.0.0.1        inside               1d01h     00:04:16  192.168.198.4 239.255.148.199  inside               1d01h     00:04:14  192.168.198.198 239.255.199.197  inside               1d01h     00:04:15  192.168.198.198 239.255.255.250  inside               1d01h     00:04:16  192.168.198.198 224.0.1.40       outside              1d01h     00:04:01  128.163.93.129 239.0.0.1        outside              1d01h     00:04:00  128.163.93.129 Firewall# 

You can display the current IGMP settings on a specific firewall interface with this command:

PIX 6.x	Firewall# show igmp interface interface_name [detail]
PIX 7.x	Firewall# show igmp interface if_name

The following example provides some sample output from this command:

 Firewall# show igmp interface inside inside is up, line protocol is up   Internet address is 192.168.198.1/24   IGMP is enabled on interface   Current IGMP version is 2   IGMP query interval is 125 seconds   IGMP querier timeout is 255 seconds   IGMP max query response time is 10 seconds   Last member query response interval is 1 seconds   Inbound IGMP access group is:   IGMP limit is 500, currently active joins: 4   Cumulative IGMP activity: 4 joins, 0 leaves   IGMP querying router is 192.168.198.1 (this system) Firewall# 

Verifying PIM Multicast Routing Operation

After you enable multicast routing on a firewall running PIX 7.x or later, you should verify that it is seeing hello messages from its PIM router neighbors. You can do this with the following command:

PIX 6.x
PIX 7.x	Firewall# show pim neighbor [count | detail] [if_name]

For example, the following output shows that a firewall is communicating with two PIM neighbors located on two different interfaces:

 Firewall# show pim neighbor Neighbor Address  Interface          Uptime    Expires DR pri Bidir 192.168.198.4     inside             1d02h     00:01:19 1 (DR) 10.1.93.1         outside            01:54:40  00:01:19 N/A Firewall# 

The Uptime column shows how long the firewall has been successfully receiving PIM hello messages from the peer router. The firewall must receive the next hello before the time shown in the Expires column reaches 0.

TIP

You can also verify that the firewall is sending its own PIM hellos by checking its neighbor status from a directly connected PIM router. For example, the router located on the firewall's outside interface shows the following information about the firewall as a PIM router:

 Router# show ip pim neighbor PIM Neighbor Table Neighbor Address  Interface          Uptime    Expires   Ver  Mode 10.1.93.2    Vlan4                   01:59:15  00:01:34  v2    (DR) Router# 

You can display the current multicast routing table with the following command:

PIX 6.x
PIX 7.x	Firewall# show mroute [{group_address | active | count | pruned | reserved | summary}]

Finally, a firewall maintains information about the PIM routing topology. This includes entries for each multicast flow that the firewall has received a PIM Join/Prune message about, as well as the flow uptime, RP for the group, firewall interfaces actively forwarding traffic for the flow, and various flags about the flow state.

As a quick summary of multicast flows in the topology table, you can use the following command:

 Firewall# show pim topology route-count PIM Topology Table Summary   No. of group ranges = 6   No. of (*,G) routes = 6   No. of (S,G) routes = 2   No. of (S,G)RPT routes = 2 Firewall# 

The actual PIM topology information is displayed with the show pim topology command, as shown in the following example. Here, the firewall is the RP (192.168.198.1) for several of the multicast groups. A Cisco IP/TV multicast source is located at 192.168.198.198, using multicast group 239.255.199.197 for streaming video and 239.255.148.199 for streaming audio.

 Firewall# show pim topology IP PIM Multicast Topology Table Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive,     RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources,     RR - Register Received, SR (*,224.0.1.40) DM Up: 1d13h RP: 0.0.0.0 JP: Null(never) RPF: ,0.0.0.0 Flags: LH DSS   outside            1d13h     off LI LH (*,239.0.0.1) SM Up: 1d13h RP: 192.168.198.1* JP: Join(never) RPF: Tunnel1,192.168.198.1* Flags: LH   inside             1d13h     fwd Join(00:02:45) LI   outside            1d13h     fwd LI LH (*,239.255.148.199) SM Up: 1d13h RP: 192.168.198.1* JP: Join(never) RPF: Tunnel1,192.168.198.1* Flags: LH   outside            00:00:33  fwd LI LH   inside             1d13h     fwd Join(00:03:14) LI (192.168.198.198,239.255.148.199)RPT SM Up: 1d13h RP: 192.168.198.1* JP: Prune(never) RPF: Tunnel1,192.168.198.1* Flags: KAT(00:02:59) RA RR   inside             1d13h     off Prune(00:03:14) (192.168.198.198,239.255.148.199)SPT SM Up: 00:04:00 JP: Join(never) RPF: inside,192.168.198.198* Flags: KAT(00:02:59) RA RR   No interfaces in immediate olist (*,239.255.199.197) SM Up: 1d13h RP: 192.168.198.1* JP: Join(never) RPF: Tunnel1,192.168.198.1* Flags: LH   outside            00:00:33  fwd LI LH   inside             1d13h     fwd Join(00:03:20) LI (192.168.198.198,239.255.199.197)RPT SM Up: 1d13h RP: 192.168.198.1* JP: Prune(never) RPF: Tunnel1,192.168.198.1* Flags: KAT(00:02:56) RA RR   inside             1d13h     off Prune(00:03:20) (192.168.198.198,239.255.199.197)SPT SM Up: 00:04:08 JP: Join(never) RPF: inside,192.168.198.198* Flags: KAT(00:02:56) RA RR   No interfaces in immediate olist (*,239.255.255.250) SM Up: 1d13h RP: 192.168.198.1* JP: Join(never) RPF: Tunnel1,192.168.198.1* Flags: LH   outside            00:01:23  fwd LI LH   inside             1d13h     fwd Join(00:02:59) LI Firewall# 

Each multicast flow is listed as (*,G), (S,G), or (S,G)RPT, where _ means any source, S is a specific source address, and G is the multicast group address. In addition, the following values are shown:

• Multicast protocol SM (sparse mode, used for most flows) or DM (dense mode).

• Flow uptime The time elapsed since the flow was first created.

• RP The address of the RP for the flow or group.

• JP Join or Prune activity.

• RPF Reverse path forwarding entry, or the interface where multicast data is expected to arrive.

  In the example, the RPF is often shown as Tunnel1,192.168.198.1. In this case, the firewall acts as the RP, and bidirectional mode is not used. Therefore, the multicast data must pass from the source to the RP over an SPT to the RP before being forwarded down the shared PIM tree. The "tunnel" is a logical interface within the firewall that points back to the source.

• Flags Various flags representing the flow's state.

• Interface information A list of interfaces involved in the flow, their current forwarding state (fwd or off), and the most recent Join or Prune event with the elapsed time.

NOTE

The firewall automatically creates a multicast flow for (*,224.0.1.40), which is used for Cisco Auto-RP discovery messages. The flow is listed as DM because it is a hop-by-hop announcement that doesn't depend on a sparse mode RP. To dynamically discover an RP, the discovery protocol can't rely on an RP.

In the example, two multicast flows of interest are shaded. The first, (*,239.255.199.197), represents the multicast flow from any source to group 239.255.199.197. This is the video stream of data being pushed down the shared multicast tree toward the receivers that have joined the group.

Note that the RPF or the source of the data is listed as Tunnel1,192.168.198.1, which is the firewall's inside interface. The firewall is acting as the RP, so it is receiving multicast data from the source over a special internal "tunnel" interface.

The second flow, (192.168.198.198,239.255.199.197)SPT, represents the multicast flow from the source (192.168.198.198) to the multicast group. This data is actually being fed to the RP over an SPT built for this purposehence the SPT designation in the flow descriptor. The RPF points to the inside interface, where the source is located.