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).
