Re: Authoritative Resources for Public DNS Pinging

[Łukasz Bromirski]

Yup. And Google folks accounted for the world pinging them all day long.

I wouldn't call using DNS resolvers as best "am I connected to internet over 
this interface" tool though. A day, year or 5 years from now the same team may 
decide to drop/filter and then thousands of hardcoded "handmade automation 
solutions" will break. And I believe that's closer to what Masataka was trying 
to convey.

— 
Łukasz Bromirski

> On 9 Feb 2022, at 14:23, Mark Tinka  wrote:
> 
>> On 2/9/22 15:00, Masataka Ohta wrote:
>> 
>> 
>> Wrong. It is not bad, at least not so bad, pinging properly
>> anycast DNS servers.
>> 
>> The point of anycast is resistance to DDoS.
>> 
>> But, relying on hard coded 8.8.8.8 is not a good idea because
>> DNS service of the address may be terminated.
>> 
>> Instead, properly anycast root name servers are authoritative
>> resources provided for public DNS queries which can be used for
>> pinging, though pinging so with ICMP should be less painful
>> for the servers.
> 
> That's like saying you won't have an egg for dinner because it's typically 
> had for breakfast.
> 
> Users don't care what infrastructure has been designated for. If they can 
> find another use for it other than designed, which serves their interests, 
> they will use it.
> 
> We need to allow, and account, for that.
> 
> Mark.

Re: IRR for IX peers

[Łukasz Bromirski]

…like a, say, „single pane of glass”? ;)

-- 
./

> On 5 Oct 2021, at 06:25, Mark Tinka  wrote:
> 
> 
> 
>> On 10/4/21 21:55, Nick Hilliard wrote:
>> 
>>  Nearly 30 years on, this is still the state of the art.
> 
> Not an unlike an NMS... still can't walk into a shop and just buy one that 
> works out of the box :-).
> 
> Mark.

Re: massive facebook outage presently

[Łukasz Bromirski]

Dual homing won’t help you if your automation template will do „no router bgp 
X” and at this point session will terminate as suddenly advertisement will be 
withdrawn…

It won’t you either if the change triggers some obscure bug in your BGP stack.

I bet FB tested the change on smaller scale and everything was fine, and only 
then started to roll this over wider network and at that point „something” 
broke. Or some bug needed a moment to start cascading issues around the infra.

-- 
./

> On 4 Oct 2021, at 22:00, Michael Thomas  wrote:
> 
> 
> 
> 
> On 10/4/21 11:48 AM, Luke Guillory wrote:
>> 
>> I believe the original change was 'automatic' (as in configuration done via 
>> a web interface). However, now that connection to the outside world is down, 
>> remote access to those tools don't exist anymore, so the emergency procedure 
>> is to gain physical access to the peering routers and do all the 
>> configuration locally.
> Assuming that this is what actually happened, what should fb have done 
> different (beyond the obvious of not screwing up the immediate issue)? This 
> seems like it's a single point of failure. Should all of the BGP speakers 
> have been dual homed or something like that? Or should they not have been 
> mixing ops and production networks? Sorry if this sounds dumb.
> 
> Mike

BGP in the lab - v4 & v6 live feeds from Europe

[Łukasz Bromirski]

Dear NANOGers,

If you’re looking for live, full BGP v4 & v6 feed for your lab or
a bit of testing before going live, I just shared a short post on
how to get it:

https://lukasz.bromirski.net/post/bgp-w-labie-3/

Happy BGPing,
-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: SPAM for nanog@ senders

[Łukasz Bromirski]

Hi Randy,

> On 22 Sep 2020, at 00:14, Randy Bush  wrote:
> 
>> I already taught my SpamAssasin and then deleted them
> 
> :0
> * ^From:.*@csvwebsupport.com
> | /usr/bin/mail -s 'Screw You' dating.supp...@csvwebsupport.com < 
> ~/screw-you.txt

I’m using different technique. I like tarpitting such scums to death.
Record holders keep their SMTP bots connected for weeks ;)

But good old punch in the face works wonders too :)

— 
./

Re: SPAM for nanog@ senders

[Łukasz Bromirski]

Job,

I already taught my SpamAssasin and then deleted them, and my
Postfix is no longer taking submission from the IP from which they
were sent - 216.176.196.72.

They seem to be using correct sending host according to SPF
record (host spamtitan.csvwebsupport.com validates using
'dating.supp...@csvwebsupport.com’).

Let me unblock them again and see if they’ll continue doing so,
hopefully I’ll be able to help.

I’m sending this email just to (hopefully) trigger the same
behavior, and will follow up with you separately.

Apologies for the noise for the rest of subscribers.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

SPAM for nanog@ senders

[Łukasz Bromirski]

NANOGers,

Have you got email from 'dating.supp...@csvwebsupport.com’ immediately
after you post to nanog@? First time I thought it’s coincidence, but
today when I got it, it’s hardly one ;)

Topic is '[#WHB-257-41491]: Re: XX’ where  is subject taken
from last e-mail.

I understand there’s need to connect people in hard, COVID times,
but I doubt automated spam sender has good intentions with that regard ;)

So.. somebody is scrapping this list to feed their spamming lists :/

— 
./

Re: SRv6

[Łukasz Bromirski]

Mark,

