Sent from my BlackTorch, powered by XL
-----Original Message-----
From: [email protected]
Sender: [email protected]
Date: Fri, 10 Sep 2010 17:34:47
To: <[email protected]>
Reply-To: [email protected]
Subject: cisco-nsp Digest, Vol 94, Issue 33
Send cisco-nsp mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
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 cisco-nsp digest..."
Today's Topics:
1. Re: Recommended 1Gb SFP for ~115km? (Abello, Vinny)
2. Re: ASIC to switch port mapping (Heath Jones)
3. Re: QoS on ingress (Heath Jones)
4. Re: QoS on ingress (Jay Nakamura)
5. Re: QoS on ingress (Heath Jones)
6. Re: REP support on 7600 (Eric Van Tol)
7. Re: ASIC to switch port mapping (Nick Hilliard)
8. Re: QoS on ingress (Keegan Holley)
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Sep 2010 12:30:06 -0500
From: "Abello, Vinny" <[email protected]>
To: Aaron <[email protected]>, "Hansen, Ulrich Vestergaard B. (E R WP
EN ES 4 2)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [c-nsp] Recommended 1Gb SFP for ~115km?
Message-ID:
<a47e89a512e4ff4492ca4de10d7b7c9002bed18...@pscdalpexmb02.perotsystems.net>
Content-Type: text/plain; charset="us-ascii"
We went with a 150km Cisco compatible SFP from Transition Networks. I have
yet to turn it up, but it is within the specifications of the fiber I was
given.
-Vinny
From: Aaron [mailto:[email protected]]
Sent: Friday, September 10, 2010 9:52 AM
To: Hansen, Ulrich Vestergaard B. (E R WP EN ES 4 2)
Cc: Abello, Vinny; [email protected]
Subject: Re: [c-nsp] Recommended 1Gb SFP for ~115km?
The distance also depends on the quality of the fiber in the ground, the
quality of the splices, and any connections.
On Fri, Sep 10, 2010 at 04:54, Hansen, Ulrich Vestergaard B. (E R WP EN ES 4
2) <[email protected]> wrote:
Hi Vinny,
I've got personel and very good experience with optics from SmartOptics.
They manufacture to brocade. They've also got the Cisco "blueprint".
Feel free to contact me directly if you have any questions.
// Ulrich
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Abello, Vinny
Sent: 4. august 2010 16:30
To: [email protected]
Subject: [c-nsp] Recommended 1Gb SFP for ~115km?
Hello,
Any pointers on real world experience on this topic would greatly be
appreciated. What are people using successfully out there as far as third
party SFP's go to hit a distance of approximately 115km? This would be for a
Catalyst 6506. Cisco's solution was a much more costly EDFA solution, but I
see plenty of vendors that make SFP's for Gigabit Ethernet that range from
115km to 150km and more. I know these are not supported by Cisco and TAC
won't troubleshoot if they are in the switch. I'm willing to work around
that should I need TAC assistance on the switch. What works well for a
single wavelength solution at this distance without having to switch to
DWDM? This circuit will have duplex fibers.
Thanks!
-Vinny
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
------------------------------
Message: 2
Date: Fri, 10 Sep 2010 20:12:18 +0100
From: Heath Jones <[email protected]>
To: Vincent Aniello <[email protected]>
Cc: [email protected]
Subject: Re: [c-nsp] ASIC to switch port mapping
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
That's a very interesting problem, I'd love to hear what you find!
Lots of different sized frames from different ingress interfaces all heading
to a few egress interfaces on the same asic perhaps?
Are you seeing an interface that is highly utilized - I'm imagining you are
and this is driving the theory?
On 10 September 2010 18:18, Vincent Aniello <
[email protected]> wrote:
> I was hoping there was an easier way. J
>
>
>
> I am trying to solve a output drops on switch ports on which bandwidth
> utilization does not seem to exceed the port speed. Seems like the drops
> are due to the buffers filling up and dropping frames. I am under the
> impression that each ASIC has their own buffer and if the buffer fills on a
> particular ASIC all ports that share that ASIC will also drop frames. If I
> know the switch interfaces associated with each ASIC I can redistribute the
> connections on the switch to better balance the load.
>
>
>
> Thanks.
>
>
>
> --Vincent
>
>
>
> *From:* Heath Jones [mailto:[email protected]]
> *Sent:* Friday, September 10, 2010 11:20 AM
>
> *To:* Vincent Aniello
> *Cc:* [email protected]
> *Subject:* Re: [c-nsp] ASIC to switch port mapping
>
>
>
> Hi Vincent
>
>
>
> 1) Obtain screwdriver
>
> 2) Remove case
>
> 3) Trace tracks... :)
>
>
>
> On a serious note, it is actually probably the best way to do it. What are
> you trying to achieve/solve/learn?
>
> Heath
>
>
>
>
>
> On 10 September 2010 15:13, Vincent Aniello <
> [email protected]> wrote:
>
> I am trying to determine the switch ports assigned to each ASIC in
> various Cisco switches, in particular a 3750 and 3560E. Can anyone
> enlighten me on how to go about doing this?
>
>
>
> Thanks.
>
>
>
> --Vincent
>
>
>
>
>
> Disclaimer: Any references to Pipeline performance contained herein are
> based on internal testing and / or historic performance levels which
> Pipeline expects to maintain or exceed but nevertheless does not guarantee.
> Congested networks, price volatility, or other extraordinary events may
> impede future trading activities and degrade performance statistics.
> Pipeline is a member of FINRA and SIPC.
> _______________________________________________
> cisco-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
------------------------------
Message: 3
Date: Fri, 10 Sep 2010 20:14:33 +0100
From: Heath Jones <[email protected]>
To: Jay Nakamura <[email protected]>
Cc: cisco-nsp <[email protected]>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Jay I know it might sound ridiculously obvious, but is another T1 out of the
question?
On 10 September 2010 19:44, Jay Nakamura <[email protected]> wrote:
> I can't seem to figure out what to do with my situation, wondering if
> anyone had encountered this.
>
> Situation :
> Router : 1841 IOS 12.4T or 15.0M
> Internet T1, two eth Interfaces
> There are VoIP traffic (SIP & RTP) and general internet traffic
>
> VoIP provider does not tag SIP/RTP with any kind of QoS in IP header.
> (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP
> traffic is not marked, it's not useful.
>
> Problem to solve : how to not drop >ingress< VoIP traffic when
> internet traffic is high as much as possible without capping the
> non-VoIP traffic to less than T1 bandwidth.
>
> Caveat : I understand that since it's not getting policed at the
> egress from the provider, any solution is not going to be perfect
>
> I can't limit the traffic on the Eth interface egress because traffic
> can go to either eth interface.
>
> Any thoughts?
> _______________________________________________
> cisco-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
------------------------------
Message: 4
Date: Fri, 10 Sep 2010 15:17:19 -0400
From: Jay Nakamura <[email protected]>
To: Heath Jones <[email protected]>
Cc: cisco-nsp <[email protected]>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Well, I don't think another T1 will solve the problem. Someone
watching Hulu or something will just suck the bandwidth down. I think
what I am hearing is, I just need to suck it up and rate limit
non-VoIP traffic to 1.2mbps or something on ingress and hope that's
enough head room for VoIP to get through while TCP traffic slows down
from the rate-limit. Of course, if all other traffic is UDP, it may
not do any good.
On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones <[email protected]> wrote:
> Jay I know it might sound ridiculously obvious, but is another T1 out of the
> question?
>
> On 10 September 2010 19:44, Jay Nakamura <[email protected]> wrote:
>>
>> I can't seem to figure out what to do with my situation, wondering if
>> anyone had encountered this.
>>
>> Situation :
>> Router : 1841 IOS 12.4T or 15.0M
>> Internet T1, two eth Interfaces
>> There are VoIP traffic (SIP & RTP) and general internet traffic
>>
>> VoIP provider does not tag SIP/RTP with any kind of QoS in IP header.
>> (DSCP/IPP) ?Internet provider can do QoS based on IPP but since VoIP
>> traffic is not marked, it's not useful.
>>
>> Problem to solve : how to not drop >ingress< VoIP traffic when
>> internet traffic is high as much as possible without capping the
>> non-VoIP traffic to less than T1 bandwidth.
>>
>> Caveat : I understand that since it's not getting policed at the
>> egress from the provider, any solution is not going to be perfect
>>
>> I can't limit the traffic on the Eth interface egress because traffic
>> can go to either eth interface.
>>
>> Any thoughts?
>> _______________________________________________
>> cisco-nsp mailing list [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
------------------------------
Message: 5
Date: Fri, 10 Sep 2010 20:33:30 +0100
From: Heath Jones <[email protected]>
To: Jay Nakamura <[email protected]>
Cc: cisco-nsp <[email protected]>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Correct. If someone wants their pr0n, they will get it either way :)
I actually meant a new T1 dedicated for voip..
On 10 September 2010 20:17, Jay Nakamura <[email protected]> wrote:
> Well, I don't think another T1 will solve the problem. Someone
> watching Hulu or something will just suck the bandwidth down. I think
> what I am hearing is, I just need to suck it up and rate limit
> non-VoIP traffic to 1.2mbps or something on ingress and hope that's
> enough head room for VoIP to get through while TCP traffic slows down
> from the rate-limit. Of course, if all other traffic is UDP, it may
> not do any good.
>
> On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones <[email protected]> wrote:
> > Jay I know it might sound ridiculously obvious, but is another T1 out of
> the
> > question?
> >
> > On 10 September 2010 19:44, Jay Nakamura <[email protected]> wrote:
> >>
> >> I can't seem to figure out what to do with my situation, wondering if
> >> anyone had encountered this.
> >>
> >> Situation :
> >> Router : 1841 IOS 12.4T or 15.0M
> >> Internet T1, two eth Interfaces
> >> There are VoIP traffic (SIP & RTP) and general internet traffic
> >>
> >> VoIP provider does not tag SIP/RTP with any kind of QoS in IP header.
> >> (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP
> >> traffic is not marked, it's not useful.
> >>
> >> Problem to solve : how to not drop >ingress< VoIP traffic when
> >> internet traffic is high as much as possible without capping the
> >> non-VoIP traffic to less than T1 bandwidth.
> >>
> >> Caveat : I understand that since it's not getting policed at the
> >> egress from the provider, any solution is not going to be perfect
> >>
> >> I can't limit the traffic on the Eth interface egress because traffic
> >> can go to either eth interface.
> >>
> >> Any thoughts?
> >> _______________________________________________
> >> cisco-nsp mailing list [email protected]
> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
>
------------------------------
Message: 6
Date: Fri, 10 Sep 2010 14:55:04 -0400
From: Eric Van Tol <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [c-nsp] REP support on 7600
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: [email protected] [mailto:cisco-nsp-
> [email protected]] On Behalf Of Jason Lixfeld
> Sent: Monday, September 06, 2010 9:05 AM
> To: Danijel
> Cc: [email protected]
> Subject: Re: [c-nsp] REP support on 7600
>
> I can't comment on pricing, but I've been testing a 36/3800 demo unit and if
> you can wait, this box will be the ultimate PE. We're going to build an
> entirely L3 network using these boxes and provide L2 services to customers
> over MPLS. No more L2 anywhere. Yippee!
>
Can they act as LSRs or are they LER functional only?
-evt
------------------------------
Message: 7
Date: Fri, 10 Sep 2010 21:10:54 +0100
From: Nick Hilliard <[email protected]>
To: [email protected]
Subject: Re: [c-nsp] ASIC to switch port mapping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 10/09/2010 18:40, Vincent Aniello wrote:
> Unless there is only a single ASIC in a 3560E switch I do not believe
> this command returns the ASICs associated with each port. Here is the
> output on my switch:
oh, 3650. hmmm.
Unfortunately, these switches have very small buffers indeed. If you
microburst above what their buffers can handle, then yes - you will drop
packets.
I'd suggest that you check your outbound port usage. If there are any
ports which are consistently or inconsistently high, or if you're seeing
any ports with buffer drops, that you upgrade those connections.
Alternatively, get a switch with larger per-port buffers.
Nick
------------------------------
Message: 8
Date: Fri, 10 Sep 2010 17:34:00 -0400
From: Keegan Holley <[email protected]>
To: Heath Jones <[email protected]>
Cc: cisco-nsp <[email protected]>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Ingress QOS may not help here even if it was supported on T1's. By the time
your router is able to police the traffic it will have already been sent
from the provider's edge router. Even if you could prioritize the VOIP
traffic at your router it would have already been delayed in the egress
queues of the last hop provider router. I would suggest separating the
internet traffic onto a different circuit. A T1 seem a bit limited anyway.
If your site is truly that small you may get more value out of a service
like FIOS or business DSL.
On Fri, Sep 10, 2010 at 3:33 PM, Heath Jones <[email protected]> wrote:
> Correct. If someone wants their pr0n, they will get it either way :)
> I actually meant a new T1 dedicated for voip..
>
>
>
>
>
> On 10 September 2010 20:17, Jay Nakamura <[email protected]> wrote:
>
> > Well, I don't think another T1 will solve the problem. Someone
> > watching Hulu or something will just suck the bandwidth down. I think
> > what I am hearing is, I just need to suck it up and rate limit
> > non-VoIP traffic to 1.2mbps or something on ingress and hope that's
> > enough head room for VoIP to get through while TCP traffic slows down
> > from the rate-limit. Of course, if all other traffic is UDP, it may
> > not do any good.
> >
> > On Fri, Sep 10, 2010 at 3:14 PM, Heath Jones <[email protected]> wrote:
> > > Jay I know it might sound ridiculously obvious, but is another T1 out
> of
> > the
> > > question?
> > >
> > > On 10 September 2010 19:44, Jay Nakamura <[email protected]> wrote:
> > >>
> > >> I can't seem to figure out what to do with my situation, wondering if
> > >> anyone had encountered this.
> > >>
> > >> Situation :
> > >> Router : 1841 IOS 12.4T or 15.0M
> > >> Internet T1, two eth Interfaces
> > >> There are VoIP traffic (SIP & RTP) and general internet traffic
> > >>
> > >> VoIP provider does not tag SIP/RTP with any kind of QoS in IP header.
> > >> (DSCP/IPP) Internet provider can do QoS based on IPP but since VoIP
> > >> traffic is not marked, it's not useful.
> > >>
> > >> Problem to solve : how to not drop >ingress< VoIP traffic when
> > >> internet traffic is high as much as possible without capping the
> > >> non-VoIP traffic to less than T1 bandwidth.
> > >>
> > >> Caveat : I understand that since it's not getting policed at the
> > >> egress from the provider, any solution is not going to be perfect
> > >>
> > >> I can't limit the traffic on the Eth interface egress because traffic
> > >> can go to either eth interface.
> > >>
> > >> Any thoughts?
> > >> _______________________________________________
> > >> cisco-nsp mailing list [email protected]
> > >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> > >
> >
> _______________________________________________
> cisco-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
------------------------------
_______________________________________________
cisco-nsp mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 94, Issue 33
*****************************************
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
