On Dec 6, 2023, at 17:46, Gert Doering wrote:
I'd argue that the DNS folks recommend using EDNS0 with 1232 bytes, which
works just fine to avoid fragments...
Of course, the last true Internet flag day was in 1994, flag days aren’t
possible anymore, & this is far from universally implemented.
On Dec 6, 2023, at 04:45, Gert Doering via cisco-nsp
wrote:
deny ipv4 any any fragments
This is approach is generally contraindicated, as it tends to break EDNS0, &
DNSSEC along with it.
If the target is a broadband access network, you can use flow telemetry to
measure normal rates of
On 2 Oct 2023, at 17:10, Hank Nussbacher
mailto:h...@interall.co.il>> wrote:
cache timeout inactive 15
Kentik recommends 15s:
This is an old, out-of-date recommendation from Cisco should be retired.
5s is plenty of time for inactive flows.
___
On 2 Oct 2023, at 13:13, Hank Nussbacher via cisco-nsp
mailto:cisco-nsp@puck.nether.net>> wrote:
Does this make sense to go 1:1 which will only increase the number of Netflow
record to export? Everyone that does 1:1000 or 1:1 sampling, do you also
seen a discrepancy between Netflow
> On Jun 2, 2021, at 20:46, Drew Weaver wrote:
>
> The reason I am asking is because I've noticed that no matter what I do I
> cannot seem to "close" the BGP port by using CoPP.
iACLs can accomplish the goal, yes?
---
roland.dobb...@netscout.com
> On 15 Mar 2021, at 14:08, Bryan Holloway wrote:
>
> Care to elaborate?
Under any kind of load, it tends to send the RP up through 100%, which causes
routing adjacencies to be lost.
I tried to get this misfeature deprecated when I was at Cisco; sadly, marketing
pressure kept it in the
On Mar 14, 2021, at 14:10, h...@interall.co.il wrote:
We are trying to implement tcp intercept on some brand new ASR1009x running
IOS-XE 16.12.5 yet nothing is seen (sometimes).
TCP Intercept is a self-DoS waiting to happen. Strongly suggest not doing this.
> On 30 Jul 2020, at 18:48, Drew Weaver wrote:
>
> I'm just curious mostly but has anyone found a platform that has high enough
> sflow/netflow "resolution" that it picks up things like single pings, or
> broadcast traffic, or other very low volume traffic?
I think what you’re looking for
On 9 Feb 2019, at 3:02, Bryan Holloway wrote:
> I suspect you are right. Saku made the same suggestion off-line.
Concur that these are likely non-initial fragments. Don't just block
all non-initial fragments willy-nill, or you'll break EDNS0.
If the targeted networks are endpoint networks
On 3 Jan 2019, at 16:58, Robert Hass wrote:
> How I can check which IP is trying constantly connect via IKEv2 to my
> router ?
Use flow telemetry to look for incoming traffic directed to your router
on UDP/4500?
You could also use a classification ACL. Or if your circumstances
permit, just
On May 6, 2014, at 6:25 AM, Mack McBride mack.mcbr...@viawest.com wrote:
One other note is that the acl compiler will attempt to expand acls for range
commands provided there aren't
too many ports in the range. This can cause TCAM exhaustion rather than LOU
exhaustion.
sh fm sum has been
On May 4, 2014, at 1:26 PM, Justin M. Streiner strei...@cluebyfour.org wrote:
I remember hearing a while ago that Cisco was working on a competing
technology to flowspec, but no details were available at that time.
You're thinking of this, which they didn't implement properly, and eventually
On May 4, 2014, at 11:16 AM, vinny_abe...@dell.com wrote:
I've always allowed echo-reply in the outside interface as well as
ttl-exceeded in the access-list applied to it.
You should also allow ICMP type-3/code-4, or you're breaking PMTU-D.
On Apr 21, 2014, at 4:37 PM, Saku Ytti s...@ytti.fi wrote:
It's RP only, it's cross-platform feature. That is RP receives IP options
like it normally does, but will always drop them.
Does Sup2T/DFC4 drop options on the linecard? How about ip options ignore?
Note to OP: traceroute uses
On Apr 21, 2014, at 5:47 PM, Saku Ytti s...@ytti.fi wrote:
While some traceroute programs do support IP options, it's very rare for
people to use IP options while traceroute.
Network engineers tend to use traceroute in this manner more than most . . .
On Apr 21, 2014, at 11:26 PM, Saku Ytti s...@ytti.fi wrote:
As ACL match work, you could do it in iACL and then you're only left with own
customers attacking you.
iACLs should be applied at all edges of the network, including customer
aggregation edges, IDC distribution edges, et. al.
On Apr 22, 2014, at 1:28 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
I'm wondering if other people stop because of ACL sizes too, if you have
large numbers of interfaces in non-aggregatable ranges e.g. customer-owned
space?
This is why having a rationalized address plan is important for
On Apr 18, 2014, at 11:40 PM, Robert Williams rob...@custodiandc.com wrote:
The lab kit is running 15.1(2)SY1 in the tests shown above.
What Sup/linecards?
Are you sure your Sup/linecards support evaluating options as a classifier? If
they don't, then even though the options keyword shows
On Mar 14, 2014, at 9:10 PM, Gustav UHLANDER gustav.ulan...@steria.se wrote:
What we've done is find some other ISP in the same colo that we knew from
some common event, and just throw two cat5 cables over the wall - one has a
/29 from their IP space, one has a /29 from our IP space, and we
On Mar 10, 2014, at 2:41 AM, redscorpion69 redscorpio...@gmail.com wrote:
Filters don't allow BGP sessions to our PE router.
You might want to double-check that your iACLs are up-to-date, that you've
enabled GTSM, that you've enabled CoPP, etc.
What make/model/OS/train/revision/linecard?
On Mar 7, 2014, at 2:07 AM, redscorpion69 redscorpio...@gmail.com wrote:
How to make sure this doesn't happen again?
Are you sure the router wasn't attacked directly? Have you implemented iACLs
to keep unauthorized traffic off your routers?
Maybe the CE router isn't properly protected and
On Feb 27, 2014, at 9:50 PM, Brian Turnbow b.turn...@twt.it wrote:
There is more info here on it
Does that still apply to Sup2T/DFC4?
---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
Luck is
On Feb 27, 2014, at 9:54 PM, Dobbins, Roland rdobb...@arbor.net wrote:
Does that still apply to Sup2T/DFC4?
Another way to deal with this is to QoS down all non-76-byte UDP/123 traffic
(i.e., non-timesync traffic) to something like 1mb/sec in aggregate.
Alternatively, someone else suggested
On Feb 28, 2014, at 2:51 AM, Randy a...@djlab.com wrote:
If the primary DDOS payload is non-initial fragments (which I suspect may be
the case) it will bypass your ACL unless you match fragments, which may
impact other traffic.
Actually, with ntp, it isn't - ntp handles message
On Feb 27, 2014, at 6:41 AM, Thomas St-Pierre tstpie...@iweb.com wrote:
Normal traffic shouldn’t be affected,
It will be crowded out during an attack.
I don't know if you've the ability to match on packet size or not in hardware
for QoS - if so, UDP/123 packets which *aren't* 76 bytes in
On Feb 18, 2014, at 2:15 PM, Aaron aar...@gvtc.com wrote:
Usually nfsen seems to be pretty accurate, is there a reason for that ~40
gbps reading during that ntp attack ?
Have you set your active flow timer to 60s/1m, so as to avoid backlogged spikes?
On Feb 18, 2014, at 5:48 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
AFAIK nfdump uses the start/end time in the flows to calculate pps, so would
this matter? Or is it a result of the sampling maths?
It has to do with long flows - flows aren't exported from the router/switch
until
On Feb 18, 2014, at 6:20 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
Aaron reported his netflow was reporting too-high spikes. How would shorter
flow timeouts - which equals high-frequency reporting bins/windows at the
collector - result in *lower* pps counters?
Because the spikes may
On Feb 18, 2014, at 12:05 AM, Joe Loiacono jloia...@csc.com wrote:
The netflow exports stayed on local time.
Are you sure it isn't an artifact of your collection/analysis software ignoring
the flow start/flow end fields in the telemetry export?
On Feb 12, 2014, at 11:07 PM, Richard Clayton sledge...@gmail.com wrote:
What is this type of DDoS called?
An ntp reflection/amplification DDoS attack.
Is the the customer being individually targeted or just the expolitable NTP
server?
It sounds as if these are ntpds which are
On Feb 13, 2014, at 12:17 AM, SilverTip257 silvertip...@gmail.com wrote:
I've seen these NTP attacks called DRDoS attacks.
( Distributed Reflection Denial of Service )
This is a marketing term used by some commercial organizations to try and
pretend that these attacks are something new and
On Feb 13, 2014, at 2:10 AM, Joe Loiacono jloia...@csc.com wrote:
This is port 123 exclusively going and coming right?
No - the reflector/amplifier - target leg will be sourced from UDP/123, but
will be destined for the port of the attackers' choice. We see a lot of
UDP/123 - UDP/80,
On Feb 12, 2014, at 6:46 AM, omar parihuana omar.parihu...@gmail.com wrote:
I've just put an ACL in order to block NTP outbound traffic.
You should look at the ntp sources, find out which allow monlist, et. al. (see
http://www.openntpproject.org/), then work to remediate those specific ntpds.
On Feb 5, 2014, at 6:58 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
That can't be. Sup2T has operationally useful netflow. I read it
somewhere...
That means it isn't broken by design, as in pre-EARL8 Sups DFCs. It doesn't
mean there can't be bugs . . .
;
On Feb 5, 2014, at 7:34 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
If that's the case, do please spell them out.
Real sampling, thereby avoiding mls table overflow, with the resultant
nondeterministic skew of statistics; seeing stats on dropped traffic; getting
TCP flags so as to
On Feb 6, 2014, at 3:23 AM, Charles Spurgeon c.spurg...@austin.utexas.edu
wrote:
TAC advised a reload on 15.1(2)SY1, which we have done.
Hopefully, this has been reported to PSIRT?
---
Roland Dobbins rdobb...@arbor.net //
On Feb 2, 2014, at 11:28 AM, Joseph Hardeman jwharde...@gmail.com wrote:
I know how to NULL route IP 's but I don't know if there is a way to block or
deny traffic based on destination port's also based on IP ranges.
On Jan 25, 2014, at 2:11 AM, Michael Sprouffske msprouff...@yahoo.com wrote:
My primary site is advertising default-originate so all my other sites can
get to the internet. How would I go about advertising 2 internet circuits in
the event my primary site lost internet?
Why don't you
On Jan 15, 2014, at 10:25 PM, Sukumar Subburayan (sukumars)
sukum...@cisco.com wrote:
Error in the DBUS (data bus) header indicates that you have had hardware.
Or that you need to re-seat the linecard(s)/RP(s) in question . . .
On Jan 3, 2014, at 4:15 PM, Eugeniu Patrascu eu...@imacandi.net wrote:
Maybe I should try this again: what I said was that on the recursive
resolvers dedicated for your clients you can add an extra layer of protection
in terms of dropping fake responses targeted at those servers by the
On Jan 3, 2014, at 6:57 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
It would be interesting to see some real-world numbers on this, to see if it
is a win or not. As I say, my gut says no, but gut != proof ;o)
I've seen it melt enough times in real life that I get a sinking feeling in my
On Jan 2, 2014, at 4:22 PM, Eugeniu Patrascu eu...@imacandi.net wrote:
FWIW, if you run your customers recursive resolvers on a Linux/*BSD box you
can setup iptables/pf in such a way that you only allow queries from
customers and from your resolver to the internet in a stateful way and deny
On Jan 2, 2014, at 8:09 PM, Gert Doering g...@greenie.muc.de wrote:
I would strongly recommend *against* doing stateful anything in front of a
DNS server. It won't serve a useful function (as unbound etc. are
quite good in recognizing real responses vs. fake), but serves as an
additional
On Jan 3, 2014, at 12:17 AM, Mack McBride mack.mcbr...@viawest.com wrote:
The big problem with DDoS is pipe filling anyway, not CPU load.
That's entirely subjective and varies from attack to attack, FYI.
And to be carify, the issue with putting stateful anything in front of servers
isn't
On Jan 3, 2014, at 12:32 AM, Eugeniu Patrascu eu...@imacandi.net wrote:
With modern machines (from a few years back) you can track a lot of
connections effortlessly.
I think you don't understand the scale of even small DDoS attacks in terms of
state-tracking.
Stateful devices put in front
On Jan 1, 2014, at 7:21 PM, Gert Doering g...@greenie.muc.de wrote:
Which is why Paul Vixie's RRL or Lutz Donnerhacke's dampening patches for
BIND exist.
Yes, hence 'not all; directly-spoofed ANY attacks and the like, which don't
involve open recursors, are the exception'.
On Jan 1, 2014, at 7:27 PM, Gert Doering g...@greenie.muc.de wrote:
Abusing authoritatives is not the exception, and has not been for over a
year.
It is 'the exception' in the context of my previous reply, which had to do with
abuse of open recursors. Agree 100% it isn't rare; that wasn't
On Jan 1, 2014, at 4:13 AM, Mack McBride mack.mcbr...@viawest.com wrote:
Recursive servers have to be able to receive responses from anywhere on the
internet.
Hence 'external resolvers', mentioned in my post.
https://app.box.com/s/72bccbac1636714eb611
Nor can RTBH stop a true DDoS.
On Jan 1, 2014, at 5:26 AM, Mack McBride mack.mcbr...@viawest.com wrote:
Why would a company that requires maximum uptime want to depend on our DNS
servers when they have bandwidth from a number of other companies?
The recommendation in question is intended for consumer broadband access
On Dec 31, 2013, at 2:19 AM, Mike mike-cisconspl...@tiedyenetworks.com wrote:
Not true. I've seen more than 600mbps of traffic and, while not in the league
of what you see, is still a sizable total of my transit and we kept chunking
along.
This is a pretty trivial amount of traffic; also,
On Dec 31, 2013, at 1:27 AM, Mack McBride mack.mcbr...@viawest.com wrote:
Phishing has little to do with DNS per se.
Some does, actually.
BUT, forcing customers to use your DNS results in the possibility of all of
your customers suffering in a DDoS situation where your DNS servers are
On Dec 29, 2013, at 2:00 AM, MIke mike-cisconspl...@tiedyenetworks.com wrote:
Open internet. I don't want to dictate to anyone which port numbers or
protocols they are limited in using, and I want to impose only the absolute
minimum of controls in order to deliver as much of an unfiltered /
On Dec 29, 2013, at 5:18 PM, Gert Doering g...@greenie.muc.de wrote:
I might be a bit extreme on this, but I highly value the end-to-end
communication nature of the Internet,
Again, causing users to utilize your recursors by default, plus Open DNS and
Google DNS, and with an opt-out proviso
On Dec 29, 2013, at 7:21 PM, Gert Doering g...@greenie.muc.de wrote:
And that is where we differ. You find it OK to limit the protocol du jour to
what users do not need, I do not agree to it. Even if I agree with
you that most users would not notice.
I'm not proposing blocking DNS. I'm
On Dec 29, 2013, at 7:47 PM, Mark Tinka mark.ti...@seacom.mu wrote:
The majority of (phishing) attacks have nothing to do with the network, with
the exception of having the network transport those packets to the user's
computing device.
Yes, but those that do, which replace the
On Dec 27, 2013, at 10:55 AM, Mike mike-cisconspl...@tiedyenetworks.com wrote:
Can anyone suggest how we might tighten this up and either have a seperate
rate limit list or somehow exclude my small list of resolver IP's from the
above limiting?
Using any QoS mechanism, let alone an old,
On Dec 27, 2013, at 4:50 PM, Gert Doering g...@greenie.muc.de wrote:
I'd terminate my contract if my ISP would take away the ability to query
foreign DNS servers (usually done to troubleshoot things), to run
traceroutes, to ping stuff, etc.
Neither you nor I are typical broadband access
On Dec 27, 2013, at 7:00 PM, Peter Rathlev pe...@rathlev.dk wrote:
Most people on this list might not be typical access customers -- they might
be running their own resolver to get proper DNSSEC -- but that
still doesn't make it okay for an ISP to do things most of their customers
wouldn't
On Dec 24, 2013, at 6:05 PM, Nikolay Shopik sho...@inblock.ru wrote:
flow-sampler-map is only apply to hardware routing platforms.
Thanks for coming back and posting this - good reference info!
---
Roland Dobbins
On Dec 22, 2013, at 7:52 AM, Łukasz Bromirski luk...@bromirski.net wrote:
ACLs are good for basic sanity checks and segmenting the traffic for ports
(L4+). BGP scales way better for L3 than them and it’s faster
and way easier to dynamically update the entries.
Concur 100%.
ACLs are a
On Dec 20, 2013, at 8:36 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
Personally, I wouldn't do what you're doing - a 100k ACE ACL is just asking
for trouble.
Concur 100%.
---
Roland Dobbins rdobb...@arbor.net //
On Dec 17, 2013, at 2:36 PM, Mark Tinka mark.ti...@seacom.mu wrote:
Flow analysis tells what kind of traffic it is, where it's coming from, where
it's going to.
Flow telemetry tells us what SNMP telemetry tells us, plus the above.
It's useful to have SNMP telemetry from interfaces to
On Dec 17, 2013, at 8:29 PM, Mark Tinka mark.ti...@seacom.mu wrote:
/it's just coincidence that you work with Arbor
Whatever point you think you're making with this sort of remark, a simple
search of the list archives will demonstrate I've consistently advocated the
use of flow telemetry and
On Dec 17, 2013, at 10:26 PM, Mark Tinka mark.ti...@seacom.mu wrote:
The two are detached, in my mind, but I can see how some might not have seen
that way, hence...
My apologies for being so dense as to fail to understand that you meant what
you said literally, heh (and I was a bit puzzled,
On Dec 16, 2013, at 9:26 PM, Rolf Hanßen n...@rhanssen.de wrote:
Maybe it works if I use an ACL with 100k entries but it takes a minute to
install.
In what topological situation do you need 100K entries? Unless you're a very
large wholesale transit network trying to enforce anti-spoofing
On Dec 10, 2013, at 12:38 AM, Rolf Hanßen n...@rhanssen.de wrote:
I am thinking about dropping some (mainly ddos) traffic on the outside
network borders with ACLs.
ACLs don't work well as a DDoS reaction mechanism. They're good for protecting
your network infrastructure:
On Dec 17, 2013, at 6:33 AM, Rolf Hanßen n...@rhanssen.de wrote:
My fear is that somebody creates blackholes in my network with spoofed source
IPs.
Nobody can create blackhole routes on your network than you - or else you have
much bigger problems, heh.
This issue applies to S/RTBH or any
On Nov 30, 2013, at 11:45 PM, madu...@gmail.com wrote:
The above spec could apply to juniper, cisco, hp, xtreme ...etc, any
recommendation should I add/adjust to my TECHNICAL SPECIFICATION
It's hard for strangers who don't know your actual requirements to make
recommendations, beyond
On Dec 1, 2013, at 2:52 AM, Eugeniu Patrascu eu...@imacandi.net wrote:
He's baiting you to do his work for him.
Concur - which is why I gently suggested that lists of specs won't cut it, that
it's necessary to engage SMEs in order to make proper decisions.
;
On Nov 29, 2013, at 4:24 PM, Nikolay Shopik sho...@inblock.ru wrote:
flow monitor IPv4
record netflow ipv4 original-input
exporter AS-STATS
cache timeout active 300
flow monitor IPv6
record netflow ipv6 original-input
exporter AS-STATS
cache timeout active 300
Your active timers should
On Nov 29, 2013, at 5:49 PM, Nikolay Shopik sho...@inblock.ru wrote:
So this is apply to any sampled netflow?
Any NetFlow, sampled or non-sampled.
Set the active timer to 60s, and the inactive timer to 5s.
c7201(config-if)#ip flow monitor IPv4 sampler SM input
On Nov 29, 2013, at 4:24 PM, Nikolay Shopik sho...@inblock.ru wrote:
flow-sampler-map SM
mode random one-out-of 100
flow-sampler-map SM
mode random 1 out-of 100
Try that with this:
interface GigabitEthernet0/1
ip address 10.10.112.143 255.255.255.0
ipv6 address 2001:db8:20:101::99/64
ip
On Nov 29, 2013, at 6:09 PM, Nikolay Shopik sho...@inblock.ru wrote:
Even when you draw graph in 5 min interval?
Yes. Your graphs will be way off unless you bring the active timer down to
60s, irrespective of graph resolution.
You should also consider graphing with 1-minute intervals, it's
On Nov 10, 2013, at 1:09 PM, Youssef Bengelloun-Zahr yous...@720.fr wrote:
Yes, sorry but I forgot to mention that we have activated every possible TCP
extension on servers in order to support latency effects over long WAN
distances.
Due to the nature of TCP, delay-product has throughput
On Nov 11, 2013, at 5:32 AM, Octavio Alvarez alvar...@alvarezp.ods.org wrote:
If you are trying to saturate the link in both directions each of the
acknowledge packets will compete against the other stream and will have a
hard time reaching back.
I first read this thread when I was
On Nov 5, 2013, at 12:57 PM, Arne Larsen / Region Nordjylland a...@rn.dk
wrote:
Citrix's is full of endless configurations samples and how to setup, none
describes how the hardware, or at least I can't find it.
Normally, when buying an expensive piece of equipment like this, a service
On Nov 3, 2013, at 7:29 AM, Justin M. Streiner strei...@cluebyfour.org wrote:
It would be great if Cisco focus-group tested these 'enhancements' before
rolling them out, and knock it off with the Java nonsense.
They've been going in this direction for the last 10 years - it's doubtful that
On Nov 3, 2013, at 12:08 PM, Jeff Kell jeff-k...@utc.edu wrote:
If enough of us complain... maybe.
Plenty of people inside and outside of Cisco have complained vociferously, to
no avail. It's unlikely to change.
---
Roland
On Oct 18, 2013, at 12:13 PM, Rolf Hanßen n...@rhanssen.de wrote:
ip flow monitor monitorname input
ip flow monitor monitorname output
If you're collecting both ingress and egress NetFlow on the same interface,
this could be contributing to your issues - Cisco do not recommend doing this
On Oct 17, 2013, at 7:06 PM, Rolf Hanßen n...@rhanssen.de wrote:
For example a box exporting something to a Peakflow SP for dos recognition.
I recognized that starting a random-source-ip flood over my box even could
make the cli freeze.
This is not normal.
What does your per-interface
On Sep 23, 2013, at 9:57 PM, Jiri Prochazka wrote:
Is this doable?
It's not a good idea, as you lose visibility into traffic which you're
blocking, but which is still chewing up link capacity and pummeling your boxen.
---
On Sep 3, 2013, at 4:34 AM, Jon Lewis wrote:
Having used it exactly for that, I disagree and am curious why you say
it's useless.
Because in any Internet-facing environment with any kind of traffic diversity,
it's non-deterministically skewed.
So, in a network environment of any scale,
On Sep 3, 2013, at 3:41 AM, Peter Rathlev wrote:
Though Sup720 Netflow has many limitations, the OP's use case is one that it
can actually help with.
No, it isn't - he won't be able to detect anomalies reliably nor will he be
able to characterize floods, because the statistics are
On Sep 1, 2013, at 7:57 AM, Randy wrote:
It would only be used for detecting inbound UDP floods and other high PPS
anomalies so there is no need for full flows or even much details, just ip
src/dst.
It's useless for this or any other application because of the limitations of
the EARL7.
On Aug 29, 2013, at 3:28 PM, CiscoNSP List wrote:
Netflow
If you go with 6500 or 7600, be sure to use Sup2T and DFC4 in order to get
usable NetFlow, uRPF, and ACLs.
---
Roland Dobbins rdobb...@arbor.net //
On Jun 27, 2013, at 5:36 PM, Tom Hill wrote:
I'm quite annoyed that there aren't any newer line cards announced that take
advantage of faster SerDes rates (as your existing X6800/X6900
series line cards will not run any faster) but then I seem to recall 6500-E
came a short while before
On Jun 27, 2013, at 3:40 AM, Gert Doering wrote:
But can cisco afford to have three quite similar product lines,
that are expensive to maintain?
Cisco isn't really a unitary company, it's a loose confederation of semi-feudal
fifedoms, each with its own PL. Effectively, they're separate
On Jun 27, 2013, at 10:10 AM, Justin M. Streiner wrote:
It just seems like the new 6k is positioned to poach prospective customers
from the (arguably) higher-margin Nexus 7k product line.
Not 'just seems' - 'is'. Just as the new fixed-config one is positioned to
poach prospective customers
On Jun 12, 2013, at 2:03 PM, PlaWanSai RMUTT CPE IX wrote:
Please help to check if you can give any advice will be appreciated.
Looks like CSCtr88610 or related, possibly. Check with your Cisco account team
and/or TAC.
---
On Jun 4, 2013, at 4:54 AM, Phil Mayers wrote:
including that you don't need to write both ingress and egress ACLs. Though I
suppose the latter are more flexible.
Egress ACLs are generally considered to be a Bad Thing, as they allow
potentially undesirable packets past the port/linecard
On May 7, 2013, at 5:17 PM, Nick Hilliard wrote:
It's a more sensible idea to filter protocol 89 to your core address ranges
using an iACL and then permit all 89 in the CoPP policy.
Concur 100%.
---
Roland Dobbins
On May 6, 2013, at 7:49 PM, Rolf Hanßen wrote:
I am trying to configure IPv6 CoPP and could use some help with several
issues.
I know this isn't what you're asking, but if you haven't done so already,
you'll get more benefit from iACLs, GTSM, re-coloring at your edges, et. al.
first, then
On May 6, 2013, at 11:11 PM, Rogelio Gamino wrote:
At that stage, neighbors agree on Master/Slave relationship before moving to
exchange DBD's.
Unless you're doing OSPF with an external organization and anticipate an attack
(either deliberate or inadvertent) from the adjacent router(s), why
On Oct 12, 2009, at 12:23 PM, Matt Hill wrote:
We have a 7600 whose sole purpose is to do Anomaly Guard/Detector Work. It
has some EBGP peering and is in the traffic path.
You should run whatever IOS Cisco say supports the AGM/ADM (keeping in mind
that the Guard/Detector are EoS/EoL, and
On Apr 20, 2013, at 1:10 PM, CiscoNSP List wrote:
Thanks for the reply - data is used for billing (So it is critical)hence
my concern with lost flows.
NetFlow should be exported via your OOB/DCN.
If you're losing packets on your OOB/DCN, you've bigger problems than worrying
about a
On Apr 17, 2013, at 12:37 AM, Antonio Soares wrote:
Now my question, is it appropriate to use uRPF loose mode on Core Routers
(Full Routing Tables) ?
It's an edge technology - use loose-mode on your peering/transit interfaces,
use strict-mode whenever possible on your customer
On Apr 17, 2013, at 8:42 AM, Lee wrote:
But the IPv4 address space is close to all allocated, so enabling it for IPv4
doesn't seem like a huge win.
This is incorrect, and is actually harmful misinformation.
The value of antispoofing has nothing to do with allocated address space
On Mar 28, 2013, at 3:54 PM, Lukasz Bromirski wrote:
uRPF is coming, both for IPv4 and IPv6. Unfortunately, it's still
in the future, not now.
It appears that Source Guard may be available now, depending upon the image
being run:
On Mar 27, 2013, at 6:42 PM, Jiri Prochazka wrote:
As soon as I limit usage to 70% (both Sup and linecards), no flows are
dropped, but the box is still dying.
Are your linecards all either DFC4 or CFC?
---
Roland Dobbins
On Mar 27, 2013, at 7:50 PM, Mikael Abrahamsson wrote:
For Internet peering router at 10GE with typical eyeball traffic my
opinion is that 6500/7600 doesn't have working netflow.
Sup2T/DFC4 fixes these issues, as well as the uRPF mode limitation and weird
ACL threshold limitation.
The
1 - 100 of 296 matches
Mail list logo
