Re: Time to add 2002::/16 to bogon filters?

[joel jaeggli]

I personally would love to see social pressure applied removing this
from the internet.

certain prominent google search results. e.g.
https://getipv6.info/display/IPv6/Linux+or+BSD+6to4+Relays probably also
could use some curation given the appropriateness of reling on a anycast
translator for your transition at this point.

On 6/18/18 2:08 PM, Job Snijders wrote:
> Dear all,
>
> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
>
> It is kind of strange that in the default-free zone (where we don’t
> announce defaults to each other) - we will propagate what is effectively an
> IPv4 default-route, in the IPv6 DFZ.
>
> IETF has politely abandoned the prefix:
> https://tools.ietf.org/html/rfc7526
>
> Wes George highlighted operational problems from accepting 2002::/16 on the
> data-plane slide 6:
> http://iepg.org/2018-03-18-ietf101/wes.pdf
>
> Is there still really any legit reason left to accept, or propagate,
> 2002::/16 on EBGP sessions in the DFZ?
>
> Kind regards,
>
> Job
>

Re: Time to add 2002::/16 to bogon filters?

[Harald Koch]

20 years from now when the IETF decides to reclaim / repurpose that prefix,
y'all are going to have to run around removing it from your filters again...

-- 
Harald

Re: Time to add 2002::/16 to bogon filters?

[j k]

This week I began mapping IPv6 SPAM headers "Received:" and "X-Received:"
and have discovered over 50% are from:

10.0.0.0 – 10.255.255.255
2002:0a00:: - 2002:aff::::::

172.16.0.0 – 172.31.255.255
2002:ac10:: - 2002:ac10::::::

192.168.0.0 – 192.168.255.255
2002:c0A8:: - 2002:c0A8::::::

Can anyone else confirm my findings?

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8

On Mon, Jun 18, 2018 at 9:18 PM, Jared Mauch  wrote:

>
>
> > On Jun 18, 2018, at 8:31 PM, Mark Andrews  wrote:
> >
> > If you are using 2002::/16 you know are relying on third parties.  Not
> that it is much
> > different to any other address where you are relying on third parties.
> >
> > If one is going to filter 2002::/16 from BGP then install your own
> gateway to preserve
> > the functionality.
>
> It does not appear the functionality is working at present, which I think
> is the more critical point.  Taking a quick sampling of where I see the
> packets going from two different networks, it doesn’t seem to be going
> where it’s expected, nor is it working as expected.  These appear to be at
> best routing leaks similar to leaking rfc6761 space that should be under
> your local control.  They could also be seen as a privacy issue by taking
> packets destined to 2002::/16 somewhere unexpected and off-continent.
>
> I would expect even in the cases where it does work, it would be subject
> to the same challenges faced by people using VPN services (being blocked
> from your kids favorite streaming services) and much poorer performance
> than native IPv4.
>
> There is also the problem noted by Wes George with 6to4 being used in DNS
> amplification, which may be interesting..
>
> http://iepg.org/2018-03-18-ietf101/wes.pdf
>
> I don’t believe most providers are intending to offer 6to4 as a global
> service.  Even the large providers (eg: Comcast) seem to have disabled it
> ~4+ years ago.  While I know there’s people on the internet that like to
> hang on to legacy things, this is one that should end.  The networks and
> devices today no longer require this sort of transition technology, and the
> networks where it’s left won’t want it as it will be used for various bad
> things(tm).
>
> - Jared

Re: Time to add 2002::/16 to bogon filters?

[Jared Mauch]

> On Jun 18, 2018, at 8:31 PM, Mark Andrews  wrote:
> 
> If you are using 2002::/16 you know are relying on third parties.  Not that 
> it is much
> different to any other address where you are relying on third parties.
> 
> If one is going to filter 2002::/16 from BGP then install your own gateway to 
> preserve
> the functionality.

It does not appear the functionality is working at present, which I think is 
the more critical point.  Taking a quick sampling of where I see the packets 
going from two different networks, it doesn’t seem to be going where it’s 
expected, nor is it working as expected.  These appear to be at best routing 
leaks similar to leaking rfc6761 space that should be under your local control. 
 They could also be seen as a privacy issue by taking packets destined to 