> On 20 Sep 2020, at 13:02, Mark Tinka  wrote:
> 
> 
> 
> On 19/Sep/20 22:53, Valdis Kl ē tnieks wrote:
> 
>> Are there any actual countries heading that way?  Seems like most of them 
>> insist
>> they have the ability to snoop unencrypted traffic (where "crypto that has a 
>> baked-in
>> back door" counts as unencrypted).
> 
> Let's not give them a reason.
> 
> The most I've heard (from Africa) is countries making requirements for 
> nominated information to not be stored outside of the country, especially in 
> the U.S, and parts of Europe. To some extent, this has pushed many of the 
> cloud bags to become present in Africa so they can comply, although I'm not 
> sure even sleeping with one eye open counts as being safe in that respect.

I believe right now the only country in the world with enforcing of crypto 
backdoors is Australia[1], which is kind-of crazy. OTOH, they had their own set 
of problems with massive Chinese intelligence penetration.

And we have couple of countries like Russia, obviously China, Turkey(?) that 
insist or either having your data locally, dear content provider, or forbid 
your service to operate at all in given country. Apple, Amazon, Microsoft and 
Google of this world are on a different level of compliance here. As far as I 
know, in most of EU countries, inspecting payload of customer traffic is 
explicitly forbidden by telco laws.

Ah, and there’s cooperation between US and EU about exchanging citizen data, 
which recently was stopped by EU once it become obvious, US was abusing that 
cooperation[2]. That can help potential malicious SP to cross-check and 
correlate user to content across continents.

We’re living in interesting times.

[1]. https://www.cyberscoop.com/australia-encryption-backdoors-law-passes/

[2]. 
https://www.wsj.com/articles/eus-top-court-restricts-personal-data-transfers-to-u-s-citing-surveillance-concerns-11594888385

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: SRv6

[Łukasz Bromirski]

Mark,

> On 16 Sep 2020, at 10:32, Mark Tinka  wrote:
> 
> On 15/Sep/20 19:00, aar...@gvtc.com wrote:
> 
>> Sorry guys, I'm not aware of much of what you mention as far as agenda, 
>> vendor motive, and hardware support, etc 
> 
> I'm not shy... this would be Cisco.

And that’s fine. The fact that some Intellectual Property[1] was created
by one vendor or another (disclaimer - I work for Cisco) shouldn’t be
by default something that discredits the idea. And BTW, if You look into
the history of how SR started, it was close feedback loop with at least
some of the ISPs wanting to have “easier” and SDN-ish control over the
network so the blame should be shared :) Having support from other
vendors was de facto requirement to even think about deploying it widely
and that's better approach IMHO than “lets patent everything out and
force everyone into our black-box-architecture that’s best in the world”.

I’m observing the discussions over the last couple of months and
generally they boil down to “leave us alone, everything sucks, we’ll 
stay with what we have”. And sure, as you indisputably proven during last
30 years, running modern ISP network can be done over IP, MPLS, and the
network can even survive introduction of IPv6. And I get it - vendors
have generally failed to address your ideas and problems in timely manner,
and when we did, quality was simply not there. But really, is that all
what’s interesting in life? I doubt it. Unless the whole point of
discussing here would be to start from technical topics
(because of ‘rules’) and end up with everybodys favorite part - beating
virtual Pinata made to look like representation of most hated
salesman/vendor. Then sorry, I somehow missed that :)

While I personally find the idea of stacking IPv6 labels gruesome for
any non-trivial label depth[2] (and I'm really worried about software guys
coming in from the “mobile app” world soon, and finding out that they can
create those IPv6 EH stacks easily), going forward we have to think
about what will keep networks running in for the next 5, 10 or 20 years.
IPv4 with MPLS+LDP+RSVP-TE will work fine of course, so will SRoMPLS,
but IPv6 is gaining adoption and need to multiplex/demultiplex more and
more services and users will only grow. And BTW, MPLS forwarding between
ASes in the internet is still something that works mainly on slides,
highly paid consulting “proposals” and of course on the CCIE exam.

On the other side, there’s Elon Musk moving us to Mars, wretched IoT
world with “build, sell and forget" mentality w/r to firmware and good
network stacks. And yet only 59% people around the world today have internet
access. At least good portion of that heavily filtered one by the way.

IPv6 seems to be good plan forward (and would potentially unify
architecture of normal routing and overlay routing with SRv6), even
if things like MPLSoUDP or GRE would really solve everything if pushed
with enough force[3] ;) It’s worth observing, that from this perspective
IPinIP would be as good as SRv6 if everyone would agree 20 years ago that
source routing is acceptable. LDP or RSVP-TE would never gain any usage
and maybe we wouldn’t learn lesson or two. BTW, we tried to somehow get
back to this simplification with LISP[4], and in the long run it seems
overloading address semantics is not something that is happily accepted
everywhere, and it doesn’t matter if that's IPv4 or IPv6.

So much hated middleboxes will also adopt faster to IPv6, as adopting MPLS
data plane after those 20 years on firewalls, load balancers and what-you
looks kind of dissapointingly. And if we are talking about network
functions - I believe it’s more important right now to agree on one way
of doing service chaining, than discussing SR or SRv6 as evil seed created
to conquer the world. 

SR takes out state out, and SRv6 has the same address format on the
outside as well as inside. You can happily run it with both data planes,
and while today maybe you can’t provide migration of ALL services,
SR+IGP quite nicely interworks with MPLS+LDP.

Will HW evolve? It has to anyway, no previous change was done day one
and 128 bits times 5 or 8 or 12 seems horrible only today. Over the
years, people got used to bigger horrors ;)

— 
./

[1]. https://patents.google.com/patent/US20140169370
[2]. Yeah, Binding SIDs of course, but that’s a solution to self-made
 problem as Ivan Pepelnjak would say.
[3]. https://tools.ietf.org/html/rfc1925 point 2.3.
[4]. https://tools.ietf.org/html/rfc6830

Re: rsvp-te admission control - i don't see it

[Łukasz Bromirski]

Aaron,

> On 3 Sep 2020, at 20:05, aar...@gvtc.com wrote:
> 
> I have a functional mpls-te test running, seems fine…but, question about 
> bandwidth reservations please.
>  
> At the Headend router, I set bandwidth on my mpls-te tunnel, but I can’t for 
> the life of me, find where in the network is this bandwidth actually being 
> admitted, or seen, or allocated or anything!
>  
> I mean I look on rsvp interfaces, I look in wireshark at the tspec field of 
> the path message, I look in the mpls te tunnels along the way, etc, etc, I 
> can’t find where the network sees that bandwidth I’m asking for at the tunnel 
> Head end.

I’m not sure if I understand you, but RSVP only does control plane reservation.

Then, once you have a tunnel to establish with specific bandwidth required, 
RSVP-TE will do CSPF based on link coloring, bandwidth available over 
interfaces and priority of tunnel to decide how to establish it. If the tunnel 
is setup over interface, bandwidth assigned to tunnel is taken out from 
bandwidth available on that interface. But this is purely control plane 
reservation. Nothing will be enforced in data plane.

To enforce those values, you need to apply QoS policies to interfaces over 
which you expert to serve MPLS TE tunnels.

