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.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.