Hi
I have Cisco-Backbone
and ALU new backbone, I want to move the customers to ALU, I’m thinking to
multi-home the switch ( MC-LAG) that our customers connected through with new
network dose the mc-lag right solution ? any recommendation .
BR
HZ
Hello Devon
My router is running out of warranty so i can't contact TAC, what do you
think about IOS upgrade ?
On Fri, Mar 15, 2013 at 11:29 PM, Devon True de...@noved.org wrote:
Ahmed,
Hello Devon,
Kindly, find below output:
#remote command switch show bootvar
BOOT variable =
On Fri, 15 Mar 2013, randal k wrote:
I love 6500s, but their Netflow sucks.
So use that 6500 towards the IX but use optical splitters towards one of
those PCs you were talking about and try to find something that'll look at
the traffic and do netflow export of it (or sFlow).
As far as I
Hi Joe,
Any thoughts on what I am seeing? I haven't seen anything like it before.
I don't know what you are seeing, but I am building a similar setup at the
moment (6500-Sup2t VSS + 5548 vPC) so I would be very interested if you find
anything. My current problem is doing VPLS on the VSS, but
HI Sander.
I will let you know if I find anything that tells me what is going on.
Thanks
Joe
On Sat, Mar 16, 2013 at 10:17 AM, Sander Steffann san...@steffann.nlwrote:
Hi Joe,
Any thoughts on what I am seeing? I haven't seen anything like it
before.
I don't know what you are seeing,
Hi Andrew,
No actually they are configured as mode on no LACP. I spoke with a CCIE
a couple of years ago and he told me that use mode on from switch to switch
and lacp from switch to server so thats what I am putting in.
Any thoughts on why the 2960's ports would turn up even with the 5010's
The port channel would be up as soon as one of the interfaces is up using
static port-channels.
Which interfaces are you using on the 2960? I know you have probably
checked, but do they stay up when you remove the cables?
You don't have any like no negotiate auto enabled on the interfaces?
What
Ahmed,
Hello Devon My router is running out of warranty so i can't contact
TAC, what do you think about IOS upgrade ?
Jared's original advice is sound and he knows his stuff. =)
We recently got hit by bug CSCtx31177, causing our Sup720-3BXLs to
reboot in our 7600 routers. We were running
Hey Andrew,
Last night we removed one of the fibers on a port-channel that was showing
up and re-inserted it. The link stayed down/down. I decided then to stop
until I had a chance to do more research and try to figure out why the
interfaces and port-channels were coming up with the other side
On 03/16/2013 03:28 PM, Joseph Hardeman wrote:
Hi Andrew,
No actually they are configured as mode on no LACP. I spoke with a CCIE
a couple of years ago and he told me that use mode on from switch to switch
FWIW I've heard that advice before - indeed, it was in the Cisco
Enterprise/Campus
Hi,
On Sat, Mar 16, 2013 at 11:28:42AM -0400, Joseph Hardeman wrote:
No actually they are configured as mode on no LACP. I spoke with a CCIE
a couple of years ago and he told me that use mode on from switch to switch
and lacp from switch to server so thats what I am putting in.
That was
Can anyone provide insight into how to defeat DNS amplification attacks?
thanks,
Mike
___
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/
That was years ago, and is not good advice today. Propably wasn't good
advice then, but that depends on how many years ago...
Agreed.LACP is the way to go, avoids all kinds of problems. Static mode
bundles fall into the same category in my mind as forcing speed/duplex on
Ethernet,
Restrict resolvers to your customer networks.
Rising tide lifts all ships. And there's a lot to secure, just like open relays
and smurf amps
Jared Mauch
On Mar 16, 2013, at 5:01 PM, harbor235 harbor...@gmail.com wrote:
Can anyone provide insight into how to defeat DNS amplification
Hi,
Can anyone provide insight into how to defeat DNS amplification attacks?
Restrict resolvers to your customer networks.
And deploy RPF
Regards,
Robert
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
It's very easy to bring down a network when configuring channel-mode on.
If we do it first on the root switch, the spanning-tree loop is already
there. Someone that wrote about this and explains some scenarios:
http://www.dasblinkenlichten.com/?p=684
channel-mode on is very bad and dangerous. I
Restrict resolvers to your customer networks.
And if you have authoritative DNSSEC zones or other zones with large answers it
might be a good idea to look at rate limiting the authoritative servers:
http://www.redbarn.org/dns/ratelimits
- Sander
On Sat, 16 Mar 2013, Robert Joosten wrote:
Hi,
Can anyone provide insight into how to defeat DNS amplification attacks?
Restrict resolvers to your customer networks.
And deploy RPF
uRPF / BCP38 is really the only solution. Even if we did close all the
open recursion DNS servers (which
Depends on whether you want to defeat being the person being attacked or
the person being tricked into being the person doing the amplification
attack.
For stopping being attacked without taking services from your upstream
provider the only thing you can do really is police DNS traffic as uRPF
Curious, how does uRPF help under this scenario? Although the source address is
spoofed, the target is stil valid destination address.
—
Laurent
On Sat, Mar 16, 2013 at 6:38 PM, David Rothera david.roth...@gmail.com
wrote:
Depends on whether you want to defeat being the person being attacked
uRPF stops your network from initiating such attacks.
Closing down your open recursive DNS servers stops you from being used /
participating in the attacks.
Other than having infinite bandwidth capacity, there's not much you can do
to defend against being attacked by a DNS amplification
yes - and it presumes your DNS servers are based on Linux and use IPTables.
http://www.cryptonizer.com/dnsamp.html
http://serverfault.com/questions/418810/public-facing-recursive-dns-servers-iptables-rules
Hi Gert,
I was thinking about it today and it was only last year that I got this
advice from the CCIE we were working with at the time. I should have
questioned his recommendation and kept using the mode auto like I had been
doing.
Joe
On Sat, Mar 16, 2013 at 2:36 PM, Gert Doering
The cisco documentation recommends static as the recovery times are supposedly
faster due to no negotiation. Not really sure if the downsides make up for that
though.
Sent from a mobile device
On 17/03/2013, at 11:31, Joseph Hardeman jwharde...@gmail.com wrote:
Hi Gert,
I was thinking
On 3/16/2013 8:34 PM, Andrew Miehs wrote:
The cisco documentation recommends static as the recovery times are
supposedly faster due to no negotiation. Not really sure if the downsides
make up for that though.
Yeah, you can screw up your network much faster that way :)
We had been doing PAgP
Using that logic you could probably also argue recovery time would be
even quicker again by disabling Spanning Tree entirely.
Funnily enough, not too many people seem to recommend completely
disabling STP to achieve that goal though.
Reuben
On 17/03/2013 11:34 AM, Andrew Miehs wrote:
The
26 matches
Mail list logo
