Network 101: March 2011

Monday, March 28, 2011

Embedded Event Manager

Embedded event manager is a very nice feature of the CISCO IOS. This feature will track the event which occur on a router and notify or automatically configure a router for us. EEM uses event detector and actions to provide the notification of those events.

Example of the events of EEM are as followings.

Router(config-applet)#event ?
application Application specific event
cli CLI event
counter Counter event
interface Interface event
ioswdsysmon IOS WDSysMon event
none Manually run policy event
oir OIR event
resource Resource event
snmp SNMP event
syslog Syslog event
timer Timer event
track Tracking object event

Action that EEM provides are as followings.

- generating syslog messages

- reload the router

- generate SNMP traps

- Executing the Cisco IOS command

- etc

Sample Configuration of EEM

event manager applet TEST_EEM
event none
action 1.1 cli command "enable"
action 1.2 cli command "conf t"
action 1.3 cli command "int f0/1"
action 1.4 cli command "ip address 192.168.1.1 255.255.255.0"
action 1.5 cli command "exit"
!

When launching this command. " event manager run TEST_EEM", because the event is NONE, the router will immediately do actions according to the configured actions.

So the interface f0/1 will be configured the IP address as 192.168.1.1/24.

Result

Router#sh ip int brief

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 unassigned YES unset administratively down down

FastEthernet0/1 192.168.1.1 YES manual administratively down down

Router#

Friday, March 25, 2011

Multicast over Frame Relay

Interesting Note.
http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frmrlay.html

Thursday, March 24, 2011

Switch Database Template (SDM)

We can use SDM template to configure the switch to optimize support for specific features depending on how the switched is used in the network. There are 3 types of features.

Routing : maximizes system resources for unicast routing.
VLANs : Maximizes number of unicast MAC address.
Default : balancing to all functions

Here is the approximate number of feature resources allowed by each template.

Configuration

In configuration mode.

-sdm prefer vlan

-sdm prefer routing

Verification

show sdm prefer

Test_switch#sh sdm prefer

The current template is "desktop default" template.

The selected template optimizes the resources in

the switch to support this level of features for

8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 6K

number of IPv4 IGMP groups + multicast routes: 1K

number of IPv4 unicast routes: 8K

number of directly-connected IPv4 hosts: 6K

number of indirect IPv4 routes: 2K

number of IPv4 policy based routing aces: 0

number of IPv4/MAC qos aces: 0.75K

number of IPv4/MAC security aces: 1K

Wednesday, March 23, 2011

MPLS advertise lable

When enable mpls in an interface, the router tags all prefixes it has learnt from the routing table and advertises out via ldp message to its neighbors. This behavior is enabled by default. However, we can tune this behavior by specifying prefixes in an access-list and configure the router to advertise them only.

Configuration Example

In normal condition which mpls ldp advertise-lables enable by default. Prefixed learnt by R1 are all tagged.

R1#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.1.2
17 Pop tag 4.4.4.4/32 0 Fa0/0 192.168.1.2
R1#

Configuration
Configure Access-list to allow specific prefix being ldp advertised by the router.

R2
mpls ldp advertise-labels for 1

access-list 1 permit 2.2.2.0 0.0.0.255

mpls ldp advertise-labels for 1

access-list 1 permit 1.1.1.0 0.0.0.255

R2#show mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Pop tag 1.1.1.1/32 0 Fa0/0 192.168.1.1

17 Untagged 3.3.3.3/32 0 Fa0/0 192.168.1.1

R1#sh mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Pop tag 2.2.2.2/32 0 Fa0/0 192.168.1.2

17 Untagged 4.4.4.4/32 0 Fa0/0 192.168.1.2

Now, after the configuration, the prefix 4.4.4.4 and 3.3.3.3 are not tagged anymore. They will be forwarded by the IP lookup as in the normal network.

Tuesday, March 22, 2011

VLAN Access control list (VACL)

VACL is used to permit and deny the traffic within the VLAN itself. Here is the example showing how this feature works.

Example

vlan access-map NO_HTTP 10

action drop

match ip address 111

vlan access-map NO_HTTP 20

action forward

vlan filter NO_HTTP vlan-list 10

access-list 111 deny tcp any any eq www

