Moving from port 24 to 25 moves you to the other Janus regardless of
whether there's a DFC or not.
John, if as you say moving to the other replication engine (RE)
solves the problem, it's possible you are simply exceeding the
replication capacity of the Janus.
Metro based cards (6708, 6716) have superior replication capacity,
but that doesn't help you for GE, there is no shipping GE card for
c6k that uses metro. Note that changing the DFC has no impact
whatsoever on the RE hardware, the RE is on the linecard itself.
More recent code does provide a CLI to monitor drops in the
replication engine, show platform hardware capacity rewrite-engine,
this was added in 12.2(33)SXI. That could help you figure out whether
drops are happening due to oversubscription of the Janus.
Hope that helps,
Tim
At 08:00 AM 7/29/2010, Ben Lovell (belovell) submitted:
John,
Is your 6748 a DFC line card? If so you are correct, moving from
port 24 to 25 would have moved you to the other Janus ASIC. Janus is
the fabric/mcast replication ASIC.
If your problem is ONLY with mcast then you can safely ignore the
Rohini. We have addressed a number of issues with mcast replication
on the Janus in recent years. So if you are running older
12.2(18)SXF or even earlier SX code you may want to consider an IOS
update. Also not knowing your network I can't say but it's not
impossible to hit the scale limits with high rates mcast pps and mroute counts.
The newer LCs with the 3CXL use a newer replication ASIC that
preforms significantly better than the Janus.
-Ben
On Jul 28, 2010, at 6:04 PM, John Neiberger wrote:
> We have a weird problem on some 7606s with WS-6748-SFP blades. We have
> a whole bunch of multicast streams running through these routers and
> there are multicast receivers directly attached. We had a problem
> where one particular multicast stream would occasionally have dropped
> packets resulting in MPEG CC errors on the receiver. We were able to
> prove that the source was clean, as were the paths between the source
> and the receiver. The receiver was not seeing MPEG CC errors on any
> other stream, which is really odd.
>
> Here's where it gets even stranger. When we moved the receiver to
> another port, like from 23 to 24, the receiver still saw the errors.
> We moved it to port 25 and the errors apparently went away. Our only
> guess is that this could potentially be an issue with the ASICs on the
> blade. Ports 13-24 are controlled by one ASIC (I believe a Rohini
> ASIC), and the four Rohini ASICs connect to two Janus ASICs. That is
> as I understand it. I may be wrong. When we moved the receiver from
> port 24 to 25, we moved to a different Rohini ASIC and possibly to
> another Janus ASIC. Regardless, according to our video guys the
> problem cleared up after the move.
>
> Have any of you ever experienced anything like this? Could this really
> be a problem on the Rohini or Janus ASICs? What sort of problem would
> only affect certain multicast groups and not others?
>
> Thanks
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
>
<https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at
<http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
<https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
<http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