— 
./

Re: BGP full feed for testing purposes

[Łukasz Bromirski]

Blazej,

> On 5 Aug 2020, at 23:13, Blažej Krajňák  wrote:
> 
> Hi Lukasz,
> 
> your feed is working well. Feed from Poland to me to Slovakia is better than 
> expected :) It's my first live BGP full feed ever so I really appreciate you.
> Will this instance run for a longer time?

Yep. I have no reasons to drop it.

Right now I have like 5 to 10 sessions in peak, most people come, get feed,
reset session couple of times and go away.

I’m finishing writing some short ‘howto’ style doc to explain how to use
this feed for egress traffic engineering when you have multiple ISPs and
no BGP with them.

— 
./

Re: BGP full feed for testing purposes

[Łukasz Bromirski]

Ah, one more thing:

> On 5 Aug 2020, at 20:01, Łukasz Bromirski  wrote:
> 
> 
> …or you can do next best thing. Which is use AS 65001 and connect your router 
> to AS 65000 under 94.246.173.181.
> 
> Please note that’s just test instance, and it has conservative timers 
> (3600/7200) to not overtax CPU.
> 
> It’s test instance of CSR 1000v running 16.9.5.
> 
> If there’ll be interest, I can setup similar box with IOS-XR and/or with IPv6.

This is European feed from Poland, so YMMV, but it has 816,090 prefixes as we 
speak.

Don’t kill me if it kills your router ;)

— 
./

Re: BGP full feed for testing purposes

[Łukasz Bromirski]

…or you can do next best thing. Which is use AS 65001 and connect your router 
to AS 65000 under 94.246.173.181.

Please note that’s just test instance, and it has conservative timers 
(3600/7200) to not overtax CPU.

It’s test instance of CSR 1000v running 16.9.5.

If there’ll be interest, I can setup similar box with IOS-XR and/or with IPv6.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

> On 5 Aug 2020, at 03:25, Jared Geiger  wrote:
> 
> You can also launch a VM in your lab 
> https://stubarea51.net/2016/01/21/put-50-bgp-routes-in-your-lab-network-download-this-vm-and-become-your-own-upstream-bgp-isp-for-testing/
>  
> <https://stubarea51.net/2016/01/21/put-50-bgp-routes-in-your-lab-network-download-this-vm-and-become-your-own-upstream-bgp-isp-for-testing/>
> On Mon, Aug 3, 2020 at 1:42 PM Josh Luthman  <mailto:j...@imaginenetworksllc.com>> wrote:
> Greg Sowell helps you out here:
> 
> http://gregsowell.com/?page_id=5771 <http://gregsowell.com/?page_id=5771>  
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> 
> On Mon, Aug 3, 2020 at 4:19 PM Brendan Carlson  <mailto:bren...@bcarlsonmedia.com>> wrote:
> Set up a Vultr instance and you can get a full feed from them for testing. 
> I've done this for a route collector and it worked well.
> 
> On Mon, Aug 3, 2020, 13:16 Blažej Krajňák  <mailto:kraj...@levonet.sk>> wrote:
> Hello,
> 
> I'm wondering, if there is any public service I can get full BGP feed 
> from for testing purposes.
> 
> I admin multi-homed AS50242 with two default routes for now (fail-over). 
> I'm going to prepare new routing setup with extended validation so reall 
> full BGP feed would be usefull. Yes, I can ask my upstream provider for 
> it, but I don't want to change settings in production setup.
> 
> 
> Thanks
> 
> Regards,
> Blažej Krajňák

Re: questions asked during network engineer interview

[Łukasz Bromirski]

Adam,

> On 21 Jul 2020, at 19:13, Mark Tinka  wrote:
> On 21/Jul/20 18:39, adamv0...@netconsultings.com wrote:
>> Little you two know about SDN, please read the following presentation from 
>> Scott Shenker and then get back here arguing what it is and what it is not: 
>> https://inst.eecs.berkeley.edu/~cs168/fa14/lectures/lec23-public.pdf
> 
> I'll pass, thanks. Already did my time in that rabbit hole.

Yeah. Also, I see great piece near end of the slide deck:

"We (Berkeley) are pushing SDNv2 which focuses on
 - General processing at the edge (middleboxes)
 - Very simple processing in the core
 - Support for third-party services (using mboxes)”

I believe I’ve seen this somewhere ;)

Are we reinventing tag switching?

Mind it, PDF is from 2014 and represents very naive approach to SDN (sorry, 
“SDNv2”).

And yes (to the main topic of this thread) - I have some certs.
I understand people without certs tend to discard them as
non-relevant or even toxic. Yes, I’ve met “paper” CCIEs,
but also JNCIEs and I can see the point being made. I’ve
met great minds (also on this list) without any networking
certificates. I believe that until you see real person on the
other side of table and not her/his cert(s), good chat and
questions will remove all doubts. Everyone has to start
somewhere and make those first errors, and being ‘expert’
doesn’t mean you’re not making them anymore.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: Sunday traffic curiosity

[Łukasz Bromirski]

Hugo,

> On 23 Mar 2020, at 01:32, Hugo Slabbert  wrote:
> 
> I think that's the thing:
> Drop cache boxes inside eyeball networks; fill the caches during off-peak; 
> unicast from the cache boxes inside the eyeball provider's network to 
> subscribers.  Do a single stream from source to each "replication point" 
> (cache box) rather than a stream per ultimate receiver from the source, then 
> a unicast stream per ultimate receiver from their selected "replication 
> point".  You solve the administrative control problem since the "replication 
> point" is an appliance just getting power & connectivity from the 
> connectivity service provider, with the appliance remaining under the 
> administrative control of the content provider.

But that’s already happening. All big content providers are doing just that. 
They even sponsor you the appliance(s) to make more money and save on transit 
costs ;)

— 
./

Re: QUIC traffic throttled on AT residential

[Łukasz Bromirski]

At this pace and having adopted CI/CD methodology, we may QUICkly run out of 
UDP ports to use.

I’d actually switch to ICMP. Type 8 code 0 and Type 0, code 0. Then staging a 
war on rate-limiters around the world.

Also, 123/udp seems to look interesting ;)

-- 
./

