Unfortunately I was sidelined with other projects and have not had a chance
to resolve this issue I described in this post. Now I should have some time
to get this resolved and I have some ideas on how I can resolve this, but I
need some advice on if its the best method or if there is a more graceful
way of defeating this single point of failure. This might help visualize my
problematic scenario.
# bgpctl show int
Interface Nexthop state Flags Link state
pflog0 ok UP unknown
carp0 ok UP CARP, master
pfsync0 ok UP unknown
lo0 ok UP unknown
enc0 invalid unknown
em0 ok UP Ethernet, active, 100 MBit/s
fxp1 ok UP Ethernet, active, 100 MBit/s
*fxp0 invalid Ethernet, active, 100 MBit/s
#This is the external link on the master firewall that dies and causes the
single point of failure because...
*# ifconfig carp0
carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:0a
* carp: MASTER carpdev fxp1 vhid 10 advbase 1 advskew 10 #The host
only has one carp device on the inside and does not preempt and still
accepts outbound traffic from internal hosts...*
groups: carp
inet x.y.z.254 netmask 0xfffffe00 broadcast x.y.z.255
# bgpctl show sum
Neighbor AS MsgRcvd MsgSent OutQ Up/Down
State/PrfRcvd
* iBGP-fw-sec 64535 55792 55793 0 02w5d08h 0
#...which gets blackholed because no prefixes are being recieved from the
ONLY iBGP speaker it can reach as expected by the behavior of the BGP
protocol.*
*
iBGP-rtr-sec 64535 790819 51490 0 00:30:43 Active # DEAD
BGP SESSION
iBGP-rtr-pri 64535 176013 619 0 00:30:43 Active #DEAD
BGP SESSION
*/etc/bgpd.conf on secondary firewall (same on primary except for
description of $iBGPpeer2)
...
network x.y.z.0/23
...
group "iBGP" {
remote-as 64535
announce all
set nexthop self
set localpref 100
neighbor $iBGPpeer0 {
descr "iBGP-rtr-pri"
}
neighbor $iBGPpeer1 {
descr "iBGP-rtr-sec"
}
neighbor $iBGPpeer2 {
descr "iBGP-fw-pri"
}
}
...
So, as you can see I do have a iBGP full mesh which doesn't solve my issue.
I was contemplating adding another carp device (carp1) on the external
interfaces which would remain unutilized due to the ospf configuration, just
so I can force the preemption in this scenario which would solve this single
point of failure, unless there is a way to force preemption with one carp
device?
Thanks.
On Mon, Feb 25, 2008 at 12:17 PM, <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Feb 22, 2008 at 5:50 PM, Stuart Henderson <[EMAIL PROTECTED]>
> wrote:
>
> > On 2008-02-23, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > I noticed that the two firewalls do not forward there
> > iBGP
> > > learned routes to one another. Is this intended/expected behavior?
> >
> > Yes, you should probably read up a bit about BGP, and why you need
> > a full mesh of i-BGP speakers.
>
>
> I've reread thru some of my BGP resources.
>
> >
> >
> > > And I had a "redistribute default" configured in ospfd.conf on the
> > routers,
> > > however I had problems with this setup as well when I unplugged the
> > external
> > > link on the firewall but this could have been due to my pf
> > configuration on
> > > the firewalls. Should I re-investigate this scenario?
> >
> > You mean, just OSPF and no BGP on the firewalls? That's probably worth
> > another look.
>
>
> No, I'm actually running OSPF and BGP on all nodes, but I believe there
> to be a config issue somewhere along the line . Because of the expected BGP
> protocol behavior, Ill have to revert back to my original configuration
> with the "redistribute default" and begin troubleshooting why this was
> problematic for me. When I unplugged the eBGP link, the unplugged router was
> still distributing the default route. What i need it to do is stop
> redistributing the default when the eBGP link dies. Ill have to reread thru
> the manpages I suppose.
>
> >
> >
> > > Also how how quickly should traffic be rerouted with OSPF if a link
> > dies?
> >
> > Depends on your timers, but <10sec is not unreasonable for OSPF.
> > If you have to wait for BGP timers and session re-establishment that
> > would take longer.
> >
>
> I have default timers set, however the typical time for reconvergence is
> between 60-120 seconds, so I must be waiting on the BGP timers.
