Yes there are still clients using radius acquired QOS.
I'll see what I can do based on your suggestions as this will be really service
affecting
What bothers me is that, I can apply this new policy to other sub-interface
with no problem at all.
I'll update on results.
thanks
Can nfdump/nfsen show useage per AS number as I cannot see anything on their
site?
Nick
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dobbins, Roland
Sent: 18 January 2012 06:14
To: Cisco NSP
Subject: Re: [c-nsp] Flow
On 18/01/12 10:38, Nick Ryce wrote:
Can nfdump/nfsen show useage per AS number as I cannot see anything on their
site?
I don't know if it's in earlier versions, but the latest version of
nfdump has aggregation / summary by asnum, e.g.
nfdump ... -a -A srcas,dstas
...or:
nfdump ... -s
On 18/01/2012 11:21, Phil Mayers wrote:
On 18/01/12 10:38, Nick Ryce wrote:
Can nfdump/nfsen show useage per AS number as I cannot see anything on
their site?
I don't know if it's in earlier versions, but the latest version of nfdump
has aggregation / summary by asnum, e.g.
nfdump ... -a
On 18/01/12 11:23, Nick Hilliard wrote:
On 18/01/2012 11:21, Phil Mayers wrote:
On 18/01/12 10:38, Nick Ryce wrote:
Can nfdump/nfsen show useage per AS number as I cannot see anything on
their site?
I don't know if it's in earlier versions, but the latest version of nfdump
has aggregation /
On 18/01/2012 11:25, Phil Mayers wrote:
Sure. In particular, I note that on the 6500/sup720 platform, src/dst AS in
the netflow requires lookup (and export) by the supervisor CPU; distributed
NDE i.e. done by the linecard CPU will not be available.
... and also if you decide to change from
Hi,
On Wed, Jan 18, 2012 at 11:27:57AM +, Nick Hilliard wrote:
... and also if you decide to change from origin-as to peer-as or
vice-versa on a sup720, you should expect the sup720's CPU to be trashed
for a couple of minutes.
Ouch. What is it doing there? Sounds like it has some sort
On 18/01/2012 12:14, Gert Doering wrote:
Ouch. What is it doing there? Sounds like it has some sort of lookup
cache to get the AS number, and needs to rebuild that...
I suspect so.
Some nice addition to netflow would be to have origin *and* peer AS,
just btw... depending on which link I'm
Nick,
Yes it can as long as the netflow data it receives has AS info in it.
nfdump can filter based on AS from its data stores, and nfsen is just
a graphing program/wrapper interface around nfdump so it can display
graphs of anything nfdump can filter with basically.
Patrick
Wed, Jan 18, 2012
On Wed, 18 Jan 2012, Dobbins, Roland wrote:
On Jan 17, 2012, at 11:23 PM, John Brown wrote:
6506-E Sup720-3BXL.
The NetFlow you get from this box won't be operationally useful - many caveats.
Strongly suggest a move to Sup2T and DFC4 (where applicable), if you want good
NetFlow from
On Jan 18, 2012, at 7:56 AM, Jon Lewis wrote:
Sampled netflow is certainly more operationally useful than no netflow.
Concur, and this is what the majority of network operators use.
Unfortunately, pre-Sup2T 6500s can't really do sampled NetFlow. Instead, in
any kind of environment with
On Wed, 2012-01-18 at 07:56 -0500, Jon Lewis wrote:
On Wed, 18 Jan 2012, Dobbins, Roland wrote:
On Jan 17, 2012, at 11:23 PM, John Brown wrote:
6506-E Sup720-3BXL.
The NetFlow you get from this box won't be operationally useful -
many caveats. Strongly suggest a move to Sup2T and DFC4
Just for the record, I'v checked this (cause I do have distributed NDE and use origin-as info), and
I can see origin AS in my flow data from 10G card with DFC. For example, 2 netflow packets with
SrcAS/DstAS (wireshark capture, unimportant omitted, IP/AS replaced):
- Packet 1 (from 10G module
On Wed, 2012-01-18 at 13:10 +, Dobbins, Roland wrote:
One can check one's 6500s in order to see if table insertion errors
are occurring, and I recommend doing so for anyone who's running
pre-Sup2T 6500s.
And for posterity: Check this with e.g. show mls netflow
table-contention detailed,
Hi,
On Wed, Jan 18, 2012 at 02:11:58PM +0100, Peter Rathlev wrote:
The Sup2T is practically the same price as the Sup720-10G, so there are
few reasons not to buy it for new deployments.
Availability of used Sup720-10G for much less money :-)
And, just maybe, non-compatibility of Sup2T with
On Tue, Jan 17, 2012 at 11:18 PM, Peter Rathlev pe...@rathlev.dk wrote:
On Tue, 2012-01-17 at 20:50 +0200, Nikolay Abromov wrote:
I haven't read what the rest of the guys suggested about this topic
but this is pretty easy.
A bit ironic...
I read your question and answered. I don't see
On 18/01/2012 13:28, Gert Doering wrote:
And, just maybe, non-compatibility of Sup2T with your existing stock
of line cards. Like, all bus-based cards, and everything with a DFC
on it.
Gert, hardware upgrades need to happen; otherwise we would all be stuck
using bus interfaces designed in
On Wed, 2012-01-18 at 16:05 +0200, Nikolay Abromov wrote:
On Tue, Jan 17, 2012 at 11:18 PM, Peter Rathlev pe...@rathlev.dk
wrote:
On Tue, 2012-01-17 at 20:50 +0200, Nikolay Abromov wrote:
I haven't read what the rest of the guys suggested about this
topic but this is pretty easy.
A
On Wed, 2012-01-18 at 14:28 +0100, Gert Doering wrote:
On Wed, Jan 18, 2012 at 02:11:58PM +0100, Peter Rathlev wrote:
The Sup2T is practically the same price as the Sup720-10G, so there are
few reasons not to buy it for new deployments.
...
And, just maybe, non-compatibility of Sup2T with
On 18/01/12 14:26, Peter Rathlev wrote:
My own experience is that there is no easy way of detecting a real
configuration change. You can only compare two copies of the
configuration, and since some things (e.g. ntp clock-period and
timestamps) change more or less by themselves, you cannot even
On 18/01/12 14:07, Nick Hilliard wrote:
Gert, hardware upgrades need to happen; otherwise we would all be stuck
using bus interfaces designed in the early 1990s. Nobody likes paying for
upgrades, but Cisco's 67xx line cards have been properly supported since
2003 - 9 years ago. If you bought
On Wed, Jan 18, 2012 at 4:26 PM, Peter Rathlev pe...@rathlev.dk wrote:
On Wed, 2012-01-18 at 16:05 +0200, Nikolay Abromov wrote:
On Tue, Jan 17, 2012 at 11:18 PM, Peter Rathlev pe...@rathlev.dk
wrote:
On Tue, 2012-01-17 at 20:50 +0200, Nikolay Abromov wrote:
I haven't read what the rest of
This might not be possible but seems like it should be somehow. I am trying to
find a way to terminate multiple inner vlan's in a single outer vlan into the
same bridge domain. The intent is to terminate DSL subscribers that come in via
ATM OC3 and then go through an Adtran DSLAM where each
Hi,
On Wed, Jan 18, 2012 at 02:07:51PM +, Nick Hilliard wrote:
On 18/01/2012 13:28, Gert Doering wrote:
And, just maybe, non-compatibility of Sup2T with your existing stock
of line cards. Like, all bus-based cards, and everything with a DFC
on it.
Gert, hardware upgrades need to
Running into this on a 3560X IP Services (context is accepted by everything
else...)
Grote-Uplink(config-ext-nacl)#85 permit tcp any any eq 9100 log
% Ambiguous command: 85 permit tcp any any eq 9100 log
Grote-Uplink(config-ext-nacl)#85 permit tcp any any eq 9100 log ! log
% Ambiguous
On Wed, 2012-01-18 at 16:37 +0200, Nikolay Abromov wrote:
On Wed, Jan 18, 2012 at 4:26 PM, Peter Rathlev pe...@rathlev.dk wrote:
My own experience is that there is no easy way of detecting a real
configuration change. You can only compare two copies of the
configuration, and since some
Hi,
Second: I'm curious if people are seeing prices that make sense for
the DFC4 upgrade parts for 67xx linecards. They were about 50% more than
the equivalent DFC3 parts. When we costed out the upgrade of our main
core routers to sup2T, the DFC parts made it quite pricey, and pushed us
So no more PFC falling back to a mode that is common to all the DFCs?
Chuck
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering
Sent: Wednesday, January 18, 2012 10:05 AM
To: Nick Hilliard
Cc: Gert Doering; Jon
On 18/01/2012 15:54, Chuck Church wrote:
So no more PFC falling back to a mode that is common to all the DFCs?
er, yes, if you mix XL and non-XL, you'll fall back to the lowest common
denominator.
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/qa_c67-649419.html#wp994
Hi,
I'm finding it slightly ironing that the subject of this email is about
netflow...and yet people are dissing the Sup2T - the Sup2T is a netflow beast!
:-)
I'm just suprised that they took the opportunity to ditch the old PFC/DFC mixing
but kept the old inter-module communication link...
There is a feature configured with parser config cache interface, that
caches interface configuration. On a Cat6k5 w/ Sup720 it reduces time to
generate running config from 7 to ~1 sec (YMMV).
Beware of the bug CSCtd93384!
Martin
On 1/18/2012 4:31 PM, Peter Rathlev wrote:
And the fact that
Oh, maybe I was thinking of 3A vs. 3B. Those would play together sort of.
Not sure about 3C.
Chuck
-Original Message-
From: Nick Hilliard [mailto:n...@foobar.org]
Sent: Wednesday, January 18, 2012 11:03 AM
To: Chuck Church
Cc: 'Gert Doering'; 'Jon Lewis'; 'Cisco NSP'
Subject: Re:
On 18/01/12 16:12, Chuck Church wrote:
Oh, maybe I was thinking of 3A vs. 3B. Those would play together sort of.
Not sure about 3C.
You can mix 3B and 3C.
You can't mix 3 and 4.
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco Digital Media Manager Privilege Escalation Vulnerability
Advisory ID: cisco-sa-20120118-dmm
Revision 1.0
For Public Release 2012 January 18 16:00 UTC (GMT)
+-
Summary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IP Video Phone E20 Default Root Account
Advisory ID: cisco-sa-20120118-te
Revision 1.0
For Public Release 2012 January 18 16:00 UTC (GMT)
+-
Summary
===
Cisco
On Jan 18, 2012, at 10:54 AM, Chuck Church wrote:
So no more PFC falling back to a mode that is common to all the DFCs?
I seem to recall you can still use CFC with SUP2T
- Jared
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
___
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/
The 6708 non-upgradability was a decision by Cisco.
They could have created an appropriate DFC but chose not to do so.
The DFC is replaceable but most people don't since the only options are
XL/non-XL and it seems most production was XL.
The fact that the DFC is not compatible with the other 67xx
On Wed, 2012-01-18 at 17:10 +0100, Martin Komoň wrote:
There is a feature configured with parser config cache interface,
that caches interface configuration. On a Cat6k5 w/ Sup720 it reduces
time to generate running config from 7 to ~1 sec (YMMV).
Beware of the bug CSCtd93384!
Nice, that
Hi,
On 19 January 2012 03:29, Dave Weis djw...@internetsolver.com wrote:
This might not be possible but seems like it should be somehow. I am trying
to find a way to terminate multiple inner vlan's in a single outer vlan into
the same bridge domain. The intent is to terminate DSL
Hrmm... looks like this release is attempting to take multiple services:
Grote-Uplink(config-ext-nacl)#101 permit tcp any host 192.168.128.74 eq smtp
syslog ftp
That was *accepted*. So a trailing log on a tcp permit is ambiguous with
login
(rlogin/513), and it's impossible to make it
Nice. What if you enter 'log' twice? Wondering if you can do something
like this:
Grote-Uplink(config-ext-nacl)#100 deny tcp any host 192.168.128.74 eq log
Grote-Uplink(config-ext-nacl)#101 permit tcp any host 192.168.128.74 eq
smtp syslog log log
Corny, but if they're going to botch up a
On Wed, 18 Jan 2012, Nick Ryce wrote:
Can nfdump/nfsen show useage per AS number as I cannot see anything on
their site?
You can also set up graphs for traffic to/from specific ASNs of interest.
I do this for several ASNs of interest in my environment.
jms
On Wed, 18 Jan 2012, Nick Hilliard wrote:
On 18/01/2012 11:25, Phil Mayers wrote:
Sure. In particular, I note that on the 6500/sup720 platform, src/dst AS in
the netflow requires lookup (and export) by the supervisor CPU; distributed
NDE i.e. done by the linecard CPU will not be available.
On 19 January 2012 03:29, Dave Weis djw...@internetsolver.com wrote:
This might not be possible but seems like it should be somehow. I am trying
to find a way to terminate multiple inner vlan's in a single outer vlan into
the same bridge domain. The intent is to terminate DSL subscribers
Dave,
We do the following on 7200 for PPPoE to terminate any inner VLAN below a
specific outer VLAN. I can't help but wonder if it would work fine with
a bridge-group too if that is what you need? The command seems to be
accepted fine on the interface.
interface gi 0/0.outerVLAN
Hi,
On 19 January 2012 12:43, Dave Weis djw...@internetsolver.com wrote:
{cut}
I'm not entirely sure if I understand you correctly, but if you strip
the inner vlan on the ingress how would you know what inner vlan to
assign to all egress packets that should go towards that internal tag
of 54?
What's the trick for getting a current MIB from Cisco?
I opened service request 619684675 last Nov. asking for the current
CISCO-FEATURE-CONTROL-MIB.my since an snmpwalk of
cfcFeatureCtrlOpStatus on a nexus 4000 returned a lot of OIDs instead
of feature names. A bit more than 2 months later and
On Wed, 18 Jan 2012, Lee wrote:
What's the trick for getting a current MIB from Cisco?
Is this a case of not being to find the right/most up-to-date MIB file, or
is this a case of the right/most up-to-date MIB file not matching the
version of code you're running?
I normally download what
Nope, it's still ambiguous.
Grote-Uplink(config-ext-nacl)#$st 192.168.128.74 eq www smtp log log ?
% Ambiguous command: 101 permit tcp any host 192.168.128.74 eq www
smtp log log
The scary part of this is that simply updating your IOS removes some
of your ACL lines (when startup-config is
Wow. I think you can include precedence between the ports and the log. Can
you put that in to maybe match all precedences? Otherwise, I think I'd hold
off on this release, sounds like it needs a good deferral.
Chuck
-Original Message-
From: Jeff Kell [mailto:jeff-k...@utc.edu]
Sent:
On 1/19/12, Lee ler...@gmail.com wrote:
What's the trick for getting a current MIB from Cisco?
I opened service request 619684675 last Nov. asking for the current
CISCO-FEATURE-CONTROL-MIB.my since an snmpwalk of
cfcFeatureCtrlOpStatus on a nexus 4000 returned a lot of OIDs instead
of
Hi Guys,
We have a current network comprising of 6 POPs, each with 3750/3560's and
7200's - The 3560/3750's take trunk links from various carriers, and client
tails are handed off to us as vlans. The 3560/3750's then have a portchan to
the 7200's where all our L3 is done(As dot1q subints)
On Thu, 19 Jan 2012, John Elliot wrote:
Having never touched the 6500 range, is this a viable(better?)
alternative to simply replacing the 7200's with ASR's?
Depends on what you want to do. If you just want to forward the packets
then 6500/7600 is a good deal, if you want to do something
Greetings all,
I am currently investigating the ASR9K as replacement Ethernet aggregation
hardware. Does anyone have a good link that contrasts the QOS capabilities of
the different line cards (Low, Medium, High)? I've been reading the Config
Guide on ASR9K QOS, but so far I haven't seen
Thanks Mikael
Depends on what you want to do. If you just want to forward the packets
then 6500/7600 is a good deal, if you want to do something intelligent
with them (shape them, QoS etc), then it starts to make less sense
(because the LCs to do this are expensive).
We do some
Hi,
Looking for a list with linecards which do support mac-sec.
I am particularly interessted in WS-X6824-SFP-2T
My setup:
6506-E with Sup-2T
many thanks,
keti
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
57 matches
Mail list logo
