07-08-2009 02:59 AM - edited 03-06-2019 06:38 AM
Hello,
I want to configure my Catalyst 3750 to act as a IGMP stub (proxy) in order to forward all IGMP packets rather than participate in PIM.
I succeed once, but now it doesn't work anymore...
I've been trying to reconfigure it, but without full success. The IGMP packets are correctly forwarded and when I type:
Switch#sh ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.255.255.250 Vlan300 01:15:31 00:01:56 172.30.10.1
225.0.0.1 Vlan300 01:15:31 00:01:56 172.30.10.1
225.0.0.2 Vlan300 01:15:30 00:01:56 172.30.10.1
I see that IGMP is correctly handled.
The topology is:
LAN (172.30.10.0/24) ------ (VLAN 300 on fast 1/0/1) Switch (VLAN 200 on fast 1/0/3 and 1/0/4) ------ WAN (172.30.1.0/24)
The thing is that multicast packets coming from the WAN are dropped by the switch...
when I enable the mrouting and mpacket debug
Switch#debug ip mrouting
IP multicast routing debugging is on
Switch#debug ip mpacket
IP multicast packets debugging is on
it displays:
MRT(0): RPF lookup for 172.30.3.1[0.0.0.0] (172.30.3.1) returned Vlan200 172.30.1.240
IP(0): s=172.30.3.1 (Vlan200) d=225.0.0.1 id=641, ttl=125, prot=255, len=1234(1220), RPF lookup failed for source or RP
....
172.30.3.1 is the sender of the multicast packets.
Finally, here is a glimpse my configuration:
--------------------------------
interface FastEthernet1/0/1
switchport access vlan 300
!
interface FastEthernet1/0/2
!
interface FastEthernet1/0/3
switchport access vlan 200
!
interface FastEthernet1/0/4
switchport access vlan 200
...
!
interface Vlan1
no ip address
ip igmp version 3
!
interface Vlan200
ip address 172.30.1.200 255.255.255.0
ip pim passive
ip igmp version 3
ip igmp proxy-service
!
interface Vlan300
ip address 172.30.10.200 255.255.255.0
ip pim passive
no ip route-cache cef
no ip route-cache
ip igmp helper-address 172.30.1.240
ip igmp version 3
no ip mroute-cache
!
ip classless
ip route 172.30.3.0 255.255.255.0 172.30.1.240
ip http server
!
....
--------------------------------
Many thanks !!
07-08-2009 07:10 AM
What is the RP address? If you could do a recursive lookup for the source see if the multicast traffic is going out the interface that the traffic was received for the RP.
07-09-2009 12:00 AM
I didn't specify a RP address, and I don't have to, do I?
Besides It already worked one time and no RP address was set.
07-09-2009 01:28 AM
In fact, I was inspired by this post:
http://www.velocityreviews.com/forums/t363331-igmp-proxy.html
but it isn't sufficient...
thanks!
07-09-2009 05:42 AM
This is a little different than you set up but here is my version of Multicast stub routing in your situation. A few commands different.
interface Vlan1
no ip address
ip igmp version 3
!
interface Vlan200 (outgoing to WAN)
ip address 172.30.1.200 255.255.255.0
ip pim dense
!
interface Vlan300 (LAN)
ip pim dense
ip address 172.30.10.200 255.255.255.0
ip igmp helper-address 172.30.1.240
!
!
On the upstream router that should be the PIM neighbor (across you WAN) you would do the following
Dont know your interfaces for the other device but for example
int fa0/0 (WAN)
ip pim spase-mode
ip pim neighbor-filter 10
access-list 10 deny 172.30.1.200
access-list 10 permit any
You create the neighbor filter because you do not want to form a PIM neighborship between the device (This way multicast packets are no set out a non PIM enabled interface). The upstream router will build its multicast distribution tree on behalf of the stub router (in your case the switch) based off the IGMP proxy function.
07-09-2009 07:22 AM
In fact your first post was more helpful!
I had to define a RP address in the switch.
I simply defined the IP of the switch itself as the RP and now the multicast stream goes from the "WAN" side to the "LAN" side!
I quoted the term "WAN" because in my architecture the WAN is not directly connected to the switch. After there is an encryption unit who is the real frontier with the WAN.
So, I didn't set anything you said in the upstream router for the simple reason that the switch cannot communicate directly to the router behind the encryption unit.
I know that I should have mentioned it at the beginning...
The thing to remember is that the switch needed a RP address (even a dummy one) to forward the multicast stream.
Again thanks for your help!
07-09-2009 07:59 AM
Well im glad to have helped you out. SHould have asked for a more detailed layout of the multicast domain but oh well. Glad its all working for you.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide