Re: BGP route processing speed

[Sebastian Spies]

Hey Sriram,

hope, you are doing fine.

my BSc thesis from 2010 might be relevant to what you are looking for.

https://drive.google.com/file/d/0B5kLBHCcFJjFZk5RTUtwbUstbm8/view?usp=sharing

Best,
Sebastian

Sriram, Kotikalapudi (Fed) schrieb:

I am interested in measurements related to BGP route processing speed

(i.e. routing engine capacity in terms of routes or updates processed per 
second).

Folks from AMS-IX did an interesting study in 2012

in their Route Server / IXP environment.

https://ams-ix.net/downloads/ams-ix-route-server-implementations-performance.pdf



Are there other measurement studies available

on this topic, especially in ISP/PE router scenarios,

including BGP policy processing, best path selection, route filtering, etc.?

Will appreciate much if you can share some pointers.



Sriram

Re: Softlayer / Blocking Cuba IP's ?

[Sebastian Spies]

Yep, see here

https://drive.google.com/file/d/0B5kLBHCcFJjFREtoMWtzMXljWXc/view?usp=sharing

No prefix responds.

Best,
Sebastian


Am 19.02.2016 um 21:27 schrieb Faisal Imtiaz:
> Hello All, 
>
> This is a shout out to Softlayer Network Admin / Policy folks...
>
> We just went thru a painful process to find out that Softlayer has recently 
> decided to block Cuba IP Address Space(on their cloud services).
>
> I am not a politician, nor any kind of a policy expert, However I have a  
> questions for the SoftLayer folks...
>
> On What basis, legal requirement, logic,  have they taken on the 
> responsibility to implement such a Block ? 
>
> Considering the fact that such a block was just put in place about a week ago 
> ? 
> Last time I checked, blocking any part of the world is not part of any legal 
> requirements on any Global Service Provider ? other than a 'company policy' ?
>
> Also, the Last time I checked the US Cuba relations are getting better not 
> worse!
>
> Would love to know what was the reasoning behind such action !
>
> Thank you. 
>
> Faisal Imtiaz
> Snappy Internet & Telecom

Re: Internap route optimization

[Sebastian Spies]

Hey Mike,

do you know route optimizers that actually do optimize inbound traffic?
We, at datapath.io, are currently working on this and could not find
another one that does it.

Best,
Sebastian

Am 05.11.2015 um 14:21 schrieb Mike Hammett:
> Keep in mind that most do not optimize inbound traffic, only outbound. 
>
>
>
>
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
> - Original Message -
>
> From: "Paras"  
> To: nanog@nanog.org 
> Sent: Thursday, November 5, 2015 2:03:41 AM 
> Subject: Internap route optimization 
>
> Does anyone know or have any experience with Internap's route 
> optimization? Is it any good? 
>
> I've heard of competing solutions as well, such as the one provided by 
> Noction. 
>
> Thanks for your input, 
> Paras 
>
>

[no subject]

[Sebastian Spies via NANOG]

This post was from a subscriber whose From: address domain has a DMARC
policy of reject or quarantine. The NANOG mailing list has
automatically wrapped this message to prevent other subscribers mail
systems from rejecting it.---BeginMessage---
Hey there,

considering the state of this discussion, BIRD seems to be the only
scalable solution to be used as a route server at IXPs. I have built a
large code base around BGP for the hoofprints project [1] and BRITE [2]
and would enjoy building another state-of-the-art open-source
route-server implementation for IXPs. Would you be so kind to send me
your feedback on this idea? Do you think, it makes sense to pursue such
a project or is it not relevant enough for you?

Best regards,
Sebastian

1: https://github.com/sspies8684/hoofprints/
2: https://brite.antd.nist.gov/statics/about

