Re: QUIC traffic throttled on AT&T residential
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: QUIC traffic throttled on AT&T residential
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: Sunday traffic curiosity
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: questions asked during network engineer interview
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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Re: BGP full feed for testing purposes
…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&S/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: BGP full feed for testing purposes
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
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: rsvp-te admission control - i don't see it
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: SRv6
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: SRv6
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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
SPAM for nanog@ senders
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: SPAM for nanog@ senders
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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Re: SPAM for nanog@ senders
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 :) — ./
BGP in the lab - v4 & v6 live feeds from Europe
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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Re: massive facebook outage presently
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
Re: IRR for IX peers
…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: Authoritative Resources for Public DNS Pinging
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: Mx204 alternative
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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Re: BGP peering strategies for smaller routers
> On 03 May 2016, at 22:31, William Herrin wrote: > > On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander > 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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Re: BGP peering strategies for smaller routers
Blake, > On 04 May 2016, at 00:23, Blake Hudson wrote: > > Łukasz Bromirski wrote on 5/3/2016 4:13 PM: >>> On 03 May 2016, at 22:31, William Herrin wrote: >>> >>> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander >>> 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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Re: MTU
> On 22 Jul 2016, at 19:37, Grzegorz Janoszka 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 Route Reflector - Route Server, Router, etc
> On 12 Jan 2017, at 21:32, Justin Krejci 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: Suggestion for Layer 3, all SFP+ switches
Colton, > On 19 Apr 2018, at 03:32, Colton Conor 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&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
Re: RTBH no_export
> 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: Requirements for IPv6 Firewalls
On 19 Apr 2014, at 20:08, George William Herbert wrote: > On Apr 18, 2014, at 9:10 PM, "Dobbins, Roland" 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: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality)
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: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
Hi Blake, On 10 Jun 2014, at 19:04, Blake Hudson 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.
On 10 Jun 2014, at 19:39, Blake Hudson 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: 10GE TOR port buffers (was Re: 10G switch recommendaton)
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: Cisco ASR1001
On 2012-03-02 22:39, david peahi wrote: I'm looking for experiences with Cisco ASR1001 as a border router, specifically BGP stability, # full BGP feeds (with 4 GB DRAM), does it perform according to wire speed acl/firewall/deep packet inspection specifications. Wire speed? You propably misread the data sheet. Look at table 1: http://www.cisco.com/en/US/prod/collateral/routers/ps9343/data_sheet_c78-450070.html The QFP will perform ACLs/DPI very fast, but not at wire speed for commonly used edge ACLs. There will be slight performance hit depending on the lenght of the ACLs and the complexity of the inspection. Also take note half of the theoretical RAM is reserved on start, so you end up running your system with 1GB of usable RAM, other 1GB taken during the start by the IOS-XE. For a lot of BGP peerings you should get at least 8GB to be on the safe side, but the default, cheapest 4GB will work fine with small number of full feeds. Also take note that this is hardware forwarding platform, so FIB size will come into play - not now, but given IPv6 growth, in future. ASR1001 has FIB for 1M of IPv4 *or* 1M of IPv6 prefixes, you'll need to check that from time to time (QFP memory usage that is). -- "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
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: Real world sflow vs netflow?
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?
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: announcement of freerouter
> 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: BGP offloading (fixing legacy router BGP scalability issues)
Hi Frederik, > On 09 Apr 2015, at 13:24, Frederik Kriewitz 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: eBay is looking for network heavies...
> On 06 Jun 2015, at 02:26, Jared Mauch wrote: > > >> On Jun 5, 2015, at 7:13 PM, John Fraizer 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 R&S/SP, CCDE #2012::17 (not that I’d know anything about troubleshooting of course)
Re: 32 bits ASN on Cisco
On 2010-04-11 12:15, Franck Martin wrote: > To come back, to your statement that says it is just supported on 7200, > means you cannot use a 32bit ASN in production today on any hardware? It doesn't mean anything like that. As the software is available for some time already, you can run 32bit ASN in production today, and actually people do that. Nothing fancy. For the list of software versions supporting 32 bit ASN please referer to this document: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html But yes, you can't run it on 2500 and 2600 as they're for long time End of Life/Engineering/Support/Everything. -- "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 bits ASN on Cisco
On 2010-04-11 13:15, Franck Martin wrote: > This is the document I quoted in my first email. > ok for 2500, 2600 they are EOL, but still out there.. A lot of boxes is still out there, sure. Some of them can't be upgraded, and it is not a problem unique only for Cisco. > but Gary says the software is too new to be used on > prod, and you say there is no problem. I didn't say there's no problem with the software - depending on your network size, features, load and millions other characteristics, some of the software may be unusable, where others will say "it works for me". 7600 guys should follow 12.2SR track, so the 12.2(33)SRE and rebuils are natural way of going forward. ISR guys (access) are usually implementing a multiservice boxes, so need new features - and they appear in 15.0(1)M, as entire 12.4T line is going EoS/EoL soon. For the legacy platforms, like 1600, 1700, 2600, 3600, 3700 the last software that runs is 12.4(15)T and rebuilds - and while it's unfortunate they don't support 32 bit ASNs, they reached EoS status before the feature was implemented, so according to Cisco rules, no new features can appear in EoSed software, only fixes. In reality, you either test yourself if the software is OK for your network, or pay for such tests/audit. While the line 'trust your vendor' looks nice, people usually do test before deployment. So you may get thousands of different opinions what's working and what is not, but for such discussions it would be better to move to cisco-...@. -- "Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end." | http://lukasz.bromirski.net
Re: Vyatta as a BRAS
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: 32-bit AS numbers
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
Re: Layer 2 vs. Layer 3 to TOR
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: ASA5580-20 with IOS software
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: D/DoS mitigation hardware/software needed.
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: BGP testbed tools
On 2010-01-12 21:27, Ben Jencks wrote: > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. Use libbgpdump from ris.ripe.net to get raw data from http://data.ris.ripe.net/ (you're looking for newest bview file), and dump them using bgpdump to something easily to parse. Then using bgpsimple (from googlecode) simulate a peer with specific number of prefixes advertised - up to the limit of the contents of the file. You can spoof next-hop, AS, etc. As for the attribute manipulation, fire up a couple of VMWare/VirtualBox/vimage instances with quagga/openbgpd to accept the prefixes from bgpsimple and mangle them in some manner. Here you go. -- "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
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: Switch with 10 Gig and GRE support in hardware.
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: Howto for BGP black holing/null routing
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: 7206 NPE-G2 with 4 full table feeds
On 2011-06-01 21:09, Eric Morin wrote: Hi I have an application where I have a 7206 with NPE-G2 (1G RAM) that currently has a full table from an eBGP peer and a full table from a co-located IBGP peer. I want to mesh this guy to two other IBGP peers that will also send their full tables. There is roughly 400Mbps (adding both direction) with an OSPF process (<30 routes) and an ISIS process (<20 routes). First of all - cisco-nsp@ is a better place to ask such question and if you search archives of it, you'll find a lot of comments for such config. I haven't been very successful at finding real life BGP scaling for this platform and was hoping that someone out there may be doing something similar (4 x full table feeds with ~400Mbps) and can provide feedback on performance and/or stability. I have soft reconfig inbound enabled on the current two feeds, I assume that this will make a difference in this application with regards to available memory for all 4 feeds? With 1GB of RAM you may run short (check current actual usage), but I'd recommend in such situation to rely rather on the route refresh standard capability, than the soft reconfig - it eats memory per-peer, and with route refresh you can get almost the same, trading bandwidth on the link for RAM in the RP. NPE-G2 can take 2GB of RAM, so if that's going to stay I'd also recommend upgrading if you're running short of memory either way. Or upgrade to ASR 1k and move into the world of hardware-forwarding platforms. -- "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
