Moving from Bird to OpenBGPD

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving from Bird to OpenBGPD

BSD user-3
Hello,

My apologies for sending this email multiple times.

I was so mortified by Tutanota's awful text formatting that I created a
new mail account that supported IMAP so that I could load it up in
Thunderbird with text only mode enabled.

Once again, my apologies for my rookie mistake choosing Tutanota for use
on an international mailing list such as this one. I hope you guys will
give me one more chance.

My (hopefully) unmangled message is below.


----------------------------------


Hello,


I’m having some trouble configuring OpenBGPD to replace my Bird deployment.

I’m trying to set up redundant web infrastructure for a few websites I
host with Vultr. To do so, I followed this guide:

https://www.vultr.com/docs/high-availability-on-vultr-with-floating-ip-and-bgp

It works flawlessly with Bird running on OpenBSD, but I obviously prefer
to run utilities from the base system wherever possible. I’ve spent more
time than I’d like to admit trying to get this setup working on OpenBGPD.

The only thing I did different from the above guide was use lo1 rather
than a dummy interface, as dummy interfaces appear to be a linuxism as
per this mailing list thread I found:

http://openbsd-archive.7691.n7.nabble.com/Dummy-Interface-In-OpenBGPd-td34009.html

Basically, all I’m trying to do is port my Bird config over to OpenBGPD.
At this point I’m just banging my head against a wall. I’ve spent
several days googling, reading man pages and trying different configs. I
must be missing something basic, and it’s likely something obvious I’m
missing, as I am by no means a BGP expert.

My bird config looks like this:


log "/var/log/bird" all;

router id xxx.xxx.224.9;

protocol device
{
     scan time 60;
}

protocol direct
{
     interface "lo1";
}

protocol bgp vultr
{
     local as 65xxx;
     source address xxx.xxx.224.9;
     import none;
     export all;
     graceful restart on;
     next hop self;
     multihop 2;
     neighbor 169.254.169.254 as 64515;
     password "xxxxxx";
}


My attempt at a bgpd.conf looks like this:


# Global Configuration

AS 65xxx
router-id xxx.xxx.224.9

# Our Address Space
network xxx.xxx.0.141/32
network inet connected

# IPv4 Peers

neighbor 169.254.169.254 {
         remote-as               64515
         tcp md5sig password     xxxxxx
         set nexthop self
         multihop                2
         descr                   Vultr
         local-address           xxx.xxx.224.9
         announce                IPv4 unicast
}



Any assistance you fine folks could provide to help me get this working
would be hugely appreciated.

I've also attached my config files to eliminate any chance of them being
mangled.

Thanks so much for your time.


