<div dir="auto">For some reason our network looks nothing like that. He either needs to define what a PoP is or define a module that does not have expensive gear like two redundant routers at every location. <div dir="auto"><br></div><div dir="auto">Regards </div><div dir="auto"><br></div><div dir="auto">Baldur </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">tir. 4. jun. 2019 15.46 skrev Mehmet Akcin <<a href="mailto:mehmet@akcin.net">mehmet@akcin.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This Gem is fantastic by the way,<div><br></div><div><a href="https://nsrc.org/workshops/2015/apricot2015/raw-attachment/wiki/Track1Agenda/01-ISP-Network-Design.pdf" target="_blank" rel="noreferrer">https://nsrc.org/workshops/2015/apricot2015/raw-attachment/wiki/Track1Agenda/01-ISP-Network-Design.pdf</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 4, 2019 at 5:57 AM Warren Kumari <<a href="mailto:warren@kumari.net" target="_blank" rel="noreferrer">warren@kumari.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 3, 2019 at 11:34 PM Brandon Martin <<a href="mailto:lists.nanog@monmotha.net" target="_blank" rel="noreferrer">lists.nanog@monmotha.net</a>> wrote:<br>
><br>
> On 6/3/19 9:56 AM, Jon Lewis wrote:<br>
> > 3) Don't advertise one transit provider's routes to another. Each should<br>
> > be filtering your routes, but you never know. Come up with, and use<br>
> > BGP communities to control route propagation. As you grow, it sucks<br>
> > having to update prefix-list filters in multiple places every time<br>
> > something changes...like a new customer with their own IPs.<br>
><br>
> To reiterate all this, FILTER EVERYTHING.<br>
><br>
> To start with, explicitly specify in a route-map or similar everything<br>
> you want to advertise. I usually create a separate route-map for each<br>
> transit/peer and include what I want to advertise via prefix lists (for<br>
> my IP space) and/or communities (for downstream BGP-speaking customers<br>
> if anticipated).<br>
<br>
I think a related *principle* is: "Build everything as though you are<br>
expecting to scale."<br>
<br>
This doesn't mean "spend lots of money to buy huge<br>
[routers|servers|commercial software|<etc>], but rather "when you plan<br>
your addressing structure and routing policies and monitoring and<br>
device config generation and... keep the in mind the question "If this<br>
suddenly takes off, and I hire N more people to run this, can I<br>
explain to them how it works? Do I have documentation I can point them<br>
at or is it stuck in my head / on the devices? If I need to add<br>
another M customers in the next month, can I do that easily?".<br>
<br>
This is related to the FILTER EVERYTHING -- when you turn up a new<br>
customer / peer / transit / whatever, you shouldn't be sitting around<br>
trying to figure out how you will write their route-map /<br>
policy-options -- this leads to weird one-offs, and quick hacks.<br>
Instead you should have policies already largely designed and simply<br>
plug in their prefixes (or, better yet, use bgpq3 or similar to build<br>
and populate these). Obviously there will be some cases where a new<br>
connection does require some special handling, but that *should* just<br>
be a plugin/chain in an existing policy-statement. Related to this is<br>
how you end up naming things -- I recently found 9 variants of<br>
firewall-filters which basically do:<br>
<br>
filter ACCEPT {<br>
term ACCEPT {<br>
then accept;<br>
}<br>
}<br>
named things like: ACCEPT, ACEPT, Accept, Allow, Permit_all,<br>
AcceptAll, dontdrop [0].<br>
<br>
Obviously, there is a tension in the "design for scale" - while it<br>
would be great to design a complete automation system so that<br>
everything from installing a new customer to a new sites is simply<br>
typing 'make <thing>' and having everything pull from a database, at<br>
some point you will need to actually build a network, or you'll never<br>
have customers :-) Just keep in mind that "Am I building myself into a<br>
corner here?". E.g it only takes 10 or 15 minutes to install something<br>
like NetBox to keep track of addresses (and prefixes and racks and<br>
connections and ...) -- stuffing this in a spreadsheet might save you<br>
a few minutes *now*, but will this scale? Can $new_person easily<br>
figure it out?<br>
<br>
<br>
W<br>
[0]: My personal favorite is:<br>
filter Accept_All {<br>
term Accept {<br>
then {<br>
count dropped;<br>
reject;<br>
}<br>
}<br>
term filter_<customer> {<br>
from {<br>
prefix-list {<br>
<customer>;<br>
}<br>
}<br>
then accept;<br>
}<br>
term NEXT {<br>
then log;<br>
}<br>
}<br>
<br>
Presumably this all made sense to <name_removed_to_protect_inoccent><br>
when they stuck it in at 3AM to deal with some crazy issue, but...<br>
<br>
<br>
<br>
><br>
> When you turn on the session, check what you're squawking AND WHAT<br>
> YOU'RE FILTERING. You shouldn't be filtering anything you don't expect.<br>
> Belt + suspenders.<br>
><br>
> The same goes for anything you accept. Obviously for a blended full<br>
> transit BGP edge router, you're probably going to accept almost<br>
> everything. But if you only want default + on-net, try to filter using<br>
> communities from the peer, etc. Again, right when you turn on the<br>
> session, "sh ip bgp ... filtered" of whatever's equivalent on your<br>
> platform. If you're filtering something you don't expect to be<br>
> receiving at all, figure out where the misunderstanding or<br>
> misconfiguration lies.<br>
><br>
> And of course it goes without saying that, if you've got BGP speaking<br>
> customers, you filter the heck out of them. Use ROAs and/or RPKI if you<br>
> can to automatically generate filter lists. Encourage your upstreams to<br>
> do the same if they're filtering you (and they probably are, or at least<br>
> should be, if you're new). Remember that you are responsible for every<br>
> route you advertise, at the end of the day, even if you only advertised<br>
> it because a downstream network made a boo-boo and you didn't filter it.<br>
><br>
> Filters are useful on your IGP, too, but there's so many ways to set all<br>
> that up that it's a bit more difficult to come up with nearly universal<br>
> best practices. Generally speaking, be careful with redistribution,<br>
> never distribute BGP into IGP or vice versa unless you have a really,<br>
> really good reason to, and consider filters between both IGP<br>
> areas/regions or protocols (e.g. RIP coming into OSPF) as well as on<br>
> redistributions of static/connected to prevent simple typos on a static<br>
> route or interface configuration from taking down more than just local<br>
> stuff.<br>
><br>
> It's way, way easier to remove or relax filters later if they prove more<br>
> of an operational hazard than asset than it is to add or tighten them if<br>
> they prove insufficient.<br>
> --<br>
> Brandon Martin<br>
<br>
<br>
<br>
-- <br>
I don't think the execution is relevant when it was obviously a bad<br>
idea in the first place.<br>
This is like putting rabid weasels in your pants, and later expressing<br>
regret at having chosen those particular rabid weasels and that pair<br>
of pants.<br>
---maf<br>
</blockquote></div>
</blockquote></div>