access-list 111 permit ip any any

Monday, March 21, 2011

QoS Tunnel

Where to configure Qos-preclassify for tunneling

You can apply a service policy to either the tunnel interface or to the underlying physical interface. The decision of where to apply the policy depends on the QoS objectives. It also depends on which header you need to use for classification.

Apply the policy to the tunnel interface without qos-preclassify when you want to classify packets based on the pre-tunnel header.
Apply the policy to the physical interface without qos-preclassify when you want to classify packets based on the post-tunnel header. In addition, apply the policy to the physical interface when you want to shape or police all traffic belonging to a tunnel, and the physical interface supports several tunnels.
Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface when you want to classify packets based on the pre-tunnel header.

Configuration of QoS tunnel

Router(config)# interface tunnel0
Router(config-if)# qos pre-classify

Voice Adaptive Traffic Shaping

Voice Adaptive Traffic Shaping is only acailable with MQC-based Frame-Relay traffic shaping, and only with LLQ enabled in sharper-queue. The goal of VATS is to throttle the PVC's sending rate once the system detected voice packets in the priority queue. The VATS feature is useful in the oversubscription scenaiio, where the customer sends traffic over the CIR. When the voice packet comes in the priority queue. the system will signal the shaper to slow its rate down to ensure router will never drop or delay any voice packets.

Command
policy-map class
shape fr-voice-adapt <deactivation N>
where N = number of seconds to deactivate shaping after the last voice packet has been seen in the priority queue.

Referecence
CCIE R&S lab INE workbook I v5.0

Thursday, March 17, 2011

Time-based ACL

Time-based ACL is one of the feature of dynamic ACL which allows us to specify the active and inactive time of the access-list. Here is how configuration of time-based access-list look like.

Configuration
We allows the configured access-list to be active during day time operation and disable the access-list after hours. In this case, we assume the hours of operation is from 8am - 5pm.

time-range MYTIME
periodic daily 8:00 to 17:00

access-list 100 dynamic ACL_DYN permit ip any any time-range MYTIME

Verify configuration

R2#sh access-lists
Standard IP access list 1
10 permit 239.0.0.0, wildcard bits 0.255.255.255
Extended IP access list 100
10 Dynamic ACL_DYN permit ip any any time-range MYTIME (inactive)
R2# sh clock
*22:05:17.614 UTC Fri Mar 1 2002
R2#

R2#sh access-lists

Standard IP access list 1

10 permit 239.0.0.0, wildcard bits 0.255.255.255

Extended IP access list 100

10 Dynamic ACL_DYN permit ip any any time-range MYTIME (active)

R2#sh clock

*14:07:02.310 PST Fri Mar 1 2002

R2#

PIM BSR priority

PIM BSR uses the 224.0.0.13 to send out the advertisement of the BSR and PR. In case there are more than one advertisement of the RP and BSR candidates, we use the priority and IP address criteria to election the primary RP and primary BSR. However, RP election and BSR election criteria is different

RP election consider the lowest priority or the lowest IP address as a primary RP. However, BSP election considers the highest priority or the highest IP address as primary BSR. We can see the RP and BSP by using following commad.

show ip pim rp mapping ( show RP mapping for the multicast groups )

show ip pim bsr-route ( show BSR router )

To change the priority of the RP and BSR, we use the following commands.

ip pim rp-candidate Loopback0 priority 10

BSR

ip pim bsr-candidate Loopback0 0 10

Example :

We configure R1 and R2 to announce themselves as the RP and BSR candidates. R1 has RP priority of 10 and BSR priority of 10. R2 has RP priority of 20 and BSR priority of 0. We expect that R1 will be the primary RP and R2 will be the primary BSR because of the criteria explained above.

Configuration

R1

ip pim bsr-candidate Loopback0 0 10

ip pim rp-candidate Loopback0 priority 10

ip pim bsr-candidate Loopback0 0

ip pim rp-candidate Loopback0 priority 20

RP Mapping

R3#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

RP 1.1.1.1 (?), v2

Info source: 1.1.1.1 (?), via bootstrap, priority 10, holdtime 150

Uptime: 00:16:29, expires: 00:02:12

RP 2.2.2.2 (?), v2

