Re: OpenBGPd Feature Request / Question if the Feature Request
Hello Gregory ,please find my responses in line On Tue 25 Sep 2018, 15:54 Gregory Edigarov, wrote: > > > the whole discussion here reminds me somewhat about my idea I wanted to > realize some time ago: > suppose we have an imaginary "fast" router, which does hardware > assisted forwarding, and an OpenBGP(on a different host) lets call it > RDE, where it will provide routes for this fast router, to be put into > forwarding engine. > then we would have the following advantages: > 1. nice way to configure whatever we need in BGP (because we all know > that bgpd.conf is a very nice thing) > Openbgpd in nice for a control plane 2. real packet forwarding will take place on the hardware, specifically > built for this purpose. > Standard l3 switches can do this as long as they have 1. Sufficient cam /asic memory to accomodate the routes you intend to load into switch forwarding plane 2. The switch os needs to support bgp and have sufficent memory + cpu to allow some route filtering between rib and fib on the switch 3. Probably ospf also would be neededon the switch 3. if somebody would manufacture such say "dumb" forwarding planes, they > would definitely cost less then a fully featured router. > Yeah i think a decent l3 switch (broadcom trident ii ) or better would do what you are asking for > > is this a feasible idea or am I thinking completely wrong I dont think u need a special manufacturer for what im proposing .
Re: OpenBGPd Feature Request / Question if the Feature Request
On 22.09.18 17:11, Tom Smyth wrote: Hello Stuart, Thanks for the feedback , I have responded to your feedback in line, On Sat, 22 Sep 2018 at 10:07, Stuart Henderson wrote: Interesting idea but I think the method you're suggesting puts you at higher risk of things *not* reaching their destination - if you have good and not-so-good transits, the diffs are likely to be things you don't want anyway and could interfere with correct routing. I see your point I had not considered that failure mode. Some providers have a bit of a problem with "stuck" routes (if there's a stuck more-specific route at one provider, that will be a difference, and you'll send traffic there on a road to nowhere instead of to a valid less-specific). I get what you are saying however this would still be a problem if I had full views (if I understand your point correctly, any more specific network that is invalid would still blackhole traffic in the case where we have full tables ) also with that risk in mind I (think) such a setup would be better than defaulting to a transit provider who has sent a withdraw message on a prefix Another issue is that a good provider may have filtered a dubious announcement (hijack attempt), a less fastidious one might not. If I wanted to identify *whether* a transit provider is sending such routes, analysing a diff of the announcements between them and another provider is quite a good way to find them. I agree with you ... there would have to be some steady state comparison between the two (or more) Transit providers in normal conditions... the usual threats (hijacks etc would have to be dealt with with the usual IRR filtersetc My suggestion if you're trying to use the hardware in this way: only use transit providers who can be trusted to generally provide good transit (which rules out a few ;) and just use defaults plus maybe allow some extra through filters to encourage certain traffic to go a certain way, or to balance load if your ports are hot. Yeah ... that would be the (rough) plan .. .or build workaround filters on the less well configured transit providers, there are other things to consider which makes it a tough(er) problem to solve what happens when your default provider looses connectivity with (most) of its peers then it would be better to swap the default route to the other transit provider and install exception routes (if any) the whole discussion here reminds me somewhat about my idea I wanted to realize some time ago: suppose we have an imaginary "fast" router, which does hardware assisted forwarding, and an OpenBGP(on a different host) lets call it RDE, where it will provide routes for this fast router, to be put into forwarding engine. then we would have the following advantages: 1. nice way to configure whatever we need in BGP (because we all know that bgpd.conf is a very nice thing) 2. real packet forwarding will take place on the hardware, specifically built for this purpose. 3. if somebody would manufacture such say "dumb" forwarding planes, they would definitely cost less then a fully featured router. is this a feasible idea or am I thinking completely wrong ?
Re: OpenBGPd Feature Request / Question if the Feature Request
Hello Stuart, Thanks for the feedback , I have responded to your feedback in line, On Sat, 22 Sep 2018 at 10:07, Stuart Henderson wrote: > > > Interesting idea but I think the method you're suggesting puts you at > higher risk of things *not* reaching their destination - if you have > good and not-so-good transits, the diffs are likely to be things you > don't want anyway and could interfere with correct routing. I see your point I had not considered that failure mode. > > Some providers have a bit of a problem with "stuck" routes (if there's > a stuck more-specific route at one provider, that will be a difference, > and you'll send traffic there on a road to nowhere instead of to a valid > less-specific). I get what you are saying however this would still be a problem if I had full views (if I understand your point correctly, any more specific network that is invalid would still blackhole traffic in the case where we have full tables ) also with that risk in mind I (think) such a setup would be better than defaulting to a transit provider who has sent a withdraw message on a prefix > > Another issue is that a good provider may have filtered a dubious > announcement (hijack attempt), a less fastidious one might not. > > If I wanted to identify *whether* a transit provider is sending such > routes, analysing a diff of the announcements between them and another > provider is quite a good way to find them. > I agree with you ... there would have to be some steady state comparison between the two (or more) Transit providers in normal conditions... the usual threats (hijacks etc would have to be dealt with with the usual IRR filtersetc > My suggestion if you're trying to use the hardware in this way: only use > transit providers who can be trusted to generally provide good transit > (which rules out a few ;) and just use defaults plus maybe allow some > extra through filters to encourage certain traffic to go a certain way, > or to balance load if your ports are hot. Yeah ... that would be the (rough) plan .. .or build workaround filters on the less well configured transit providers, there are other things to consider which makes it a tough(er) problem to solve what happens when your default provider looses connectivity with (most) of its peers then it would be better to swap the default route to the other transit provider and install exception routes (if any) Thanks for your feedback and time Tom Smyth
Re: OpenBGPd Feature Request / Question if the Feature Request
On 2018/09/22 09:21, Tom Smyth wrote: > I like the NFsen idea, however I think for a simple eyeball ISP we could > be able to achieve it by adding a default + exceptions summarisation > to openBGPd ( I would rather not create more dependencies on our BGP > ) > I want to install the minimum number of routes for transit > so that I am confident the packet will reach the intended destination > and then leave the rest of the switch CAM for Prefixes learned on > a local internet exchange. Interesting idea but I think the method you're suggesting puts you at higher risk of things *not* reaching their destination - if you have good and not-so-good transits, the diffs are likely to be things you don't want anyway and could interfere with correct routing. Some providers have a bit of a problem with "stuck" routes (if there's a stuck more-specific route at one provider, that will be a difference, and you'll send traffic there on a road to nowhere instead of to a valid less-specific). Another issue is that a good provider may have filtered a dubious announcement (hijack attempt), a less fastidious one might not. If I wanted to identify *whether* a transit provider is sending such routes, analysing a diff of the announcements between them and another provider is quite a good way to find them. My suggestion if you're trying to use the hardware in this way: only use transit providers who can be trusted to generally provide good transit (which rules out a few ;) and just use defaults plus maybe allow some extra through filters to encourage certain traffic to go a certain way, or to balance load if your ports are hot.
Re: OpenBGPd Feature Request / Question if the Feature Request
Hello Remi, Thanks for that, I saw a presentation from Paulo Lucende about this. for us as an eyeball ISP, my request is slightly simpler, because I can Advertise my routes to all peers / transit so my downloads will happen, to sort the upload I need to learn and install the routes. (content providers need to use netflow to learn which prefixes should be installed on the switch to deliver content to the users) I like the NFsen idea, however I think for a simple eyeball ISP we could be able to achieve it by adding a default + exceptions summarisation to openBGPd ( I would rather not create more dependencies on our BGP ) I want to install the minimum number of routes for transit so that I am confident the packet will reach the intended destination and then leave the rest of the switch CAM for Prefixes learned on a local internet exchange. Thanks for the feedback on the Spotify Use case... On Sat, 22 Sep 2018 at 09:11, Remi Locherer wrote: > > On Sat, Sep 22, 2018 at 08:22:52AM +0100, Tom Smyth wrote: > > OpenBGPd Feature Request / Question if the Feature Request > > is something the community would use ? > > > > Background, > > Ideally we would run full tables so that we have visibility > > on reachibility of a prefix via a transit provider, > > > > Problem: routers that support this functionality Reliably > > are quite expensive, (or inexpensive and unreliable) > > Workaround: > > so many people accept default over BGP from transit and > > then peer locally on the exchange > > Issue with this is that you lose visibility of wheather > > an ip is actually reachable via your transit provider > > > > > > Question: > > is it feasible to have a hybrid between a default route > > for transit and bgp full views of transit? > > Is it feasible to: > > a) take two or more full bgp feeds from transit, > > b) diff them continuously on a software route server, > > c) install a default route to your preferred transit provider > > on your lower cost L3 Switches / Routers > > d) install differences in prefix reachibilitity to the > > appropiate transit provider (which would otherwise not > > be reachable via your preferred transit provider) > > > > > > Why am I asking this ? > > I want to have the advantages of full views of internet > > but I want the simplicity of a single default route + > > any exceptions. and use more cost effective hardware > > > > Im asking this in the context of an ISP which is not > > proividing transit to other ISPs > > > > I ideally would like to run multihop BGP to my transit > > providers, > > and then use a L3 switch for forwarding in hardware > > (something like an arista / Broadcom Trident II ) > > which can take up to around 128k routes on its asics > > > > If it is feasible to do what is involved in adding it > > to OpenBGPd and is this something the wider community > > would use / enjoy ? > > > > Your feedback would be really appreciated... > > Yes, it is feasible. Spotify is doing something like this. > https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html > > In short: analyse where 80% of your traffic goes to (nfsen) and write a > filter to only install those prefixes in addition to the default route. > > A year ago I did this analysis for the network I operate: > 80% of our Internet traffic went to 20 ASs and was covered by ~9k prefixes. > > Cheers, > Remi
Re: OpenBGPd Feature Request / Question if the Feature Request
On Sat, Sep 22, 2018 at 08:22:52AM +0100, Tom Smyth wrote: > OpenBGPd Feature Request / Question if the Feature Request > is something the community would use ? > > Background, > Ideally we would run full tables so that we have visibility > on reachibility of a prefix via a transit provider, > > Problem: routers that support this functionality Reliably > are quite expensive, (or inexpensive and unreliable) > Workaround: > so many people accept default over BGP from transit and > then peer locally on the exchange > Issue with this is that you lose visibility of wheather > an ip is actually reachable via your transit provider > > > Question: > is it feasible to have a hybrid between a default route > for transit and bgp full views of transit? > Is it feasible to: > a) take two or more full bgp feeds from transit, > b) diff them continuously on a software route server, > c) install a default route to your preferred transit provider > on your lower cost L3 Switches / Routers > d) install differences in prefix reachibilitity to the > appropiate transit provider (which would otherwise not > be reachable via your preferred transit provider) > > > Why am I asking this ? > I want to have the advantages of full views of internet > but I want the simplicity of a single default route + > any exceptions. and use more cost effective hardware > > Im asking this in the context of an ISP which is not > proividing transit to other ISPs > > I ideally would like to run multihop BGP to my transit > providers, > and then use a L3 switch for forwarding in hardware > (something like an arista / Broadcom Trident II ) > which can take up to around 128k routes on its asics > > If it is feasible to do what is involved in adding it > to OpenBGPd and is this something the wider community > would use / enjoy ? > > Your feedback would be really appreciated... Yes, it is feasible. Spotify is doing something like this. https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html In short: analyse where 80% of your traffic goes to (nfsen) and write a filter to only install those prefixes in addition to the default route. A year ago I did this analysis for the network I operate: 80% of our Internet traffic went to 20 ASs and was covered by ~9k prefixes. Cheers, Remi
OpenBGPd Feature Request / Question if the Feature Request
OpenBGPd Feature Request / Question if the Feature Request is something the community would use ? Background, Ideally we would run full tables so that we have visibility on reachibility of a prefix via a transit provider, Problem: routers that support this functionality Reliably are quite expensive, (or inexpensive and unreliable) Workaround: so many people accept default over BGP from transit and then peer locally on the exchange Issue with this is that you lose visibility of wheather an ip is actually reachable via your transit provider Question: is it feasible to have a hybrid between a default route for transit and bgp full views of transit? Is it feasible to: a) take two or more full bgp feeds from transit, b) diff them continuously on a software route server, c) install a default route to your preferred transit provider on your lower cost L3 Switches / Routers d) install differences in prefix reachibilitity to the appropiate transit provider (which would otherwise not be reachable via your preferred transit provider) Why am I asking this ? I want to have the advantages of full views of internet but I want the simplicity of a single default route + any exceptions. and use more cost effective hardware Im asking this in the context of an ISP which is not proividing transit to other ISPs I ideally would like to run multihop BGP to my transit providers, and then use a L3 switch for forwarding in hardware (something like an arista / Broadcom Trident II ) which can take up to around 128k routes on its asics If it is feasible to do what is involved in adding it to OpenBGPd and is this something the wider community would use / enjoy ? Your feedback would be really appreciated... Tom Smyth