2002::/16 somewhere unexpected and off-continent.

I would expect even in the cases where it does work, it would be subject to the 
same challenges faced by people using VPN services (being blocked from your 
kids favorite streaming services) and much poorer performance than native IPv4.

There is also the problem noted by Wes George with 6to4 being used in DNS 
amplification, which may be interesting..

http://iepg.org/2018-03-18-ietf101/wes.pdf

I don’t believe most providers are intending to offer 6to4 as a global service. 
 Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. 
 While I know there’s people on the internet that like to hang on to legacy 
things, this is one that should end.  The networks and devices today no longer 
require this sort of transition technology, and the networks where it’s left 
won’t want it as it will be used for various bad things(tm).

- Jared

Re: Time to add 2002::/16 to bogon filters?

[Ca By]

On Mon, Jun 18, 2018 at 5:31 PM Mark Andrews  wrote:

> If you are using 2002::/16 you know are relying on third parties.


I highlly doubt most people using 6to4 know they are using it, let alone
the arbitrary nature of its routing.

Not that it is much
> different to any other address where you are relying on third parties.
>
> If one is going to filter 2002::/16 from BGP then install your own gateway
> to preserve
> the functionality.
>
> > On 19 Jun 2018, at 10:23 am, Ca By  wrote:
> >
> >
> >
> > On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews  wrote:
> > If a ASN is announcing 2002::/16 then they are are happy to get the
> traffic.  It
> > they don’t want it all they have to do is withdraw the prefix.  It is
> not up to
> > the rest of us to second guess their decision to keep providing support.
> >
> > That sounds like an interesting attack scenario where a malicious actor
> can insert themselves in a path, via bgp, announcing 6to4 space
> >
> >
> > If you filter 2002::/16 then you are performing a denial-of-service
> attack on
> > the few sites that are still using it DELIBERATELY.
> >
> > None of the problems required removing it from BGP.  There were end
> sites that
> > had firewalls that blocked 6to4 responses and the odd site that ran a
> gateway
> > and failed to properly manage it.  The rest could have been dealt with by
> > configuring more gateways.  If every dual stacked ASN had run their own
> gateways
> > there wouldn’t have been a scaling issue.  i.e. take the 2002::/16
> traffic and
> > dump it onto IPv4 as soon as possible and take the encapsulated traffic
> for the
> > rest of IPv6 and de-encapsulate it as soon as possible.
> >
> > Mark
> > > On 19 Jun 2018, at 8:56 am, McBride, Mack 
> wrote:
> > >
> > > This should have been filtered before.
> > > Lots of people improperly implemented this so it caused issues.
> > >
> > > Mack
> > >
> > > -Original Message-
> > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John
> Kristoff
> > > Sent: Monday, June 18, 2018 3:48 PM
> > > To: Job Snijders 
> > > Cc: NANOG [nanog@nanog.org] 
> > > Subject: Re: Time to add 2002::/16 to bogon filters?
> > >
> > > On Mon, 18 Jun 2018 21:08:05 +
> > > Job Snijders  wrote:
> > >
> > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
> > >
> > > Hi Job,
> > >
> > > I've been asking people about this recently.  I don't particularly
> like having misdirected traffic or badly configured hosts sending junk to
> those who happen to be announcing addresses from this prefix.  I'm planning
> on adding this to a bogon filter here.
> > >
> > > John
> > > E-MAIL CONFIDENTIALITY NOTICE:
> > > The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) and may contain confidential and/or legally
> privileged information. If you are not the intended recipient of this
> message or if this message has been addressed to you in error, please
> immediately alert the sender by reply e-mail and then delete this message
> and any attachments. If you are not the intended recipient, you are notified
> that any use, dissemination, distribution, cop
> ying,
> or storage of this message or any attachment is strictly prohibited.
> > >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
>

Re: Time to add 2002::/16 to bogon filters?

[Mark Andrews]

If you are using 2002::/16 you know are relying on third parties.  Not that it 
is much
different to any other address where you are relying on third parties.

If one is going to filter 2002::/16 from BGP then install your own gateway to 
preserve
the functionality.