Info source: 1.1.1.1 (?), via bootstrap, priority 20, holdtime 150

Uptime: 00:16:40, expires: 00:01:56

BSR Router

R2#show ip pim bsr-router

PIMv2 Bootstrap information

BSR address: 1.1.1.1 (?)

Uptime: 00:13:08, BSR Priority: 10, Hash mask length: 0

Expires: 00:01:12

This system is a candidate BSR

Candidate BSR address: 2.2.2.2, priority: 0, hash mask length: 0

Candidate RP: 2.2.2.2(Loopback0)

Holdtime 150 seconds

Advertisement interval 60 seconds

Next advertisement in 00:00:37

Candidate RP priority : 20

Friday, March 11, 2011

OSPF Demand-Circuit

In the normal OSPF process, OSPF sets the age of the LSA to 30 minutes. When the LSA timer expires, the router flooding / refresh the LSA again. This is to ensure that each router has the updated OSPF database. However, in the pay-per-use link or low-speed link, we sometimes do not want to enable the 30 minutes LSA aging time. We can enable OSPF demand-circuit to help us for this purpose.

The OSPF demand-circuit will set LSA age bit to DONOTAGE value. By setting this the LSA aging process is stopped and no periodic update.

Command

interface s1/1
ip ospf demand-circuit

.

Monday, March 7, 2011

Voice VLAN

Voice VLAN Configuration guide

Configuring Ports to Carry Voice Traffic in 802.1Q Frames

switchport voice vlan{vlan-id | dot1p |none |untagged}

Configure how the Cisco IP Phone carries voice traffic:

•

vlan-id—Configure the Cisco IP Phone to forward all voice traffic through the specified VLAN. By default, the Cisco IP Phone forwards the voice traffic with an 802.1Q priority of 5. Valid VLAN IDs are from 1 to 4094.

•

dot1p—Configure the Cisco IP Phone to use 802.1p priority tagging for voice traffic and to use the default native VLAN (VLAN 0) to carry all traffic. By default, the Cisco IP Phone forwards the voice traffic with an 802.1p priority of 5.

•

none—Allow the IP phone to use its own configuration to send untagged voice traffic.

•

untagged—Configure the phone to send untagged voice traffic

Overriding the CoS Priority of Incoming Data Frames

You can configure the switch to override the priority of frames arriving on the IP phone port from connected devices.

switchport priority extend
cos value

Set the IP phone access port to override the priority received from the PC or the attached device.

The CoS value is a number from 0 to 7. Seven is the highest priority. The default is 0.

Configuring the IP Phone to Trust the CoS Priority of Incoming Data Frames

switchport priority extend trust

Set the IP phone access port to trust the priority received from the PC or the attached device.

Displaying Voice VLAN

To display voice VLAN for an interface, use the show interfaces interface-id switchport privileged EXEC command.

For detailed information about the fields in the display, refer to the command reference for this release.

PPPoFR

Sample Configuration of PPPoFR

Configuration
R1 and R2 are connected via Frame relay network. We now configure PPPoFR with the network 192.168.1.0/24 as below.

R1
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay interface-dlci 102 ppp Virtual-Template10
end
!

interface Virtual-Template10
ip address 192.168.1.1 255.255.255.0

interface Serial1/0

no ip address

encapsulation frame-relay

no fair-queue

serial restart-delay 0

frame-relay interface-dlci 201 ppp Virtual-Template10

interface Virtual-Template10

ip address 192.168.1.2 255.255.255.0

Verify configuration

R1#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES unset administratively down down
FastEthernet0/1 unassigned YES unset administratively down down
Serial1/0 unassigned YES unset up up
Serial1/1 unassigned YES unset administratively down down
Serial1/2 unassigned YES unset administratively down down
Serial1/3 unassigned YES unset administratively down down
Virtual-Access1 unassigned YES unset down down
Virtual-Access2 192.168.1.1 YES TFTP up up
Virtual-Template10 192.168.1.1 YES manual down down

