Differences

This shows you the differences between two versions of the page.

--- peering-toolbox:hardware [2022/08/18 21:35] – [BGP] philip
+++ peering-toolbox:hardware [2023/03/27 11:57] (current) – [BGP] philip
@@ Line 24: / Line 24: @@
 The Peering Toolbox is aimed at organisations who are or are planning to take part in peering. For this reason a consumer/home router (often erroneously called an "internet modem") is not sufficient and cannot be recommended (even through there are some quite capable devices available).
-The type that needs to be looked at need to be "enterprise grade" which means the router is offered with reasonable warranty, a support contract (often required by enterprises), is usefully rack (or shelf) mountable, has sufficient cooling, has possibility of redundant power supplies, has a console port for in-situ access, is accessible remotely using Secure Shell, and supports a command line interface suitable for human or automated tool use.
+The type that needs to be looked at need to be "enterprise grade" which means the router is offered with reasonable warranty, a support contract (often required by enterprises), is usefully rack (or shelf) mountable, has sufficient cooling, has possibility of redundant power supplies, has a console port for in-situ access, is accessible remotely using Secure Shell, supports SNMP (Simple Network Management Protocol), and supports a command line interface suitable for human or automated tool use.
 Alternatively, there are several software routers available which could be installed on a Linux container or virtual machine or small Linux appliance. These might be entirely suitable, as the software is usually fully featured (like the main stream vendor routers) and very capable. One example of a software router is [[https://frrouting.org|FRR]] which is widely used as an alternative to dedicated vendor supplied hardware.
@@ Line 44: / Line 44: @@
 Note that even if the router may have Gigabit or fibre optic interfaces, there is no guarantee that it can actually deliver Gbps rates. This is especially true for the CPU based routers whose throughput slows down significantly with increasing traffic, the amount of packet filtering configured, and Network Address Translation (if sufficient IPv4 address space is not available).
-It is important to check with the vendor what the true throughput is in a realistic use case (known as Internet Mix or IMIX, representing the typical average packet size seen on the Internet today), not lab testing!
+It is important to check with the vendor what the true throughput is in a realistic use case (known as //Internet Mix// or IMIX, representing the typical average packet size seen on the Internet today), not lab testing!
 ==== IPv4 & IPv6 ====
-If the transit provider has deployed both IPv4 and IPv6 on their network and offers the capability to customers, it is strongly recommended that the router be able to handle IPv4 and IPv6 (known as dual-stack operation).
+If the transit provider has deployed both IPv4 and IPv6 on their network and offers the capability to customers, it is strongly recommended that the router chosen be able to handle IPv4 and IPv6, known as dual-stack operation. This dual-stack support needs to have all commands available supporting both IP protocols (and not a reduced command set for IPv6).
 Using IPv6 is advantageous as it means that content traffic (which forms about 80% of typical Internet traffic today) will not have to traverse Network Address Translation devices in the upstream's network or use the NAT feature on the router, reducing the resource burden, and also improving the service quality experienced by the end-users.
@@ Line 54: / Line 54: @@
 ==== BGP ====
+(UPDATED)
 Most "first time" Internet connections will simply use a static default route pointing to the upstream provider, with the upstream pointing a route to their customer for the customer's address space.
-However, it pays to think forwards, especially considering that this Toolbox is all about how an organisation should go about peering! And for that, BGP will be required, and it is recommended that any new procured router is BGP capable.
+However, it pays to think forwards, especially considering that this Toolbox is all about how an organisation should go about peering! And for that, BGP will be required, and it is recommended that any new procured router is fully BGP capable.
-Some end-sites will start off with using BGP even for their first Internet connection, from day one. Historically they'd use a private AS number for this, but with the relaxation of policies in some of the Regional Internet Registry regions, an public AS number can now be obtained simply by becoming a member of the RIR and receiving address space.
+Some end-sites will start off with using BGP even for their first Internet connection, from day one. Historically they'd use a private AS number for this, but with the relaxation of policies in some of the Regional Internet Registry regions, a public AS number can now be obtained simply by becoming a member of the RIR and receiving address space.
 If BGP is going to be used on the link, the router must be BGP capable, although it does not have to or need to carry the full BGP table (which is large and growing rapidly). Most modern routers have implemented the latest BGP standards and extended capabilities - reviewing [[https://bgp4all.com/pfs/_media/workshops/05-bgp-bcp.pdf|BGP Best Practices]] documentation and comparing with vendors' claimed feature support is strongly recommended.
-If BGP is being used on this transit link, and there are no other external links for this network, then all the operator needs to do is announce their address space to their upstream, and accept a default router from their upstream. This scenario is discussed in the [[single_upstream#single_upstream|Single Upstream]] section of the Toolbox.
+If BGP is being used on this transit link, and there are no other external links for this network, then all the operator needs to do is announce their address space to their upstream, and accept a default route from their upstream. This scenario is discussed in the [[single_upstream#single_upstream|Single Upstream]] section of the Toolbox.
+The control plane needs of the router (the processor to handle BGP and other routing protocols) are not significant where there are just a few BGP peers and only a few routes are being handled as in this case.
 ==== Packet Filtering ====
-The final router requirement is the ability to do packet filtering, with at least being able to filter by source address, destination address, source port, destination port, and IP protocol.
+The final router requirement is the ability to do packet filtering, with at least the ability to filter by source address, destination address, source port, destination port, and IP protocol.
 It is important to check how many of these filter rules the router will support, and if performance degrades as more rules are added. Ideally there should be minimal performance impact as rules are added; be aware that CPU based routers are likely to show a significant performance hit as rules are added.
-The minimum filtering is needed on an enterprise connection today would be:
+The minimum filtering needed on an enterprise connection today would be:
   * allow all ICMP
   * allow inbound established TCP connections (sessions originated internally)
-  * allow inbound connections to public hosted services
+  * allow externally originated connections inbound to public hosted services (website, email server)
   * block external access to network infrastructure control planes
   * allow outbound traffic only from public address space used internally (anti-spoofing)
-  * allow UDP such that essential UDP based services work
+  * allow UDP such that essential UDP based services work (Domain Name Service, Network Time Protocol, etc)
 A network operator will likely be more generous, with filter rules only blocking access to the network infrastructure control planes, implementing anti-spoofing filters, but permitting all other public address space.
@@ Line 114: / Line 118: @@
 The discussion about the type of router used in the [[hardware#ipv4_ipv6|Transit Connection]] applies here too. If the operator has deployed IPv6 in addition to IPv4 to their upstream provider, then naturally the router procured for the peering link needs full dual-stack support as well.
+When operating a dual stack network, it is strongly recommended to ensure that whatever connectivity is supplied for IPv4 is also replicated for IPv6. For example, if the peering links are IPv4-only, yet the transit is dual stack IPv4/IPv6, then potential peering traffic will use the paid-for transit link, rather than the free peering link.
 ==== BGP ====
+(UPDATED)
 BGP will be required for any peering connection, in which case the peering router has to fully support BGP.
@@ Line 122: / Line 130: @@
 The BGP configuration used on a private peering connection is discussed in the [[single_upstream_private_peer|Single Upstream and Private Peer]] section of the Toolbox.
+The control plane needs of the router (the processor to handle BGP and other routing protocols) are not significant where there are just a few BGP peers and only a few routes are being handled as in this case.
 ==== Packet Filtering ====
-The discussion about Packet Filtering support for the router used in the [[hardware#packet_filtering|Upstream Connection]] fully applies here too.
+The discussion about Packet Filtering support for the router used in the [[hardware#packet_filtering|Transit Connection]] fully applies here too.
 ===== Public Peering Link =====
@@ Line 163: / Line 173: @@
 ==== BGP ====
+(UPDATED)
 The discussion about BGP support for the router used in the [[hardware#bgp1|Private Peering Link]] fully applies here too.
 The BGP configuration used on a public peering connection is discussed in the [[single_upstream_ixp|Single Upstream and IXP]] section of the Toolbox.
+The control plane needs of the router (the processor to handle BGP and other routing protocols) in this case can be quite significant and care is needed when selecting suitable hardware.
+Small IXPs will have only a few peers so there it a likelihood that only a few thousand routes will be received by the new member. Most standard router hardware has sufficient control plane capability to handle this.
+Larger IXPs will likely have dozens of members, with the largest IXPs today approaching one thousand members. This has significant control plane demands on the peering router, and it is important that one with a powerful control plane CPU is chosen, especially one that is proven to handle several hundred peers and tens of thousands of routes with ease. In this case it can be helpful to consult with existing IXP members seeking suggestions or recommendations. Note the usual caveat between vendor marketing claims and real world experience of network operators.
 ==== Packet Filtering ====
-The discussion about Packet Filtering support for the router used in the [[hardware#packet_filtering|Private Peering Link]] fully applies here too.
+The discussion about Packet Filtering support for the router used in the [[hardware#packet_filtering1|Private Peering Link]] fully applies here too.
-[[:peering-toolbox/how-to-peer| Back to "What I need to Peer" page]]
+[[:peering-toolbox/how-to-peer| Back to "What is required for Peering" page]]