bgpd.conf (455 bytes) Download Attachment
bird.conf (393 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

Denis Fondras
On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:

> Hello,
>
> My apologies for sending this email multiple times.
>
> I was so mortified by Tutanota's awful text formatting that I created a
> new mail account that supported IMAP so that I could load it up in
> Thunderbird with text only mode enabled.
>
> Once again, my apologies for my rookie mistake choosing Tutanota for use
> on an international mailing list such as this one. I hope you guys will
> give me one more chance.
>
> My (hopefully) unmangled message is below.
>

You did not include which version you are running, I'll assume this is 6.5.
It seems you do not have any filter, OpenBGPD denies everything by default.

>
> ----------------------------------
>
>
> Hello,
>
>
> I’m having some trouble configuring OpenBGPD to replace my Bird deployment.
>
> I’m trying to set up redundant web infrastructure for a few websites I
> host with Vultr. To do so, I followed this guide:
>
> https://www.vultr.com/docs/high-availability-on-vultr-with-floating-ip-and-bgp
>
> It works flawlessly with Bird running on OpenBSD, but I obviously prefer
> to run utilities from the base system wherever possible. I’ve spent more
> time than I’d like to admit trying to get this setup working on OpenBGPD.
>
> The only thing I did different from the above guide was use lo1 rather
> than a dummy interface, as dummy interfaces appear to be a linuxism as
> per this mailing list thread I found:
>
> http://openbsd-archive.7691.n7.nabble.com/Dummy-Interface-In-OpenBGPd-td34009.html
>
> Basically, all I’m trying to do is port my Bird config over to OpenBGPD.
> At this point I’m just banging my head against a wall. I’ve spent
> several days googling, reading man pages and trying different configs. I
> must be missing something basic, and it’s likely something obvious I’m
> missing, as I am by no means a BGP expert.
>
> My bird config looks like this:
>
>
> log "/var/log/bird" all;
>
> router id xxx.xxx.224.9;
>
> protocol device
> {
>     scan time 60;
> }
>
> protocol direct
> {
>     interface "lo1";
> }
>
> protocol bgp vultr
> {
>     local as 65xxx;
>     source address xxx.xxx.224.9;
>     import none;
>     export all;
>     graceful restart on;
>     next hop self;
>     multihop 2;
>     neighbor 169.254.169.254 as 64515;
>     password "xxxxxx";
> }
>
>
> My attempt at a bgpd.conf looks like this:
>
>
> # Global Configuration
>
> AS 65xxx
> router-id xxx.xxx.224.9
>
> # Our Address Space
> network xxx.xxx.0.141/32
> network inet connected
>
> # IPv4 Peers
>
> neighbor 169.254.169.254 {
>         remote-as               64515
>         tcp md5sig password     xxxxxx
>         set nexthop self
>         multihop                2
>         descr                   Vultr
>         local-address           xxx.xxx.224.9
>         announce                IPv4 unicast
> }
>
>
>
> Any assistance you fine folks could provide to help me get this working
> would be hugely appreciated.
>
> I've also attached my config files to eliminate any chance of them being
> mangled.
>
> Thanks so much for your time.
>

> # Global Configuration
>
> AS 65xxx
> router-id xxx.xxx.224.9
>
> # Our Address Space
> network xxx.xxx.0.141/32
> network inet connected
>
> # IPv4 Peers
>
> neighbor 169.254.169.254 {
>         remote-as               64515
>         tcp md5sig password     xxxxxx
>         set nexthop self
>         multihop                2
>         descr                   Vultr
>         local-address           xxx.xxx.224.9
>         announce                IPv4 unicast
> }

> log "/var/log/bird" all;
>
> router id xxx.xxx.224.9;
>
> protocol device
> {
>     scan time 60;
> }
>
> protocol direct
> {
>     interface "lo1";
> }
>
> protocol bgp vultr
> {
>     local as 65xxx;
>     source address xxx.xxx.224.9;
>     import none;
>     export all;
>     graceful restart on;
>     next hop self;
>     multihop 2;
>     neighbor 169.254.169.254 as 64515;
>     password "xxxxxx";
> }
>

Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

Rudy Baker
In reply to this post by BSD user-3
It's sad how hostile this mailing list is that you need to beg forgiveness
for using a different email client because you may have triggered some of
these people. 🙄

On Sun, Jul 14, 2019, 12:51 AM BSD user, <[hidden email]> wrote:

> Hello,
>
> My apologies for sending this email multiple times.
>
> I was so mortified by Tutanota's awful text formatting that I created a
> new mail account that supported IMAP so that I could load it up in
> Thunderbird with text only mode enabled.
>
> Once again, my apologies for my rookie mistake choosing Tutanota for use
> on an international mailing list such as this one. I hope you guys will
> give me one more chance.
>
> My (hopefully) unmangled message is below.
>
>
> ----------------------------------
>
>
> Hello,
>
>
> I’m having some trouble configuring OpenBGPD to replace my Bird deployment.
>
> I’m trying to set up redundant web infrastructure for a few websites I
> host with Vultr. To do so, I followed this guide:
>
>
> https://www.vultr.com/docs/high-availability-on-vultr-with-floating-ip-and-bgp
>
> It works flawlessly with Bird running on OpenBSD, but I obviously prefer
> to run utilities from the base system wherever possible. I’ve spent more
> time than I’d like to admit trying to get this setup working on OpenBGPD.
>
> The only thing I did different from the above guide was use lo1 rather
> than a dummy interface, as dummy interfaces appear to be a linuxism as
> per this mailing list thread I found:
>
>
> http://openbsd-archive.7691.n7.nabble.com/Dummy-Interface-In-OpenBGPd-td34009.html
>
> Basically, all I’m trying to do is port my Bird config over to OpenBGPD.
> At this point I’m just banging my head against a wall. I’ve spent
> several days googling, reading man pages and trying different configs. I
> must be missing something basic, and it’s likely something obvious I’m
> missing, as I am by no means a BGP expert.
>
> My bird config looks like this:
>
>
> log "/var/log/bird" all;
>
> router id xxx.xxx.224.9;
>
> protocol device
> {
>      scan time 60;
> }
>
> protocol direct
> {
>      interface "lo1";
> }
>
> protocol bgp vultr
> {
>      local as 65xxx;
>      source address xxx.xxx.224.9;
>      import none;
>      export all;
>      graceful restart on;
>      next hop self;
>      multihop 2;
>      neighbor 169.254.169.254 as 64515;
>      password "xxxxxx";
> }
>
>
> My attempt at a bgpd.conf looks like this:
>
>
> # Global Configuration
>
> AS 65xxx
> router-id xxx.xxx.224.9
>
> # Our Address Space
> network xxx.xxx.0.141/32
> network inet connected
>
> # IPv4 Peers
>
> neighbor 169.254.169.254 {
>          remote-as               64515
>          tcp md5sig password     xxxxxx
>          set nexthop self
>          multihop                2
>          descr                   Vultr
>          local-address           xxx.xxx.224.9
>          announce                IPv4 unicast
> }
>
>
>
> Any assistance you fine folks could provide to help me get this working
> would be hugely appreciated.
>
> I've also attached my config files to eliminate any chance of them being
> mangled.
>
> Thanks so much for your time.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

Ingo Schwarze
Hi Rudy,

Rudy Baker wrote on Sun, Jul 14, 2019 at 03:38:03PM -0400:

> It's sad how hostile this mailing list is

It is true that some people on this list are sometimes hostile
and everybody is indeed invited to refrain from gratuitious attacks, ...

> that you need to beg forgiveness for using a different email client
> because you may have triggered some of these people.

 ... but telling people to comply with netiquette and format their
postings properly is not hostility (in particular not when done
quietly in private by a developer like i did).  Grossly mangled
postings *are* a problem because they waste everybody's time - both
by being tedious to read and also by often causing misunderstandings
because broken formatting often also breaks the syntax of included
code, examples, and patches.  People can be expected to know how
to use email before posting.  If you are not sure you do, practice
with private messages to friends until you are sure you know how
to get everything right.

This wasn't about email clients at all.  You are welcome to use whatever
software and providers you like as long as you observe the netiquette
explained on:

  https://www.openbsd.org/mail.html

By the way, no need for long apologies, if something went wrong,
simply make sure you do things right in the future.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

BSD user-3
In reply to this post by Denis Fondras


On 7/14/19 12:52 AM, Denis Fondras wrote:

> On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:
>> Hello,
>>
>> My apologies for sending this email multiple times.
>>
>> I was so mortified by Tutanota's awful text formatting that I created a
>> new mail account that supported IMAP so that I could load it up in
>> Thunderbird with text only mode enabled.
>>
>> Once again, my apologies for my rookie mistake choosing Tutanota for use
>> on an international mailing list such as this one. I hope you guys will
>> give me one more chance.
>>
>> My (hopefully) unmangled message is below.
>>
>
> You did not include which version you are running, I'll assume this is 6.5.
> It seems you do not have any filter, OpenBGPD denies everything by default.
>

Thanks for the reply Denis. You were right, I was missing my allow
rules. After setting "allow from any AS 64515" and "allow to any" rules,
everything started working. I was able to get IPv6 working as well
without a hitch.

Are there any other filter rules I should be setting to secure my BGP
deployment? I'm on a private ASN assigned to me by Vultr. This is my
first forray into BGP land, so any advice or tips would be much
appreciated.

Cheers

Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

BSD user-3
In reply to this post by Rudy Baker


On 7/14/19 12:38 PM, Rudy Baker wrote:
> It's sad how hostile this mailing list is that you need to beg forgiveness
> for using a different email client because you may have triggered some of
> these people. 🙄
>

I'm not too concerned. I'm grateful for the fact that the OpenBSD
community has high standards. Upon reading my message on marc.info, I my
self was irritated by the poor formatting. I appreciate that Ingo
contacted my privately and informed me that tutanota was mangling my
mail. Upon realizing this, I rectified the issue, as it's a matter of
etiquette-- I'm already asking strangers to take time out of their day
to assist me, the least I can do is make it easy for them to understand
my request.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

Claudio Jeker
In reply to this post by BSD user-3
On Sun, Jul 14, 2019 at 07:28:29PM -0700, BSD user wrote:

>
>
> On 7/14/19 12:52 AM, Denis Fondras wrote:
> > On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:
> > > Hello,
> > >
> > > My apologies for sending this email multiple times.
> > >
> > > I was so mortified by Tutanota's awful text formatting that I
> > > created a new mail account that supported IMAP so that I could load
> > > it up in Thunderbird with text only mode enabled.
> > >
> > > Once again, my apologies for my rookie mistake choosing Tutanota for
> > > use on an international mailing list such as this one. I hope you
> > > guys will give me one more chance.
> > >
> > > My (hopefully) unmangled message is below.
> > >
> >
> > You did not include which version you are running, I'll assume this is
> > 6.5.  It seems you do not have any filter, OpenBGPD denies everything
> > by default.
> >
>
> Thanks for the reply Denis. You were right, I was missing my allow
> rules. After setting "allow from any AS 64515" and "allow to any" rules,
> everything started working. I was able to get IPv6 working as well
> without a hitch.
>
> Are there any other filter rules I should be setting to secure my BGP
> deployment? I'm on a private ASN assigned to me by Vultr. This is my
> first forray into BGP land, so any advice or tips would be much
> appreciated.

Ideally you want to limit the filters to only announce what you really
need to announce to prevent leaking of prefixes because of a
missconfiguration. Also what is Vultr sending you via BGP?  Depending on
that you may be able to limit the input as well.

I guess in this simple setup it does not matter to have simple allow
filters since this bgpd instance is not connected to the default free zone
and so there is less risk of leaking or receiving leaked routes.  In
general if your BGP setup has more than one external neighbor you need to
take care of your filters to make sure that you don't leak updates from
one neighbor to the other.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

BSD user-3


On 7/14/19 11:24 PM, Claudio Jeker wrote:

> On Sun, Jul 14, 2019 at 07:28:29PM -0700, BSD user wrote:
>>
>>
>> On 7/14/19 12:52 AM, Denis Fondras wrote:
>>> On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:
>>>> Hello,
>>>>
>>>> My apologies for sending this email multiple times.
>>>>
>>>> I was so mortified by Tutanota's awful text formatting that I
>>>> created a new mail account that supported IMAP so that I could load
>>>> it up in Thunderbird with text only mode enabled.
>>>>
>>>> Once again, my apologies for my rookie mistake choosing Tutanota for
>>>> use on an international mailing list such as this one. I hope you
>>>> guys will give me one more chance.
>>>>
>>>> My (hopefully) unmangled message is below.
>>>>
>>>
>>> You did not include which version you are running, I'll assume this is
>>> 6.5.  It seems you do not have any filter, OpenBGPD denies everything
>>> by default.
>>>
>>
>> Thanks for the reply Denis. You were right, I was missing my allow
>> rules. After setting "allow from any AS 64515" and "allow to any" rules,
>> everything started working. I was able to get IPv6 working as well
>> without a hitch.
>>
>> Are there any other filter rules I should be setting to secure my BGP
>> deployment? I'm on a private ASN assigned to me by Vultr. This is my
>> first forray into BGP land, so any advice or tips would be much
>> appreciated.
>
> Ideally you want to limit the filters to only announce what you really
> need to announce to prevent leaking of prefixes because of a
> missconfiguration. Also what is Vultr sending you via BGP?  Depending on
> that you may be able to limit the input as well.
>
> I guess in this simple setup it does not matter to have simple allow
> filters since this bgpd instance is not connected to the default free zone
> and so there is less risk of leaking or receiving leaked routes.  In
> general if your BGP setup has more than one external neighbor you need to
> take care of your filters to make sure that you don't leak updates from
> one neighbor to the other.
>

Thanks for the reply Claudio!

You were right, my "allow from" rule was unnecessary, Vultr doesn't
appear to be sending me anything.

I managed to get my "allow to" rule tightened up to look like this:

allow to any prefix {xxx.xxx.xxx.141/32 2001:xxxx:xxxx:xxxx::/64}

I tried tightening the rule down further to restrict to Vultr's upstream
AS and IP addresses like so:

'allow to 169.254.169.254 AS 64515 prefix 140.82.0.141/32'

Unfortunately the rule doesn't work properly as my prefixes immediately
become unpingable after loading that rule. I'm probably missing
something obvious. Any suggestions on how to tighten down the rule further?

My final question is concerning assigning prefixes to interfaces. Is it
best practice to assign the addresses to something like 'lo1' loopback
interface, or should assigning it as an alias on an egress interface
suffice? I tried and they both seem to work.

Thanks


Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

Claudio Jeker
On Mon, Jul 15, 2019 at 11:33:45PM -0700, BSD user wrote:

>
>
> On 7/14/19 11:24 PM, Claudio Jeker wrote:
> > On Sun, Jul 14, 2019 at 07:28:29PM -0700, BSD user wrote:
> > >
> > >
> > > On 7/14/19 12:52 AM, Denis Fondras wrote:
> > > > On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:
> > > > > Hello,
> > > > >
> > > > > My apologies for sending this email multiple times.
> > > > >
> > > > > I was so mortified by Tutanota's awful text formatting that I
> > > > > created a new mail account that supported IMAP so that I could load
> > > > > it up in Thunderbird with text only mode enabled.
> > > > >
> > > > > Once again, my apologies for my rookie mistake choosing Tutanota for
> > > > > use on an international mailing list such as this one. I hope you
> > > > > guys will give me one more chance.
> > > > >
> > > > > My (hopefully) unmangled message is below.
> > > > >
> > > >
> > > > You did not include which version you are running, I'll assume this is
> > > > 6.5.  It seems you do not have any filter, OpenBGPD denies everything
> > > > by default.
> > > >
> > >
> > > Thanks for the reply Denis. You were right, I was missing my allow
> > > rules. After setting "allow from any AS 64515" and "allow to any" rules,
> > > everything started working. I was able to get IPv6 working as well
> > > without a hitch.
> > >
> > > Are there any other filter rules I should be setting to secure my BGP
> > > deployment? I'm on a private ASN assigned to me by Vultr. This is my
> > > first forray into BGP land, so any advice or tips would be much
> > > appreciated.
> >
> > Ideally you want to limit the filters to only announce what you really
> > need to announce to prevent leaking of prefixes because of a
> > missconfiguration. Also what is Vultr sending you via BGP?  Depending on
> > that you may be able to limit the input as well.
> >
> > I guess in this simple setup it does not matter to have simple allow
> > filters since this bgpd instance is not connected to the default free zone
> > and so there is less risk of leaking or receiving leaked routes.  In
> > general if your BGP setup has more than one external neighbor you need to
> > take care of your filters to make sure that you don't leak updates from
> > one neighbor to the other.
> >
>
> Thanks for the reply Claudio!
>
> You were right, my "allow from" rule was unnecessary, Vultr doesn't
> appear to be sending me anything.
>
> I managed to get my "allow to" rule tightened up to look like this:
>
> allow to any prefix {xxx.xxx.xxx.141/32 2001:xxxx:xxxx:xxxx::/64}

This rule is perfectly fine.
 
> I tried tightening the rule down further to restrict to Vultr's upstream
> AS and IP addresses like so:
>
> 'allow to 169.254.169.254 AS 64515 prefix 140.82.0.141/32'

The problem here is that AS 64515 wants to match any part of the ASPATH
for AS 64515.  Which is not there and so this rule never matches.

You can write this rule either as:
'allow to 169.254.169.254 prefix xxx.xxx.xxx.141/32'
or
'allow to AS 64515 prefix xxx.xxx.xxx.141/32'

> Unfortunately the rule doesn't work properly as my prefixes immediately
> become unpingable after loading that rule. I'm probably missing
> something obvious. Any suggestions on how to tighten down the rule further?

Normally it is enought to limit the rule to the prefixes you want to
announce. So the first rule is just fine.
 
> My final question is concerning assigning prefixes to interfaces. Is it
> best practice to assign the addresses to something like 'lo1' loopback
> interface, or should assigning it as an alias on an egress interface
> suffice? I tried and they both seem to work.

That is a bit of a style question. In some cases using lo1 has benefits
(the IP will always be UP which can matter when you have multiple
interfaces). Using it on the only interface out would have the benefit
that you could use a default route that uses the public IP as source IP
for outgoing packets by default. (using 'route add default gateway
-ifa xxx.xxx.xxx.141')

In your case I guess neither matters so you can decide what you like
better.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: Moving from Bird to OpenBGPD

BSD user-3


> Sent: Monday, July 15, 2019 at 11:52 PM
> From: "Claudio Jeker" <[hidden email]>
> To: "BSD user" <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Moving from Bird to OpenBGPD
>
> On Mon, Jul 15, 2019 at 11:33:45PM -0700, BSD user wrote:
> >
> >
> > On 7/14/19 11:24 PM, Claudio Jeker wrote:
> > > On Sun, Jul 14, 2019 at 07:28:29PM -0700, BSD user wrote:
> > > >
> > > >
> > > > On 7/14/19 12:52 AM, Denis Fondras wrote:
> > > > > On Sat, Jul 13, 2019 at 09:44:28PM -0700, BSD user wrote:
> > > > > > Hello,
> > > > > >
> > > > > > My apologies for sending this email multiple times.
> > > > > >
> > > > > > I was so mortified by Tutanota's awful text formatting that I
> > > > > > created a new mail account that supported IMAP so that I could load
> > > > > > it up in Thunderbird with text only mode enabled.
> > > > > >
> > > > > > Once again, my apologies for my rookie mistake choosing Tutanota for
> > > > > > use on an international mailing list such as this one. I hope you
> > > > > > guys will give me one more chance.
> > > > > >
> > > > > > My (hopefully) unmangled message is below.
> > > > > >
> > > > >
> > > > > You did not include which version you are running, I'll assume this is
> > > > > 6.5.  It seems you do not have any filter, OpenBGPD denies everything
> > > > > by default.
> > > > >
> > > >
> > > > Thanks for the reply Denis. You were right, I was missing my allow
> > > > rules. After setting "allow from any AS 64515" and "allow to any" rules,
> > > > everything started working. I was able to get IPv6 working as well
> > > > without a hitch.
> > > >
> > > > Are there any other filter rules I should be setting to secure my BGP
> > > > deployment? I'm on a private ASN assigned to me by Vultr. This is my
> > > > first forray into BGP land, so any advice or tips would be much
> > > > appreciated.
> > >
> > > Ideally you want to limit the filters to only announce what you really
> > > need to announce to prevent leaking of prefixes because of a
> > > missconfiguration. Also what is Vultr sending you via BGP?  Depending on
> > > that you may be able to limit the input as well.
> > >
> > > I guess in this simple setup it does not matter to have simple allow
> > > filters since this bgpd instance is not connected to the default free zone
> > > and so there is less risk of leaking or receiving leaked routes.  In
> > > general if your BGP setup has more than one external neighbor you need to
> > > take care of your filters to make sure that you don't leak updates from
> > > one neighbor to the other.
> > >
> >
> > Thanks for the reply Claudio!
> >
> > You were right, my "allow from" rule was unnecessary, Vultr doesn't
> > appear to be sending me anything.
> >
> > I managed to get my "allow to" rule tightened up to look like this:
> >
> > allow to any prefix {xxx.xxx.xxx.141/32 2001:xxxx:xxxx:xxxx::/64}
>
> This rule is perfectly fine.
>
> > I tried tightening the rule down further to restrict to Vultr's upstream
> > AS and IP addresses like so:
> >
> > 'allow to 169.254.169.254 AS 64515 prefix 140.82.0.141/32'
>
> The problem here is that AS 64515 wants to match any part of the ASPATH
> for AS 64515.  Which is not there and so this rule never matches.
>
> You can write this rule either as:
> 'allow to 169.254.169.254 prefix xxx.xxx.xxx.141/32'
> or
> 'allow to AS 64515 prefix xxx.xxx.xxx.141/32'
>
> > Unfortunately the rule doesn't work properly as my prefixes immediately
> > become unpingable after loading that rule. I'm probably missing
> > something obvious. Any suggestions on how to tighten down the rule further?
>
> Normally it is enought to limit the rule to the prefixes you want to
> announce. So the first rule is just fine.
>
> > My final question is concerning assigning prefixes to interfaces. Is it
> > best practice to assign the addresses to something like 'lo1' loopback
> > interface, or should assigning it as an alias on an egress interface
> > suffice? I tried and they both seem to work.
>
> That is a bit of a style question. In some cases using lo1 has benefits
> (the IP will always be UP which can matter when you have multiple
> interfaces). Using it on the only interface out would have the benefit
> that you could use a default route that uses the public IP as source IP
> for outgoing packets by default. (using 'route add default gateway
> -ifa xxx.xxx.xxx.141')
>
> In your case I guess neither matters so you can decide what you like
> better.
>
> --
> :wq Claudio
>

Hi Claudio,

Thanks so much for clarifying things for me, I really appreciate it. I now feel I have a much better understanding of OpenBGPD (and the BGP protocol in general).

I was able to get my filter rule down to one line covering both IPv4 and IPv6:

allow to AS 64515 prefix {xxx.xxx.xxx.141/32 2001:xxxx:xxxx:xxxx::/64}

Thanks for the advice regarding filtering rules by ip address and AS, as well as prefix interface assignment. I ended up assigning the public ip as an alias on my egress interface so I could NAT outgoing traffic from my httpd server cluster using that address.

I must say, I love the 'depend on' feature. I have failover between redundant machines using carp working perfectly.

Cheers

PS

Hopefully this email arrives to you unmangled. My trial period with mail.com ended and I can no longer use IMAP/Thunderbird as it's apparently a "premium feature". I hope the mail.com web clients text mode works properly.