R1#sh int virtual-access2
Virtual-Access2 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 192.168.1.1/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,
   reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoFR vaccess, cloned from Virtual-Template10
  Vaccess status 0x44
  Bound to Serial1/0 DLCI 102, Cloned from Virtual-Template10, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:00:02, output never, output hang never
  Last clearing of "show interface" counters 00:04:53
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
   23 packets input, 364 bytes, 0 no buffer
   Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
   0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
   51 packets output, 582 bytes, 0 underruns
   0 output errors, 0 collisions, 0 interface resets
   0 output buffer failures, 0 output buffers swapped out
   0 carrier transitions

R1# ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/70/108 ms
R1#

On-Demand Routing (ODR)

On Demand Routing uses CDP to advertise the connected IP prefix of the stub router via CDP and transmit to HUB router. The stub router will have a default route installed in its routing table. When configuring ODR, make sure that there is no routing protocol running on the router.

Command to enable ODR.
In global configuration
router odr

Example

R1 is a HUB. R2 and R3 are spoke routers. Note that we do not have any routing process on R3 and R2. R1 only have IP reachability to R2 and R3. Configuration is only done on R1.

Configuration

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router odr
R1(config)#router odr
R1(config-router)#

Verify Configuration

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

   1.0.0.0/32 is subnetted, 1 subnets
o 1.1.1.1 [160/1] via 192.168.1.2, 00:00:01, FastEthernet0/0
   2.0.0.0/32 is subnetted, 1 subnets
o 2.2.2.2 [160/1] via 192.168.2.2, 00:00:35, FastEthernet0/1
C 192.168.1.0/24 is directly connected, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/1
R1#

Spoke Routing table

R2#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.2.1 to network 0.0.0.0

2.0.0.0/32 is subnetted, 1 subnets

C 2.2.2.2 is directly connected, Loopback1

C 192.168.2.0/24 is directly connected, FastEthernet0/0

o* 0.0.0.0/0 [160/1] via 192.168.2.1, 00:00:48, FastEthernet0/0

Thursday, March 3, 2011

Q-in-Q tunneling

Q-in-Q Tunneling allows us to extend layer 2 beyond WAN boundary. Q-in-Q allows customer to preserve 802.1Q VLAN tags across a WAN. Service provider will receive the tagged frame from the customer and add the additional 8021.Q tag in the frame header so called double tagged frame. SP assigns different VLAN tag to different customer in order to identify which customer the frames are belong to. This allows overlapping VLAN IDs between customers.

In addition, CDP and VTP packets are able to pass over Q-in-Q service also.

Basic configuration

Provide Edge SW
PE1
interface FastEthernet0/x
description to PE2
switchport mode access
switchport access vlan 100

switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel vtp
no cdp enable

interface FastEthernet0/y
description to CE
swtichport access vlan 10

From the configuration above, the VLAN tag will be 10 and 100. 10 for customer VLAN and 100 is for SP VLAN.

.

Dynamic ARP inspection

ARP inspection checks the arp packet which is sent and received in the network. It checks the MAC address in the ethernet frame header and try to match the MAC address information inside the frame to prevent the attacker responds the arp request of the legitimate host as shown in the figure below

Also, ARP inspection uses the dhcp snooping binding table to see if the IP address and the MAC address of PC which is connected to the port matched the dhcp snooping binding table. If it does not, the switch will not forward the packet out of its interfaces.

Example
In this example, we first enable the dhcp snooping and the arp inspection on the switch. After the dhcp snooping gets the MAC Address and IP address of the PC, we statically change the IP address from 192.168.1.11 to 192.168.12 in order to violate the dhcp snooping binding table. We can see the log below to have better understanding.

Switch#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:14:22:F9:B3:3D 192.168.1.11 86255 dhcp-snooping 10 FastEthernet0/7
Total number of bindings: 1

Switch#

When changing the IP address of the PC to 192.168.1.12 statically, the result is violating the dhcp snooping table. So that the arp inspection is not passed. We can see it in the syslog that DHCP_SNOOPING_DENY. Therefore, the PC cannot connect to the network.

Syslog message

20:35:05: ARP Packet (Fa0/7/10) Src: 0014.22f9.b33d, Dst: ffff.ffff.ffff, SM: 0014.22f9.b33d, SI: 192.168.1.12, TM: 0000.0000.0000, TI: 192.168.1.1
20:35:05: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/7, vlan 10.([0014.22f9.b33d/192.168.1.12/0000.0000.0000/192.168.1.1/20:35:05 UTC Mon Mar 1 1993])