> On 22 Feb 2020, at 00:21, Matthew Petach  wrote:
> 
> 
> 
> 
>> On Fri, Feb 21, 2020, 13:31 Łukasz Bromirski  wrote:
>> 
>> [...]
>> 
>> Now… once we are aware, the only question is — where we go from here?
>> 
>> — 
>> ./
> 
> 
> 
> Well, it's clear the UDP 443 experiment wasn't entirely successful.
> 
> So clearly, it's time to use the one UDP port that is allowed through at the 
> top of everyone's ACL rules, and update QUIC in the next iteration to use 
> UDP/53.
> 
> *THAT* should solve the whole problem, once and for all.
> 
> ;)
> 
> Matt
> 

Re: QUIC traffic throttled on AT residential

[Łukasz Bromirski]

Hi Dan!

> On 21 Feb 2020, at 20:22, Dan Wing  wrote:
> 
> There are choices, such as making connection initiation, connection 
> acceptance, and connection termination parsable by network elements on the 
> path so state can be established, maintained, and cleared, DoS can be 
> identified, and so on.  The decision was to hide all that from network 
> elements.

Because monetization of content delivery should be constrained only
for those, that are able to make new standards, while ignoring
openness and cooperation.

Google is the new AOL? With AMP, QUIC and other nice, shiny,
closed and proprietary stuff? Oh, and BTW, please sync your life
with our cloud.

Now… once we are aware, the only question is — where we go from here?

— 
./

Re: Mx204 alternative

[Łukasz Bromirski]

Adam,

> On 2 Sep 2019, at 19:42, adamv0...@netconsultings.com wrote:
> 
> You nailed it, 
> Actually very few line-cards or fabric-less boxes with (run to completion
> vendor chips) out there do line-rate at 64B packets nowadays.
> -with the advent of 100G the "line-rate at 64B" is pretty much not a thing
> anymore...
> Something to consider, not because one wants to push 64B packets at
> line-rate on all ports but because one needs to push IMIX through QOS or
> filters... and the card/box might simply not deliver.

But those are two completely different use cases.

The fact that vendors (full disclosure - I work for Cisco) don’t want to
optimize for 64 bytes forwarding is totally independent on how those
architectures deal/manage to apply policies on the traffic.

64B traffic simply doesn’t happen apart from DDoS scenarios, so
why bother at all? Customers anyway want to use dedicated
anty-DDoS boxes, so apart from synthetic performance testing,
pushing the architecture to be able to forward couple of mpps more
just to cover the “64B” scenario means $ (sometimes $$$) just
to satisfy requirement that’s usually simply not there.

In other words, the fact that given architecture can’t forward "wire-rate"
of 64B traffic doesn’t mean that it can’t apply QoS for IMIX pattern
at wire-speed. Forwarding engine is usually different part of
hardware than services, more often than not decisions are totally
independent to speed up processing.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: RTBH no_export

[Łukasz Bromirski]

> On 31 Jan 2019, at 20:28, Roel Parijs  wrote:
> 
> Hello NANOG,
> 
> To minimize the impact of DDoS, I have setup RTBH.
> For our own customers, we can set the RTBH community ourselves towards our 
> transit suppliers and this works well.
> 
> For our BGP customers the problem is more complex. Our BGP customers can send 
> us the RTBH community, and we will drop the traffic at our borders. Since 
> we're only running a small network, we don't have the capacity to deal with 
> large attacks. If we would be able to forward (and maybe alter it) this RTBH 
> community towards our upstream providers, the impact on our network would be 
> limited. However, the RFC states that an announcement tagged with the 
> blackhole community should get the no_advertise or no_export community.
> 
> What is your opinion on this ?

Community agreed between you and your peer is one thing, the other
is community agreed with your upstreams. If in addition you own the
customer IP space, it’s even less of a problem. 

And… if you upstreams agree to signal RTBH with you, it’s added bonus
for them - they’re stopping the flood at their own edges thanks to you.

win-win-win-drop ;)

— 
./

Re: Suggestion for Layer 3, all SFP+ switches

[Łukasz Bromirski]

Colton,

> On 19 Apr 2018, at 03:32, Colton Conor <colton.co...@gmail.com> wrote:
> 
> Cisco has mutliple options, but mainly the NCS based on your port count I
> think. Supposely the C3850 and C9500 now support MPLS? There is a new 16
> port 10G version of the C9500. I haven't looked into Nexus switches. Does
> Nexus support full MPLS?

UADP based platforms, both older (C3650/3850) and newer (C9xxx) do
support MPLS encap and VXLAN encap and can be extended in future to
support others. There are new 9xxx based off UADP 3.0 with 40G and 100G
ports:
https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9500-series-switches/datasheet-c78-738978.html
 
<https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9500-series-switches/datasheet-c78-738978.html>

Nexus 7k supports MPLS with LDP while Nexus 9k supports MPLS but
with SR (IGP) or BGP-LU (no LDP support).

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: BGP Route Reflector - Route Server, Router, etc

[Łukasz Bromirski]

> On 12 Jan 2017, at 21:32, Justin Krejci <jkre...@usinternet.com> wrote:
> 
> Nanog,
> […]

You did some homework. In essence, there’s no immediate problem with running 
Quagga or OpenBGPd as
RR apart from lack of different knobs and not-so-stellar 
performance/scalability. BIRD is grounds up built
to act as high-performance BGP daemon, and it’s actually used as RR in live 
deployments, not only at IXes.

> I am wondering if people can point me in the direction to some good resource 
> material on how to select a good BGP route reflector design. Should I just 
> dust off some 7206VXR routers to act as route reflectors? Use a few existing 
> live routers and just add the responsibility of being route reflectors, is 
> there a performance hit? Install and run BIRD on new server hardware? Buy 
> some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as 
> route reflectors and add them to the iBGP topology? GNS3 running IOS on 
> server hardware? Something else? How many reflectors should be implemented? 
> Two? Four?

Disclaimer: I work at Cisco.

If You have some 7200VXRs that have 1 or 2GBs of RAM, that may be the best 
option (IF you have them).
Loaded with 12.2S/15S software they may actually be the most cost-effective 
solution and at the same
time support things like AddPath, BGP error handling, etc - when time comes to 
use such features.
If that’s a NPE400 based chassis or something even older - leave it for lab/etc 
as You need rather
performant CPU.

