Has anyone thought of or found an alternative to the Ethernet switch needed for lab7 in R2 (3800 series)?
Regards, Jay McMickle- CCNP, CCSP, MCSE Sent from my iPhone On Jul 25, 2010, at 11:00 AM, [email protected] wrote: > Send CCIE_RS mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://onlinestudylist.com/mailman/listinfo/ccie_rs > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CCIE_RS digest..." > Today's Topics: > > 1. multicast igmp filtering (marc abel) > 2. Re: multicast igmp filtering (marc abel) > 3. Re: multicast igmp filtering (Steve Shaw) > 4. Re: multicast igmp filtering (marc abel) > I'm working on Vol 1 Lab 24 task 8 + 9 and can't reproduce what is shown in > the DSG. The task shows us applying an access list on F0/0 for R5,R6,R7 like > this: > > access-list 11 deny 224.0.0.0 15.255.255.254 > access-list 11 permit 224.0.0.1 15.255.255.255 > int f0/0 > ip igmp access-group 11 > > Then the solution guide show the output of Debug ip igmp. In the output they > show 240.0.0.0 blocked on fastethernet 0/0 like this: > > Jul 24 16:14:34.903: IGMP(*): Group 224.0.1.40 access denied on > Fastethernet0/0 > > I can not get my routers to produce this line. My outputs seem to be keyed to > the loopbacks. If I apply the access-list to my loopback interface then I > will indeed see this line: > > Jul 24 16:14:34.903: IGMP(*): Group 224.0.1.40 access denied on loopback0 > > What am I missing? > > Here are the relevant parts of my config on R7 (R6 and R5 are identical) > > hostname R7 > > ip multicast-routing > > interface Loopback0 > ip address 200.0.0.7 255.255.255.255 > ip pim sparse-mode > ! > interface FastEthernet0/0 > ip address 150.100.220.7 255.255.255.0 > ip pim sparse-mode > ip igmp access-group 11 > duplex auto > speed auto > ! > interface FastEthernet0/1 > ip address 150.100.221.7 255.255.255.0 > ip pim sparse-mode > duplex auto > speed auto > > ip pim autorp listener > ! > access-list 11 deny 224.0.0.0 15.255.255.254 > access-list 11 permit 224.0.0.0 15.255.255.255 > > Further testing shows other groups blocked correctly. I just can't seem to > block 224.0.1.40 as the DSG shows. I wonder if there is some mechanism that > prevents 224.0.1.40 from being filtered. > > On Sat, Jul 24, 2010 at 11:33 AM, marc abel <[email protected]> wrote: > I'm working on Vol 1 Lab 24 task 8 + 9 and can't reproduce what is shown in > the DSG. The task shows us applying an access list on F0/0 for R5,R6,R7 like > this: > > access-list 11 deny 224.0.0.0 15.255.255.254 > access-list 11 permit 224.0.0.1 15.255.255.255 > int f0/0 > ip igmp access-group 11 > > Then the solution guide show the output of Debug ip igmp. In the output they > show 240.0.0.0 blocked on fastethernet 0/0 like this: > > Jul 24 16:14:34.903: IGMP(*): Group 224.0.1.40 access denied on > Fastethernet0/0 > > I can not get my routers to produce this line. My outputs seem to be keyed to > the loopbacks. If I apply the access-list to my loopback interface then I > will indeed see this line: > > Jul 24 16:14:34.903: IGMP(*): Group 224.0.1.40 access denied on loopback0 > > What am I missing? > > Here are the relevant parts of my config on R7 (R6 and R5 are identical) > > hostname R7 > > ip multicast-routing > > interface Loopback0 > ip address 200.0.0.7 255.255.255.255 > ip pim sparse-mode > ! > interface FastEthernet0/0 > ip address 150.100.220.7 255.255.255.0 > ip pim sparse-mode > ip igmp access-group 11 > duplex auto > speed auto > ! > interface FastEthernet0/1 > ip address 150.100.221.7 255.255.255.0 > ip pim sparse-mode > duplex auto > speed auto > > ip pim autorp listener > ! > access-list 11 deny 224.0.0.0 15.255.255.254 > access-list 11 permit 224.0.0.0 15.255.255.255 > > > Marc, when would you see 224.0.1.40 in your network? > >> On Jul 24, 2010 1:27 PM, "marc abel" <[email protected]> wrote: >> >> Further testing shows other groups blocked correctly. I just can't seem to >> block 224.0.1.40 as the DSG shows. I wonder if there is some mechanism that >> prevents 224.0.1.40 from being filtered. >> >> >> On Sat, Jul 24, 2010 at 11:33 AM, marc abel <[email protected]> wrote: >> > >> > I'm working on Vol 1 L... >> >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> > > For RP discovery. Garry Baker showed me that it has to do with last IGMP > reporter for the group > > R7(config-if)#do show ip igmp mem > > > Channel/Group Reporter Uptime Exp. Flags > Interface > *,224.0.1.39 200.0.0.7 00:06:21 02:25 2LA Lo0 > *,224.0.1.40 200.0.0.7 00:04:17 02:28 2LA Lo0 > > Now if I shut down lo0 > > do show ip igmp mem > > > Channel/Group Reporter Uptime Exp. Flags > Interface > *,224.0.1.39 150.100.220.7 02:13:16 02:51 2LA Fa0/0 > *,224.0.1.40 150.100.220.7 00:00:08 stop 2LA Fa0/0 > > and now I start seeing the filtering happen. > > I guess I am still a bit deficient in my understanding of the RP process > because seemingly the RP traffic to group 224.0.1.40 would be coming in from > interface f0/0 but maybe since the source of the join was lo0 that is why. > > > On Sat, Jul 24, 2010 at 12:36 PM, Steve Shaw <[email protected]> wrote: > Marc, when would you see 224.0.1.40 in your network? > >> On Jul 24, 2010 1:27 PM, "marc abel" <[email protected]> wrote: >> >> Further testing shows other groups blocked correctly. I just can't seem to >> block 224.0.1.40 as the DSG shows. I wonder if there is some mechanism that >> prevents 224.0.1.40 from being filtered. >> >> >> >> On Sat, Jul 24, 2010 at 11:33 AM, marc abel <[email protected]> wrote: >> > >> > I'm working on Vol 1 L... >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