Am 25.04.2015 um 22:06 schrieb Goran Slavić:
 Andy,
   
   Believe me when I say: I would never have the idea to think about
 attempting to try to test my ability to generate configurations for this 2
 route servers/ 2 different programs that run them solution without the IXP
 Manager :-)

   I am familiar with the work INEX has been doing with IXP Manager and
 have for some time attempted to find time from regular SOX operation to
 implement it in our IX. This migration gives me the excellent opportunity
 and arguments to finally allocate time, resources and manpower for
 installation and implementation of IXP Manager as the route server
 configuration generator at SOX.
   
   Regards
   G.Slavic


 -Original Message-
 From: Andy Davidson [mailto:a...@nosignal.org] 
 Sent: Saturday, 25 April 2015 21:34
 To: Goran Slavić
 Cc: nanog@nanog.org
 Subject: Re: Euro-IX quagga stable download and implementation


 On 25 Apr 2015, at 15:16, Goran Slavić gsla...@sox.rs wrote:

  Considering what I have learned in your posts (and on other places
 that I have informed myself) I will definitely suggest to SOX management
 to
 go the way similar to what LINX did (1 Bird + 1 Quagga as route servers)
 for
 the simple reason that 2 different solution provides more security in
 context of new program update-new bugs problems and incidents and
 prevents other potential problems.
 Goran - glad to have helped.

 One last piece of advice which might be useful - to help to guarantee
 consistency of performance between the two route-servers, you should
 consider a configuration generator so that your route-server configs are in
 sync.  The best way to implement this at your exchange is to use IXP
 Manager, maintained by the awesome folks at the Irish exchange point, INEX.
 https://github.com/inex/IXP-Manager

 IXP Manager will get you lots of other features as well as good route-server
 hygiene.

 There's also a historic perl-script that does this on my personal github.
 Both of these solutions allow you to filter route-server participants based
 on IRR data, which has proved to be a life-saver at all of the exchanges I
 help to operate.  Having my horrible historic thing is maybe better than no
 thing at all, but I deliberately won't link to it as you should really use
 IXP Manager. :-)

 Andy=


---End Message---

yarr - Yet Another Route Server Implementation [WAS: Euro-IX quagga stable download and implementation]

[Sebastian Spies]

sorry, for the double post. dmarc fuckup...

Hey there,

considering the state of this discussion, BIRD seems to be the only
scalable solution to be used as a route server at IXPs. I have built a
large code base around BGP for the hoofprints project [1] and BRITE [2]
and would enjoy building another state-of-the-art open-source
route-server implementation for IXPs. Would you be so kind to send me
your feedback on this idea? Do you think, it makes sense to pursue such
a project or is it not relevant enough for you?

Best regards,
Sebastian

1: https://github.com/sspies8684/hoofprints/
2: https://brite.antd.nist.gov/statics/about

Am 25.04.2015 um 22:06 schrieb Goran Slaviæ:
 Andy,
   
   Believe me when I say: I would never have the idea to think about
 attempting to try to test my ability to generate configurations for this 2
 route servers/ 2 different programs that run them solution without the IXP
 Manager :-)

   I am familiar with the work INEX has been doing with IXP Manager and
 have for some time attempted to find time from regular SOX operation to
 implement it in our IX. This migration gives me the excellent opportunity
 and arguments to finally allocate time, resources and manpower for
 installation and implementation of IXP Manager as the route server
 configuration generator at SOX.
   
   Regards
   G.Slavic


 -Original Message-
 From: Andy Davidson [mailto:a...@nosignal.org] 
 Sent: Saturday, 25 April 2015 21:34
 To: Goran Slaviæ
 Cc: nanog@nanog.org
 Subject: Re: Euro-IX quagga stable download and implementation


 On 25 Apr 2015, at 15:16, Goran Slaviæ gsla...@sox.rs wrote:

  Considering what I have learned in your posts (and on other places
 that I have informed myself) I will definitely suggest to SOX management
 to
 go the way similar to what LINX did (1 Bird + 1 Quagga as route servers)
 for
 the simple reason that 2 different solution provides more security in
 context of new program update-new bugs problems and incidents and
 prevents other potential problems.
 Goran - glad to have helped.

 One last piece of advice which might be useful - to help to guarantee
 consistency of performance between the two route-servers, you should
 consider a configuration generator so that your route-server configs are in
 sync.  The best way to implement this at your exchange is to use IXP
 Manager, maintained by the awesome folks at the Irish exchange point, INEX.
 https://github.com/inex/IXP-Manager

 IXP Manager will get you lots of other features as well as good route-server
 hygiene.

 There's also a historic perl-script that does this on my personal github.
 Both of these solutions allow you to filter route-server participants based
 on IRR data, which has proved to be a life-saver at all of the exchanges I
 help to operate.  Having my horrible historic thing is maybe better than no
 thing at all, but I deliberately won't link to it as you should really use
 IXP Manager. :-)

 Andy=