So, if that’s not the option, try to work with the BIRD, CSR 1000v (IOS-XE on 
VM) or ASR 1001X/HX
(currently, the most scaleable and fastest BGP route reflector out there, but 
one that will cost $$$).

Two RRs provide ample redundancy to run even very large deployments (1000+ 
clients), so unless you’re
trying to hit higher numbers or plan to play fancy games with one pair of RRs 
for IPv4/IPv6 unicast
and other pair for different AFs, four may be an overkill to maintain, 
synchronize and monitor.

Don’t go with GNS3, running compiled at runtime emulation is wrong idea for any 
production deployment,
not to mention rights/licenses to do it.

— 
Łukasz Bromirski

Re: MTU

[Łukasz Bromirski]

> On 22 Jul 2016, at 19:37, Grzegorz Janoszka <grzeg...@janoszka.pl> wrote:
> 
>> On 2016-07-22 15:57, William Herrin wrote:
>> On a link containing only routers, you can safely increase the MTU to
>> any mutually agreed value with these caveats:
> 
> What I noticed a few years ago was that BGP convergence time was faster with 
> higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.

Quite obvious thing - BGP by default on Cisco and Juniper will use up to max 
allowed 4k message per packet, which for typical unicast IPv4/v6 helps to pack 
all attributes with prefix. This not only improves  (lowers) CPU load on 
sending side but also on the receiving end and helps with routing convergence.

There was a draft to use up to 9k for BGP messaging, but I belive it's buried 
somewhere on the outside of town called "our current version RFC".

-- 
Łukasz Bromirski

Re: BGP peering strategies for smaller routers

[Łukasz Bromirski]

Blake,

> On 04 May 2016, at 00:23, Blake Hudson <bl...@ispn.net> wrote:
> 
> Łukasz Bromirski wrote on 5/3/2016 4:13 PM:
>>> On 03 May 2016, at 22:31, William Herrin <b...@herrin.us> wrote:
>>> 
>>> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander
>>> <gustav.ulan...@telecomputing.se> wrote:
>>>> Yes I can confirm that we also had the issue with the asr1001s.

[...]

> I feel like you're trying to fit some other (possible, but far fetched) 
> scenario from where we started.

Yeah, sorry for that - saw 1001 in quote and kept that as original platform.

For 1002 with SSO off you may be fine, sure. BTW, the versions you're quoting 
as working were also quoted by me as the ones that could have been OK even on 
the 1001 (I know, I know).

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: BGP peering strategies for smaller routers

[Łukasz Bromirski]

> On 03 May 2016, at 22:31, William Herrin <b...@herrin.us> wrote:
> 
> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander
> <gustav.ulan...@telecomputing.se> wrote:
>> Yes I can confirm that we also had the issue with the asr1001s.
>> For us the router was fine until we upgraded it. When
>> we rebooted it after the upgrade it ran out of memory
>> when populating 2 full feeds.
>> When we contacted TAC they confirmed that indeed
>> it was a memory problem and that we would need to
>> add more memory to the box.
> 
> Hi Gustav,
> 
> IMO, you should not accept that answer from the TAC. An IOS release
> that crashes with two 600k BGP feeds in 4 gigs of RAM is badly
> defective.

Not necessarily.

In essence, your physical memory gets halved in two after
router boots up, then it may be further halved if you’re
using features like SSO. So, with 4GB RAM config and with
SSO running, you may be left with around 600-650MB free after
boot and with IOS-XE loaded, and then all the features kick
in. Including your BGP feeds that need around 300MB of memory
just to store the tables, then there’s CEF RAM representation,
and so on.

Here’s a good WP w/r to memory usage & architecture on ASR 1k:
http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116777-technote-product-00.html

It actually contains the same recommendation given by TAC -
with recent/current code if you want to run full tables with
BGP, get 8GB of RAM on ASR 1k. In the 3.10-3.12S era I believe
it was still possible to fit (without the SSO) full tables
in RAM and be fine. 

As Nick just responded, it’s faster to source the RAM or modify
the config to cut down on number of BGP prefixes rather than
ping back and forth here discussing all the possibilities.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

Re: announcement of freerouter

[Łukasz Bromirski]

> On 31 Dec 2015, at 01:54, Jimmy Hess  wrote:
> 
>> On Tue, Dec 29, 2015 at 1:29 PM, Mel Beckman  wrote:
>> Amazing what the proprietary appropriation of a single Word can do :)
> 
> Yes I'm quite bothered by that.   As far as I'm concerned  "Router
> OS"  refers to whatever operating system drives a router.

I believe Mikrotik is using "RouterOS" and "RouterBOARD" as registered 
trademarks, not generic "router os".

The problem however is, that according to google search (I may be wrong here), 
the trademark was eventually never registered:

https://trademarks.justia.com/771/58/routeros-77158105.html

Anyway, let's concentrate on the source code and solution provided (further 
referred as "meat"), and let parties involved sort out the trademarks, 
copyrights and other issues (further referred as to "slack" ;)) themselves.

-- 
./

Re: eBay is looking for network heavies...

[Łukasz Bromirski]

 On 06 Jun 2015, at 02:26, Jared Mauch ja...@puck.nether.net wrote:
 
 
 On Jun 5, 2015, at 7:13 PM, John Fraizer j...@op-sec.us wrote:
 
 Head of line for CCIE / JNCIE but knowledge and experience trumps a piece
 of paper every time!
 
 Can you please put these at the back of the line?  My experience is that
 the cisco certification (at least) is evidence of the absence of actual
 troubleshooting skills.  (or my standards of what defines “expert” are
 different than the rest of the world).

Jared, don’t generalize.

True - there are people that are ‘paper’ CCIE/JNCIEs - but let’s not
start a rant unless you've met tens of CCIEs/JNCIEs and all of them
didn’t know a jack. About troubleshooting.

— 
CCIE #15929 RS/SP, CCDE #2012::17
(not that I’d know anything about troubleshooting of course)

Re: BGP offloading (fixing legacy router BGP scalability issues)

[Łukasz Bromirski]