DHCP Snooping

DHCP snooping prevents attacks that use DHCP. It only allows dhcp message on the configured trusted port to communicate to clients. Otherwise, it will drop the packets. When enabling the dhcp snooping on the switch, all ports are as default an untrusted port. Therefore, we need to specify which port connects to the DHCP server to allow DHCP message being forward by the switch.

Also, DHCP snooping builds a table of IP address and port mapping based on legitimate DHCP messages on trusted ports called DHCP snooping binding table. This table will be used by arp inspection and IP source guard feature.

Configuration

SWICH Configuration

ip dhcp snooping vlan 10
no ip dhcp snooping information option
ip dhcp snooping

interface FastEthernet0/1

switchport access vlan 10

switchport mode access

ip dhcp snooping trust

ip dhcp snooping limit rate 100

interface FastEthernet0/3

switchport access vlan 10

switchport mode access

Verify Configuration

Switch#sh ip dhcp snooping

Switch DHCP snooping is enabled

DHCP snooping is configured on following VLANs:

DHCP snooping is operational on following VLANs:

DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is disabled

circuit-id format: vlan-mod-port

remote-id format: MAC

Option 82 on untrusted port is not allowed

Verification of hwaddr field is enabled

DHCP snooping trust/rate is configured on the following Interfaces:

Interface Trusted Rate limit (pps)

------------------------ ------- ----------------

FastEthernet0/1 yes 100

Switch#show ip dhcp snooping binding

MacAddress IpAddress Lease(sec) Type VLAN Interface

------------------ --------------- ---------- ------------- ---- --------------------

00:14:22:F9:B3:3D 192.168.1.11 69287 dhcp-snooping 10 FastEthernet0/7

Total number of bindings: 1

Switch#

Wednesday, March 2, 2011

IGMP Snooping Cisco Catalyst problem

This article is copied from Cisco website
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008059a9df.shtml

Problem
Multicast traffic does not seem to pass across Catalyst switches, even in the same VLAN. Figure 1 depicts a typical scenario:
Figure 1 – Network Setup with Multicast Source and Receivers

The multicast source is connected to Switch 1, which is a Catalyst 6500 Switch with Supervisor Engine 720 that runs Cisco IOS Software. Receiver 1 is connected to Switch 1, and Receiver 2 is connected to Switch 2. Switch 2 is a Catalyst 3750. There is a Layer 2 link, either access or trunk, between Switch 1 and Switch 2.
In this setup, you find that Receiver 1, which is on the same switch as the source, gets the multicast stream with no problems. However, Receiver 2 does not get any multicast traffic. This document aims to resolve this issue.

Revisit Some Key Multicast Concepts

Before you explore the solution and the different options you have, you must be clear on certain key concepts of Layer 2 multicast. This section defines these concepts.

Note: This section provides a very simple and direct explanation that focuses only on this particular issue. See the Related Information section of this document for a more detailed explanation of these terms.

IGMP

IGMP is a protocol that enables end hosts (receivers) to inform a multicast router (IGMP querier) of the end host intention to receive particular multicast traffic. So this is a protocol that runs between a router and end hosts and allows:

Routers to ask end hosts if they need a particular multicast stream (IGMP query)
End hosts to tell or respond to the router if they seek a particular multicast stream (IGMP reports)

IGMP Snooping

IGMP snooping is a mechanism to constrain multicast traffic to only the ports that have receivers attached. The mechanism adds efficiency because it enables a Layer 2 switch to selectively send out multicast packets on only the ports that need them. Without IGMP snooping, the switch floods the packets on every port. The switch "listens" for the exchange of IGMP messages by the router and the end hosts. In this way, the switch builds an IGMP snooping table that has a list of all the ports that have requested a particular multicast group.

Mrouter Port

The mrouter port is simply the port from the switch point of view that connects to a multicast router. The presence of at least one mrouter port is absolutely essential for the IGMP snooping operation to work across switches. The Understand the Problem and Its Solutions section of this document discusses this requirement in more detail.

Multicast at L2

