We will now provide various configuration tips on BGP and IGP best practices. The first one to remember is the use of loopback addresses, always make sure loopback is configured on the router. Remember that iBGP is between loopbacks and not real interfaces. Another one to remember is that IGP carries loopback addresses, which is typically a /32 address for IPv4 and a /128 address for IPv6. Considerations for the DMZ nets are, are you going to use unnumbered interfaces? Always remember to use "next-hop-self" on iBGP neighbors. Also carry the DMZ IPv4 /30s and IPv6 /127s in the iBGP. Remember to keep the DMZ nets out of IGP. We're now going to talk about the use of "next-hop-self". A BGP speaker will always announce its external network to iBGP peers using its loopback address as the next-hop. This is used by many ISPs on edge routers, since this is preferable to carrying DMZ point-to-point link addresses in the IGP. It also reduces size of IGP to just core infrastructure. This is an alternative to using unnumbered interfaces. This also helps scale the network and many ISPs consider this best practice. We're going to talk about limiting AS path length. Some BGP implementations have problems with long AS paths, as this often causes memory corruption and fragmentation. Even when using AS path prepends it is not normal to see more than 20 ASes in a typical AS path in the internet today. The Internet is around 5 ASes deep on average, and the largest AS path usually has about 16 to 20 ASNs. Some announcements have ridiculous lengths of AS paths as shown in the example on the screen. The first example is an error in one IPv6 implementation. The second example shows 100 prepends for no obvious reasons. If your implementation supports it, consider limiting the maximum AS path length you will accept. This can be done using "neighbor <IP address of the peer> maxas-limit <number you want to limit to>". We're now going to talk about BGP maximum prefix tracking. One should allow configuration of the maximum number of prefixes a BGP router will receive from a peer. This feature allows a router to bring down a peer when the number of received prefixes from that peer exceeds the configured maximum prefix limit. This can be implemented using the command shown on the screen. One can implement two levels of control by using the threshold value, which will generate a warning message when the percentage of max prefixes is reached, and the max value which will actually tear down the BGP peering when that number is reached. Manual intervention is required to restart the BGP peer. "restart" is an optional keyword which will restart the BGP session N minutes after being torn down. "warning-only" is an optional keyword which allows log messages to be generated but peering session will not be torn down. We're now going to talk about BGP TTL "hack". It is advisable to implement RFC5082 on BGP peerings otherwise known as TTL "hack". This is a generalized TTL security mechanism. A BGP neighbor sets TTL to 255, a local router expects TTL of incoming BGP packets to be 254. No one apart from directly attached devices can send BGP packets which will arrive with TTL of 254, so any possible attack by a remote miscreant is dropped due to TTL mismatch as shown on the diagram. When using TTL hack, both neighbors must agree to use the feature. TTL check is much easier to perform than MD5. BGP TTL security hack is also called BTSH. TTL hack provides security for BGP sessions, in addition to packet filters of course. MD5 should still be used for messages which slip through the TTL hack. See the URL below for more details which can be found on the NANOG website. We'll now talk about routing protocol admin distances. Please be mindful of various routing protocol distances as shown on the screen. As you can see, eBGP by default has a lower admin distance than iBGP on Cisco devices whereas the admin distance is the same for both Juniper and Huawei devices. You also see that eBGP by default has a lower admin distance than both OSPF and IS-IS, which is not true for Cisco and Huawei devices which have low admin distances for both OSPF and IS-IS. Apart from directly connected interfaces, static routes have lower admin distances than all routing protocols for all devices but Huawei. If you want this default behavior to change please remember to set the admin distance in your BGP settings, as the routing protocol with the lower admin distance is always preferred. We're now going to talk about BGP templates. Good practice is to configure templates for everything. Vendor defaults tend not to be optimal or even very useful for ISPs. ISPs tend to create their own defaults by using configuration templates. We will be showing you examples of what to include in your iBGP and eBGP templates. You can also see Team Cymru's BGP templates on the URL at, www.team-cymru.org/documents.html or the URL shown on the screen. We'll now give you an example of an iBGP template. Remember to use iBGP between loopbacks and not real interfaces. We are also encouraged to use next-hop-self to keep DMZ and external point-to-point out of IGP. Always send communities in iBGP, otherwise BGP policy accidents will happen. This is default on some vendor implementation whereas it is optional on others. Hardwire BGP to version 4 to prevent accidental configurations of version 3 BGP still supported in some implementations. You should also secure your iBGP session using passwords. This is not being paranoid, but it's very necessary as it helps defeat miscreants who wish to attack BGP sessions. A password is a secret shared between you and your peer, so if arriving packets don't have the correct MD5 hash they are ignored. This is a powerful preventive tool especially when combined with filters and TTL "hack". We're now going to show you templates of eBGP. First thing to remember is you should not use BGP damping unless you understand the impact. You should also not use vendor BGP damping defaults without thinking as well. Do not use Cisco's soft reconfiguration, unless troubleshooting as it will also consume considerable amounts of extra memory for BGP. Please remove private ASes from announcements, this is also a common omission today. One should also use extensive filters with "backup", for example use AS path filters to backup prefix filters. Keep policy language for implementing policy, rather than basic filtering. You should also use passwords agreed between you and your peers for your eBGP sessions. Use maximum-prefix tracking as your router will warn you if there are sudden increases in your BGP table size, bringing down eBGP if desired. Limit maximum AS path length inbound. Log changes to your neighbor state and monitor those logs as well. Make sure BGP admin distance is higher than any of your IGP, otherwise prefixes heard from outside your network could override your IGP. In summary, you should always use configuration templates. Standardize the configuration. Beware of standard "tricks" to avoid compromise of your BGP session. Use anything to make your life easier as this will make your network less prone to errors and more likely to scale. Remember it's all about scaling, if your network won't scale it won't be successful.