Re: [c-nsp] ibgp TTL

2009-10-15 Thread Oliver Boehmer (oboehmer)
How about explicit path TE with no autoroute announce (and only statics for these dedicated iBGP loopbacks?) well, if the only path to the destination is through the non-MPLS part of the network, there will be no TE path available. so the tunnel will go down and the statics go away, and IGP

Re: [c-nsp] IPv6 on ME3400

2009-10-15 Thread Brad Henshaw
Dale W. Carder wrote: On Oct 14, 2009, at 10:03 PM, ML wrote: I've got a customer that *needs* a 1-2 RU router that handles IPv6 in hardware. Make sure what you want to do fits in the sdm profile. Carving up tcam for ipv6 steals from other areas like mac addrs, vlans, v4 routes and such.

Re: [c-nsp] ibgp TTL

2009-10-15 Thread JC Cockburn
Hi, What about simple acl on the non-mpls interfaces blocking bgp from loopback of ibgp src - loopback of ibgp dest? Am I missing the boat completely? I know you don't want acl's on any core intf's, but if you want funny solutions you might have to do funny stuff... Cheers ;-) -Original

Re: [c-nsp] 3560 buffering

2009-10-15 Thread Mateusz Blaszczyk
On Wed, Oct 14, 2009 at 12:05:37PM +0200, Peter Rathlev wrote: It seems that all queues are actually used according to the default CoS map. I think I'm getting confused here. Can anybody shed light on this? I saw that myself and that's why I asked you. It is very confusing. The reason I

[c-nsp] QoS best practices

2009-10-15 Thread Peter Rathlev
The 3560 buffering discussion has reminded me: It's not hard to find documentation on configuring QoS, but I haven't yet found any best practices reagarding how to specifically classify, i.e. what traffic goes in what queue with what DSCP/CoS marking. For VoIP it seems there are some notes, so

Re: [c-nsp] QoS best practices

2009-10-15 Thread Alan Buxey
Hi, The 3560 buffering discussion has reminded me: It's not hard to find documentation on configuring QoS, but I haven't yet found any best practices reagarding how to specifically classify, i.e. what traffic goes in what queue with what DSCP/CoS marking. For VoIP it seems there are some

Re: [c-nsp] QoS best practices

2009-10-15 Thread Brian Turnbow
The 3560 buffering discussion has reminded me: It's not hard to find documentation on configuring QoS, but I haven't yet found any best practices reagarding how to specifically classify, i.e. what traffic goes in what queue with what DSCP/CoS marking. RFC 4594 is a good start For VoIP it

Re: [c-nsp] Cisco SCE RTM

2009-10-15 Thread Yann Gauteron
I privately answered to Khalil: Please refer to http://www.cisco.com/en/US/docs/cable/serv_exch/serv_control/broadband_app/rel350/swcfg8000/AppendixA_MIBs.html You'll read that Cisco replaced the Pcube MIBs (Pcube is the company who created the SCE 1000 and SCE 2000 and which was acquired and

Re: [c-nsp] 3560 buffering

2009-10-15 Thread Benny Amorsen
Marian Ďurkovič m...@bts.sk writes: Yes, if both hosts are connected at the same speed, no extensive buffering is needed. However, another usage scenario for such switches is speed downshift, e.g. 1Gbps uplink - 100 Mbps host (or 10 Gbps - 1 Gbps), where the relation to TCP window size does

Re: [c-nsp] ASN statistic tools

2009-10-15 Thread RAZAFINDRATSIFA Rivo Tahina
Hi Christian, I'm trying that now, will revert back later. BR. At 10:12 14/10/2009, christian wrote: take a look at: https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf On Tue, Oct 13, 2009 at 10:52 PM, RAZAFINDRATSIFA Rivo Tahina r.tah...@moov.mg wrote: Daer All, I'm looking

[c-nsp] AS5300 issue

2009-10-15 Thread RAZAFINDRATSIFA Rivo Tahina
Hi, I have trouble with an AS5300, during seconds, it is unreachable and I have this in log: Oct 15 17:21:10.876: -Traceback= 60252E7C 602F8364 60271D88 6017D884 6017F524 604C9C8C 60458438 Oct 15 17:21:10.900: ASSERTION FAILED: file ../as/if_as_pm7366_packet.c, line 746 Any one know what

Re: [c-nsp] ASN statistic tools

2009-10-15 Thread RAZAFINDRATSIFA Rivo Tahina
Hi, I tried but didn't help. BR At 11:02 14/10/2009, Gideon Popol wrote: Hello , Did you tried NetFlow Analyzer http://www.manageengine.com/products/netflow/index.html they have ASN statistics Best Regards Gideon Popol gid...@gilat.net Office: +972.3.9255039 MSN:

Re: [c-nsp] ASN statistic tools

2009-10-15 Thread RAZAFINDRATSIFA Rivo Tahina
Hi, Will try also this one. BR. At 12:26 14/10/2009, Gustaf Hyllested Serve wrote: I'm looking for utilities which allow to have ASN statistics, the netflow tools I tried doesn't do that, any idea? take a look at NetQos ReportAnalyzer -- Gustaf Hyllested Serve

Re: [c-nsp] ASN statistic tools

2009-10-15 Thread RAZAFINDRATSIFA Rivo Tahina
Hi, Thank you, I will check. BR At 20:26 14/10/2009, Paolo Lucente wrote: Hi, You can certainly have a look to the following page which captures a number of NetFlow collector packages (free and commercial) available around. I'm sure most of them are supporting ASNs:

