Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf
per engelbrecht wrote: 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: ? Using your own AS as an remote ASn will, per definition, make your BGP session into an internal BGP session. In the Ciscoeee world, no synchronization means to begin announcing your networks before higher priority network protocols are up and stabilized. Without you will wait for OSPF/IS-IS to stabilize first (For OSPF, there is a certain state in its state machine it has to reach for all broadcast clouds etc). However, in modern BGP setups, you screw OSPF/IS-IS royally and ignore the stabilization. This is viable, since you ``nail down'' your networks as CIDR aggregates (to minimize the number of BGP prefixes you announce) and give a heck about internal reachability. Oh, and while we are at Zebra: Its crap, kill it as soon as possible or install quagga. Case in point: mirah% pwd /usr/ports/net/zebra/w-zebra-0.93ap3/zebra-0.93a/ospfd mirah% grep OSPF_LSA_HEADER ospf_lsa.c ospf_output_forward (s, OSPF_LSA_HEADER_SIZE); assert (l1->data->length > OSPF_LSA_HEADER_SIZE); if (memcmp (p1 + OSPF_LSA_HEADER_SIZE, p2 + OSPF_LSA_HEADER_SIZE, ntohs( l1->data->length ) - OSPF_LSA_HEADER_SIZE) != 0) mirah% Lets see... On the last line, we have identified that l1->data->length is in network byte order. But in the assert 2 lines up, we do _not_ have a ntohs() call. This took a medium sized ISP down in Denmark because Zebra suddenly died due to the fact, that certain packets, if certain size, will be caught by the assertion and ospfd gets to say hello to the kernel thread known as reaper man. 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: ? It will push directly connected routes into OSPF. That is, if the machine has a network to which it has a direct connection in the routing table, then the rest of your OSPF speakers will learn that this network is reachable by going through this router. redistribute ospf in Ciscoee in the BGP section of the router configuration tells the IOS to take all OSPF learned routes and push them into BGP. This can be extremely dangerous to do, depending on the configuration. 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: ? A more specific route will always match. Normally, you do not need to redistribute routes between the protocols at all, considered all of your routers are running BGP as well as OSPF. BGP will then handle prefixes for external networks and OSPF will handle prefixes for internal ones in the case both BGP and OSPF have the route then BGP wins -- but note the note about specific matches ;)
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf
Jesper Louis Andersen wrote: per engelbrecht wrote: 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: ? Using your own AS as an remote ASn will, per definition, make your BGP session into an internal BGP session. In the Ciscoeee world, no synchronization means to begin announcing your networks before higher priority network protocols are up and stabilized. Without you will wait for OSPF/IS-IS to stabilize first (For OSPF, there is a certain state in its state machine it has to reach for all broadcast clouds etc). Hi jlouis It was more of a what_can_option_[a-z] from Zebra be put on par with in OpenBGPD and/or do I need these options at all (different implementation) but thank you for your explanation. However, in modern BGP setups, you screw OSPF/IS-IS royally and ignore the stabilization. This is viable, since you ``nail down'' your networks as CIDR aggregates (to minimize the number of BGP prefixes you announce) and give a heck about internal reachability. Screwing IGP's from whitin EGP's keep things apart, buy they are (conceptually, at least in my head) still manipulating the same routing table. And yes of course I only announce our own net. Returning 120.000+ prefixes (at that time) to a eBGP peer with inferior Cisco hw works like magic - the phone rings within minutes .. and they're not returning a call :) Oh, and while we are at Zebra: Its crap, kill it as soon as possible or install quagga. Case in point: .. install quagga ? Nooope. mirah% pwd /usr/ports/net/zebra/w-zebra-0.93ap3/zebra-0.93a/ospfd mirah% grep OSPF_LSA_HEADER ospf_lsa.c ospf_output_forward (s, OSPF_LSA_HEADER_SIZE); assert (l1->data->length > OSPF_LSA_HEADER_SIZE); if (memcmp (p1 + OSPF_LSA_HEADER_SIZE, p2 + OSPF_LSA_HEADER_SIZE, ntohs( l1->data->length ) - OSPF_LSA_HEADER_SIZE) != 0) mirah% Lets see... On the last line, we have identified that l1->data->length is in network byte order. But in the assert 2 lines up, we do _not_ have a ntohs() call. This took a medium sized ISP down in Denmark because Zebra suddenly died due to the fact, that certain packets, if certain size, will be caught by the assertion and ospfd gets to say hello to the kernel thread known as reaper man. 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: ? It will push directly connected routes into OSPF. That is, if the machine has a network to which it has a direct connection in the routing table, then the rest of your OSPF speakers will learn that this network is reachable by going through this router. Which is also what I want. redistribute ospf in Ciscoee in the BGP section of the router configuration tells the IOS to take all OSPF learned routes and push them into BGP. This can be extremely dangerous to do, depending on the configuration. Yes that could easily have disaster written all over it. 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: ? A more specific route will always match. Normally, you do not need to redistribute routes between the protocols at all, considered all of your routers are running BGP as well as OSPF. BGP will then handle prefixes for external networks and OSPF will handle prefixes for internal ones in the case both BGP and OSPF have the route then BGP wins -- but note the note about specific matches ;) Thank you for joining in jlouis. /per [EMAIL PROTECTED]
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
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 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
> 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
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
Claudio Jeker wrote:
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.
Hi Claudio
Most documentation on BGP or OSPF is geared towards IOS systems or pro
ISO systems like Zebra, with whatever options and syntax that comes with
the territory. Finding alternatives for options like e.g. 'no
synchronization' and'no auto-summary' when changing from (in my case)
Zebra to OpenBGPD, is not covered too well in a otherwise fine
documentation, but thank you for clarifying.
A small paragraph in the bgpd.conf man page for people comming to
OpenBGPD dealing with this would be nice.
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 clear will clear
the session and activate tcp md5. You can do that one peer at a time.
Check.
(thank you)
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.
Perfect.
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).
I guess reading BGP from Cisco literature would match learning TCP/IP
with books from Microsoft ...
The BGP implementation in Cisco IOS uses a administrative distance,
hence the question.
I you mean equal routes from a 'weight' point of view, then I have a
problem. So fare all my peers have the same weight.
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
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.
I have carp1 on em5. I'll change em5 > carp1 right away. Thank you.
announce all
That's actually the default :)
I know. In every conf file I write what I want it to do (even defaults)
and remove anything else. Makes it easy to parse for !me without having
to know system 'default'.
announce IPv6 none
enforce neighbor-as no
That one as well.
Ditto.
:)
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 t
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
* Claudio Jeker <[EMAIL PROTECTED]> [2005-11-02 12:04]: > 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). that is not true. there is no undefined behaviour. first one wins. > Again this is on the todo list (even before the redistribute thing). yes. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
* per engelbrecht <[EMAIL PROTECTED]> [2005-11-02 00:52]: > 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. should just work. > 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. not needed. retarded idea in the first place... I mean, you don't need "ip classless" on OpenBSD either to tell it we're not in the 80s any more :) > 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. # bgpctl reload next time the session(s) in question traverses IDLE the settings become active. you can force that using # bgpctl neighbor foo clear -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
