Using Old Cisco Routers as Console Servers

2022-05-11T00:00:00+00:00

Serial Ports §</a> </h1>
Ah, yes, the network admin's best friend. A Serial Port.
While serial ports come in many varieties, the most common standard is `RS-232</code> (or rather the modern variant of it). It describes communication between a DTE (Data Terminal Equipment) and DCE (Data Communication Equipment).`
`The distinction is important as the wiring for the DB-25M</code> or DE-9M</code> differed for each end. However, at some point, someone (probablyYost</a>) came up with a way to use 8P8C</code> connectors have it all use the same pinout. These cables and adapters have been called many things:`
Rollover cable</li> Cisco Cable</li> Yost Cable</li> (Cisco) Console Cable</li> </ul> You can connect two 8P8C</code> serial ports between anything together without worring what function it is. Nowadays, the "DTE" will be a laptop with a serial dongle and the "DCE" will be a router/switch/... Pretty much all serial ports will be 8P8C</code>. Oh, don't plug in your ethernet port into an 8P8C</code> serial port. Bzzzt Serial Data§</a> </h1> First, the most important thing: Almost everything is 8N1</code> nowadays: 8 Databits</li> No Parity</li> 1 Stop bit</li> </ul> Usually, serial consoles have one of the following two common speeds: 9600</code> or 115200</code> Baud. Here are some general guidelines: Cisco, Juniper, HP, Ubiquiti.. consoles usually run at 9600 Baud.</li> Mallanox (and Linux) consoles run at 115200</code> Baud quite often.</li> </ul> When in doubt, try 9600</code> first, then 115200</code>, then look at the manual. :) Attaching Serial Consoles to Cisco Routers§</a> </h1> There are several ways to attach another device with a serial port to a cisco router. These are the ones I recommend: AUX</code> port: 1 port (usually)</li> </ol> This is undoubtedly the simplest choice.</li> Simply connect the AUX</code> port to other 8P8C</code> console ports.</li> </ul> HWIC-8A</code> + CAB-ASYNC-8</code>/CAB-HD8-ASYNC</code>: 8 ports per HWIC</li> </ol> Good option if you have a router that takes (E)HWIC cards and you find it cheap.</li> 8 ports are okay, but the following option is more "future proof".</li> </ul> HWIC-16A</code> + 2x CAB-ASYNC-8</code>/CAB-HD8-ASYNC</code>: 16 ports per HWIC slot</li> </ol> Excellent option if you have a router that can take (E)HWIC cards.</li> One module gets you 16 serial ports, so a single card should be more than enough for homelab purposes.</li> Can buy one CAB-ASYNC-8</code>/CAB-HD8-ASYNC</code> at a time for 8 ports per.</li> </ul> SM-32A</code> + 4x CAB-ASYNC-8</code>/CAB-HD8-ASYNC</code>: 32 ports per NM slot</li> </ol> If you have one of those chonkers with a Network Module slot.</li> A whopping 32 serial ports! And rather cheap, too.</li> Can buy one CAB-ASYNC-8</code>/CAB-HD8-ASYNC</code> at a time for 8 ports per.</li> </ul> NIM-16A</code> + 2x CAB-ASYNC-8</code>/CAB-HD8-ASYNC</code>: 16 ports per NIM slot</li> </ol> If you have more modern equipment, this is an option.</li> Not quite cheap.</li> Can buy one CAB-ASYNC-8</code>/CAB-HD8-ASYNC</code> at a time for 8 ports per.</li> </ul> NIM-24A</code> + 3x CAB-ASYNC-8</code>: 16 ports per NIM slot</li> </ol> Like the above, but one more slot.</li> Even less cheap and requires the new cables to fit all three.</li> Can buy one CAB-ASYNC-8</code> at a time for 8 ports per.</li> </ul> You definitly want something with not-stone-age IOS for modern crypto. Line Config§</a> </h1> You're gonna need to configure the serial ports first. The following is on an ISR G2, specifically the 2901, with the HWIC-16A</code>. ! AUX port config. 115200 8N1 on rotary 10 with DCD. line aux 0 login local modem Host rotary 1 no exec transport input ssh transport output none stopbits 1 speed 115200 ! HWIC slot 0, first cable, first port. 9600 (default) 8N1 on rotary 100 with DCD. line 0/0/0 login local modem Host rotary 100 no exec transport input ssh transport output none stopbits 1 ! HWIC slot 0, second cable, first port. 9600 (default) 8N1 on rotary 108 with DCD. line 0/0/8 login local modem Host rotary 108 no exec transport input ssh transport output none stopbits 1 </code></pre> You might also need to exchange login local</code> with login authentication default</code> depending on your device. Cisco IOS also supports autobaud functionality. I couldn't get it to work decently. Instead, just configure it when you need it. (Reverse) SSH§</a> </h1> Make sure to configure SSH sanely: ! Generate keys if you haven't already. crypto key generate rsa modulus 3072 ! If using the Loopback interface, make sure it uses it. ip ssh source-interface Loopback0 ip ssh logging events ip ssh version 2 ip ssh dh min size 2048 ip ssh server algorithm mac hmac-sha2-512 ip ssh server algorithm encryption aes256-ctr ip scp server enable </code></pre> That'll make the whole thing less crappy security-wise at the cost of slightly longer initial handshake. If you have to impress your friends with your big keys, you can also choose 4096</code> bit instead of 3072</code> for neglible benefits, but this thing's probably a security nightmare anyway. If you want to configure an SSH key - which you do - keep in mind that it only really supports RSA, no Ed25519. Fetch your legacy RSA key's public key and wrap it below the 254 byte line limit IOS has. In this case, I chose 70 characters, like OpenSSH private keys, but 128 works as well.</li> </ol> cat .ssh/id_legacy_rsa.pub | sed -En 's/^ssh-rsa ([^ ]+).$/\1/p' | fold -b -w70 </code></pre> Enter the right mode to save it in the config.</li> </ol> stale(config)#ip ssh pubkey-chain stale(conf-ssh-pubkey)#username vifino stale(conf-ssh-pubkey-user)#key-string stale(conf-ssh-pubkey-data)# <PASTE LINES HERE > stale(conf-ssh-pubkey-data)#exit </code></pre> If you're using something above 12.3</code>, say 15.0</code>, you can use the feature described in Reverse SSH Enhancements</a>. tl;dr</code>: You can slap the rotary</code> number behind the username instead of selecting a specific SSH port. If that's not available, you don't like it or want more choice, you can configure seperate SSH ports for each of the rotaries: ! Enable rotary 1 on port 9001, rotary 2 on 9002, etc.. for all* rotaries. ip ssh port 9001 rotary 1 127 </code></pre> Use it!§</a> </h1> After you configured the ports with their rotary group, you can use it with the following two ways: ssh -u myuser -p 9100 serialbox</code></li> </ol> This accesses port 9100 via SSH, 9100 in my example maps to rotary 100</code>.</li> I prefer this. Target port gets closed if the line is in use - instant disconnect.</li> It'll also not be available if the line is down.</li> </ul> ssh -u myuser:$PORT serialbox</code></li> </ol> This accesses port 22 via SSH, but uses the Reverse SSH Enhancements</a> to access the line instead of a specific port.</li> What is $PORT</code>? Well. N</code> to dial line N</code> (see show line</code> for the mapping)</li> rotaryN</code> to dial rotary N</code> (e.g. rotary100</code>)</li> </ul> </li> You get spicy and confusing error messages! Wrong line number? Received disconnect from <addr> port 22:2: Non-assigned port!</code></li> Line in use? Received disconnect from <addr> port 22:2: Requested line not found!</code></li> </ul> </li> </ul> Personally, I prefer the former. Just my regular username, no special stuff except the target port. Either is fine, but I suggest using rotary groups in either case for less hassle when moving things around. Summary§</a> </h1> Apart from the quirks in the config and the slow speed of the SSH handshake with decent crypto, this works very well! With modem signals enabled (DCD), you can even trigger automatic logout on the target devices. For example, in Junos, you can configure the console port to do that: set system ports console log-out-on-disconnect </code></pre> Plus, if you're into retrocomputing, you can enable X.25</code> and use PAD features to dial into the same rotaries. Maybe I'll write a post about X.25</code> in general. Fun!