[c-nsp] Possible interface counter bug, but wanted to check..

2009-10-15 Thread Drew Weaver
Hi, We have a Gig-E connection going from a GSR to a 6500 and the 6500 appears to be showing almost double the amount of traffic/packets per second than the GSR is showing in its interface counters (for the same connection) GSR: 30 second input rate 326816000 bits/sec, 233144 packets/sec 30

Re: [c-nsp] Possible interface counter bug, but wanted to check..

2009-10-15 Thread Drew Weaver
Ah, it looks like the SNMP counters match between the 6500 and GSR so this must be an interface counter bug, but i was under the impression that they used the same counter. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On

Re: [c-nsp] Possible interface counter bug, but wanted to check..

2009-10-15 Thread Raymond, Steven
Has anyone seen this before and know what the issue could be? The 6500 is running: 12.2(18)SXD7b I'm more inclined to believe the stats coming from the GSR, but I wanted to check with you folks and see if anyone has any experience with this particular errata. Definitely saw 2:1 counting

Re: [c-nsp] Possible interface counter bug, but wanted to check..

2009-10-15 Thread Gert Doering
Hi, On Thu, Oct 15, 2009 at 12:56:07PM -0400, Drew Weaver wrote: We have a Gig-E connection going from a GSR to a 6500 and the 6500 appears to be showing almost double the amount of traffic/packets per second than the GSR is showing in its interface counters Not that anybody has ever heard

Re: [c-nsp] ASN statistic tools

2009-10-15 Thread Charlie Allom
On Wed, Oct 14, 2009 at 12:12:45AM -0700, christian wrote: take a look at: https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf This notes: should be possible given src/dst IP address and a full BGP table to map IP address → ASN Is this something it does? I have

[c-nsp] IOS question for c12406

2009-10-15 Thread Leif Sawyer
In the process of upgrading from a c12008 to a c12406, with the following linecards: SIP-601 + SPA-10X1GE-V2 2 x PRP-2 LC-4OC3/POS-SM 4GE-SFP-LC Looks like I've got a choice between these two: c12kprp-k4p-mz.120-32.SY10.bin c12kprp-k4p-mz.120-33.S5.bin feature-set comparison

Re: [c-nsp] QoS best practices

2009-10-15 Thread Raymond Lucas
Peter, Agree with others about RFC4594 being a particularly good discussion of what different types of traffic there are and appropriate markings. For quick Cisco overviews the At a Glance documents are quite good - http://www.cisco.com/en/US/tech/tk543/tk759/tech_white_papers_list.html. Also

[c-nsp] EoMPLS issue between 3750-ME and 7600-ES card

2009-10-15 Thread samuel vuillaume
Hi guys, here's my diagram: 6500-(ES40 card) 7600--- (ES port) 3750ME(FastEthernet 1 port)--- I'm currently running a PW between the ES card and the 3750ME (FE port), and it doesn;t work due to an MTU issue: ES Card : 9000 bytes FastEthernet on 3750: 1998 bytes

Re: [c-nsp] IOS question for c12406

2009-10-15 Thread Eninja
Leif, Not sure what you're asking but GSR 12K is a distributed platform where each LC switches packets independently of the RPand whatever IOS is running on the box. Eninja On Oct 15, 2009, at 10:37 PM, Leif Sawyer lsaw...@gci.com wrote: In the process of upgrading from a c12008

Re: [c-nsp] IOS question for c12406

2009-10-15 Thread Leif Sawyer
I'm stating a that Feature Set Navigator is unstable for purposes of my research (based on the (d)CEF issue, and lack of updates) and asking for feedback about which train (SY or S) to use on my 12406, given the listed linecards. -Original Message- From: Eninja

Re: [c-nsp] IOS question for c12406

2009-10-15 Thread Eninja
GSR 12Ks only run DCEF. So any software suitable for this platform will support DCEF. Feature navigator is imperfect - like a lot of 'tools' on CCO. Eninja On Oct 16, 2009, at 2:09 AM, Leif Sawyer lsaw...@gci.com wrote: I'm stating a that Feature Set Navigator is unstable for purposes of

Re: [c-nsp] IOS question for c12406

2009-10-15 Thread Leif Sawyer
I understand this. My point is that Feature Navigator is not a worthwhile tool for investigating the differences between the trains, which is why I'm asking for feedback. Real. World. Feedback. As in people who have tested already. Does this make sense yet? -Original Message-

Re: [c-nsp] IOS question for c12406

2009-10-15 Thread Eninja
Any worthwhile real world feedback would involve folks understanding what protocols and technologies you intend to deploy rather than just a list of LCs. Eninja On Oct 16, 2009, at 2:25 AM, Leif Sawyer lsaw...@gci.com wrote: I understand this. My point is that Feature Navigator is not

[c-nsp] Shared CISCO IOS IP SLA shadow Router in QinQ envirment

2009-10-15 Thread samuel vuillaume
Hi guys, find enclosed a project i;m working on... It's just an idea and i'd like to get your thoughts! context: Shared CISCO Router ISR 2811 with IOS IP SLA running to Customer sites. Each customer is Q tunneled across VPLS. My Management Server is in the global routing table, and both

Re: [c-nsp] IOS question for c12406

2009-10-15 Thread Mikael Abrahamsson
On Thu, 15 Oct 2009, Leif Sawyer wrote: Anybody have any experience with these, recommendations, comments or caveats? 12.0(32)SY train has a huge exposure to real world, everybody is running it. 12.0(33)S hasn't got even close to that field exposure, so I'd recommend to stay away unless