Any IP version 4 (IPv4) traffic with a destination IP in the range of 224.0.0.0 to 239.255.255.255 is a multicast stream. All IPv4 multicast packets map to a predefined IEEE MAC address that has the format 01.00.5e.xx.xx.xx.

Note: IGMP snooping works only if the multicast MAC address maps to this IEEE-compliant MAC range. Some reserved multicast ranges are excluded from being snooped by design. If a nonconforming multicast packet is sourced on a switched network, the packet is flooded throughout that VLAN, which means that it is treated like broadcast traffic.

Understand the Problem and Its Solutions

By default, the Catalyst switches have IGMP snooping enabled. With IGMP snooping, the switch snoops (or listens) for IGMP messages on all the ports. The switch builds an IGMP snooping table that basically maps a multicast group to all the switch ports that have requested it.

Assume that, without any prior configuration, Receiver 1 and Receiver 2 have signaled their intentions to receive a multicast stream for 239.239.239.239 that maps to the L2 multicast MAC address of 01.00.5e.6f.ef.ef. Both Switch 1 and Switch 2 create an e

ntry in their snooping tables for these receivers in response to the IGMP reports that the receivers generate. Switch 1 enters port Gigabit Ethernet 2/48 in its table, and Switch 2 enters port Fast Ethernet 1/0/47 in its table.

Note: At this point, the multicast source has not started its traffic, and none of the switches knows about the switch mrouter port.

When the source on Switch 1 starts to stream multicast traffic, Switch 1 has "seen" the IGMP report from Receiver 1. As a result, Switch 1 delivers the multicast out port Gigabit Ethernet 2/48. But, since Switch 2 "absorbed" the IGMP report from Receiver 2 as part of the IGMP snooping process, Switch 1 does not see an IGMP report (multicast request) on port Gigabit Ethernet 2/46. As a result, Switch 1 does not send any multicast traffic out to Switch 2. Therefore, Receiver 2 never gets any multicast traffic, even though Receiver 2 is in the same VLAN but merely on a different switch than the multicast source.

The reason for this issue is that IGMP snooping is not really supported on any Catalyst platform without an mrouter. The mechanism "breaks down" in the absence of an mrouter port. If you want a fix for this solution, you must have the switches somehow learn or know of an mrouter port. The Solutions section of this document explains the procedure. But how does the presence of an mrouter port on the switches remedy the situation?

Basically, when the switches learn or statically know about an mrouter port, two critical things occur:

The switch "relays" the IGMP reports from the receivers to the mrouter port, which means that the IGMP reports go toward the multicast router. The switch does not relay all the IGMP reports. Instead, the switch sends only a few of the reports to the mrouter. For the purpose of this discussion, the number of reports is not important. The multicast router only needs to know if there is at least one receiver that is still interested in the multicast downstream. In order to make the determination, the multicast router receives the periodic IGMP reports in response to its IGMP queries.
In a source-only multicast scenario, in which no receivers have yet "joined" in, the switch only sends the multicast stream out its mrouter port.

When the switches know their mrouter port, Switch 2 relays out the IGMP report that the switch received from Receiver 2 to its mrouter port. This port is Fast Ethernet 1/0/33. Switch 1 gets this IGMP report on the switch port Gigabit Ethernet 2/46. From the perspective of Switch 1, the switch has received merely another IGMP report. The switch adds that port into its IGMP snooping table and begins to send out the multicast traffic on that port as well. At this point, both the receivers receive the requested multicast traffic, and the application works as expected.

But how do the switches identify their mrouter port so that IGMP snooping works as it is expected to work in a simple environment like this? The Solutions section provides some answers.

Solutions

Use these solutions to solve the problem.

Solution 1: Enable PIM on the Layer 3 Router/VLAN Interface

All Catalyst platforms have the ability to dynamically learn about the mrouter port. The switches passively listen to either the Protocol Independent Multicast (PIM) hellos or the IGMP query messages that a multicast router sends out periodically.

This example configures the VLAN 1 switched virtual interface (SVI) on the Catalyst 6500 with ip pim sparse-dense-mode.

Switch1#show run interface vlan 1
!
interface Vlan1
 ip address 1.1.1.1 255.255.255.0
 ip pim sparse-dense-mode
end

