BGP, ebgp-multihop and multiple peers
Hi everyone, This question comes after likely overlooking an IETF document or BCP that describes what I'm after. Given that I am looking for advice from someone who is more experienced operationally in this regard than me, and that this technically is an implementation-neutral question, I wanted to ask here. Taking one router I have as an example, I have four IPv6 BGP peers (two are for true routing, the other two for route server projects), and five IPv4 BGP peers. Two of the v4 peers are Cymru for BOGONS, the other three are purely outbound to route server projects. All five v4 peers are ebgp-multihop. I'm looking for advice on the configuration of the peers with ebgp-multihop (IPv4). I have a reserved block carved out of my allocation specifically for /32s on loopbacks, and when I light up a new peer, I configure a new looopback interface for that peer, and subsequently give it the next available IP from the reserved /32 block. There are numerous drawbacks to doing it this way... waste of IPv4 addresses, additional keystrokes on the router for interface config, documentation, expanded margin for error et-al. There are a few benefits to doing it this way (IMHO), but I see obvious benefits of using a single loopback interface and single IP for ALL of these multihop peers. Before I state good/bad, or get any wrong idea in my head, I'd like to ask the real experts here which way they would/do this type of thing, and why. - single loopback/single IP for all peers, or; - each peer with its own loopback/IP? Thanks, Steve
Steve, You ask a very good question because I have seen some providers embark on the multiple loopback approach for numerous reasons. I suggest a single loopback per routing-instance whenever possible. The cost savings in OSS and integration in routing configurations with a single repeatable block of configuration per peer/peer group is far more beneficial than some corner case technical benefit of having multiple loopback addresses. I have been forced for other feature support to deploy multiple loopback interfaces, but have always opted to keep all EBGP peering with a single loopback interface per routing-instance. Kind regards, Truman On 26/08/2008, at 7:48 PM, Steve Bertrand wrote:
Hi everyone,
This question comes after likely overlooking an IETF document or BCP that describes what I'm after. Given that I am looking for advice from someone who is more experienced operationally in this regard than me, and that this technically is an implementation-neutral question, I wanted to ask here.
Taking one router I have as an example, I have four IPv6 BGP peers (two are for true routing, the other two for route server projects), and five IPv4 BGP peers. Two of the v4 peers are Cymru for BOGONS, the other three are purely outbound to route server projects. All five v4 peers are ebgp-multihop.
I'm looking for advice on the configuration of the peers with ebgp- multihop (IPv4).
I have a reserved block carved out of my allocation specifically for /32s on loopbacks, and when I light up a new peer, I configure a new looopback interface for that peer, and subsequently give it the next available IP from the reserved /32 block.
There are numerous drawbacks to doing it this way... waste of IPv4 addresses, additional keystrokes on the router for interface config, documentation, expanded margin for error et-al.
There are a few benefits to doing it this way (IMHO), but I see obvious benefits of using a single loopback interface and single IP for ALL of these multihop peers. Before I state good/bad, or get any wrong idea in my head, I'd like to ask the real experts here which way they would/do this type of thing, and why.
- single loopback/single IP for all peers, or; - each peer with its own loopback/IP?
Thanks,
Steve
On Tue, Aug 26, 2008 at 7:48 PM, Steve Bertrand <steve@ibctech.ca> wrote:
There are a few benefits to doing it this way (IMHO), but I see obvious benefits of using a single loopback interface and single IP for ALL of these multihop peers. Before I state good/bad, or get any wrong idea in my head, I'd like to ask the real experts here which way they would/do this type of thing, and why.
- single loopback/single IP for all peers, or; - each peer with its own loopback/IP?
You should use caution when using loopback IP addresses and building external multihop BGP sessions. By permitting external devices to transmit packets to your loopback(s), you open the door to spoof/denial of service attacks. However, if you must establish sessions to something external, it would be best to do so from a dedicated IP address for external peering that you can poke a hole into your ACLs and apply the appropriate rate-limiting/filtering/CoPP controls. Ideally, if you have an allocation for loopbacks, I would hope you wouldn't allow the Internet fling packets at them. Most frequently loopback peering is used when aggregating multiple physical interfaces and is used in conjunction with static routes to load balance traffic over the interfaces.
On 27 aug 2008, at 7:58, Paul Wall wrote:
- single loopback/single IP for all peers, or; - each peer with its own loopback/IP?
You should use caution when using loopback IP addresses and building external multihop BGP sessions. By permitting external devices to transmit packets to your loopback(s), you open the door to spoof/denial of service attacks.
[...] Indeed. I would use two loopbacks, one for internal stuff that is unreachable from the outside, another one from another range that allows the external sessions. But that's more a question of ease of management than of risk, because if people can do something bad using one loopback address, it really doesn't matter much that additional ones are better protected.
Iljitsch van Beijnum wrote:
On 27 aug 2008, at 7:58, Paul Wall wrote:
- single loopback/single IP for all peers, or; - each peer with its own loopback/IP?
You should use caution when using loopback IP addresses and building external multihop BGP sessions. By permitting external devices to transmit packets to your loopback(s), you open the door to spoof/denial of service attacks.
[...]
Indeed. I would use two loopbacks, one for internal stuff that is unreachable from the outside, another one from another range that allows the external sessions.
But that's more a question of ease of management than of risk, because if people can do something bad using one loopback address, it really doesn't matter much that additional ones are better protected.
Thanks for the feedback. The only reason I use loopbacks for eBGP multihop is so that if one of my physical interfaces goes down taking a transit link with it, these particular sessions will attempt to re-establish via another path. Would someone be so kind as to point me in the direction of some documentation that describes the drawbacks (regarding the mentioned possibility of DoS/spoof attacks) of externally accessible loopbacks? I'm drawing a blank on why this is any more risky than having a peering session (multihop) on a physical interface. Would it be best if I configured the peering sessions on a physical interface instead? Steve
On 27 aug 2008, at 14:16, Steve Bertrand wrote:
The only reason I use loopbacks for eBGP multihop is so that if one of my physical interfaces goes down taking a transit link with it, these particular sessions will attempt to re-establish via another path.
Actually they should stay up.
Would someone be so kind as to point me in the direction of some documentation that describes the drawbacks (regarding the mentioned possibility of DoS/spoof attacks) of externally accessible loopbacks?
Apart from general vulnerabilities that are possible on services open to the internet and password brute forcing it's mainly a question of TCP RST packets on the BGP session, which an MD5 password will protect you from. But then an attacker can try to bring down your route processor CPU because the MD5 calculations use much more CPU time than they should. Or simply overload the input buffers. (If someone with this level of knowledge is out to get you you're pretty much screwed whatever you do, though...)
I'm drawing a blank on why this is any more risky than having a peering session (multihop) on a physical interface.
It isn't.
Would it be best if I configured the peering sessions on a physical interface instead?
No, physical interfaces can go down. The advantage of a separate loopback address is that if you ever have any trouble, you can simply remove that address and the trouble is gone, too. This wouldn't work for the loopback address you also use for iBGP or a physical interface.
Iljitsch van Beijnum wrote:
The advantage of a separate loopback address is that if you ever have any trouble, you can simply remove that address and the trouble is gone, too. This wouldn't work for the loopback address you also use for iBGP or a physical interface.
Ok. It probably would have made much more sense in my original post to clarify that each eBGP multihop peer session is configured on separate loopback interfaces, apart from the ones I use internally. Generally, I leave lo0 as-is, lo1 for internal, then configure each eBGP multihop peer on an incremental loopback basis thereafter. So, in essence, I'll continue to use a loopback (separate from internal functions) for ebgp-multihop peers, but instead of each session having its own interface/IP, I'll share one for all of them. Thanks everyone! Steve
If you keep a separate peering/loopback-IP for each peer, you can move individual peering sessions to other devices if needed. On Wed, August 27, 2008 05:39, Steve Bertrand wrote:
Iljitsch van Beijnum wrote:
The advantage of a separate loopback address is that if you ever have any trouble, you can simply remove that address and the trouble is gone, too. This wouldn't work for the loopback address you also use for iBGP or a physical interface.
Ok. It probably would have made much more sense in my original post to clarify that each eBGP multihop peer session is configured on separate loopback interfaces, apart from the ones I use internally.
Generally, I leave lo0 as-is, lo1 for internal, then configure each eBGP multihop peer on an incremental loopback basis thereafter.
So, in essence, I'll continue to use a loopback (separate from internal functions) for ebgp-multihop peers, but instead of each session having its own interface/IP, I'll share one for all of them.
Thanks everyone!
Steve
participants (5)
-
Iljitsch van Beijnum -
Paul Wall -
Rick Ernst -
Steve Bertrand -
Truman Boyes