On Wed, Nov 02, 2005 at 12:34:29AM +0100, per engelbrecht wrote:
> Hi all
>
> [20051019 snap i386]
>
> I've made a setup with two identical bgp routers. On each router there's
> 3 peers (BGP and eBGP), one failover (carp/iBGP/ospf) interconnecting
> these routers and finally pipes backwards to the internal nets. Part of
> bgpd.conf further down.
> I'm replacing a single router (no ospf) fbsd/zebra setup.
>
That should be no problem.
>
> Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a
> 'no synchronization' option for this connection. Do I need it at all.
> Been poking around in /usr/src/usr.sbin/bgpd without solving it, but
> it's needed in zebra and Cisco IOS hence the question.
> A: ?
>
There is no 'no synchronization' option. We never enforce the
synchronisation of iBGP with an IGP. That's retarded. Like pumping 170'000
routes into OSPF and thinking all will be fine. Sure you may get bitten if
you have routers that do not run iBGP in between the two iBGP routers but
that's more a design problem and is solvable.
>
> Q: adding md5sig password, how can I activate these stepwise without
> having to take bgpd down/up and affecting all connections - ospfctl does
> not seem have it as an option. Would like to add md5sig one carrier at a
> time on a "live" system.
> A: ?
>
Just add the 'tcp md5sig password "fluffy"' to a neighbor and
bgpctl reload. Afterwards a bgpctl neighbor <fluffy_peer> clear will clear
the session and activate tcp md5. You can do that one peer at a time.
>
> Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and
> internal intfaces in area 0.0.0.1 (and from ospfd.conf)
> [...]
> fib-update yes
> redistribute connected
> [...]
> This is about redistributing routes - will the above let BGP and OSPF
> "play along" in the same way a 'redistribute ospf' in Zebra/Cisco IOS
> A: ?
>
"redistribute ospf" is currently not implemented. bgpd is currently not
able to redistribute routes added by ospfd. This is on the todo list.
>
> Q: default gateway is added to the routing table after all interfaces
> are configured. BGP is adding information into the routing table and so
> does OSPF (updates). That's 3 times "redistributing" of routes between
> different protocols and with 3 different administrative distances but
> still in/from the same table. Since directly connected (0) or static (1)
> connections are superior to e.g. eBGP (20) and OSPF (110) then should or
> shouldn't /etc/mygate be removed from a BGP router before putting it
> into production. Will it/can it mock the routing decision despite
> 'weight' in bgpd.conf due to the lower distance.
> A: ?
>
Neither ospfd nor bgpd know about administrative distances. Currently it
is only save to use the two together if there are no equal routes. If
both bgpd and ospfd try to add the same route to the kernel routing table
it will result in undefined behaviour. (mostly the first one wins).
Again this is on the todo list (even before the redistribute thing).
>
> Part of bgpd.conf:
>
> [...]
> neighbor $peer0 {
> remote-as ABCD
> descr "ebgp sucks"
> set nexthop aaa.aaa.aaa.aab
> multihop 10
> local-address aaa.aaa.aaa.aaa
> announce self
> announce IPv6 none
> enforce neighbor-as yes
> set weight 100
> #tcp md5sig password HotPotatoes
> }
> ...
> ...
> neighbor $carp {
> remote-as <our_own_AS>
> descr "internal"
> local-address 172.16.0.1
> depend on em5
I think this is not doing what you think. depend on is only useful on
carp(4) interfaces. It does not make sense for physical interfaces.
> announce all
That's actually the default :)
> announce IPv6 none
> enforce neighbor-as no
That one as well.
> set weight 200
> #tcp md5sig password NoPotatoes
> }
>
> I have a:
> deny from any prefix 172.16.0.0/12 prefixlen >= 12
> but the carp interface uses a /8 i.e. should be safe :)
>
Iick. That will cause troubles with everything in the 172/8 range.
You can add a rule like:
allow from $carp prefix 172.16.0.0/24
afterwards. That would be much nicer.
--
:wq Claudio