> On 19 Jun 2018, at 10:23 am, Ca By  wrote:
> 
> 
> 
> On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews  wrote:
> If a ASN is announcing 2002::/16 then they are are happy to get the traffic.  
> It
> they don’t want it all they have to do is withdraw the prefix.  It is not up 
> to
> the rest of us to second guess their decision to keep providing support.
> 
> That sounds like an interesting attack scenario where a malicious actor can 
> insert themselves in a path, via bgp, announcing 6to4 space 
> 
> 
> If you filter 2002::/16 then you are performing a denial-of-service attack on
> the few sites that are still using it DELIBERATELY.
> 
> None of the problems required removing it from BGP.  There were end sites that
> had firewalls that blocked 6to4 responses and the odd site that ran a gateway
> and failed to properly manage it.  The rest could have been dealt with by
> configuring more gateways.  If every dual stacked ASN had run their own 
> gateways
> there wouldn’t have been a scaling issue.  i.e. take the 2002::/16 traffic and
> dump it onto IPv4 as soon as possible and take the encapsulated traffic for 
> the
> rest of IPv6 and de-encapsulate it as soon as possible.
> 
> Mark
> > On 19 Jun 2018, at 8:56 am, McBride, Mack  
> > wrote:
> > 
> > This should have been filtered before.
> > Lots of people improperly implemented this so it caused issues.
> > 
> > Mack
> > 
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff
> > Sent: Monday, June 18, 2018 3:48 PM
> > To: Job Snijders 
> > Cc: NANOG [nanog@nanog.org] 
> > Subject: Re: Time to add 2002::/16 to bogon filters?
> > 
> > On Mon, 18 Jun 2018 21:08:05 +
> > Job Snijders  wrote:
> > 
> >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
> > 
> > Hi Job,
> > 
> > I've been asking people about this recently.  I don't particularly like 
> > having misdirected traffic or badly configured hosts sending junk to those 
> > who happen to be announcing addresses from this prefix.  I'm planning on 
> > adding this to a bogon filter here.
> > 
> > John
> > E-MAIL CONFIDENTIALITY NOTICE: 
> > The contents of this e-mail message and any attachments are intended solely 
> > for the addressee(s) and may contain confidential and/or legally privileged 
> > information. If you are not the intended recipient of this message or if 
> > this message has been addressed to you in error, please immediately alert 
> > the sender by reply e-mail and then delete this message and any 
> > attachments. If you are not the intended recipient, you are notified that 
> > any use, dissemination, distribution, copying, or storage of this message 
> > or any attachment is strictly prohibited.
> > 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Time to add 2002::/16 to bogon filters?

[Ca By]

On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews  wrote:

> If a ASN is announcing 2002::/16 then they are are happy to get the
> traffic.  It
> they don’t want it all they have to do is withdraw the prefix.  It is not
> up to
> the rest of us to second guess their decision to keep providing support.
>

That sounds like an interesting attack scenario where a malicious actor can
insert themselves in a path, via bgp, announcing 6to4 space


> If you filter 2002::/16 then you are performing a denial-of-service attack
> on
> the few sites that are still using it DELIBERATELY.
>
> None of the problems required removing it from BGP.  There were end sites
> that
> had firewalls that blocked 6to4 responses and the odd site that ran a
> gateway
> and failed to properly manage it.  The rest could have been dealt with by
> configuring more gateways.  If every dual stacked ASN had run their own
> gateways
> there wouldn’t have been a scaling issue.  i.e. take the 2002::/16 traffic
> and
> dump it onto IPv4 as soon as possible and take the encapsulated traffic
> for the
> rest of IPv6 and de-encapsulate it as soon as possible.
>
> Mark
> > On 19 Jun 2018, at 8:56 am, McBride, Mack 
> wrote:
> >
> > This should have been filtered before.
> > Lots of people improperly implemented this so it caused issues.
> >
> > Mack
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff
> > Sent: Monday, June 18, 2018 3:48 PM
> > To: Job Snijders 
> > Cc: NANOG [nanog@nanog.org] 
> > Subject: Re: Time to add 2002::/16 to bogon filters?
> >
> > On Mon, 18 Jun 2018 21:08:05 +
> > Job Snijders  wrote:
> >
> >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
> >
> > Hi Job,
> >
> > I've been asking people about this recently.  I don't particularly like
> having misdirected traffic or badly configured hosts sending junk to those
> who happen to be announcing addresses from this prefix.  I'm planning on
> adding this to a bogon filter here.
> >
> > John
> > E-MAIL CONFIDENTIALITY NOTICE:
> > The contents of this e-mail message and any attachments are intended
> solely for the addressee(s) and may contain confidential and/or legally
> privileged information. If you are not the intended recipient of this
> message or if this message has been addressed to you in error, please
> immediately alert the sender by reply e-mail and then delete this message
> and any attachments. If you are not the intended recipient, you are
> notified that any use, dissemination, distribution, copying, or storage of
> this message or any attachment is strictly prohibited.
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
>