Hi Frederik,

 On 09 Apr 2015, at 13:24, Frederik Kriewitz frede...@kriewitz.eu wrote:
 
 Thank you very much for all your responses.
 
 First of all, the problems we see are really RIB (Processor memory)
 and CPU related.
 The TCAM/FIB limits are properly configured. From the FIB capacity
 view they should last a couple of more years. Software routing doesn't
 cause the problem.
 The most extreme case of Cisco 6500/SUP720 abuse I'm aware of is a
 setup with 4 full table transit connections + 2 RR sessions + ~20
 peerings, no downstreams. Besides the IPv4 and IPv6 peerings it's
 pretty much only handling a small amount of OSPF and MPLS (5k
 prefixes ~500 routers). No netflow or any other memory hog. Under
 normal condition it's running at 20% CPU and 90% processor memory
 (1G/SUP720 XL).

The main limit here apart from the rather slow CPU for RP is
the amount of memory you can have. I’d setup a CSR1000v as RR
and offload the 6500 from the control-plane completely. It’s nice
box to do very fast hardware forwarding as long as the FIB fits
in the TCAMs, which it seems it does in your scenario.

 In case a session with a lot of prefixes (e.g. a transit) fails, it
 takes up to 5 minutes for the BGP Router process to recompute the RIB,
 etc.. During that time it's running at 100% CPU. Low priority
 processes are completely ignored (e.g. SNMP based monitoring stops
 working). Occasionally it even drops OSPF neighbours or other BGP
 sessions due to expired hold timers causing further havoc.

You can tune this with process time tweaks.

 Applying a /22 filter was suggested. In order to actually safe the RIB
 memory we would have to disable soft-reconfiguration on the
 corresponding sessions.
 I don't like that option for various reasons as it trades less memory
 usage for longer convergence times and significant bigger impacts on
 route map updates.
 Due to the IPv4 exhaustion we expect to see more small prefixes in the
 future which can't be aggregated (considering the AS path). Simply
 dropping them would result in less optimal routing.

If you have to filter somewhere on something, I’d rather try to filter
by AS_PATH (neighbors, etc) than prefix lengths.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.

[Łukasz Bromirski]

Hi Blake,

On 10 Jun 2014, at 19:04, Blake Hudson bl...@ispn.net wrote:

 In this case, does the 512k limit of the 6500/7600 refer to the RIB or the 
 FIB? And does it even matter since the BGP prefix table can automatically be 
 reduced to ~300k routes?

Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600
Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for
1M IPv4 prefixes.

You can find more information here:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html

And yes, you’re right - no matter how many neighbors you have, the FIB
will only contain best paths, so it will be closer to 500k entries in
total rather than N times number of neighbours.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.

[Łukasz Bromirski]

On 10 Jun 2014, at 19:39, Blake Hudson bl...@ispn.net wrote:

 And yes, you’re right - no matter how many neighbors you have, the FIB
 will only contain best paths, so it will be closer to 500k entries in
 total rather than N times number of neighbours.
 Please correct me if I'm wrong, but if the BGP table contains ~500k prefixes, 
 which are then summarized into ~300k routes (RIB), and the FIB contains only 
 the best path entries from the RIB, wouldn't the FIB be at or below 300k?

Because you need to do your own summarization or ask your upstreams
to do it for you. Until then, most of transit accepts loosely
prefixes in exact length but also longer (i.e. /24 but also both /25s).

You’ll see more and more deaggregation with the rise of smaller
entities fighting for chance to do some traffic engineering, so be
prepared to constant rise of prefixes overall.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality)

[Łukasz Bromirski]

On 13 May 2014, at 14:17, coy.h...@coyhile.com wrote:

 It could be worse! Somebody might have thrown a 'v1' in there, too, Joel!

Well - just imagine that network without mask.

On public list.

Horrible.

Thankfully, we have civilization  stuff, so nothing like that couldn’t
have had happened.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Requirements for IPv6 Firewalls

[Łukasz Bromirski]

On 19 Apr 2014, at 20:08, George William Herbert george.herb...@gmail.com 
wrote:

 On Apr 18, 2014, at 9:10 PM, Dobbins, Roland rdobb...@arbor.net wrote:
 
 You can 'call' it all you like - but people who actually want to keep their 
 servers up and running don't put stateful firewalls in front of them,
 
 I don't know where you find ideas like this.

From real world.

 There are stateful firewalls in the security packages in front of all the 
 internet facing servers in all the major service providers I've worked at.  
 Not *just* stateful firewalls, but they're in there.

There’s no sense in putting stateful firewall in front of DNS server,
unless the DNS server is underperforming, and then it should be
exchanged and not protected by stateful firewall.

You can try to protect mail/WWW servers with stateful firewalls, but
it often achieves nothing but makes the firewalls weakest link in
the setup. And tuning it to perform reasonably well in normal and
peak traffic is usually not achievable.

In case of DDoS attack, the stateful firewall goes out first. I’ve
seen them burn too. To protect high-performance services, you do
stateless filtering + NetFlow based QoS policies, or shunt to
dedicated DDoS filtering boxes.

Adding state where it’s not needed, is sign of bad design. And just
because a lot of people do that, doesn’t make it any better.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Real world sflow vs netflow?

[Łukasz Bromirski]

On 7/13/12 10:20 PM, Peter Phaal wrote:


1. NetFlow: Packets are decoded on the router, flow keys are extracted
and used to lookup/create an entry in a flow cache which is then
updated based on values in the packet. Records are exported from the
flow cache in the form of Netflow datagrams when the flow completes or
based on a timeout.


This is because NetFlow is based on the Flows, where sFlow name is
misleading - it's actually PACKET monitoring technology, not FLOW
monitoring. So the difference in the way both mechanisms work is
inline with their definition.


2. sFlow: Packets are randomly sampled in hardware and the packet
headers are immediately exported as sFlow datagrams - there is no flow
cache on the switch/router.


And that's the biggest problem with sFlow. Packets are sampled, not
flows. You may miss the big or important flow, you don't have
visibility into every conversation going through the device.

sFlow and randomized sampling rely heavily on statistics, but as soon
as you agree on that, you'll loose accuracy right away.


