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
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.
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
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
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
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
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
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
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
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
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
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:
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
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:
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
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
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
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
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
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
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
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
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
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
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
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-
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
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
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
29 matches
Mail list logo