Re: Time to add 2002::/16 to bogon filters?

[Mark Andrews]

If a ASN is announcing 2002::/16 then they are are happy to get the traffic.  It
they don’t want it all they have to do is withdraw the prefix.  It is not up to
the rest of us to second guess their decision to keep providing support.

If you filter 2002::/16 then you are performing a denial-of-service attack on
the few sites that are still using it DELIBERATELY.

None of the problems required removing it from BGP.  There were end sites that
had firewalls that blocked 6to4 responses and the odd site that ran a gateway
and failed to properly manage it.  The rest could have been dealt with by
configuring more gateways.  If every dual stacked ASN had run their own gateways
there wouldn’t have been a scaling issue.  i.e. take the 2002::/16 traffic and
dump it onto IPv4 as soon as possible and take the encapsulated traffic for the
rest of IPv6 and de-encapsulate it as soon as possible.

Mark
> On 19 Jun 2018, at 8:56 am, McBride, Mack  wrote:
> 
> This should have been filtered before.
> Lots of people improperly implemented this so it caused issues.
> 
> Mack
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff
> Sent: Monday, June 18, 2018 3:48 PM
> To: Job Snijders 
> Cc: NANOG [nanog@nanog.org] 
> Subject: Re: Time to add 2002::/16 to bogon filters?
> 
> On Mon, 18 Jun 2018 21:08:05 +
> Job Snijders  wrote:
> 
>> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
> 
> Hi Job,
> 
> I've been asking people about this recently.  I don't particularly like 
> having misdirected traffic or badly configured hosts sending junk to those 
> who happen to be announcing addresses from this prefix.  I'm planning on 
> adding this to a bogon filter here.
> 
> John
> E-MAIL CONFIDENTIALITY NOTICE: 
> The contents of this e-mail message and any attachments are intended solely 
> for the addressee(s) and may contain confidential and/or legally privileged 
> information. If you are not the intended recipient of this message or if this 
> message has been addressed to you in error, please immediately alert the 
> sender by reply e-mail and then delete this message and any attachments. If 
> you are not the intended recipient, you are notified that any use, 
> dissemination, distribution, copying, or storage of this message or any 
> attachment is strictly prohibited.
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: Time to add 2002::/16 to bogon filters?

[Jared Mauch]

> On Jun 18, 2018, at 5:08 PM, Job Snijders  wrote:
> 
> Dear all,
> 
> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
> 
> It is kind of strange that in the default-free zone (where we don’t
> announce defaults to each other) - we will propagate what is effectively an
> IPv4 default-route, in the IPv6 DFZ.
> 
> IETF has politely abandoned the prefix:
> https://tools.ietf.org/html/rfc7526


I don’t believe there is a reason that folks should accept this prefix from a 
transit/peer.  If they have need for 6to4 within their network, they should 
operate their own local 6to4 relays.

It seems native IPv6 is fairly widely available:

https://www.google.com/intl/en/ipv6/statistics.html

And there is almost zero 6to4 activity in those stats as well.  Since it’s a 
known path for abuse as well, I would expect networks to not carry these IPv6 
routes and filter them.

- Jared

RE: Time to add 2002::/16 to bogon filters?

[McBride, Mack]

