From: Tim Last (packtmon@yahoo.com)
Date: Sat Apr 03 2004 - 20:52:50 GMT-3
Chuck,
I'm stumped. I assume that you checked that Bcast and Ucast traffic operates properly and there isn't a cable problem, right?
At this point, I would look deeper into the operation of Mcast on the Cat. Also, I would look at the port to vlan mapping, if any. Look at what ports are mapped to which mcast groups.
Are you running an actual mcast application on the PC's with 1 sending and 1receiving mcast traffic? Can you manually set which mcast group the app uses? If so, have you tried using different mcast groups? What happens?
What version of IGMP is running on PC? On routerB ?
Again, I don't really know what the problem is, but if you're getting FCS errors, that indicates to me some sort of Layer 1 problem. Bad cable, bad connector, cable too long.
What is the size of the mcast packets being sent including Layer 2 headers? What's the MTU?
You realize that once this problem is corrected, you have an obligation to report your findings to GS, right? :-)
HTH
"C. Warren" <chuck@infla.us> wrote:
Well, I'm certainly on the right track....I've asked/answered all the same questions you pose.....the 2924 was between rtr B/pc b....even tried a hub.
-----Original Message-----
From: Tim Last [mailto:packtmon@yahoo.com]
Sent: Saturday, April 03, 2004 11:07 AM
To: chuck@infla.us
Subject: RE: Multicast strangeness
Hey Chuck,
The config's look fine, but where does the 2924 fit in to this scenario? Is it between RTR B and the PC? Yes
A few other questions:
Has cgmp been configured on the switch? I don't know much about that switch in particular but might it require something special configured to support mcast? Yes(and router)...it doesn't, and just in case it did, that was why we went straight to pc from rtr
Is anything configured on the ports of the cat, such as strom control, that could be interfering with the traffic flow? Have you tried using other ports on the cat? Does the same thing happen? no, yes, yes
On rtr B, what does the output of the show ip mroute command look like? What interfaces are in the oil for the active mcast group?
mroute looks looks fine, oil is proper
Have you done a debug of igmp on rtr B? What does the output show? yes, I can see the joins/leaves
Have you done a show ip igmp interface and show ip igmp groups? What does the output tell you? yes, all as expected
At what rate is mcast traffic being sent by source? At what rate can rtrA send the traffic to rtrB? ~1MB, set for 2MB
Is rtrA experiencing buffer overflows on it's interface connected to rtrB? In other words, is rtrA sending mcast traffic to it's serial interface faster than it's serial interface can send the traffic out onto the wire? In other words, is there a speed mis-match issue causing lots of mcast pkts to be dropped? No, debug on receiving rtr shows inbound multicast frames being 'mforward'ed
Can you rate limit the mcast traffic coming from the source PC on the PC itself? no
Have you tried using Helper Maps to bypass mcast routing? yes
You what say, if you throw enough at the wall, some of it will stick. one slippery wall :)
HTH
"C. Warren" <chuck@infla.us> wrote:
Tim, thanks for taking time out of your day to look at this...I've spent a couple days on this now and probably just can't see the obvious! When you get that number, is seems like you can solve anything.....well, almost. :)
Chuck
f-ether = fastethernet
PC A connected to Router A via crossover cat5
Router A connected to Router B via serial crossover
Router B connected to PC B via crossover cat 5
Configs are at work but I do my best here:
-----------------------------------------------------------------------------
PC A
ip ad 172.32.1.1/24
send data to 239.5.5.5
-------------------------------------------------------------------
RTR A (source side of multicast) 239.5.5.5
ip multicast-routing
int f0/0
ip ad 172.32.1.254 255.255.255.0
ip pim sparse-dense
duplex full
speed 100
int s0/0
ip ad 10.1.1.1 255.255.255.0
ip pim sparse-dense
ip pim send-rp-announce f0/0 scope 16
ip pim send-rp-discovery
router eigrp 1
network 172.32.0.0
network 10.0.0.0
no auto-summary
----------------------------------------------------------------------
RTR B (receiver side)
ip multicast-routing
int f0/0
ip ad 129.61.50.246 255.255.254.0
ip pim sparse-dense
duplex full
speed 100
int s0/0
clock rate 2000000
ip ad 10.1.1.2 255.255.255.0
ip pim sparse-dense
router eigrp 1
network 129.61.0.0
network 10.0.0.0
no auto-summary
-----------------------------------------------------
PC B
ip ad 129.61.50.247/23
Receive 239.5.5.5
Like I said, the IGMP process is good, flow is sent across, but the packets appear to be errored when they exit the fastether receive side.
-----Original Message-----
From: Tim Last [mailto:packtmon@yahoo.com]
Sent: Saturday, April 03, 2004 7:49 AM
To: C. Warren
Subject: Re: Multicast strangeness
Hey Chuck,
What do you mean f-ether? Also, could you post the config's and draw out a little diagram?
I think I know what the problem is but without all the details I can't be sure.
"C. Warren" <chuck@infla.us> wrote:
Here's a strange one I could use some additional brain cells on:
I have two 2621 routers running 122-16 IP plus code. They are connected
back-to-back via serial with a
mulicast sender on one end (f-ether) and a receiver on the other (f-ether).
I'm using a single auto-rp with
sparse-dense configured on each interface. IGMP's are being sent/heard/and
processed. RPF is functioning
as expected. Group is 239.5.5.5
Flow is being started upon request of the receiver, and I can see packets
coming in to the receiver router
via a 'debug ip mpacket detail"....but here's the issue:
Every packet that comes out of the receiver side ether puts the switch
(2924XL) port in an error state.
Port status shows lots of FCS. So we tried running a crossover-cable direct
to the receiving pc in hopes of sniffing
with ethereal....no packets for the flow. Other flavor of packets are
coming through, but nothing related to the flow
in question.
Anyone seen this before??? Tried a couple different 2621's with the same
result.
Thanks,
Chuck
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:43 GMT-3