The Odd World of the DFZ - Fundamentals

2022-04-14T00:00:00+00:00

This is probably going to be a series of regularly updated posts trying to pass some knowledge about how to do your best at being a member of the Internet. These posts are also explicitly talking about eBGP with other networks instead of internal routing, though some information might still be applicable.

As I learn more about that myself, I'll update this post with some general advice. There will be other posts describing routing platforms/vendors and their quirks.

Be warned however that you need to know some basic networking terminology, for example what Network Prefixes and Routes are.

Trash or Treasure?§</a> </h2>
The millions of routes covering "the whole internet" are what make up the DFZ</a> - the Default-free Zone. When a router in the DFZ</a> needs to forward a packet to a destination it doesn't know about, it can't simply forward it to another one. Thus, getting all of the routes is crucial to ensure reachability.
Adjacent networks (ASN</a>s) announce to each other a subset of routes they know about and receive the same. Sometimes just a few routes they are resonsible for, sometimes all routes they know about.
However, to make that work, the Internet is built on varying degrees of mutual trust. This mesh relies heavily on the idea that almost every given route information is correct, up to date and not maliceous. If that's not the case, traffic towards some destinations might be slower than it has to be, doesn't reach the destination or even gets intercepted.
When you are a network operator in the DFZ</a>, you'll most likely end up with an ASN</a> and BGP</a> to route your prefixes. It does not matter if you are a big global ISP - like Lumen</a> or DTAG</a> - or a small research network (like me, AS213342</a>).
Trusting is nice, but mistakes happen. And sometimes, Route Hijacking</a> happens on purpose.