Re: OT: VPS with Routed IP space

[Sebastian Spies]

Am 24.02.2015 um 23:59 schrieb Doug Barton:
 On 2/24/15 1:42 PM, Michael Helmeste wrote:
 ARP Networks: https://www.arpnetworks.com/vps

 Routed IP space (v4 and v6) as well as BGP peering.

 +1 for Arp, I'm a happy customer (no other affiliation).



We are going to do this at datapath.io using AWS and others soon. We do
some BGP peering on your behalf and expose some parameters to the VPS
via API.


Best regards,
Sebastian

Re: OT: VPS with Routed IP space

[Sebastian Spies]

Am 26.02.2015 um 22:14 schrieb Owen DeLong:
 On Feb 26, 2015, at 9:58 AM, Sebastian Spies s+mailinglisten.na...@sloc.de 
 wrote:



 Am 24.02.2015 um 23:59 schrieb Doug Barton:
 On 2/24/15 1:42 PM, Michael Helmeste wrote:
 ARP Networks: https://www.arpnetworks.com/vps

 Routed IP space (v4 and v6) as well as BGP peering.
 +1 for Arp, I'm a happy customer (no other affiliation).


 We are going to do this at datapath.io using AWS and others soon. We do
 some BGP peering on your behalf and expose some parameters to the VPS
 via API.
 Since the requirement included IPv6, I’m not sure how you plan to use AWS.


You are right. Sorry for the sloppiness.
OT: There is no way to even let two instances communicate with each
other in the same VPC subnet using a protocol other than IPv4, although
they transport ethernet headers (no VXLAN). Our only solution was to use
v6 load balancers that tunnel with our endpoint on the other side of
direct connect.

Re: ISP inbound failover without BGP

[Sebastian Spies]

Am 04.03.2014 05:19, schrieb William Herrin:

 Reasons why dynamic DNS fails to perform as expected include:

 * Web browser DNS pinning can result in a customer's web browser
 holding the old IP address indefinitely.

 * Host-level caching of looked up names which discards the TTL.
 Remember: your desktop or laptop performs lookups against multiple
 name services, e.g. DNS, /etc/hosts, lmhosts, NIS+. DNS TTL is no
 longer in scope once the name to address map enters the generic host
 lookup mechanism. Most OSes have a fixed timeout of one sort or
 another, some old ones as long as 24 hours.

* Eyeball ISPs' DNS resolvers might tamper with TTL values.


-- SEBASTIAN SPIES lnked.in/sspies vastly.de

Route Server Filters at IXPs and 4-byte ASNs

[Sebastian Spies]

Hi there,

as 2-byte ASNs are close to depletion (see NRO announcement this week),
we have come across a topic, that might influence the adoption of 4-byte
ASNs. First of all, we have no data or experience about 4-byte ASN
adoption and are therefore unable to evaluate, if we should rush for the
last available numbers.

So here's the thing: IXPs usually implement N:M filtering based on
standard community strings. As standard BGP communities support only 4
bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte
ASNs.

Extended communities to the rescue? We are not sure: While RFC4260
(Extended Communities) allows for Global Admin,2bytes:Local Admin,
4bytes community strings (3.1 Two-Octet AS Specific Extended
Community), this works as long as the IXP itself uses a 2-byte ASN.

