From: Tim Last (packtmon@yahoo.com)
Date: Sun Apr 04 2004 - 08:58:17 GMT-3
Well, Chuck, I look forward to hearing what's the cause of these problems. I can't tell you how much time I've wasted trying to solve networking problems at the layer 3 level only to finally figure out that the root cause of the problem was at layer 1 or 2.
Typically, what would happen is that something would indicate that layer 2 was working, when in fact, it wasn't. For example, a unicast ping would work and I'd assume all is OK and then look for the problem at layer 3.
Check, then double check, all your assumptions. Remove the config, then reboot the routers and then re-enter the config - checking at each step.
If you can, put a sniffer on the line.
Also, try to reverse the flow eg. make the sender the receiver and vice versa.
See if the problem occurs when different interfaces are used.
I'm sure that eventually, you'll track down the problem. Let us know how you do it.
HTH
"C. Warren" <chuck@infla.us> wrote:
Answers in-line.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tim
Last
Sent: Saturday, April 03, 2004 5:53 PM
To: chuck@infla.us; Group Study
Subject: RE: Multicast strangeness
Chuck,
I'm stumped. I assume that you checked that Bcast and Ucast traffic
operates properly and there isn't a cable problem, right?
- yes...this is a piece of software
(http://www.asti-usa.com/dacs/index.html) that is capable of sending DIS
packets in both broadcast/multicast modes. Broadcast forwarding via ip
helpers....our old way, works fine! Unfortunately, the network we're moving
to (http://www.jwfc.jfcom.mil/about/fact_jntc.htm) isn't going to support
broadcast forwarding because of scalability.
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.
- removed the cat at this time and doing pc-router-router-pc to minimize
fail points.
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?
- yes, yes, yes, same results
What version of IGMP is running on PC? On routerB ?
- tried both 1/2
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.
- seems reasonable, except there are no issues with any other traffic type
What is the size of the mcast packets being sent including Layer 2 headers?
What's the MTU?
- less than 500 bytes, default mtu
You realize that once this problem is corrected, you have an obligation to
report your findings to GS, right? :-)
- yep....... :) I may have a couple of 4500's I can put in place of the
2621's, worst case I can use two 7206's, but then I'm doing irb based on the
switching blade, not other ether on that box.
- This will be solved come Monday!!!! I hope :)
HTH
"C. Warren" 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" 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" 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:42 GMT-3