Trust but Verify.§</a> </h2>
It is clear that it is probably not a good idea to let anyone pretend to be anyone. Luckily for all Netizens, it is not quite Wild West out there.
Thanks to the IRR</a> and RIRs</a>, it's rather clear who owns what prefixes. Clearly we need to apply Route Filtering</a> to make sure the implicit trust given to us by others is not violated. We don't want mistakes to be propagated to others. That's what stops misconfiguration from becoming Route Hijacking</a>.

Route Filtering §</a> </h1>
When a BGP</a> peer announces a prefix to another, there are a lot of reasons why it may be incorrect or not desired.
Some reasons why a route announcement may be "incorrect" in the DFZ</a> are listed below. This is not the everything, it's really just meant as general examples to help you get started.

Invalid Next-Hops §</a> </h2>

Sometimes a router might announce routes with invalid next-hops to you. Say, internal IP addresses that you have no way to reach.

If your router receives a route that says X.Y.Z.0/24</code> is reachable via A.B.C.5</code>, it has to resolve that last IP to a MAC address to forward the Layer 3 information to it. When it can't figure out a way to reach the last IP, that route is invalid.

Most platforms will reject it or hide it and simply not consider it a valid route. This should be automatic.

Enforcing first AS

§</a>
</h2>
Unless you're peering with a Route Server on an IXP or something similar, routes announced to you via eBGP will contain the AS of the network that announced that route to you.</p>
This makes a lot of sense, as the traffic will flow through that network to reach the routes announced to you.</p>
However, routers being designed for flexibility and not knowing what type of peer you're peering with, usually don't default to enforcing that.
Turn it on for any eBGP peering sessions that isn't to a Route Server, as routes announced to you that don't have the peer AS prepended in that case are most likely accidental and/or invalid.</p>
The option is usually called enforce-first-as</code> or a variation of that.</p>
Default Routes§</a>
</h2>
This might seem obvious that the DFZ</a> - the Default-free Zone - shouldn't have defaults.
In the grand scheme of things, this is correct!</p>
However, upstreams may announce a Default Route in addition to a Full Table</a> or instead of one or another.
And there are several reasons why you might want that!</p>
Perhaps you just want a default route from a transit provider and peerings in addition to that.
This might be the case when you only have one upstream or two "equal" feeds.
Or when you are using a Layer 3 Switch or Router with a small FIB</a> instead of a full blown router, capable of carring the millions of routes.</p>
But, to save you some time, if you can accept a Full Table</a>, you probably should.</p>
This ensures that you have the best chance at finding the best path to a network instead of just a reasonable one.
If you don't have feeds from the same ISP twice - limiting your capabilities in terms of redundancy and high availability - it is highly likely that one has better routes to some network than the other.
If you plan on becoming an upstream, not carrying the entire DFZ</a> becomes unfeasable as well.
Therefore, if you're serious about that Internet thing, probably a wise choice to carry a Full Table</a>.</p>
Note that when you do so, you essentially become your own source of the Default Routes, which you can advertise to your own internal equipment or customers if they so desire.</p>
Bogon Prefixes§</a>
</h2>
Bogon Filtering</a> is a common practice and when filtering, kind of a low hanging fruit.
There are lots of network prefixes that are not supposed to be carried through the Internet.</p>
[edit]
</span>vifino@core1.fra1.de.as208431.net# show policy-options prefix-list BOGONS_V4
</span>apply-flags omit;
</span>/* RFC1122 'this' network */
</span>0.0.0.0/8;
</span>/* RFC1918 Private-Use */
</span>10.0.0.0/8;
</span>/* RFC6598 Shared Address Space/CGNAT */
</span>100.64.0.0/10;
</span>/* RFC1122 Loopback */
</span>127.0.0.0/8;
</span>/* RFC3927 Link Local */
</span>169.254.0.0/16;
</span>/* RFC1918 Private-Use */
</span>172.16.0.0/12;
</span>/* RFC6333 DS-Lite/IETF Protocol Assignments */
</span>192.0.0.0/29;
</span>/* RFC5737 TEST-NET-1 */
</span>192.0.2.0/24;
</span>/* RFC7526 6to4 Relay Anycast */
</span>192.88.99.0/24;
</span>/* RFC1918 Private-Use */
</span>192.168.0.0/16;
</span>/* RFC2544 Benchmarking */
</span>198.18.0.0/15;
</span>/* RFC5737 TEST-NET-2 */
</span>198.51.100.0/24;
</span>/* RFC5737 TEST-NET-3 */
</span>203.0.113.0/24;
</span>/* RFC5771 Multicast */
</span>224.0.0.0/4;
</span>/* RFC1112 Reserved */
</span>240.0.0.0/4;
</span>/* RFC8190 Limited Broadcast */
</span>255.255.255.255/32;
</span>
</span>
</span>[edit]
</span>vifino@core1.fra1.de.as208431.net# show policy-options prefix-list BOGONS_V6
</span>apply-flags omit;
</span>/* RFC4291 IPv4-compatible, loopback, et al */
</span>::/8;
</span>/* RFC6666 Discard-Only Address Block */
</span>0100::/8;
</span>/* RFC4048 OSI NSAP IPv6 mapping */
</span>0200::/7;
</span>/* RFC4291 Reserved by IETF */
</span>0400::/6;
</span>/* RFC4291 Reserved by IETF */
</span>0800::/5;
</span>/* RFC4291 Reserved by IETF */
</span>1000::/4;
</span>/* RFC4380 Teredo */
</span>2001::/32;
</span>/* RFC5180 Benchmarking */
</span>2001:2::/48;
</span>/* RFC7450 Automatic Multicast Tunneling */
</span>2001:3::/32;
</span>/* RFC4843 ORCHID */
</span>2001:10::/28;
</span>/* RFC7343 ORCHIDv2 */
</span>2001:20::/28;
</span>/* RFC3849 Documentation */
</span>2001:db8::/32;
</span>/* RFC7526 6to4 Relay Anycast */
</span>2002::/16;
</span>/* RFC2471 6bone */
</span>3ffe::/16;
</span>/* RFC4193 Unique Local Unicast */
</span>fc00::/7;
</span>/* RFC4291 Link Local Unicast */
</span>fe80::/10;
</span>/* RFC3879 old site local unicast */
</span>fec0::/10;
</span>/* RFC4291 Multicast */
</span>ff00::/8;
</span>
</span></code></pre>
These are not to be announced and not to be routed into the DFZ</a>. Never. Always invalid.</p>
Well, with the exception of Teredo</a>, depending on your understanding, but honestly, that ship has sunk. Reject it when coming from external sources.</p>
Bogon ASNs§</a>
</h2>
Like Bogon Prefixes, Bogon ASNs are ASN</a> that are not supposed to be in the DFZ</a>.</p>
Job Snijders</a> has done the Internet a favour and compiled Bogon ASN Filter examples for several vendors.
See bogon-asn-filters</a> for up to date examples.</p>
Another Juniper example:</p>
[edit]
</span>vifino@core1.fra1.de.as208431.net# show policy-options as-path-group BOGON_ASNS
</span>/* RFC7607 */
</span>as-path zero ".* 0 .*";
</span>/* RFC4893 AS_TRANS */
</span>as-path AS_TRANS ".* 23456 .*";
</span>/* RFC5398 Documentation/Example ASNs */
</span>as-path examples1 ".* [64496-64511] .*";
</span>as-path examples2 ".* [65536-65551] .*";
</span>/* RFC6996 Private ASNs */
</span>as-path reserved1 ".* [64512-65534] .*";
</span>as-path reserved2 ".* [4200000000-4294967294] .*";
</span>/* RFC6996 Last 16-bit ASN */
</span>as-path last16 ".* 65535 .*";
</span>/* RFC6996 Last 32-bit ASN */
</span>as-path last32 ".* 4294967295 .*";
</span>/* IANA Reserved ASNs */
</span>as-path iana-reserved ".* [65552-131071] .*";
</span>
</span></code></pre>
When you receive a route with them in the path, you should reject them.
You should also make sure your announcements strip all your private ASNs, but don't do it for your customers or peers.</p>
Too Big or Small Networks§</a>
</h2>
Some prefix sizes just have no business in the DFZ</a>.</p>
For IPv4, a longer prefix length than a /24</code> is not considered routable. So anything /25-/32</code> has no business being advertised.
A shorter prefix length than a /8</code> does not make much sense either. So anything /1-/7</code> should be rejected.</p>
For IPv6, a longer prefix than a /48</code> is not considered routable. So anything /49-/128</code> belongs in the trash.
Defining the shortest prefix length to accept is a bit more difficult. /12</code>s are the largest blocks assigned to RIRs</a>, so that's a very safe bet.
/29</code>s are pretty much the shortest prefix length blocks they will allocate.
I chose /19</code>, because there are currently only two prefixes announced with that size. DTAG</a>'s 2003::/19</code> and Orange S.A.'s Opentransit 2a01:c000::/19</code>.
There is only one prefix I know of that is bigger: 2002::/16</code>, the 6to4 prefix, which I chose to reject anyway. See the Bogon Prefixes.
So, I'll reject any IPv6 prefix /1-/17</code>.</p>
Keep in mind that I explicitly left out /0</code> prefixes - the default routes.
That one has its own section.</p>
[edit]
</span>vifino@core1.fra1.de.as208431.net# show policy-options policy-statement REJECT_ODD_SIZE_V4
</span>term too-small {
</span>    from {
</span>        route-filter 0.0.0.0/0 prefix-length-range /25-/32;
</span>    }
</span>    then reject;
</span>}
</span>term too-big {
</span>    from {
</span>        route-filter 0.0.0.0/0 prefix-length-range /1-/7;
</span>    }
</span>}
</span>
</span>[edit]
</span>vifino@core1.fra1.de.as208431.net# show policy-options policy-statement REJECT_ODD_SIZE_V6
</span>term too-small {
</span>    from {
</span>        route-filter ::/0 prefix-length-range /49-/128;
</span>    }
</span>    then reject;
</span>}
</span>term too-big {
</span>    from {
</span>        route-filter ::/0 prefix-length-range /1-/18;
</span>    }
</span>    then reject;
</span>}
</span></code></pre>
Reject Transit ASNs§</a>
</h2>
When not peering with a transit provider, you usually don't expect huge Transit ASNs to appear in the path.
If you don't expect it, it is most likely a Transit Leak!</p>
In practice, if you peer with a route server of an IXP and you receive a path containing a big Transit network, it'll either be announcing itself or it's a leak.
If it's just a regular peering session with some random network, it most definitly is a leak.</p>
This is the as-path regex list I came up with:</p>
/* List of ASNs to filter when peering with RS or not-T1s */
</span>as-path-group TRANSIT_LEAKS {
</span>    as-path cogent ".* 174 .*";
</span>    as-path centurylink ".* 209 .*";
</span>    /* Verizon/UUNET is at IXPs, doesn't peer with RS */
</span>    as-path verizon ".* 701 .*";
</span>    /* Vodafone iss at IXPs, never peers with RS */
</span>    as-path vodafone ".* 1273 .*";
</span>    as-path arelion ".* 1299 .*";
</span>    /* Verizon is at IXPs, doesn't peer with RS */
</span>    as-path verizon ".* 2828 .*";
</span>    /* NTT is at IXPs, never peers with RS */
</span>    as-path ntt ".* 2914 .*";
</span>    /* GTT is at IXPs, never peers with RS */
</span>    as-path gtt ".* 3257 .*";
</span>    /* DTAG is barely at IXPs, never peers with RS */
</span>    as-path dtag ".* 3320 .*";
</span>    /* Lumen is at IXPs, doesn't peer with RS */
</span>    as-path lumen ".* 3356 .*";
</span>    /* PCCW is at IXPs, never peers with RS */
</span>    as-path pccw ".* 3491 .*";
</span>    /* ChinaNet peers with RS */
</span>    as-path chinanet "[^4134]+ 4134 .*";
</span>    /* Telsta peers with RS */
</span>    as-path telsta "[^4637]+ 4637 .*";
</span>    /* ChinaNet peers with RS */
</span>    as-path chinanet2 "[^4809]+ 4809 .*";
</span>    /* Orange is at IXPs, doesn't peer with RS */
</span>    as-path orange ".* 5511 .*";
</span>    as-path tata ".* 6453 .*";
</span>    /* Zayo peers with RSes */
</span>    as-path zayo "[^6461]+ 6461 .*";
</span>    /* Seabone is at IXes, but doesn't peer with RS */
</span>    as-path ti-seabone ".* 6762 .*";
</span>    /* LG is at IXPs, never peers with RS */
</span>    as-path libertyglobal ".* 6830 .*";
</span>    /* HE peers with RS */
</span>    as-path hurricane "[^6939]+ 6939 .*";
</span>    as-path atnt ".* 7018 .*";
</span>    /* Singtel is at IXPs, doesn't peer with RS */
</span>    as-path singtel ".* 7473 .*";
</span>    as-path comcast ".* 7922 .*";
</span>    /* ReTN is at IXPs and with RS! */
</span>    as-path retn "[^9002]+ 9002 .*";
</span>    /* Telxius is at IXes, but doesn't peer with RS */
</span>    as-path telxius ".* 12956 .*";
</span>}
</span></code></pre>
It drops some routes with carriers in the list that never peer with a route server, plus big networks that would only announce itself.</p>
I doubt I'll ever get the chance to do settlement free peering with most of these on that list and if that happens, I'll most likely classify it as "transit" anyway.
That way I don't fully overload my poor QFXes that just do default routes + peers.</p>
Keep in mind that this is for my network</em>. The list might be different, you might have sensible additions or changes.</p>
RPKI§</a>
</h2>
Oh boy, this one is great! This is about RFC6480.</p>
A bunch of people realized that while there are a bunch of measures against bad announcements, none of them were easily deployable or maintainable.
Mostly before RPKI, the best way to filter were prefix lists generated from IRR</a> data with tools like bgpq4</a>. Another thing Job Snijders</a> has helped with.</p>
While feasable for filtering Eyeball Networks</a> that generally have a fixed list of prefixes and stick to them for a while, for huge service providers this list changes very often.
At some point, there is at least some degree of necessary trust or you'll risk not being able to reach a lot of prefixes.</p>
If say, Amazon would announce a prefix of Google, I'm sure there are a bunch of routers that'd accept it.</p>
RPKI is meant to solve issues like this by implementing a cryptographically verifyable way to assert ownership of resources.
Much like Root DNS servers, RIRs</a> enable a signed certificate trust chain for proof of origin. Thus, it is much harder to fake.</p>
Thanks to software support, it is also much easier to keep this information up to date and offloading the "knowing the ownership of all resources in the internet" to another server.
This lets routers just ask that server on-demand instead of having to keep that entire ownership information in memory at all times.</p>
The thing that does the most impact in todays world is rejecting RPKI Invalid prefixes.
We can also consider accepting RPKI Valid prefixes even if they are not in our generated prefix list for a peer.</p>
While I hope for a future where every prefix is signed, we are unfortunately not at that point.
When RPKI does not know about a prefix, we'll just have to rely on prefix lists once again.
All I can do to do my part is to ensure all my customers have RPKI records and it's valid.</p>
Maximum AS_PATH Length§</a>
</h2>
Sometimes there are really ridiculous paths being advertised thanks to path prepending being used as a traffic shaping mechanism.</p>
Realistically, you'd only see a maximum AS_PATH length of somewhere around 10 for like 99.9% of the routes.
It's probably safe to drop routes with an AS_PATH length of 20 or more. That'd give it a 10 AS safety margin.</p>
A BIRD example for this could look something like this:</p>
function reject_long_aspath() {
</span>    if (bgp_path.len > 20) then {
</span>        print "Reject: AS_PATH too long: ", net, " ", bgp_path, " protocol: ", proto;
</span>        reject;
</span>    }
</span>}
</span></code></pre>
Cisco has bgp maxas-limit</code>.</p>
Maximum Prefix Limit§</a>
</h2>
While not strictly filtering routes itself, it is the last line of defense: The dreaded Maximum Prefix Limit.</p>
Intended as a way to bring down peering sessions forcibly when the other side is clearly misconfigured, it stops just that.
If the other side is trying to send you a Full Table</a> and you expect a few dozen prefixes instead, this might overload your router and kill it!
Or you end up routing to it but it'll just drop the packets.</p>
Either way, it's just one less thing to worry about. Usually your peering partners mention a sane limit either directly or have it somewhere, for example on PeeringDB</a>.</p>
Packet Filtering§</a>
</h1>
Route Filtering is only half the story. You need to filter the actual traffic, too.</p>
Just because you only announce certain routes does not mean you don't get packets that are destined for others.</p>
Discarding Bogons§</a>
</h2>
Like I mentioned in the Bogon Prefixes section, Bogons are not welcome in the Internet. They must be discarded.
You can do this in a plethora of ways, important is that they are welcome neither as source nor destination.</p>
Dropping packets destined for bogons is simple enough. On Junos and other routing platforms, you simply install discard routes for the prefixes.</p>
Packets with bogon as source address vary more between vendors. With Junos, you simply set up rpf-loose-mode-discard</a>, enable uRPF loose and it discards packets whose source address points to a discard</code> next-hop.
See the next section.</p>
Unicast Reverse-Path Forwarding (uRPF)§</a>
</h2>
Unicast Reverse-Path Forwarding</a> is a way to prevent IP address spoofing.</p>
uRPF has three modes, two of them are commonly implemented:</p>