What happens, if the IXP uses a 4-byte ASN? RFC5668 (4-Octet AS Specific
BGP Extended Community) defines Global Admin,4bytes:Local Admin,
2bytes.

I have been asking some IXP operators, about their practice and their
reply was 4-byte ASNs are supported by our RS. What's your experience?
Did you see IXPs, that do not support them? Do you think, the IXP
operators are aware of this limitation? Have you seen IXPs with 4-byte
ASNs or do RIRs reserve 2-byte ASNs for future IXPs?  What other
operational problems did you experience while using 4-byte ASNs?

A lot of questions. I am very curious about your answers.

Cheers,
Sebastian


-- 

SEBASTIAN SPIES

lnked.in/sspies

Re: Route Server Filters at IXPs and 4-byte ASNs

[Sebastian Spies]

Am 25.01.2014 16:38, schrieb Bryan Socha:
 Re-reading, I was thinking of someone connecting to an IXP, not a new
 IXP needing a 2Byte.This is an interesting situation and you are
 correct, my comment was off topic.

Sorry for not mentioning the beef: Extended Communities effectively
leave 6 bytes to the user. So, it is not possible, that a 4-byte-ASN IXP
encodes its own 4-byte-ASN and a 4-byte-ASN customer in one extended
community string. This is needed, as the IXP RS usually interpret their
own ASN and a peer ASN as: Send this prefix out to the peer ASN.

To make things worse: even if the IXPs ASN is 2-byte, I would assume,
that RS implementors chose to interpret extended community strings as
always being in the format 4-byte:2-byte (see RFC5668).

Best regards,
Sebastian

Re: incoming smtp from v6 addresses

[Sebastian Spies]

Am 04.01.2012 11:10, schrieb Randy Bush:
 for incoming mail that is *accepted*, i.e. not stuff like
 2012-01-04 00:37:28 REJECT because 118.39.80.118 listed in 
 rbl-plus.mail-abuse.org
 2012-01-04 00:37:28 H=(nexo.es) [118.39.80.118] F=ped...@nexo.es 
 rejected RCPT owner-radius...@ops.ietf.org: blocked because 118.39.80.118 
 is in  blacklist at rbl-plus.mail-abuse.org: Mail from 118.39.80.118 blocked 
 using Trend Micro Email Reputation database. Please see 
 http://www.mail-abuse.com/cgi-bin/lookup?118.39.80.118
 2012-01-04 00:37:28 no host name found for IP address 118.39.80.118
 2012-01-04 00:37:29 REJECT 118.39.80.118 too many bad recip
 2012-01-04 00:37:29 REJECT because 118.39.80.118 listed in 
 rbl-plus.mail-abuse.org

 7.8% is over ipv6 transport

 but only 2% of outgoing deliveries are over ipv6.

 what do other folk see?

 randy

Received

$ grep 'amavis' mail.log | grep Passed | wc -l
448

$ grep 'amavis' mail.log | grep Passed | grep IPv6 | wc -l
91

$ grep 'amavis' mail.log | grep Passed  | grep IPv6 | grep -v
'2001:1838::cc5d:d48a' | wc -l
18


Sent

$ grep 'postfix/smtp' mail.log | grep 'status=sent' | grep -v
'127.0.0.1' |wc -l
253

enceladus:/var/log# grep 'postfix/smtp' mail.log | grep 'status=sent' |
egrep '\[([a-f0-9]{0,4}:)+[a-f0-9]{0,4}\]' | wc -l
19

with most of them going to mailin.v6.t-online.de[2003:2:2:10:fee::32]:25
~40 silent users


Sebastian

Re: economic value of low AS numbers

[Sebastian Spies]

Hi Dave,


On 17.11.2011 15:53, Dave Hart wrote:

 I recognize there's no practical shortage of AS numbers.  BGP's
 preference for low AS numbers doesn't come into play much.  On the
 other hand, a low AS number can't hurt at the human level when
 negotiating peering or attracting customers.
Could you explain, what you mean with BGP's preference for low AS
numbers.


Sebastian