Hello, We are configuring a BSDRP server (FreeBSD router.bsdrp.net 10.3-RELEASE-p2 FreeBSD 10.3-RELEASE-p2 #0 r299108M). We have two fullrouting bgp carriers, some bgp members and some ospf members. To isolate OSPF members we want to use kernel fibs. But we do not understand how it works. What we need is a diferent table for each ospf member, so for example ospf1member will use carrier1 routes, and ospf2member will use carrier2 routes. Which is the best way to get this? If we configure kernel fib 1 with carrier1 routes, but ospf1 doesn't use it, how we can to configure because ospf1 use kernel fib 1? How to do the same for ospf2 with kernel fib 2? We have to configure interfaces in these fibs? What about carriers interface? Could you give us some example to get above configuration? Regards, Angel.
On 27/05/16 19:14, Angel wrote:
Hello,
We are configuring a BSDRP server (FreeBSD router.bsdrp.net 10.3-RELEASE-p2 FreeBSD 10.3-RELEASE-p2 #0 r299108M).
We have two fullrouting bgp carriers, some bgp members and some ospf members.
To isolate OSPF members we want to use kernel fibs. But we do not understand how it works.
OSPF assumes that all OSPF speaking routers trust each other. OSPF relies on all OSPF routers receiving the same unfiltered set of routes, because otherwise the link-state databases would be out of sync.
What we need is a diferent table for each ospf member, so for example ospf1member will use carrier1 routes, and ospf2member will use carrier2 routes.
Which is the best way to get this?
I would recommend against speaking OSPF to routers administered by a different party. If both sides support BGP use BGP instead of OSPF. If you can't speak BGP to the other party use one OSPF instance per party.
If we configure kernel fib 1 with carrier1 routes, but ospf1 doesn't use it, how we can to configure because ospf1 use kernel fib 1? How to do the same for ospf2 with kernel fib 2?
We have to configure interfaces in these fibs? What about carriers interface?
Do you require routing domains (aka vnet/VIMAGE in FreeBSD) or just policy based routing?
Could you give us some example to get above configuration?
Not without further information.
I would recommend against speaking OSPF to routers administered by a different party. If both sides support BGP use BGP instead of OSPF. If you can't speak BGP to the other party use one OSPF instance per party.
I'd just like to add that filtering can be done in any distance-vector protocol. If you prefer an IGP (so you can avoid messing with private AS numbers), this can be done in RIPv2/RIPng, EIGRP, and Babel. But I agree with Jan, BGP is a good choice. -- Juliusz
On 27 May 2016, at 18:14, Angel <angel@bitnap.net> wrote:
We have two fullrouting bgp carriers, some bgp members and some ospf members.
To isolate OSPF members we want to use kernel fibs. But we do not understand how it works. What we need is a diferent table for each ospf member, so for example ospf1member will use carrier1 routes, and ospf2member will use carrier2 routes.
Are you trying to get the OSPF members to talk to each other, or are you trying to get the OSPF members not to talk to each other? Within any one given OSPF process, all OSPF speakers should receive the same set of link states (what OSPF advertises) [1]. Filtering link states will not work as the protocol assumes the link state database is the same everywhere. Moreover link states are not routes. You can in theory filter link states between the OSPF RIB and the kernel FIB without breaking the OSPF process, but it is likely to break forwarding unless you are careful. So, within one OSPF process in general you will have no filtering (none of link states, and probably none of routes). You can filter how you wish between OSPF processes (each being a protocol within bird). You should ensure (ospf authentication is a good way to do this) the processes don't talk to each other and accidentally join. I *think* what you are trying to do is run one IGP (OSPF) with one upstream BGP speaker, and a completely separate IGP (a different OSPF process) with another BGP speaker, and have these talk to two kernel FIBs, rather like 2 separate VRFs on Cisco. Not only do you need to inject OSPF routes from each process into a different kernel FIB, but you are are also running 2 OSPF processes on the same interface and need to have both interfaces deal with it, but also (and here's the killer) you need some way to get inbound traffic to route using the correct kernel FIB. That's going to be really hard (funkiness with ToS bits aside). Instead, you want to make subinterfaces / VLAN interfaces / whatever for each process, and attach those to each kernel routing table. Then run only one OSPF process on each interface. Authentication is still a good idea. Whenever I've done this I've run bird in a separate network container (unshare -n) but with separate interfaces, and separate FIBs, this should theoretically work. [1] - An oversimplification in stub areas and NSSA but ignore that complication for now as they are nothing to do with what you are asking. -- Alex Bligh
Hello Alex, Thanks, so what we will do is configure one vlan interface for each ospf protocol, so they could use different kernel tables. How could we configure becuase: ospf1 with vlan igb1.1 use kernel 1? ospf2 with vlan igb1.2 use kernel 2? ospf3 with vlan igb1.3 use kernel 3? We have to configure only igb1.x interfaces on each kernel table or we have to configure ix0 (carriers bgp interface) on every of them? So, we want to get following picture: OSPF1 --> igb1.1 --> kernel1 --> ix0 --> internet OSPF2 --> igb1.2 --> kernel2 --> ix0 --> internet OSPF3 --> igb1.3 --> kernel3 --> ix0 --> internet And kernel1, kernel2, kernel3 are diferrent. Regards, -----Mensaje original-----
De: "Alex Bligh" <alex@alex.org.uk> A: Angel <angel@bitnap.net> Cc: "Alex Bligh" <alex@alex.org.uk>, bird-users@network.cz Fecha: 30-05-2016 10:36 Asunto: Re: routing using kernel fibs
On 27 May 2016, at 18:14, Angel <angel@bitnap.net> wrote:
We have two fullrouting bgp carriers, some bgp members and some ospf members.
To isolate OSPF members we want to use kernel fibs. But we do not understand how it works. What we need is a diferent table for each ospf member, so for example ospf1member will use carrier1 routes, and ospf2member will use carrier2 routes.
Are you trying to get the OSPF members to talk to each other, or are you trying to get the OSPF members not to talk to each other?
Within any one given OSPF process, all OSPF speakers should receive the same set of link states (what OSPF advertises) [1]. Filtering link states will not work as the protocol assumes the link state database is the same everywhere. Moreover link states are not routes. You can in theory filter link states between the OSPF RIB and the kernel FIB without breaking the OSPF process, but it is likely to break forwarding unless you are careful.
So, within one OSPF process in general you will have no filtering (none of link states, and probably none of routes). You can filter how you wish between OSPF processes (each being a protocol within bird). You should ensure (ospf authentication is a good way to do this) the processes don't talk to each other and accidentally join.
I *think* what you are trying to do is run one IGP (OSPF) with one upstream BGP speaker, and a completely separate IGP (a different OSPF process) with another BGP speaker, and have these talk to two kernel FIBs, rather like 2 separate VRFs on Cisco. Not only do you need to inject OSPF routes from each process into a different kernel FIB, but you are are also running 2 OSPF processes on the same interface and need to have both interfaces deal with it, but also (and here's the killer) you need some way to get inbound traffic to route using the correct kernel FIB. That's going to be really hard (funkiness with ToS bits aside).
Instead, you want to make subinterfaces / VLAN interfaces / whatever for each process, and attach those to each kernel routing table. Then run only one OSPF process on each interface. Authentication is still a good idea. Whenever I've done this I've run bird in a separate network container (unshare -n) but with separate interfaces, and separate FIBs, this should theoretically work.
[1] - An oversimplification in stub areas and NSSA but ignore that complication for now as they are nothing to do with what you are asking.
-- Alex Bligh
participants (4)
-
Alex Bligh -
Angel -
Jan Bramkamp -
Juliusz Chroboczek