Re: OpenBGPd kickstart
On 2008-12-10, Rod Whitworth [EMAIL PROTECTED] wrote: Redundancy: At first I would have thought that two identical routers in a classical carp firewall hookup would have been a good choice. .. Searching found quite a few other ideas and our peering provider's support guy is nervous about anything that is akin to VRRP(!) I told him it is way better but he offered I would not recommend going down that path. I would prefer to allocate you a second ip on the IX and have you run a separate BGP session from each router. That is definitely good advice for the provider-facing interface. bgpd has support for carp interfaces, but it's mostly for the situation where you _can't_ get another address. Apart from the added complexity, having a separate address from the provider's range means you have a chance of reaching both routers if BGP is down. You can still run carp on the inside network interface/s, probably in conjunction with demote in bgpd.conf. What would an experienced user do in this case? I've often wondered about what happens when a carp box on standby fails. Does it / can it be sensed/monitored by the master? Most places I use carp, I give everything non-carp addresses which can be monitored (usually in each subnet, as there are some occasions where it can be useful to access a network while a carp router is not master :-) So is a pair of routers to the same three IXes a better choice? Without carp? Can they balance any traffic? If not what happens? Do I need bgp sessions between the two? There are ways to balance traffic with BGP but you should really get familiar with a basic working setup before you look at that. You do need ibgp sessions between your two routers. __ Also if you run PF on them with stateful rules, you need to take account of asymmetrically routed packets; sequence number tracking can't reliably be handled by pfsync. __ I don't yet know the importance of all the bgpd.conf options. Later I might post a copy of my intended version for target practice. ;-) Filtering and preferencing sound important and I'm still trying to figure out what filters I need that are not in the default /etc/bgpd.conf. You often want to prefer to send traffic via low-cost routes, so you can match routes coming from those peers and set a higher local-preference on them. (For convenience I usually put those peers in a group and set localpref there, rather than write separate rules to match them). To influence incoming traffic you can either prepend announcements to that peer to make the path longer so it's less attractive, you can sometimes send BGP communities to the peer to do the same thing but selectively (this is usually only done with transit providers, see whois -m as3356 for a good example of what some providers allow). There's also MED which comes into play when you have 2+ paths from your AS to a peer AS. As well as setting preferences, filters are also useful for restricting what you accept over peer sessions. It's often done for bgp-speaking customers based on routing registry data, but IME is pretty rare on internet exchanges (it doesn't do good things for CPU use at config reload time..) - it's sometimes done for transit connections but only in special circumstances (e.g. trying to trim the routing table enough to fit it into a router with low memory).
Re: OpenBGPd kickstart
I normally prefer interspersed or bottom replies but I'll top post this time for brevity. Thanks very much for this. It's nearly bedtime (i'm catching up on missed sleep) and I know I'm going to read this again, many times, hard copy of man pages in hand. (and your other notes) Hopefully there will be some tutorial value for others setting out to do BGP without the big name router makers' training to get the basics. Very gratefully, Rod/ On Wed, 10 Dec 2008 09:41:40 + (UTC), Stuart Henderson wrote: On 2008-12-10, Rod Whitworth [EMAIL PROTECTED] wrote: Redundancy: At first I would have thought that two identical routers in a classical carp firewall hookup would have been a good choice. .. Searching found quite a few other ideas and our peering provider's support guy is nervous about anything that is akin to VRRP(!) I told him it is way better but he offered I would not recommend going down that path. I would prefer to allocate you a second ip on the IX and have you run a separate BGP session from each router. That is definitely good advice for the provider-facing interface. bgpd has support for carp interfaces, but it's mostly for the situation where you _can't_ get another address. Apart from the added complexity, having a separate address from the provider's range means you have a chance of reaching both routers if BGP is down. You can still run carp on the inside network interface/s, probably in conjunction with demote in bgpd.conf. What would an experienced user do in this case? I've often wondered about what happens when a carp box on standby fails. Does it / can it be sensed/monitored by the master? Most places I use carp, I give everything non-carp addresses which can be monitored (usually in each subnet, as there are some occasions where it can be useful to access a network while a carp router is not master :-) So is a pair of routers to the same three IXes a better choice? Without carp? Can they balance any traffic? If not what happens? Do I need bgp sessions between the two? There are ways to balance traffic with BGP but you should really get familiar with a basic working setup before you look at that. You do need ibgp sessions between your two routers. __ Also if you run PF on them with stateful rules, you need to take account of asymmetrically routed packets; sequence number tracking can't reliably be handled by pfsync. __ I don't yet know the importance of all the bgpd.conf options. Later I might post a copy of my intended version for target practice. ;-) Filtering and preferencing sound important and I'm still trying to figure out what filters I need that are not in the default /etc/bgpd.conf. You often want to prefer to send traffic via low-cost routes, so you can match routes coming from those peers and set a higher local-preference on them. (For convenience I usually put those peers in a group and set localpref there, rather than write separate rules to match them). To influence incoming traffic you can either prepend announcements to that peer to make the path longer so it's less attractive, you can sometimes send BGP communities to the peer to do the same thing but selectively (this is usually only done with transit providers, see whois -m as3356 for a good example of what some providers allow). There's also MED which comes into play when you have 2+ paths from your AS to a peer AS. As well as setting preferences, filters are also useful for restricting what you accept over peer sessions. It's often done for bgp-speaking customers based on routing registry data, but IME is pretty rare on internet exchanges (it doesn't do good things for CPU use at config reload time..) - it's sometimes done for transit connections but only in special circumstances (e.g. trying to trim the routing table enough to fit it into a router with low memory). *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
Re: OpenBGPd kickstart
Continuing the learning process: Since my last session on this I've had lots of pointers to things I could research. Particular thanks to Stuart. Man oh man, there are lots of monkeys typing junk that Google pads out the useful search results with. Anyway there are some things that are a matter of judgement (or even opinion) aided by experience. I don't have much of that in bgp-land so I'd like to ask about a couple or so. Redundancy: At first I would have thought that two identical routers in a classical carp firewall hookup would have been a good choice. Henning has dealt with questions about that in various ways to suit the poster's needs. None of those was quite like mine. I read his presentation with notes (at daemonnews) and the notes really added quite a bit to the slides. Maybe that articel could be referenced on the OpenBGPd website. Searching found quite a few other ideas and our peering provider's support guy is nervous about anything that is akin to VRRP(!) I told him it is way better but he offered I would not recommend going down that path. I would prefer to allocate you a second ip on the IX and have you run a separate BGP session from each router. What would an experienced user do in this case? I've often wondered about what happens when a carp box on standby fails. Does it / can it be sensed/monitored by the master? So is a pair of routers to the same three IXes a better choice? Without carp? Can they balance any traffic? If not what happens? Do I need bgp sessions between the two? I don't need a how-to. Directions to take let me read and research usually get me pretty close to working setups. I don't yet know the importance of all the bgpd.conf options. Later I might post a copy of my intended version for target practice. ;-) Filtering and preferencing sound important and I'm still trying to figure out what filters I need that are not in the default /etc/bgpd.conf. TIA Rod/ *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
Re: OpenBGPd kickstart
On 2008-11-02, Rod Whitworth [EMAIL PROTECTED] wrote: There is an IPv4 /21 transit and an IPv6 /32 transit at the moment. No BGP. Enter a peering service which is to provide peering for those netblocks over a pretty fat single link. (I don't know the bandwidth but I am assured it is big enough) I have ASNs for the peering outfit (PO) and the hosting service (HS). The assumption conveyed to me was that the only BGP would be between those two but I have my doubts that that is the right thing to do. It would be usual to announce your networks over BGP sessions with both the peering outfit and the transit provider. The PO has also requested that replies to traffic incoming via the PO would return on the same path. I don't know if we can do that with bgpd or to use pf. It took me a couple of days to work out what they mean here, but I think they just mean you should use a higher localpref on the peering routes than transit routes (but then you'd probably want to do that anyway). btw: asymmetric routing is totally normal on the internet. At the moment the IPv6 traffic is pretty light and interruptions are likely to be tolerated if short so I think I can use it to test how the whole deal will work and just add IPv4 later to the config. I have also figured out all of the internal routing changes needed to be able to cut over in seconds and fall back if needed on both v4 and v6. I think starting with v6 only and later adding v4 complicates things. Where does the address space come from? is it an independent block or part of a larger allocation from one of the providers? is it announced as part of the transit provider's AS at present? There, I have displayed my status as an absolute bgpd virgin: Where do I go from here? Everthing else I have done (mail, web, IPsec, OpenVPN etc) has been able to be tested with some old PCs so that I could try stuff and it didn't matter if it broke, it was all isolated from the 'net. This one is different. yep, welcome to BGP routing ;-) you can test some things, but there's a point you just have to be reasonably sure that either the intended configuration or your backout plan are going to work and bite the bullet..
OpenBGPd kickstart
Hi BGP4 experts, I'm not one of you and getting to the first step is pretty scary. I've been reading the van Beijnum (O'Reilly) and Stewart (A-W) books and the man pages for bgpd, bgpd.conf and anything else I can find. What is really hard is to get a configuration to test stuff when you don't have a peer to test against that has been configured properly. In my case the work I do will only be able to be tested when it is put into service and that is a bit daunting to say the least. There is one less critical part of the system that can be tried first (the IPv6 part) but the entire system has to work with minimal disturbance to a swag of hosted webservers etc pretty soon or there will be blood. The scenario is: There is an IPv4 /21 transit and an IPv6 /32 transit at the moment. No BGP. Enter a peering service which is to provide peering for those netblocks over a pretty fat single link. (I don't know the bandwidth but I am assured it is big enough) I have ASNs for the peering outfit (PO) and the hosting service (HS). The assumption conveyed to me was that the only BGP would be between those two but I have my doubts that that is the right thing to do. The PO has also requested that replies to traffic incoming via the PO would return on the same path. I don't know if we can do that with bgpd or to use pf. Maybe at some stage the HS is going to want to favour one or the other for cost reasons. At the moment the IPv6 traffic is pretty light and interruptions are likely to be tolerated if short so I think I can use it to test how the whole deal will work and just add IPv4 later to the config. I have also figured out all of the internal routing changes needed to be able to cut over in seconds and fall back if needed on both v4 and v6. There, I have displayed my status as an absolute bgpd virgin: Where do I go from here? Everthing else I have done (mail, web, IPsec, OpenVPN etc) has been able to be tested with some old PCs so that I could try stuff and it didn't matter if it broke, it was all isolated from the 'net. This one is different. TIA, *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