This should have been filtered before.
Lots of people improperly implemented this so it caused issues.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff
Sent: Monday, June 18, 2018 3:48 PM
To: Job Snijders 
Cc: NANOG [nanog@nanog.org] 
Subject: Re: Time to add 2002::/16 to bogon filters?

On Mon, 18 Jun 2018 21:08:05 +
Job Snijders  wrote:

> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?

Hi Job,

I've been asking people about this recently.  I don't particularly like having 
misdirected traffic or badly configured hosts sending junk to those who happen 
to be announcing addresses from this prefix.  I'm planning on adding this to a 
bogon filter here.

John
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: Time to add 2002::/16 to bogon filters?

[John Kristoff]

On Mon, 18 Jun 2018 21:08:05 +
Job Snijders  wrote:

> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?

Hi Job,

I've been asking people about this recently.  I don't particularly like
having misdirected traffic or badly configured hosts sending junk to
those who happen to be announcing addresses from this prefix.  I'm
planning on adding this to a bogon filter here.

John

Time to add 2002::/16 to bogon filters?

[Job Snijders]

Dear all,

TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?

It is kind of strange that in the default-free zone (where we don’t
announce defaults to each other) - we will propagate what is effectively an
IPv4 default-route, in the IPv6 DFZ.

IETF has politely abandoned the prefix:
https://tools.ietf.org/html/rfc7526

Wes George highlighted operational problems from accepting 2002::/16 on the
data-plane slide 6:
http://iepg.org/2018-03-18-ietf101/wes.pdf

Is there still really any legit reason left to accept, or propagate,
2002::/16 on EBGP sessions in the DFZ?

Kind regards,

Job

Re: BGP in a containers

[Doug Clements]

These days I think the idea is to use unnumbered or dynamic neighbors so
most of the configuration complexity goes away:

https://docs.cumulusnetworks.com/display/DOCS/Border+Gateway+Protocol+-+BGP#BorderGatewayProtocol-BGP-ConfiguringBGPUnnumberedInterfaces

In this case, your container would peer directly with the switch.

--Doug


On Mon, Jun 18, 2018 at 2:13 PM, Jeff Walter  wrote:

> Years back I ran ExaBGP inside a Docker container (when it wasn't
> "production ready") to anycast a contained service both within a datacenter
> and across them. To make routing work correctly I had to also run another
> BGP daemon on the Docker host machine; I can't remember if I used bird for
> this, but it seems like what I'd use since I didn't need programmatic
> control of prefixes.
>
> Would I do it that way today? Not a chance. How would I do it? That would
> really depend on two things: what I'm trying to accomplish with BGP and
> what the service is. If you just want portability of a service (not
> redundancy/balancing via anycast) is BGP really the best option? I'd make a
> strong case for OSPF due to it needing far less config. The same need for a
> routing instance on the Docker host would apply, but you wouldn't need to
> manage configuration for neighbors as containers come up and go down (since
> the IP will likely change). Sure, you could just add neighbor config for
> every IP Docker might use, however-- ouch.
>
> Jeff Walter
>
> On Mon, Jun 18, 2018 at 8:45 AM, Hugo Slabbert  wrote:
>
> >
> > On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess  wrote:
> >
> >
> >> Running the BGP application in a container on a shared storage system
> >> managed by
> >> a host cluster would also make it easier to start the service up on a
> >> different host when
> >> the first host fails or requires maintenance.
> >>
> >> On the other hand, running directly on a host,  suggests that
> >> individual hosts need
> >> to be backed up again,   and  some sort of manual restore of  local
> >> files from the lost host
> >> will be required to copy the non-containerized application to a new
> host.
> >>
> >
> > Even if the BGP speaker is running right on the host, the shared storage
> > or backups thing doesn't click for me.  What about your BGP speaker will
> > need persistent storage?  At least in our environment, everything unique
> > about the BGP speaker is config injected at startup or can be derived at
> > startup.  This might be based on differences in how we're using them (BGP
> > daemon per container host in our case, rather than "I need X number of
> BGP
> > speakers; schedule them somewhere"), I guess.
> >
> >
> > --
> > Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> > pgp key: B178313E   | also on Signal
> >
>