Moving the flow cache off the router has a number of benefits:
1. You are no longer limited by the hardware/firmware capabilities of
the router - your analysis software decides which fields to decode and
how to accumulate results. For example, if you are managing a mixed
IPv4/IPv6 environment you can decide to use sFlow to look into v6 over
v4 and v4 over v6 tunnels (to do the same thing with Netflow would
likely require a hardware upgrade). You can even feed sFlow into
Wireshark for detailed analysis of protocols and packet headers.


NetFlow supports IPv6. As well as L2 traffic (v9), MPLS, multicast and
so on.


2. Operational complexity is greatly reduced since the configuration
options and resource management issues associated with the flow cache
are eliminated.


That will depend on the device and the options. It takes around
3-4 commands to configure the export and then one to activate
it without any templates on a interface on Cisco device.

What's more important, you can have multiple monitors on one
interface monitoring  exporting different sets of traffic to
different groups within company (Security, Network Monitoring,
Trafic Engineering). sFlow gives just sampled packets.


3. Low latency. Measurements aren't delayed by the flow cache - you
can detect DDoS attacks/large flows within seconds.


The same with NetFlow. Cache can be actively flushed.


4. Scalability - you can turn on sFlow on every link (even 100G
links), on every device for a comprehensive view of traffic.


Same with NetFlow  sampling turned on.


However, there are a wide range of Netflow
sampling implementations, many of which yield questionable results. In
contrast, the sFlow standard specifies how sampling must be performed
and ensures that information is included that allows the sampled data
to be correctly scaled and produce unbiased measurements.


The measurements provided by sFlow are only approximation of the real
traffic and while it may be acceptable on LAN links where details don't
matter as much, it's hardly good enough to present a real view on the
WAN links.

sFlow was built to work on switches and provide some accuracy, it's
not good enough (unless you do sampling on a 1:5-1:10 basis) to
do billing or some detailed analysis of traffic:

http://www.inmon.com/pdf/sFlowBilling.pdf

You can use it to *estimate* the traffic, detect DDoS, sure. But the
data  scaling used by sFlow (and additionally tricks used by ASIC
vendors implementing it in the hardware) can't change the fundamental
difference - sFlow is really sPacket, as it doesn't deal with flows.

NetFlow, jFlow, IPFIX deal with flows. You can discuss sampling
accuracy and things like that, but working with flows is more accurate.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Real world sflow vs netflow?

[Łukasz Bromirski]

On 7/14/12 11:15 AM, Mikael Abrahamsson wrote:

On Sat, 14 Jul 2012, Łukasz Bromirski wrote:


NetFlow, jFlow, IPFIX deal with flows. You can discuss sampling
accuracy and things like that, but working with flows is more accurate.


If you do 1:1000 sampling with both Netflow and sFlow, why would one of
them be more accurate than the other? If you analyze the flow on the
device or on the collector (as might be done with sFlow), I don't see
why one would be btter than the other.


Sure, but with sampling you'll loose accuracy anyway. The difference is
subtle, and depends on the (Net|j)Flow implementation - on some devices
for sampled NetFlow you'll still get sampled FLOWS (1:x) not sampled
PACKETS (thus disregarding the flow advantage).

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Łukasz Bromirski]

On 2012-03-12 22:14, Iljitsch van Beijnum wrote:

On 12 Mar 2012, at 21:15 , William Herrin wrote:


Not at all. You just build a second tier to the routing system.


It's so strange how people think a locator/identifier split will solve

 the scalability problem. We already have two tiers: DNS names and IP
 addresses. So that didn't solve anything. I don't see any reason a
 second second tier would.

Wrong analogy IMHO.

Using it, you'd know how to get to specific host in IPv4/IPv6-centric
Internet by looking up it's name. Knowing a host is 'thishost.org'
doesn't give you information needed to route IPv4/v6 packets that we
still use, to this specific system. You still need to lookup the IP
assigned to this name.

For LISP (other solutions may vary obviously) knowing node 54.100 is
available (after lookup) currently at 200.101 makes possibility for
core routers to only remember the paths to 200.101/16 and not
thousands of this prefix aggregates. This is aggregation of information
at the same level of lookup execution.

The real problems for world-wide LISP adoption are currently:
 - nobody sees a FIB explosion for IPv6, because
 - only around 8k worth of prefixes is in the global IPv6 table

Hardly a reason for anyone to implement aggregation. If IPv6 would
reach todays IPv4 level of 400k it would be still not a very compelling
reason apart from those SPs willing to run all their edge without MPLS
and with L3 devices that have very tiny FIBs - like 2/4/8k of entries.
Typical core router has ability to forward 2-3M of IPv4 prefixes in
hardware, and around 500k-2M of IPv6 prefixes in hardware - today.

Ideal LISP use case would be for example 4M of IPv6 prefixes with
steady clearly visible growth. Aggregating this down to for example
(I've made this completely up) 200k prefixes and still having
ability to traffic engineer the paths between the source and destination
almost at the levels of having all 4M prefixes in FIB is very compelling
reason to deploy LISP.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: 10GE TOR port buffers (was Re: 10G switch recommendaton)

[Łukasz Bromirski]

On 2012-01-28 01:00, Joel jaeggli wrote:


C NSP has been full with threads about appalling microburst
performance of the 6500 for years..

And people who care have been using something other than a c6500 for
years. it's a 15 year old architecture, and it's had a pretty good run,
but it's 2012.
An ex8200 has 512MB per port on non-oversuscribed 10Gig ports and 42MB
per port on 1Gig ports. that's a lot of ram.


6500 has up to 256MB for non-oversubscribed 10GE ports. People
complaining about microburst tend to use the cheapest 6704 linecard,
and 'microbursts' are a problem seen across most of the products that
don't even try to have a 1/12th of a 6500 history.

Everyone has it's own problems, and as people already said, not
understanding the way properly sized buffers influence the way TCP
traffic behaves can do more harm than good.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Howto for BGP black holing/null routing

[Łukasz Bromirski]

On 2011-02-22 22:42, David Hubbard wrote:

I was wondering if anyone has a howto floating around on the
step by step setup of having an internal bgp peer for sending
quick updates to border routers to null route sources of
undesirable traffic?  I've seen it discussed on nanog from
time to time, typically suggesting using Zebra, but could
not search up a link on a step by step.


Take a look here for starters:
http://www.cisco.com/web/about/security/intelligence/blackhole.pdf

Searching through NANOG archives will return a couple of sessions
that went through the other vendor configs for such functionality.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Switch with 10 Gig and GRE support in hardware.

[Łukasz Bromirski]

On 2011-02-18 15:37, Jeffrey Lyon wrote:


I am looking for a switch with a minimum of 12  X 10GE ports on it,

 that can has routing protocol support and can do GRE in hardware.

Yes, Juniper EX4500.


Interesting:
http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/general/ex-series-l3-protocols-not-supported.html

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

Re: Vyatta as a BRAS

[Łukasz Bromirski]

On 2010-07-15 19:22, Dennis Burgess wrote:

RouterOS is a software based router, we have them all over the world as
CORE and EDGE routers to networks.


Wonderful, congratulations.

 Some of our hardware can hit multi-gig speeds, BGP etc.

Same can do your competitors.


We commonly replace 7206VXRs.


Sad story, really. And I bet 7200VXRs commonly replace RouterOS.

 Does some other form of DoS attack have an effect on it, sure, but
 as long as you have enough CPU to weather the storm you normally
 don't have major issues.

Sure, a lot of people were at this point of their learning curve,
pretty sure that they will withstand anything with their multi-GHz,
multi-core CPUs. Then they met real world, or as it is often said,
real world met them.

(and I'm all for FreeBSD boxes, don't get me wrong, the whole point
 of this discussion is that either you're doing hardware forwarding
 and you're pretty safe [unfortunately often with a lot of caveats,
 but still], or you're doing software forwarding and you have
 a nice attack vector open for anyone willing)