Strict Mode</li>
</ol>

Each incoming packet's source is checked against the FIB, which contains only the best path.</li>
If the FIB doesn't contain an entry for the source or it points to a different interface than the one you received it on, the packet gets discarded.</li>
This only works in symmetric routing, so only applicable for your own infrastructure or Eyeball Networks</a>.</li>
</ul>

Feasable-Paths Mode</li>
</ol>

Each incoming packet's source is checked against the FIB, which carries all sane paths, not just the best one.</li>
If the FIB doesn't contain an entry for the source or if no entry points to the interface the packet was received on, the packet gets discarded.</li>
This works with asymmetric routing, however, it is not always implemented on lower-grade routers.</li>
</ul>

Loose mode</li>
</ol>

Each incoming packet's source is checked against the FIB.</li>
If the FIB doesn't contain an entry for the source (or points to a discard interface on some platforms), the packet gets discarded.</li>
This shouldn't cause trouble to implement but doesn't help that much (except for bogon filtering).</li>
</ul>
These all help in some degree, strict mode being the most helpful but only sometimes applicable and loose mode being only generally useful if discard routes get honored.
General recommendation from me is the following:</p>

Transit gets uRPF loose.</li>
Peers get uRPF feasable-paths if supported or uRPF loose otherwise.</li>
Customers get uRPF feasable-paths if supported or strict.</li>
</ul>
Note that this will only go well for customers who actually export you their prefixes and not just send traffic to you. Tell them about it, mention that they can add no-export</code> communities, etc..</p>
They are usually set on a per-interface basis, but some vendors/platforms might allow you to set loose mode globally.</p>
Remote Triggered Black Hole (RTBH)§</a>
</h2>
RTBH is a way to route a specific prefix (usually a more specific) explicitly to the void. Usually when that prefix is targeted by DDoS as a last measure when mitigation is not otherwise possible.</p>
Sometimes this is signalled by attaching the well known blackhole community to a route and is usually an option on Route Servers on an IXP or on peerings with bigger providers.</p>
Inbound Filtering§</a>
</h1>
When accepting routes from your upstreams and peers, there are some things you should always reject, like the Bogons, too big/small networks and RPKI Invalids.
Depending on your needs, you should also filter for your desired default route behaviour. Discard Bogons.</p>
Doing any more filtering on your upstreams is a loosing battle. If you see them announcing RPKI Invalids, do tell them, though. :)</p>
Filtering peers that don't provide you a Full Table</a> is much more feasable. You can generate prefix lists with bgpq4</a> for example for their ASN</a> or AS-SET of their choosing.
Make sure to update that regularly though.
AIf you can't generate prefix-lists or keep them up to date for whatever reason, make sure to at least drop Bogons, too big/small, RPKI Invalids and transit leaks.
Configure the Maximum Prefix Limit to something sane, too.</p>
Filtering routes from your downstream customers is the best case for you.
You should filter strict with a prefix list, possibly (only) allowing RPKI Valids anyway and maybe apply uRPF feasable-paths/strict (but think about it).</p>
If they complain, ask them why. If they don't have a good answer, tell them to Do Things Correctly™: They are either abusing you or doing things they almost certainly shouldn't.</p>
Outbound Filtering§</a>
</h1>
"Right, after making clear that there is a bunch we can't accept, what stops me from just announcing my prefixes statically? After all, I know what my prefixes are!"</p>
Well, nothing! If you don't provide upstream to another ASN</a>, that's just fine.
But, once that changes, you'll probably need to do some dynamic filtering or you could interfer with the operations of your downstream.</p>
After filtering your downstreams inbound - accepting only what you know to be correct - and making sure you're allowed to announce the prefixes according to the IRR</a> and RPKI,
you can announce that to your peers and upstreams.
One of the simplest way to do that is to attach a BGP Community to it of some kind and making your outbound policies ensure it is attached to a route before announcing it.
You should also make sure you filter it when it comes from external sources. Unless you wanna become a free upstream provider, that is.</p>
If you provide someone downstream the Full Table</a> of yours, you should make sure you did your best to filter your inbound routes first and don't announce internal or invalid routes alongside.</p>
So be a good egg in the chicken coop, make sure you don't announce crap and RPKI sign all your routes.
You should also tell others to set a sane Maximum Prefix Limit (usually 10x the actual number of prefixes expected to be announced for that safety margin), just in case.</p>
Make sure to not route Bogon sources or destinations and only route packets for destinations your peers announce.
Best way to ensure sane outgoing traffic is to discard bad incoming traffic.</p>
Notes§</a>
</h1>
Again, this is not complete and just my understanding of best practices mixed in with my own opinion. If you have suggestions, feel free to contact me.</p>
FYI: I mentioned a lot of RFCs here, I wanted to generate markdown footnotes for the references to those, but failed to realize that in code blocks, they don't work.
Here's what I attempted regardless.</p>
# Unify RFC references and delete old ones. Breaks thanks to codeblocks.
</span>sed -Ei -e </span>'</span>s/\[?RFC ?([0-9]+)\]?/[RFC\1]/ig</span>'</span> -e </span>'</span>/^\[RFC/d</span>' content/odd-world-fundamentals.md
</span>
</span># Generate the references. This part works, but with no links to point to it, rather useless.
</span>sed -En </span>'</span>s@.*(RFC ?)([0-9]+).*@[\1\2]: https://datatracker.ietf.org/doc/html/rfc\2@igp</span>' content/odd-world-fundamentals.md | </span>uniq </span>>> content/odd-world-fundamentals.md
</span></code></pre>
So I undid that. Sorry!</p>
Hope you can make some sense of this and it helped you.</p>
Update 2022-04-18§</a>
</h2>
On Twitter Daryll Swer</a> pointed out that I didn't mention traffic filtering at all and suggested some things.</p>
Initially, I didn't want to touch this subject as this post was basically inspired by a colleague who wanted to know more about BGP filtering, but not mentioning it seems negligent.
So, I added some sections.</p>
Update 2022-04-24§</a>
</h2>
Mention filtering of Transit Leaks and add my own as-path filter list. Does drop some routes, but you should have better routes to those anyway.</p>