Re: BGP in a containers

[Jeff Walter]

Years back I ran ExaBGP inside a Docker container (when it wasn't
"production ready") to anycast a contained service both within a datacenter
and across them. To make routing work correctly I had to also run another
BGP daemon on the Docker host machine; I can't remember if I used bird for
this, but it seems like what I'd use since I didn't need programmatic
control of prefixes.

Would I do it that way today? Not a chance. How would I do it? That would
really depend on two things: what I'm trying to accomplish with BGP and
what the service is. If you just want portability of a service (not
redundancy/balancing via anycast) is BGP really the best option? I'd make a
strong case for OSPF due to it needing far less config. The same need for a
routing instance on the Docker host would apply, but you wouldn't need to
manage configuration for neighbors as containers come up and go down (since
the IP will likely change). Sure, you could just add neighbor config for
every IP Docker might use, however-- ouch.

Jeff Walter

On Mon, Jun 18, 2018 at 8:45 AM, Hugo Slabbert  wrote:

>
> On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess  wrote:
>
>
>> Running the BGP application in a container on a shared storage system
>> managed by
>> a host cluster would also make it easier to start the service up on a
>> different host when
>> the first host fails or requires maintenance.
>>
>> On the other hand, running directly on a host,  suggests that
>> individual hosts need
>> to be backed up again,   and  some sort of manual restore of  local
>> files from the lost host
>> will be required to copy the non-containerized application to a new host.
>>
>
> Even if the BGP speaker is running right on the host, the shared storage
> or backups thing doesn't click for me.  What about your BGP speaker will
> need persistent storage?  At least in our environment, everything unique
> about the BGP speaker is config injected at startup or can be derived at
> startup.  This might be based on differences in how we're using them (BGP
> daemon per container host in our case, rather than "I need X number of BGP
> speakers; schedule them somewhere"), I guess.
>
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
>

Re: fd.io vs cumulus vs snabb vs OVS vs OpenNSL

[Luke Gorrie]

On Thu, 14 Jun 2018 at 22:17, Marcus Leske  wrote:

> Any thought leader on the list to shed some light to what is happening
> in the world of open networking ? OVS vs OpenNSL vs Cumulus vs fd.io
> vs Snabb vs a lot of stuff :)
>
> Where is this going ?


I work on Snabb and to me our most interesting application area is "the
long tail." You have a problem that you can describe on a whiteboard, but
you can't get an off-the-shelf solution for, and you want to solve it by
sitting down and writing an ordinary program in an ordinary high level
programming language. So that is what you do.

It's not necessarily *easy* but it is straight forwardly similar to the way
people write other programs in languages like
perl/python/ruby/javascript/etc.

Re: BGP in a containers

[Hugo Slabbert]

On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess  wrote:



Running the BGP application in a container on a shared storage system managed by
a host cluster would also make it easier to start the service up on a
different host when
the first host fails or requires maintenance.

On the other hand, running directly on a host,  suggests that
individual hosts need
to be backed up again,   and  some sort of manual restore of  local
files from the lost host
will be required to copy the non-containerized application to a new host.


Even if the BGP speaker is running right on the host, the shared storage or 
backups thing doesn't click for me.  What about your BGP speaker will need 
persistent storage?  At least in our environment, everything unique about 
the BGP speaker is config injected at startup or can be derived at startup.  
This might be based on differences in how we're using them (BGP daemon per 
container host in our case, rather than "I need X number of BGP speakers; 
schedule them somewhere"), I guess.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Google Peering/Edge Network Contact?

[Mark Tinka]

On 15/Jun/18 00:02, Zach Puls wrote:

> Does anyone have a contact for Google Peering / PNI?
>
> We have a caching appliance whose BGP session has been flapping nonstop for
> the past month or so. We've had a ticket open with Google since it started,
> but they haven't really made any headway, or provided much of a response.

IIRC, if you're talking about their GGC (or the evolution of it),
flapping BGP sessions is normal. BGP, in this case, is used for mapping
and not routing.

Google only say to complain if the session is down for more than an hour.

Of course, it's possible you have a totally different issue.

Mark.