Hi Aron
i guess you can simply use this:
Router(config)#login block-for {seconds} attempts {tries} within {seconds}
Router(config)#login on-failure log
Router(config)#login on-success log
This will generate logging messages for every failed and successful login
hope that helps
cheers,
Nad
On
ip ssh logging events works well for ssh.
Success
000962: Mar 5 2008 21:09:14.376 NZDT: %SSH-5-SSH2_USERAUTH: User 'user'
authentication for SSH2 Session from 192.168.111.10 (tty = 0) using
crypto cipher 'aes256-cbc', hmac 'hmac-sha1' Succeeded
000963: Mar 5 2008 21:11:06.755 NZDT:
hey,
Is there an easy way to log remote access login attempts on the cisco kit?
I see there is a way to enable configuration change logs but I don't see an
option to log accepted logins / failed logins etc.
login (on-failure|on-success) log with recent enough (12.2S, 12.4T) software
--
At 09:14 PM 05-03-08 +1300, Ivan wrote:
Not for all trains:
petach-tikva-gp#conf t
Enter configuration commands, one per line. End with CNTL/Z.
petach-tikva-gp(config)#ip ssh ?
authentication-retries Specify number of authentication retries
source-interfaceSpecify interface for
Dimitry,
The asr has support for traditional netflow as well as nf v9 exports. If it is
missing from the datasheet it is an oversight as the asr has very good scale
support for nf.
--Aamer
-Original Message-
From: Dmitry Kiselev [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04,
RPF on the edge?
On Wed, 2008-03-05 at 18:32 +1100, Whisper wrote:
Which is the prefered method for blocking bogons on the Internet why? Is
the prefered solution sometimes hardware specific?
Something like this:
ip route 10.0.0.0 255.0.0.0 Null0
ip route 127.0.0.0 255.0.0.0 Null0
ip
Thanks Roy
That is sort of part of the question.
In what circumstances would 1 method be prefered over the other, if at all?
On Wed, Mar 5, 2008 at 8:51 PM, roy [EMAIL PROTECTED] wrote:
RPF on the edge?
On Wed, 2008-03-05 at 18:32 +1100, Whisper wrote:
Which is the prefered method for
The ISP I work for is using several 10k's. We had some (rather silly)
bugs initially but they seem to be fully ironed out now and the boxes
are cruising along quite nicely now (to the best of my knowledge - I
certainly havnt seen any internal notices about outages for quite some
time).
Thanks guys,
I shall give it a go tomorrow.
Cheers,
Aaron.
-Original Message-
From: shadow floating [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2008 5:29 PM
To: Arie Vayner (avayner)
Cc: Aaron R; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Logging remote access logins
Hi
Hi,
On Wed, 2008-03-05 at 20:58 +1100, Whisper wrote:
In what circumstances would 1 method be prefered over the other, if at
all?
IIRC, ip route bogon/net null0 will filter on near line-rate based on
destination addresses.
rpf (strict/loose) on the other hand will accomplish a somewhat
Ian MacKinnon wrote:
Hi All,
Any idea how much ipsec performance you might expect out of a Sup32
without the Ipsec module?
Can't see figures anywhere obvious.
Ta
I have just found the answer from the nsp archives.
The answer is zero :-)
--
This email and any files transmitted with it
I was the one who asked it ;)
10k will get PRE-4 and SIP/SPA (+10GE) support soon. Better late, than never
--
Tassos
Justin Shore wrote on 5/3/2008 5:59 πμ:
Rubens Kuhl Jr. wrote:
I see no netflow word in the ASR 1000 RP datasheet... :(
It is mean no hardware support available or just
Hi All,
Any idea how much ipsec performance you might expect out of a Sup32
without the Ipsec module?
Can't see figures anywhere obvious.
Ta
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are
We also use some AS5350 (in replacement of broken AS5300) and we're happy until
now.
Only time will tell, if they can last for the years to come.
--
Tassos
Mark Holloway wrote on 4/3/2008 5:21 μμ:
They must have improved the AS5400. I have several in production for SIP to
PRI that are solid
Perhaps this is a naïve question, as I'm in the same boat as Jimmy, but
should I put my 2 backbones on my RSP720s instead, one backbone on each of
them, to avoid the problem? Will the GigE ports on each of the RSP720s be
in a working state, or only the active sup?
Frank
-Original
On Mon, Mar 3, 2008 at 10:04 AM, Jimmy [EMAIL PROTECTED] wrote:
Anyone having the same issue? Any better solution?
On 6506 sup720 we use switch mode interfaces with mls qos vlan-based enabled
and
service-policy input policy-in
service-policy output policy-out
on SVI.
Policies like:
On Wed, Mar 5, 2008 at 8:32 AM, Whisper [EMAIL PROTECTED] wrote:
Which is the prefered method for blocking bogons on the Internet why?
It depends what you wanna do.
ip route 10.0.0.0 255.0.0.0 Null0
ip route 127.0.0.0 255.0.0.0 Null0
ip route 169.254.0.0 255.255.0.0 Null0
ip route
roy wrote:
IIRC, ip route bogon/net null0 will filter on near line-rate based on
destination addresses.
rpf (strict/loose) on the other hand will accomplish a somewhat similar
solution as with your acl to filter packets based on source addresses
consuming less resources (assuming you have
On Wednesday 05 March 2008, Saku Ytti wrote:
Looks you indeed have tiny fraction in PXF, guess you're not running
12.2S family, where I believe PXF is not supported at all in
this platform.
Nope, running 12.4.
--
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1
Does loose rpf indeed drop packets sourced from null routes? I know
strict does for certain, and is the least intensive method of blocking
packets sourced from a particular IP/subnet.
Yes, it does. And it works pretty well.
___
cisco-nsp mailing
Thanks to everyone for all the responses (public and private).
They were all illuminating :)
~JasonG
--
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
Hey all,
Is there any advantage to moving your more heavily-used ACL entries
to the top of the ACL anymore, or is that a thing of the past? I
thought CEF and compiled ACLs replaced that long ago, but figured I'd
ask. It's on a CPU based router, running 12.4. Lots of ACLs for
inbound
Not 100% Cisco related, but supported by Cisco technology ultimately.
We
have the need to consistently share large files (250MB - 5GB) across
many
sites and geographies, and securely. FTP is commonly used, but do
other
companies utilize different technologies to support this need -
On Wed, 5 Mar 2008, Church, Charles wrote:
Is there any advantage to moving your more heavily-used ACL entries
to the top of the ACL anymore, or is that a thing of the past? I
thought CEF and compiled ACLs replaced that long ago, but figured I'd
ask. It's on a CPU based router, running
Not 100% Cisco related, but supported by Cisco technology ultimately. We
have the need to consistently share large files (250MB - 5GB) across many
sites and geographies, and securely. FTP is commonly used, but do other
companies utilize different technologies to support this need - yousendit,
SCP
On Wed, 5 Mar 2008, Mike wrote:
Not 100% Cisco related, but supported by Cisco technology ultimately. We
have the need to consistently share large files (250MB - 5GB) across many
sites and geographies, and securely. FTP is commonly used, but do other
companies utilize different technologies
Not 100% Cisco related, but supported by Cisco technology
ultimately. We
have the need to consistently share large files (250MB - 5GB)
across many
sites and geographies, and securely. FTP is commonly used,
but do other
companies utilize different technologies to support this need
-
I'd also mention 50% of the transfers are public - to/from client networks.
Thanks so far.
On Wed, Mar 5, 2008 at 7:24 AM, Jonty Bale [EMAIL PROTECTED] wrote:
Not 100% Cisco related, but supported by Cisco technology
ultimately. We
have the need to consistently share large files (250MB -
You might want to check out Cisco WAAS. We have a couple customers using
AutoCad and moving large files across T1 based WANs that are using this
technology with great success.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike
Sent: Wednesday, March
On Wed, Mar 5, 2008 at 8:32 AM, Whisper [EMAIL PROTECTED] wrote:
Which is the prefered method for blocking bogons on the Internet why?
It depends what you wanna do.
ip route 10.0.0.0 255.0.0.0 Null0
ip route 127.0.0.0 255.0.0.0 Null0
ip route 169.254.0.0 255.255.0.0 Null0
ip route
In the case of public transfers, WAAS would not work. WAN control sites though
would be great.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Louis
Sent: Wednesday, March 05, 2008 10:26 AM
To: Mike; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp]
On Wed, 5 Mar 2008, Giles Coochey wrote:
Not 100% Cisco related, but supported by Cisco technology ultimately.
We
have the need to consistently share large files (250MB - 5GB) across
many
sites and geographies, and securely. FTP is commonly used, but do
It depends. I'm experimenting with
You could use also https with some kind of authentication (you can even
integrate something like SecurID) and of course you may use PGP encrypted
files.
WebDAV would be a candidate also...
John
On Wed, 5 Mar 2008, Mike wrote:
Not 100% Cisco related, but supported by Cisco technology
Justin M. Streiner wrote:
On Wed, 5 Mar 2008, Mike wrote:
Not 100% Cisco related, but supported by Cisco technology ultimately. We
have the need to consistently share large files (250MB - 5GB) across many
sites and geographies, and securely. FTP is commonly used, but do other
companies
The problem exists as long as there are multiple
active forwarding engines in the box, even if you use the uplinks on the sup.
Tim
(BTW, the uplinks on the RSP are active on both sups).
At 06:51 AM 3/5/2008 -0600, Frank Bulk - iNAME observed:
Perhaps this is a naïve question, as I'm in the
Hello,
Anyone who know where to buy a power supply for a 2960G?
I got one which just caught fire!!
/Johnny
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
R
M
A
--
Regards,
Jason Plank
CCIE #16560
e: [EMAIL PROTECTED]
-- Original message --
From: Jonas [EMAIL PROTECTED]
Hello,
Anyone who know where to buy a power supply for a 2960G?
I got one which just caught fire!!
/Johnny
pictures!
On Wed, 5 Mar 2008, Jonas wrote:
Hello,
Anyone who know where to buy a power supply for a 2960G?
I got one which just caught fire!!
/Johnny
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
[EMAIL PROTECTED] wrote:
R
M
A
--
Regards,
Jason Plank
CCIE #16560
e: [EMAIL PROTECTED]
-- Original message --
From: Jonas [EMAIL PROTECTED]
Hello,
Anyone who know where to buy a power supply for a 2960G?
I got one which just caught fire!!
Hello,
I am in the process of configuring QOS for our video system.
Currently I'm having trouble configuring our 2960's with srr queuing.
I have not yet tackled the 3560's.
Here is the config I'm working with, there are more 3560's and 2960's,
but this should give an idea on how I have
I'm pretty certain you will not get output on this information based on the
qos works on these devices, specifically the 3560/3750. The best way to
check this stuff out from what I've seen on the CLI is show mls qos
interface x/y statistics. This will give you an idea of the DSCP values
coming
Will you be using video in the priority queue in this configuration?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Griffin
Sent: Wednesday, March 05, 2008 5:46 PM
To: Dan Letkeman
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] QOS Configuration
On Wed, Mar 5, 2008 at 4:42 PM, [EMAIL PROTECTED] wrote:
Hi,
I am in the process of configuring QOS for our video system.
Currently I'm having trouble configuring our 2960's with srr queuing.
I have not yet tackled the 3560's.
Here is the config I'm working with, there are more
dscp: incoming
---
0 - 4 : 184155000 385
5 - 9 : 0 82000
10 - 14 : 00000
15 - 19 : 0
Mike,
Yes I do have the global mls qos command enabled. This is the default
configuration:
mls qos map cos-dscp 0 8 16 26 32 46 48 56
mls qos srr-queue input bandwidth 90 10
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66
mls qos srr-queue input buffers 67 33
Also, native vlan will not have a cos value on the trunk link. You will have to
trust DSCP on that link to have it match the dscp setting from the downstream
switch since native is passed w/o dot1q header
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ok, that would explain some of my problems. But my main question is
why won't the 2960 get a match on the ACL? I even changed the ACL to
permit ip any any and it still didn't get a match. Without that acl
getting a match nothing will work.
On Wed, Mar 5, 2008 at 4:59 PM, Mike Louis [EMAIL
Dan Letkeman wrote:
On Wed, Mar 5, 2008 at 4:42 PM, [EMAIL PROTECTED] wrote:
switchport nonegotiate - so link cant become a trunk with malicious
endpoint, spanning-tree portfast, (its not a trunk)
This is OT for this discussion but nonegotiate doesn't actually prevent
a trunk from
I'm going to recommend rsync mainly for it's resume of transfer
ability over scp(given your files sound large), you can tunnel it via
ssh using a flag like --rsh=ssh or similar for security, it would
depend on your OS, on top of that to make it even smoother you could
use pre-shared keys
Well that depends, if your doing the trust dscp on the port facing the video
server, as well as your interconnects and your video application is tagging
dscp values appropriately, then you don't need an acl for classification as
it's already classified by the application itself. It's not that the
On 06/03/2008, at 9:59 AM, Justin Shore wrote:
No-negotiate - Forces trunking but will not negotiate anything.
I don't think that's right, switchport nonegotiate actually just
stops DTP from being transmitted and hence can't be applied when the
switchport is in dynamic desirable mode,
Thanks Nick. That does make sense. I have a polycom vsx 6000 that is
marking the packets already. So what you are saying is I shouldn't
need to have an acl to match the traffic if the port is setup properly
because the device is tagging the traffic with the correct values. I
will try wireshark
Ben Steele wrote:
On 06/03/2008, at 9:59 AM, Justin Shore wrote:
No-negotiate - Forces trunking but will not negotiate anything.
I don't think that's right, switchport nonegotiate actually just stops
DTP from being transmitted and hence can't be applied when the
switchport is in dynamic
Mike,
Makes perfect senseand actually seems more simple than what I was
trying to do!
Thanks for the detailed explanation.
Dan.
On Wed, Mar 5, 2008 at 6:26 PM, Mike Louis [EMAIL PROTECTED] wrote:
You don't need to use the service policy input unless you are trying to
remark the traffic
Some other things to watch out for are your trunk links and port channels.
For example, on a 3750/3560 you would configure trust dscp on the physical
member interfaces not the port channel. If for example you have channels on
a 4500 you should put the trust commands on both the port channel as
Is the stripping particular to the 4500 chassis? Have you experience similar
results with the 4948 series as well?
What supervisors did you experience this with on the 4500?
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Nick Griffin [EMAIL
Which is the prefered method for blocking bogons on the Internet why? Is
the prefered solution sometimes hardware specific?
..
Up to date bogon lists can be found here:
http://www.cymru.com/Documents/bogon-list.html
A more dynamic approach would perhaps be
1) Static route some unused
Hi guys,
Recently, I experiencing a continuos %SYS-4-P2_WARN: 1/Astro - timeout error
on the C2948G switch log.
For example:
2008 Mar 05 11:07:32 UTC +00:00 %SYS-4-P2_WARN: 1/Astro(2/2) - timeout
occurred
The CPU was high as well during that time. At the end, it was found that one
of switch
58 matches
Mail list logo