Switch 1 now reflects itself (Actually the internal router port) as an Mrouter port. 

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Router

Switch 2 receives the same PIM hellos on its Fa 1/0/33 interface. So it assigns that 
port as its Mrouter port.

Switch2#show ip igmp snooping mrouter 
Vlan    ports
----    -----
   1    Fa1/0/33(dynamic)

Solution 2: Enable IGMP Querier Feature on a Layer 2 Catalyst Switch

The IGMP querier is a relatively new feature on Layer 2 switches. When a network/VLAN does not have a router that can take on the multicast router role and provide the mrouter discovery on the switches, you can turn on the IGMP querier feature. The feature allows the Layer 2 switch to proxy for a multicast router and send out periodic IGMP queries in that network. This action causes the switch to consider itself an mrouter port. The remaining switches in the network simply define their respective mrouter ports as the interface on which they received this IGMP query.

Switch2(config)#ip igmp snooping querier

Switch2#show ip igmp snooping querier 
Vlan      IP Address     IGMP Version   Port               
-------------------------------------------------------------
1         1.1.1.2        v2             Switch

Switch 1 now sees port Gig 2/46 linking to Switch 2 as an mrouter port.

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Gi2/46

When the source on Switch 1 starts to stream multicast traffic, Switch 1 forwards the multicast traffic to the Receiver 1 found via IGMP snooping (i.e., out port Gig 2/48) and to the mrouter port (i.e., out port Gig 2/46).

Solution 3: Configure Static Mrouter Port on the Switch

The multicast traffic fails within the same Layer 2 VLAN because of the lack of an mrouter port on the switches, as the Understand the Problem and Its Solutions section discusses. If you statically configure an mrouter port on all the switches, IGMP reports can be relayed in that VLAN to all switches. As a result, multicasting is possible. So, in the example, you must statically configure the Catalyst 3750 Switch to have Fast Ethernet 1/0/33 as an mrouter port.

In this example, you need a static mrouter port on Switch 2 only:

Switch2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 1/0/33

Switch2#show ip igmp snooping mrouter
Vlan    ports
----    -----
   1    Fa1/0/33(static)

Solution 4: Configure Static Multicast MAC Entries on All the Switches

You can make a static content-addressable memory (CAM) entry for the multicast MAC address on all the switches for all the receiver ports and the downstream switch ports. Any switch obeys the static CAM entry rules and sends the packet out all the interfaces that are specified in the CAM table. This is the least-scalable solution for an environment that has a lot of multicast applications.

Switch1(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface 
gigabitethernet 2/46 gigabitethernet 2/48

!--- Note: This command should be on one line.

Switch1#show mac-address-table multicast vlan 1

 vlan   mac address     type   learn qos             ports
-----+---------------+--------+-----+---+--------------------------------
   1  0100.5e6f.efef    static  Yes          -   Gi2/46,Gi2/48


Switch2(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface 
fastethernet 1/0/47

!--- Note: This command should be on one line.

Switch2#show mac-address-table multicast vlan 1
Vlan    Mac Address       Type       Ports
----    -----------       ----       -----
   1    0100.5e6f.efef    USER        Fa1/0/47

Solution 5: Disable IGMP Snooping on All the Switches

If you disable IGMP snooping, all switches treat multicast traffic as a broadcast traffic. This floods the traffic to all the ports in that VLAN, regardless of whether the ports have interested receivers for that multicast stream.

Switch1(config)#no ip igmp snooping

Switch2(config)#no ip igmp snooping

** mrouter = port on the Catalyst Switch to the multicast router **.

Tuesday, March 1, 2011

IGMP Snooping

In subnets where IGMP is configured, IGMP snooping manages multicast traffic at Layer 2 to dynamically forward multicast traffic to interfaces that want to receive the multicast traffic only. IGMP snooping, thus, helps reduce the broadcast traffic in the layer 2 network.

Router sends out periodic general IGMP queries. When the IGMP snooping is enabled, the switch will response the query and create the entry per subnet in the layer forwarding table for each layer 2 multicast group. Host which are interested in the multicast traffic send IGMP join request and are added to the forwarding table.

**Note**

IGMP snooping constrains traffic in MAC multicast groups 0100.5e00.0001 - 0100.5eff.ffff