On 13-11-11 11:48 PM, Chris Cappuccio wrote:
Adam Thompson [athom...@athompso.net] wrote:
Well, you could - perhaps - flip this on its head. Instead of changing BGP,
what about forcing one router to be the master (via advbase/advskew),
advertising a lower BGP preference (probably by using both localpref for
iBGP and path prepending for eBGP) from the slave, using pfsync (default,
not defer) to sync the state tables, and simply assuming that if the slave
becomes the master it's because the master is dead, so losing a few packets
isn't the end of the world?
If you're talking about eBGP..or even iBGP for that matter, an interesting
way to go could be:
Two BGP sessions from different IPs (no CARP)
BGP next-hop pointing to CARP-protected IP
I'm trying this, but I'm not sure it's actually working. I suspect
bgpd.conf cluelessness on my part, suggestions appreciated.
Existing situation:
- dedicated VLAN 207 and X.X.X.160/28 for BGP interconnect
- one router on their side (perhaps one logical router, using VRRP),
two routers on my side (R{1,2}).
- carp207 (X.X.X.162) on vlan207 (X.X.X.{163,164}) on trunk0
- existing bgpd.conf works, each router (R1,R2) has 2 IPv4 neighbours:
its redundant copy (R2/R1) and the upstream (.161). Very simple config,
will email off-list if desired.
Change:
- added "match to X.X.X.161 set nexthop X.X.X.162" before the existing
"allow to any" on both R1 & R2
(I thought about doing "network x.x.x.x/xx set nexthop X.X.X.162"
globally, but worried that will affect too many things later.)
Result:
- no change, according to upstream provider
- traceroute inbound shows replies from .163 (right now, anyway)
Am I misunderstanding the syntax, or perhaps making some more
fundamental error? I can also anonymize and post bgpd.conf here if needed.
--
-Adam Thompson
athom...@athompso.net
