From: Marko Milivojevic (markom@vodafone.is)
Date: Tue Jun 05 2007 - 11:06:11 ART
If I'm not much mistaken, switches always flood traffic destined to MAC addresses associated with 224.0.0.0/24 (0100.5e00.0000 - 0100.5e00.00ff). Disabling IGMP snooping and tricks like that won't help, as there is no IGMP involved in EIGRP - had it been involved, you would need to enable PIM on all EIGRP speaking interfaces and this is not something you have to do.
You may need to use VACL in this case, but I'm not 100% sure if that would work either.
Without knowing the full question, I'm sure the solution to your problem lies in EIGRP configuration and not in multicast filtering.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of ismail el-shalh
Sent: 4. jznm 2007 17:13
To: ccielab@groupstudy.com
Subject: IEWB LAB 14, Task 4.5 EIGRP
Hi Group,
The task is stating "Do not allow BB3 to intercept EIGRP updates coming from R1, R3 and R6"
Now I have two issues :
Issue No.1
- The solution is assuming that R6 and BB3 are connected to SW1 while they are not.
- Because BB3 is connected to SW3, I believe we could solve this task by only issuing the following command on SW3 :
no ip igmp snooping vlan 1363
mac-address-table static 0100.5e00.000a vlan 1363 interface FastEthernet0/20 FastEthernet0/21
by doing this we are telling SW3 (3550) to only forward the multicast address 224.0.0.10 toward port 0/20 and 0/21, hence BB3 will not receive any eigrp packets.
Issue No.2
SW1 in my lab is 3750, and the mac-address-table static did not work , for example if I want to only forward the multicast traffic 224.0.0.10 toward fas0/19 which is connected to SW4, and Fas0/1 which is connected to R1, the multicast packets are still forwarded to R3.
no ip igmp snooping vlan 1363
mac-address-table static 0100.5e00.000a vlan 1363 interface FastEthernet1/0/1 FastEthernet1/0/19
Reply to request 0 from 204.12.1.9, 12 ms
Reply to request 0 from 150.1.1.1, 20 ms
Reply to request 0 from 204.12.1.6, 16 ms
Reply to request 0 from 204.12.1.3, 12 ms <----- R3 is still receiving the multicast ?
what is so special about the 3750 in this case ?
This archive was generated by hypermail 2.1.4 : Sun Jul 01 2007 - 17:24:46 ART