`Summary§</a> </h2> This failed. I couldn't get OpenBSD installed.</p> Honestly, the whole experience was very painful. The UX sucks.</p> I can't complain about the price of free. But I should send Oracle a bill for wasting my time.</p>`

Update 2022-04-24 §</a> </h2>
Mention filtering of Transit Leaks and add my own as-path filter list. Does drop some routes, but you should have better routes to those anyway.</p>

vifino's ramblings - the blinken life

blinken.life - vifino's Blog

Updating Crucial P3 Plus NVMe Firmware on Linux

Crossflashing the Logitech Brio 4K Stream Edition (2017)

Hidden Poetry in Juniper's Junos

Using Old Cisco Routers as Console Servers

Failing to install OpenBSD 7.1 on Oracle Cloud Infrastructure

The Odd World of the DFZ - Fundamentals

OpenBSD 6.9 time server with Meinberg clocks

vifino's ramblings - the blinken life

blinken.life - vifino's Blog

Updating Crucial P3 Plus NVMe Firmware on Linux

Crossflashing the Logitech Brio 4K Stream Edition (2017)

Hidden Poetry in Juniper's Junos

Using Old Cisco Routers as Console Servers

Serial Data§</a> </h1> First, the most important thing: Almost everything is 8N1</code> nowadays:</p> 8 Databits</li> No Parity</li> 1 Stop bit</li> </ul> Usually, serial consoles have one of the following two common speeds: 9600</code> or 115200</code> Baud. Here are some general guidelines:</p>

Attaching Serial Consoles to Cisco Routers§</a> </h1> There are several ways to attach another device with a serial port to a cisco router. These are the ones I recommend:</p> AUX</code> port: 1 port (usually)</li> </ol> This is undoubtedly the simplest choice.</li>

Failing to install OpenBSD 7.1 on Oracle Cloud Infrastructure

The Odd World of the DFZ - Fundamentals

OpenBSD 6.9 time server with Meinberg clocks