[c-nsp] cisco-nsp Digest, Vol 94, Issue 33

Sat Sep 11 02:47:25 EDT 2010

Sent from my BlackTorch, powered by XL

-----Original Message-----
From: cisco-nsp-request at puck.nether.net
Sender: cisco-nsp-bounces at puck.nether.net
Date: Fri, 10 Sep 2010 17:34:47 
To: <cisco-nsp at puck.nether.net>
Reply-To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 94, Issue 33

Send cisco-nsp mailing list submissions to
	cisco-nsp at puck.nether.net

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
	cisco-nsp-request at puck.nether.net

You can reach the person managing the list at
	cisco-nsp-owner at puck.nether.net

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" <Vinny_Abello at dell.com>
To: Aaron <dudepron at gmail.com>, "Hansen, Ulrich Vestergaard B. (E R WP
	EN ES 4 2)" <uvh at siemens.com>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] Recommended 1Gb SFP for ~115km?
Message-ID:
	<A47E89A512E4FF4492CA4DE10D7B7C9002BED1825E at 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:dudepron at gmail.com] 
Sent: Friday, September 10, 2010 9:52 AM
To: Hansen, Ulrich Vestergaard B. (E R WP EN ES 4 2)
Cc: Abello, Vinny; cisco-nsp at puck.nether.net
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) <uvh at siemens.com> 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: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Abello, Vinny
Sent: 4. august 2010 16:30
To: cisco-nsp at puck.nether.net
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  cisco-nsp at puck.nether.net
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 <hj1980 at gmail.com>
To: Vincent Aniello <vincent.aniello at pipelinefinancial.com>
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASIC to switch port mapping
Message-ID:
	<AANLkTik+QcqAM747vRagvUd0ndCX=Sa8gm6DxAbRYqi=@mail.gmail.com>
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 <
vincent.aniello at pipelinefinancial.com> 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:hj1980 at gmail.com]
> *Sent:* Friday, September 10, 2010 11:20 AM
>
> *To:* Vincent Aniello
> *Cc:* cisco-nsp at puck.nether.net
> *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 <
> vincent.aniello at pipelinefinancial.com> 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  cisco-nsp at puck.nether.net
> 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 <hj1980 at gmail.com>
To: Jay Nakamura <zeusdadog at gmail.com>
Cc: cisco-nsp <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
	<AANLkTim+HCw6956KHK4h9R_a=OnM7cz27FK39Ee7t3=d at mail.gmail.com>
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 <zeusdadog at gmail.com> 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  cisco-nsp at puck.nether.net
> 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 <zeusdadog at gmail.com>
To: Heath Jones <hj1980 at gmail.com>
Cc: cisco-nsp <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
	<AANLkTi=G0M=FPb7VfKGLUMBCpWom6Dhm=+E7944f8VMs at mail.gmail.com>
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 <hj1980 at gmail.com> 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 <zeusdadog at gmail.com> 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 ?cisco-nsp at puck.nether.net
>> 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 <hj1980 at gmail.com>
To: Jay Nakamura <zeusdadog at gmail.com>
Cc: cisco-nsp <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
	<AANLkTi=V86S=to1456fOxDgM77Obo6_5ZRLDnLXXEOrj at mail.gmail.com>
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 <zeusdadog at gmail.com> 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 <hj1980 at gmail.com> 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 <zeusdadog at gmail.com> 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  cisco-nsp at puck.nether.net
> >> 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 <eric at atlantech.net>
To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] REP support on 7600
Message-ID:
	<2C05E949E19A9146AF7BDF9D44085B863C6E366DAA at exchange.aoihq.local>
Content-Type: text/plain; charset="us-ascii"

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Jason Lixfeld
> Sent: Monday, September 06, 2010 9:05 AM
> To: Danijel
> Cc: cisco-nsp at puck.nether.net
> 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 <nick at foobar.org>
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASIC to switch port mapping
Message-ID: <4C8A90CE.3090000 at foobar.org>
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 <keegan.holley at sungard.com>
To: Heath Jones <hj1980 at gmail.com>
Cc: cisco-nsp <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] QoS on ingress
Message-ID:
	<AANLkTi=J-SSRLvg8TYDYbgPW0ou5-L5k-PoGLU7XTMxZ at mail.gmail.com>
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 <hj1980 at gmail.com> 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 <zeusdadog at gmail.com> 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 <hj1980 at gmail.com> 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 <zeusdadog at gmail.com> 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  cisco-nsp at puck.nether.net
> > >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> > >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> > >
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>

------------------------------

_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp

End of cisco-nsp Digest, Vol 94, Issue 33
*****************************************