--
Everything will be okay in the end.  | Łukasz Bromirski
 If it's not okay, it's not the end. |  http://lukasz.bromirski.net

Re: Using private APNIC range in US

[Łukasz Bromirski]

On 2010-03-18 19:35, Jared Mauch wrote:

 http://www.google.com/search?q=1.2.3.4+site%3Acisco.com
 I know that the University of Michigan utilize 1.2.3.4 for their
 captive portal login/logout pages as recently as monday when I was
 on the medical campus.

A lot of cheap, low-end devices (sometimes with names of well-know
vendors) use IPs like 1.1.1.1 and 1.2.3.4 as captive portal IPs to
authenticate connecting clients. A lot of WLAN hotspots users will
have problems reaching 1/8 unless they connect via VPN to corporate
and browse from there or something like that. The question is how
soon 1/8 will have interesting content to serve, as I know at least
one popular hotel chain in Europe using 1.1.1.1.

-- 
Everything will be okay in the end.  | Łukasz Bromirski
 If it's not okay, it's not the end. |  http://lukasz.bromirski.net

Re: D/DoS mitigation hardware/software needed.

[Łukasz Bromirski]

On 2010-01-05 03:17, Tim Eberhard wrote:
 Kinda funny you state that Roland. I know of at least two very large
 carriers that uses Netscreens (and soon SRX's) for their DoS/DDoS
 mitigation.

You mean Juniper SRX? The biggest box is a 5800, and it can handle
up to 350k new sessions each second, up to maximum of 10 million
(let's skip the fact that it's not that simple as it would look from
the data sheet and there are major obstacles from reaching the
numbers).

350kpps of TCP SYNs or whatever more wiser your botnet controller
will generate, coming to your Internet pipe is really a small,
very small DDoS. In terms of short packets like TCP SYN
it's only around 179Mbit/s worth of bandwidth.

Roland is right. Given finite resources to hold and process
stateful information, the stateful device on a packet way to protected
device is always vulnerable itself to become DDoSed. You can't discuss
the logic of that, you can only throw more capable boxes and of course
fail at some point.

-- 
Everything will be okay in the end. |  Łukasz Bromirski
 If it's not okay, it's not the end. |   http://lukasz.bromirski.net

Re: ASA5580-20 with IOS software

[Łukasz Bromirski]

On 2009-12-06 02:42, frogmanc...@gmail.com wrote:

Does anyone have experience using an ASA5580-20 with IOS software? On
top of that, using it as a headend for an Easy VPN solution? I am trying
to figure out how many sites it can safely support, also are there any
major problems with it? All of the documentation on Cisco's site only
talks about using it with ASA software, but then it only supports Legacy
Easy VPN and not Enhanced Easy VPN. In order to support Enhanced you
have to run IOS.


ASA doesn't run IOS, it runs ASA OS/PIX OS, so there's no selection
to choose from. Ask this question again on cisco-nsp@, this isn't
a 'product/vendor selection list'.

--
Everything will be okay in the end. |  Łukasz Bromirski
 If it's not okay, it's not the end. |   http://lukasz.bromirski.net

Re: Layer 2 vs. Layer 3 to TOR

[Łukasz Bromirski]

On 2009-11-12 22:37, David Coulson wrote:


The MX-series are pretty nice. That should be able to do VPLS PE,
however I've never tried it - MX240 did it pretty well last time I
tried. I've no clue how the cost of that switch compares to a cisco 4900
or something (not that a 4900 is anything special - L3 is all in software).


For both 4948/4948-10GE and 4900M L3 is in hardware. For
4948/4948-10GE IPv6 is in software, for 4900M it's in hardware.

--
Everything will be okay in the end. |  Łukasz Bromirski
 If it's not okay, it's not the end. |   http://lukasz.bromirski.net

Re: 32-bit AS numbers

[Łukasz Bromirski]

On 2009-10-10 12:36, Matthew Palmer wrote:


http://as4.cluepon.net/index.php/Main_Page

While it's good to see support _finally_ in 2.2SX, I still don't see it
in 12.2SR (for rsp720).  It's almost like Cisco has no idea how
many of these things are actually used on the Internet.

Or, more plausibly, they know exactly how many there are out there, and how
much they'd be able to make if everyone were forced to upgrade.


The 12.2SRE for RSP720 on 7600 is going to be available shortly and
it will support 4B ASNs. It was communicated a number of times on
cisco-nsp@ for those who subscribe it and did care.

But I see that conspiracy theory looks nicer.

--
Everything will be okay in the end. |  Łukasz Bromirski
 If it's not okay, it's not the end. |   http://lukasz.bromirski.net