nested prefixes in Internet

[Martin T]

Hi,

let's assume that there is an ISP "A" operating in Europe region who
has /19 IPv4 allocation from RIPE. From this /19 they have leased /24
to ISP "B" who is multi-homed. This means that ISP "B" would like to
announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this
gives two possibilities:

1) Deaggregate /19 in ISP "A" network and create "inetnum" and "route"
objects for all those networks to RIPE database. This means that ISP
"A" announces around dozen IPv4 prefixes to Internet except this /24
and ISP "B" announces this specific /24 to Internet.

2) ISP "A" continues to announce this /19 to Internet and at the same
time ISP "B" starts to announce /24 to Internet. As this /24 is
more-specific than /19, then traffic to hosts in this /24 will end up
in ISP "B" network.


Which approach is better? To me the second one seems to be better
because it keeps the IPv4 routing-table smaller and requires ISP "A"
to make no deaggregation related configuration changes. Only bit weird
behavior I can see with the second option is that if ISP "B" stops for
some reason announcing this /24 network to Internet, then traffic to
hosts in this /24 gets to ISP "A" network and is blackholed there.


thanks,
Martin

Re: nested prefixes in Internet

[Martin T]

Florian:

> Are the autonomous systems for the /19 and /24 connected directly?

Yes they are.


> (1) can be better from B's perspective because it prevents certain routing 
> table optimizations (due to the lack of the covering prefix)

What kind of routing table optimizations are possible if covering /19
prefix is also present in global routing table?


> But (1) can also be worse for B and A's other customers if /24s (and slightly 
> shorter prefixes) in this part of the IPv4 address space are commonly 
> filtered.

Based on my experience /24 is allowed in prefix-filters.. Longer IPv4
prefixes are not.



Roy, Mel:

Could you please elaborate on that option. What kind of advantages
does this have compared to option 2?


thanks,
Martin


On Tue, Sep 27, 2016 at 8:52 PM, Michael Hallgren  wrote:
> Hi Martin,
>
> What do you want to do? Move from A to B or add A to B?
>
> Cheers,
> mh
>
>
>
> Le 27 sept. 2016 17:52, à 17:52, Mel Beckman  a écrit:
>>Precisely. This is how it's done by providers I've worked with.
>>
>> -mel beckman
>>
>>> On Sep 27, 2016, at 7:06 AM, Roy  wrote:
>>>
>>>
>>>
>>> Option 3?
>>>
>>> ISP A announces the /19 and the /24 while ISP B does just the /24
>>>
>>>> On 9/27/2016 4:20 AM, Martin T wrote:
>>>> Hi,
>>>>
>>>> let's assume that there is an ISP "A" operating in Europe region who
>>>> has /19 IPv4 allocation from RIPE. From this /19 they have leased
>>/24
>>>> to ISP "B" who is multi-homed. This means that ISP "B" would like to
>>>> announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this
>>>> gives two possibilities:
>>>>
>>>> 1) Deaggregate /19 in ISP "A" network and create "inetnum" and
>>"route"
>>>> objects for all those networks to RIPE database. This means that ISP
>>>> "A" announces around dozen IPv4 prefixes to Internet except this /24
>>>> and ISP "B" announces this specific /24 to Internet.
>>>>
>>>> 2) ISP "A" continues to announce this /19 to Internet and at the
>>same
>>>> time ISP "B" starts to announce /24 to Internet. As this /24 is
>>>> more-specific than /19, then traffic to hosts in this /24 will end
>>up
>>>> in ISP "B" network.
>>>>
>>>>
>>>> Which approach is better? To me the second one seems to be better
>>>> because it keeps the IPv4 routing-table smaller and requires ISP "A"
>>>> to make no deaggregation related configuration changes. Only bit
>>weird
>>>> behavior I can see with the second option is that if ISP "B" stops
>>for
>>>> some reason announcing this /24 network to Internet, then traffic to
>>>> hosts in this /24 gets to ISP "A" network and is blackholed there.
>>>>
>>>>
>>>> thanks,
>>>> Martin
>>>

Re: nested prefixes in Internet

[Martin T]

Florian:

as I told in my initial e-mail, ISP-B is multi-homed, i.e connected to
ISP-A(who leases the /24 to ISP-B from their /19 block) and also to
ISP-C. ISP-B wants to announce this /24 both to ISP-A and ISP-C.
That's the reason why either solution 1 or 2 in my initial e-mail is
needed.

However, I would like to hear from Roy and Mel why do they prefer a
third option where ISP A announces the /19 and the /24 while ISP B
does just the /24.


thanks,
Martin

On Wed, Oct 5, 2016 at 11:50 PM, Florian Weimer  wrote:
> * Martin T.:
>
>> Florian:
>>
>>> Are the autonomous systems for the /19 and /24 connected directly?
>>
>> Yes they are.
>
> Then deaggregation really isn't necessary at all.
>
>>> (1) can be better from B's perspective because it prevents certain
>>> routing table optimizations (due to the lack of the covering prefix)
>>
>> What kind of routing table optimizations are possible if covering /19
>> prefix is also present in global routing table?
>
> The /24 prefix could arguably be dropped and ignored for routing
> decisions.

Re: nested prefixes in Internet

[Martin T]

Hi,

I made a drawing of those two best solutions: http://i.imgur.com/7NQVgUH.png

As much as I understand, both solutions require no special changes
from "ISP C". Only advantage of solution B over solution A, that I can
see, is that at the time when link between "ISP C" and "ISP B" is up,
the traffic from Internet towards "ISP B" prefers the "ISP C"
connection.


In case the link between "ISP A" and "ISP B" goes down, then traffic
from "ISP A" addressed to this /24 will use a private peering link
between "ISP A" and "ISP C" so the transit costs are not an issue.


thanks,
Martin

On Wed, Oct 12, 2016 at 1:58 AM, Owen DeLong  wrote:
>
>> On Oct 10, 2016, at 14:59 , Baldur Norddahl  
>> wrote:
>>
>>
>>
>> Den 10/10/2016 kl. 22.27 skrev Owen DeLong:
>>> Not true… There are myriad reasons that the /24 might not reach a network 
>>> peered with ISP-A, including the possibility of being a downstream customer 
>>> of a network peered with or buying transit from ISP-A. In the latter case, 
>>> not an issue, since it’s paid transit, but in the former (peered, not 
>>> transit), again, ISP-A is probably not super excited to carry traffic that 
>>> someone isn’t paying them to carry.
>>>
>>
>> But ISP-A is in fact being paid to carry the traffic. Supposedly ISP-B has a 
>> paid transit relation to ISP-A. In the case the transit link is down ISP-A 
>> might have to transport the traffic through a less profitable link however.
>
> Which isn’t really in the agreement between ISP-B and ISP-A unless it was 
> specifically (and unusually) negotiated.
>
> Also, you’re assuming that the leased space came with a transit agreement. In 
> many cases, address leases don’t, so consider the additional scenario where 
> ISP-B leases addresses from ISP-A, but has transit contracts with ISP-C and 
> ISP-D but no connection at all to ISP-A.
>
>> I know that if ISP-A was my network I would be making money even with the 
>> transit link down. Yes I might have to transport something out of my network 
>> through one of my transits, but outbound traffic is in fact free for us 
>> because we are heavy inbound loaded.
>
> Yes, but it doesn’t help if it also came in on a transit link. Any traffic 
> you both receive and transmit on transit costs you money pretty much no 
> matter who you are.
>
>
> Owen
>

Re: nested prefixes in Internet

[Martin T]

Thank you all for the replies! I'll go with the solution where "ISP A"
announces both /19 prefix and /24 prefix.


Martin

On Thu, Oct 20, 2016 at 1:16 AM, Matt Buford  wrote:
> On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl 
> wrote:
>
>
>> Is that a real problem? In my experience a /24 is honoured almost
>> universially.
>>
>
> Here's a real-world issue I ran into with this.  In this case, it isn't
> that someone filtered /24s, but that they didn't have a full table (peering
> routes only plus a default).  This resulted in them following the less
> specific route for traffic destined for the /24.
>
> A customer of mine was advertising only a /20 to me and then only a more
> specific /24 was advertised from a remote site of theirs to a different
> ISP.  The customer did have a connection between their two sites, so in
> theory it was OK if the traffic arrived on their "wrong" link, except that
> the customer strongly didn't want this to happen, thus the inconsistent
> routes.
>
> This customer found that the remote /24 was unable to access a large CDN
> provider.  This CDN told them that a traceroute to the /24 went to my
> network (we peered at an exchange) and was then dropped.
>
> This seemed odd at first, as I confirmed I was not advertising the /24 to
> them so why were they routing it to me?  It turned out that the CDN
> provider was running a peer-routes-only network with a default to their
> transit.  This meant that they saw the /20 from their peer (me) but never
> saw the /24, since they carried no transit routes.  This resulted in them
> routing the entire /20 to me.
>
> My peering router was not willing to route traffic from a peering exchange
> towards transit I had to pay for, so it was dropped.
>
> The customer's split advertisements didn't seem particularly unreasonable
> or invalid, though perhaps they were not the preferred setup.  It wasn't
> unreasonable for me to not route from a peering exchange to transit.  It
> wasn't unreasonable of the CDN to have a peering-and-default routing
> table.  But, those three things together were not compatible.
>
> I called the customer and presented them with my findings and some
> potential options to consider, and consistent advertisements was one of
> those options.  The customer strongly wanted incoming traffic to arrive
> directly to the correct location so he didn't want to do that.  I suggested
> a possible compromise was for him to advertise both the /24 and /20 to me,
> but use communities so that I never advertised his /24 to any upstreams or
> peering exchanges.  That way, if traffic for the /24 accidentally hit my
> network like we were running into, I would route it to him and he could
> pass it to the correct site.  It meant that a little traffic would arrive
> at the wrong site in his network and have to pass over his back-end link,
> but at least it would be fairly limited.  He didn't like this either.  He
> didn't want to split the /20 advertisement up to no longer cover the /24
> either, I think just because "I shouldn't have to do that!"
>
> The option the customer chose in the end was to use a community on his
> advertisement to instruct my routers to no longer advertise his /20 to any
> peering exchanges at all.  That ensured the CDN didn't directly send me
> anything for him (not the /24 or the /20), and the transit networks
> in-between took care of making sure traffic to the /24 didn't accidentally
> end up on my network.  While I didn't find it very elegant to be shifting
> traffic from peering exchanges to transit, it wasn't a significant amount
> of traffic and it got him off my back.

some shallow statistics about finding the name/netname for IP address using RDAP and WHOIS

[Martin T]

Hi!

For testing a script I generated 1 random IPv4 and global unicast
IPv6 addresses. For all those addresses I tried to find the
netname/name attribute value from WHOIS servers using the latest
version of https://github.com/rfc1036/whois and RDAP servers using the
curl. Basically 'whois -H ' and 'curl -L
"https://rdap.db.ripe.net/ip/"'. Out of those 1 random IPv4
and IPv6 addresses, 7351 gave the same name/netname using RDAP and
WHOIS. In case of 2285 addresses, the RDAP was able to find the name
while WHOIS was not. Probably thanks to bootstrap feature. In case of
364 addresses, the WHOIS found a different netname than RDAP. Those
cases can be seen here: http://termbin.com/p6u7 Left column is the
RDAP and the right one is the WHOIS. If "IANA-BLK" WHOIS results for
IPv6 are excluded, then only <1% of queries did not return a result
using RDAP while they did return a result using WHOIS.
In short, based on this small test, the RDAP is much more reliable
than WHOIS for finding the name/netname for an IP address.

Maybe those results are interesting or useful for somebody.

PS. IPv4 and IPv6 addresses were generated like this:

if (( $(($RANDOM % 2)) == 0 )); then

# Generate random IPv4 address.
printf -v ip '%d.%d.%d.%d' \
"$(($RANDOM % 256))" \
"$(($RANDOM % 256))" \
"$(($RANDOM % 256))" \
"$(($RANDOM % 256))"
else

# Gnerate random IPv6 global unicast address.
hex_digit=( 0 1 2 3 4 5 6 7 8 9 a b c d e f )
ip=
for i in {1..7}; do
nibble=
for i in {1..4}; do
nibble="$nibble""${hex_digit[$(($RANDOM % 16))]}"
done
ip="$ip":"$nibble"
done
ip=2001"$ip"
fi


Martin

association between ASN and company name in ARIN region

[Martin T]

Hi,

how to associate AS number with company name in ARIN region? For
example in a small European country, where I leave, it can be done
roughly like that:

1) ISP named "XYZ" and IP transit customer named "KLM Inc." sign an IP
transit contract
2) IP transit customer "KLM Inc." tells to ISP that their AS number is 123
3) ISP engineers, who configure the service, check the "org" attribute
value from AS123 "aut-num" object from RIPE database. This is a RIPE
NCC managed value. For example it is ORG-KLM-RIPE.
4) then they check "org-name" attribute value for ORG-KLM-RIPE
organisation object. Again, this is RIPE NCC managed value. "org-name"
value(organization name) is exactly the same as in company
registration papers.
5) now they can search for this organization name from country centre
of registers and information systems database which contains
registration papers for all the companies in this country and contact
with this company if anything looks suspicious

This is obviously simply an example to show that it is possible to
trace from AS number back to company registration papers and thus to
even people behind the company(listed in company registration papers).

Is it possible to make a similar connection between AS number and
company name in ARIN region? In other words, how do you find out that
company is eligible to use AS number?


thanks,
Martin

Re: association between ASN and company name in ARIN region

[Martin T]

Thanks for replies! Who is allowed to change "OrgName" attribute
value? Only ARIN?


thanks,
Martin

On Fri, Mar 31, 2017 at 11:59 AM, Florian Weimer  wrote:
> * Arnold Nipper:
>
>> On 30.03.2017 17:50, Martin T wrote:
>>
>>> Is it possible to make a similar connection between AS number and
>>> company name in ARIN region? In other words, how do you find out that
>>> company is eligible to use AS number?
>>>
>>
>>
>> This doesn't work for you?
>>
>> whois -h whois.arin.net as174 | egrep
>
> Note that depending on the WHOIS client, this does not work.  The
> correct AS number query syntax for whois.arin.net does not include an
> “AS” prefix.  The difference is only visibile for AS numbers with in
> an AS range object.  14745 is an example that shows the difference.

Are specific "route" objects in RIR databases needed?

[Martin T]

Hi,

for example there is a small company with /22 IPv4 allocation from
RIPE in European region. This company is dual-homed and would like to
announce 4x /24 prefixes to both ISPs. Both ISP's update their
prefix-lists automatically based on records in RIPE database. For
example Level3 uses this practice at least in Europe. If this small
company creates a "route" object for it's /22 allocation, then is it
enough? Theoretically this would cover all four /24 networks. Or in
which situation it is useful/needed to have "route" object for each
/24 prefix?



regards,
Martin

Re: Are specific "route" objects in RIR databases needed?

[Martin T]

Job, Tore: ok, I see. So "route" object in RIR routing registry database
for each announced prefix is needed only because some ISPs create filters
exactly the size of the "route" object in database? So for example if there
is a "route" object for 192.0.2.0/24 in RIR database, then ISP-A might
create a following strict prefix-filter entry:

policy-options {
policy-statement EXAMPLE {
term prefixes {
from {
route-filter 192.0.2.0/24 exact;
}
then next policy;
}
then reject;
}
}

On the other hand, ISP-B might create loose filter based on the same
"route" object like this:

policy-options {
policy-statement EXAMPLE {
term prefixes {
from {
route-filter 192.0.2.0/24 upto /32;
}
then next policy;
}
then reject;
}
}


PS: this is a theoretical question :) I'm also for keeping the BGP table as
short as possible.


regards,
Martin

On Thu, Jan 30, 2014 at 5:13 PM, Tore Anderson  wrote:

> * Job Snijders
>
> > On Thu, Jan 30, 2014 at 06:51:59PM +0200, Martin T wrote:
> >
> >> for example there is a small company with /22 IPv4 allocation from
> >> RIPE in European region. This company is dual-homed and would like to
> >> announce 4x /24 prefixes to both ISPs. Both ISP's update their
> >> prefix-lists automatically based on records in RIPE database. For
> >> example Level3 uses this practice at least in Europe. If this small
> >> company creates a "route" object for it's /22 allocation, then is it
> >> enough? Theoretically this would cover all four /24 networks. Or in
> >> which situation it is useful/needed to have "route" object for each
> >> /24 prefix?
> >
> > You should create a route object for each route that you announce, if
> > you announce 4 x /24 you should create a route: object for each /24.
>
> +1
>
> > ps. Can you please send 20 dollarcent per /24 to my paypal account
> > (j...@instituut.net) with the reference "deaggregation fee"?
>
> Indeed.
>
> Martin, I'd suggest announcing the 4 x /24s to each ISP tagged with the
> no-export community in order to achieve whatever you are trying to do,
> *in addition* to the covering /22. That way you're not polluting Job,
> my, and everyone else's routing tables more than necessary, only your
> own ISPs', but then again you're actually paying them for the privilege.
>
> Tore
>

RTT of ICMP "TTL exceeded" messages in Level3 network remains the same throughout the network

[Martin T]

Hi,

if I make a traceroute to a host in San Jose in Level3 network from
DigitalOcean server in Amsterdam, then in Level3 network(hop 6 in
example below) the RTT remains the same:

# traceroute -q 1 -I ZYNGA-INC.edge1.SanJose3.Level3.net
traceroute to ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114), 30
hops max, 60 byte packets
 1  5.101.103.253 (5.101.103.253)  0.265 ms
 2  95.85.0.229 (95.85.0.229)  0.236 ms
 3  ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25)  0.275 ms
 4  if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46)  0.630 ms
 5  4.68.63.41 (4.68.63.41)  0.635 ms
 6  vl-3603-ve-227.csw2.Amsterdam1.Level3.net (4.69.162.153)  155.309 ms
 7  ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201)  155.627 ms
 8  ae-46-46.ebr2.London1.Level3.net (4.69.143.74)  153.470 ms
 9  *
10  ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66)  148.972 ms
11  *
12  ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185)  147.881 ms
13  ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14)  149.632 ms
14  ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208)  151.107 ms
15  ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114)  154.431 ms
#

In other words, one sees the RTT of the end-host as a RTT for all the
hops in Level3 netwotk. If I make the traceroute to penultimate hop
ae-4-90.edge1.SanJose3.Level3.net, then RTT is as expected:

root@vserver:~# traceroute -q 1 -I ae-4-90.edge1.SanJose3.Level3.net
traceroute to ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208), 30
hops max, 60 byte packets
 1  5.101.103.254 (5.101.103.254)  0.228 ms
 2  95.85.0.237 (95.85.0.237)  0.217 ms
 3  ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25)  0.276 ms
 4  if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46)  0.656 ms
 5  4.68.63.41 (4.68.63.41)  0.607 ms
 6  vl-3604-ve-228.csw2.Amsterdam1.Level3.net (4.69.162.157)  0.696 ms
 7  ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201)  0.677 ms
 8  ae-45-45.ebr2.London1.Level3.net (4.69.143.70)  7.059 ms
 9  ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78)  76.311 ms
10  ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74)  76.265 ms
11  ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41)  76.820 ms
12  ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185)  149.101 ms
13  ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14)  150.557 ms
14  ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208)  162.022 ms
root@vserver:~#

All the ICMP "TTL exceeded" messages except the first and the
penultimate one in Level3 network have MPLS extensions
header(s24.postimg.org/4z9at9z45/ICMP_echo_reply_MPLS_extensions.png)
which is always the same except the tag value changes.

How does this technically work? What are the advantages of such setup?


thanks,
Martin

determine relationship between the operators based on import and export statements in aut-num object?

[Martin T]

Hi,

bit weird question, but is it possible to determine
relationship(Internet transit, settlement-free peering, etc) between
the operators based on import and export statements in aut-num object?
Often aut-num objects in RIR database contain the remarks which
describe such relationships. However, for example here I have
following import and export attributes from an aut-num object of an
ISP:

import: from AS65133 action pref=100; accept ANY
import: from AS65798 accept AS65798
import: from AS65084 accept AS65084
import: from AS65485 action pref=100; accept ANY
import: from AS65751 accept AS65751
import: from AS65059 action pref=100; accept ANY
import: from AS65128 accept AS65128
export: to AS65133 announce AS-SET
export: to AS65798 announce ANY
export: to AS65084 announce ANY
export: to AS65485 announce AS-SET
export: to AS65751 announce ANY
export: to AS650835 announce AS-SET
export: to AS65128 announce ANY

Am I correct that it is safe to say that probably AS65133, AS65485 and
AS65059 are the uplink providers and AS65798, AS65084, AS65751 and
AS65128 are the customers of this ISP? Last but not least, maybe there
is altogether a more reliable way to understand the relationship
between the operators than aut-num objects(often not updated) in RIR
database?


thanks,
Martin

Re: determine relationship between the operators based on import and export statements in aut-num object?

[Martin T]

Hi,

thanks! I guess one of the most exhaustive and freely-available
route-views data to analyze is from RIPE Routing Information Service
project? For example if I would like to analyze a certain prefix
announced by a certain AS for time period from 1.11.2014 to
30.11.2014, then I should download route-views data for this
period(for rrc_id in {00..14}; do for d in {01..30}; do wget
http://data.ris.ripe.net/rrc"$rrc_id"/2014.11/bview.201411"$d".0800.gz;
done; done) and anayze this with bgpdump(bgpdump -m bview* | grep -w
65133)? Other option would be to use one of the tools like RIPEstat
BGPlay?


thanks,
Martin

On 11/25/14, William Waites  wrote:
> On Tue, 25 Nov 2014 17:36:47 +0200, Martin T  said:
>
> > Last but not least, maybe there is altogether a more reliable
> > way to understand the relationship between the operators than
> > aut-num objects(often not updated) in RIR database?
>
> The first thing to do is look and see if the policy of, e.g. AS65133
> is consistent with what you see there. I suspect you'll find a lot of
> mismatches but I don't know if that has been studied systematically,
> but it should be simple to do.
>
> Next, much more data intensive, is trawl through the route views data
> and see to what extent the actual updates seen are consistent with the
> RIR objects, and also see what (topological, not financial as Valdis
> points out) relationships they imply that are not present in the RIR
> database.
>
> -w
>

correlation between ingress and egress traffic in case of volume-based DDoS

[Martin T]

Hi,

volume-based DDoS attacks should often result with following bandwidth graphs:

http://s12.postimg.org/gy3eps10t/volume_based_DDo_S_graph.png


This is a fabricated bps graph for 100GigE port facing an uplink
provider. As seen on the image, outgoing traffic drops at the time
when incoming traffic increases. I could see following reasons for
this:

1) large portion of traffic uses TCP protocol and in case of
congestion(even in one direction), ACK messages are lost and TCP
congestion avoidance kicks in and as a result it will reduce the cwnd
which in effect reduce the data TCP sender can send

2) certain router platforms share some hardware resources both with Tx
and Rx traffic

Are those assumptions correct? Are there any other reasons which cause
outgoing traffic to drop if incoming traffic is very high or the other
way around?


thanks,
Martin

strategies to mitigate DNS amplification attacks in ISP network

[Martin T]

Hi,

as around 40% of ASNs allow at least partial IPv4 address spoofing in
their network(http://spoofer.csail.mit.edu/summary.php) and there are
around 30 million open-resolvers(http://openresolverproject.org/) in
the Internet, then DNS amplification traffic is daily occasion for
ISPs. This in probably mainly because RPF checks and DNS
RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html)
are not ubiquitously implemented, recursive requests without any ACLs
in DNS servers are often allowed, it requires little effort from
attackers point of view and is effective attack method. Unfortunately,
there seems to be very limited number of countermeasures for ISPs. Few
which I can think of:

1) higher capacity backbone links - I'm not sure if this can be
considered a mitigation method, but at least it can help to affect
smaller amount of customers if traffic volumes are not very high


2) rate-limit incoming DNS traffic flows on peering and uplink ports -
here I mean something similar to iptables "recent"
module(http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16)
which allows certain number of certain type of packets in a configured
time-slot per IP. However, such functionality is probably not common
on edge or backbone routers.


Tracking the packet state does definitely not work because state table
should be synchronized between all the routers in the network and
again, this requires Internet-routers to have stateful firewall
functionality. In addition, one also needs to allow new DNS
connections from Internet to its network.
If one simply polices incoming DNS traffic on uplink and peering
ports(for example if baseline DNS traffic is 5Mbps, then policer is
set to 50Mbps), then legitimate customers DNS traffic is also affected
in case of actual attack occurs and policer starts to drop DNS
traffic, i.e. policer has no way to distinguish between the legitimate
and non-legitimate incoming DNS traffic.


Am I wrong in some points? What are the common practices to mitigate
DNS amplification attacks in ISP network?


thanks,
Martin

algorithm used by (RIPE region) ISPs to generate automatic BGP prefix filters

[Martin T]

Hi,

am I correct that ISPs (in RIPE region), who update their BGP prefix
filters automatically, ask their IP transit customer or peering
partner to provide their "route"/"route6" object(s) or "as-set" object
in order to find all the prefixes which they should accept? If the IP
transit customer or peering partner provides an "as-set", then ISP
needs to ensure that this "as-set" belongs to this IP transit customer
or peering partner because there is no automatic authentication for
this, i.e. anybody can create an "as-set" object to database with
random "members" attributes? This is opposite to "route"/"route6"
objects which follow a strict authentication scheme. In addition, in
case of "as-set", an ISP needs to recursively find all the AS numbers
from "members" attributes because "as-set" can include other
"as-sets"? Quite a lot of question, but I would simply like to be sure
that I understand this correctly.


thanks,
Martin

Re: common checks performed when passing on an IPv4 PA allocation from one end-customer to another

[Martin T]

In general, are there any other similar databases to DNSBL(used for
fighting against spam) system? For example lets say that some
institution holds a public database of IP addresses of web-servers
which (regularly) serve malware and anyone can check if their IP
addresses are listed there. Or for example public database of IP
addresses of botnet members. The reason I ask is the same- I would
like to be 100% sure that when I hand out a range of IPv4 addresses,
which were previously used by some other customer, then those
addresses were not abused in any way and new customer will not have
any trouble with those addresses.



thanks,
Martin

On Tue, Apr 28, 2015 at 4:23 PM, Martin T  wrote:
> Colin,
>
> this is a good idea, but in this case the network I am interested in
> does not have a RIPE Atlas probe.
>
>
> regards,
> Martin
>
> On 4/28/15, Colin Johnston  wrote:
>>
>>
>>
>>> On 28 Apr 2015, at 10:32, Martin T  wrote:
>>>
>>> Hi,
>>>
>>> as far as I know, some large US Internet companies like Google,
>>> Facebook or Amazon restrict access to some services for certain
>>> regions like Crimea or countries like Iran or North Korea. Do they
>>> rely on services like MaxMind? Or do they use some other method to
>>> check the geographical location of IP address? If yes, then is there
>>> an API to check if an address is allowed to use Google, Facebook, etc
>>> services or not?
>>>
>>
>> you could use ripe atlas selecting nodes in countries you require and
>> destination facbook/google/amazon servers and check results
>>
>> Colin
>>
>>

(network)technologies used by NSA for data collection

[Martin T]

Hi,

I watched "Citizenfour"(imdb.com/title/tt4044364/) documentary and at
41:12 Edward Snowden gives a brief overview of some of the leaked
documents to journalists Glenn Greenwald and Ewen MacAskill. At 42:57
Snowden mentions devices which are able to collect data at rate of
1Tbps. This was in 2011. Screen-shots from the movie can be seen here:
https://nsa.gov1.info/dni/2014/tumult.jpg Third slide looks like some
sort of vendor product roadmap :)
Just out of curiosity, what kind of equipment those might be? Is it
realistic that NSA/DoD are able to produce their own hardware? Let
alone custom silicon like Cisco or Juniper are. Or do they use off the
self hardware.. In addition, it's relatively easy to install a passive
fiber optical tap for a submarine cable, but how do you get
information out of it? I mean all the different wavelengths(CWDM/DWDM)
within the same cable, line rates(up to 100GigE), circuit switched and
packet switched technologies which those devices should support.. In
addition, how(bandwidth and network wise) to transport this data to
data analysis and storage equipment if it collected far away from
USA..
Some of those questions or thoughts might be naive and stupid, but
that's what crossed my mind when I watched the documentary. Maybe
somebody, who has done more research in this field, could clarify.



thanks,
Martin

Re: (network)technologies used by NSA for data collection

[Martin T]

I see, thanks! However, this all requires at least some level of
Internet operator cooperation? For example if ISP in Northern Europe
owns a sub-marine cable between Finland and Sweden and they decide to
upgrade their legacy Nortel equipment with STM-64 line-card in both
ends of the cable to a Juniper T1600 core routers with 100GigE
line-cards, then it's not possible that intelligence agency equipment
supports this, is it?
In addition, how is the collected data transported for storing in
(NSA) datacenters and later analysis? I guess the data collection
actually has to be fairly selective simply because the amount of data
is so huge. For example take the large Internet Exchanges where
several Tbps of data are exchanged in peak hours each day.


thanks,
Martin

On Sun, Mar 22, 2015 at 4:29 AM, Jason Bothe  wrote:
> Sorry. I got trigger happy. The STAs can read data Rey efficiently from
> multiple wavelengths or grey light simultaneously.
>
> Jason Bothe, Manager of Networking
>
> Rice University
>
>
> o   +1 713 348 5500
>
> m  +1 713 703 3552
>
> ja...@rice.edu
>
>
> On Mar 21, 2015, at 21:05, Martin T  wrote:
>
> Hi,
>
> I watched "Citizenfour"(imdb.com/title/tt4044364/) documentary and at
> 41:12 Edward Snowden gives a brief overview of some of the leaked
> documents to journalists Glenn Greenwald and Ewen MacAskill. At 42:57
> Snowden mentions devices which are able to collect data at rate of
> 1Tbps. This was in 2011. Screen-shots from the movie can be seen here:
> https://nsa.gov1.info/dni/2014/tumult.jpg Third slide looks like some
> sort of vendor product roadmap :)
> Just out of curiosity, what kind of equipment those might be? Is it
> realistic that NSA/DoD are able to produce their own hardware? Let
> alone custom silicon like Cisco or Juniper are. Or do they use off the
> self hardware.. In addition, it's relatively easy to install a passive
> fiber optical tap for a submarine cable, but how do you get
> information out of it? I mean all the different wavelengths(CWDM/DWDM)
> within the same cable, line rates(up to 100GigE), circuit switched and
> packet switched technologies which those devices should support.. In
> addition, how(bandwidth and network wise) to transport this data to
> data analysis and storage equipment if it collected far away from
> USA..
> Some of those questions or thoughts might be naive and stupid, but
> that's what crossed my mind when I watched the documentary. Maybe
> somebody, who has done more research in this field, could clarify.
>
>
>
> thanks,
> Martin
>

Re: common checks performed when passing on an IPv4 PA allocation from one end-customer to another

[Martin T]

Hi,

as far as I know, some large US Internet companies like Google,
Facebook or Amazon restrict access to some services for certain
regions like Crimea or countries like Iran or North Korea. Do they
rely on services like MaxMind? Or do they use some other method to
check the geographical location of IP address? If yes, then is there
an API to check if an address is allowed to use Google, Facebook, etc
services or not?


thanks,
Martin

On 9/17/13, Martin T  wrote:
> Hi,
>
> when one end-customer has been using for example /24 IPv4 allocation
> for a while and returns this(for example changes an ISP) to LIR, then
> are there some good practices before handing out this same /24 to a
> new customer? I guess LIR should:
>
> 1) remove all the DNS PTR records, classless of classful delegations
> 2) check if some of the IP addresses are in DNSBL(maybe the previous
> customer was a spammer). Example with 93.184.216.0/24:
>
> $ for ip in {0..255}.216.184.93;\
>> do for addr in \
>> cbl.abuseat.org \
>> dnsbl.inps.de \
>> no-more-funn.moensted.dk \
>> dnsbl.sorbs.net \
>> bl.spamcannibal.org \
>> bl.spamcop.net \
>> psbl.surriel.com \
>> dnsrbl.swinog.ch; \
>> do dig @8.8.8.8 "$ip"."$addr" +short | grep -q "^127.0.0." && \
>> echo "DNSBL-Alarm: $ip is listed on $addr"; done; done
> $
>
>
> Anything else?
>
>
> regards,
> Martin
>

Re: common checks performed when passing on an IPv4 PA allocation from one end-customer to another

[Martin T]

Colin,

this is a good idea, but in this case the network I am interested in
does not have a RIPE Atlas probe.


regards,
Martin

On 4/28/15, Colin Johnston  wrote:
>   
>
>
>> On 28 Apr 2015, at 10:32, Martin T  wrote:
>>
>> Hi,
>>
>> as far as I know, some large US Internet companies like Google,
>> Facebook or Amazon restrict access to some services for certain
>> regions like Crimea or countries like Iran or North Korea. Do they
>> rely on services like MaxMind? Or do they use some other method to
>> check the geographical location of IP address? If yes, then is there
>> an API to check if an address is allowed to use Google, Facebook, etc
>> services or not?
>>
>
> you could use ripe atlas selecting nodes in countries you require and
> destination facbook/google/amazon servers and check results
>
> Colin
>
>

disadvantages of peering with own IP transit customers

[Martin T]

Hi,

what are the disadvantages of peering(announcing own and all customers
prefixes) with own IP transit customers? One disadvantage is obviously
that amount of traffic on IP transit link is lower and thus customer
pays for smaller amount of Mbps. On the other hand, this can be
somewhat compensated with higher price per Mbps if the amount of
traffic on the IP transit connection is lower. However, are there any
other disadvantages/concerns when peering with own IP transit
customers?


regards,
Martin

most accurate geo-IP source to build country-based access lists

[Martin T]

Hi,

let's say that I need to build an ACL where I block all the IPv4
traffic from Sweden. I considered following solutions:

1) RIR statistics
files(ftp://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt)
accessible for example at ftp://ftp.apnic.net/pub/stats/. However,
those files contain allocations and assignment made by the registry
producing the file and not any sub-assignments by other agencies(for
example NIR, LIR). This means that this information is not very
accurate. Another problem which I found out is that in case of inetnum
object has many country fields, the first one is used. In addition,
even the RIR statistics exchange format document says that:

cc= ISO 3166 2-letter country code, and the enumerated
variances of

{AP,EU,UK}

These values are not defined in ISO 3166 but are widely used.

The cc value identifies the country. However, it is
not specified
if this is the country where the addresses are used.
There are no rules defined for this value.
It therefore cannot be used in any reliable way to map
IP addresses
to countries



2) MaxMind products. Those should rely on user input(for example
MaxMind purchases user data from ISP's or content providers) and based
on personal experience defaults to RIR data if no other more accurate
source is available. If anyone has something to specify here, then
please do so.


3) Use iptables geoip module, but turned out, that it uses MaxMind database:

root@VM-host:~# grep -Hsi maxmind $(dpkg -L xtables-addons-common)
/usr/lib/xtables-addons/xt_geoip_build:#Converter for MaxMind
CSV database to binary, for xt_geoip
/usr/lib/xtables-addons/xt_geoip_dl:
http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz \
/usr/lib/xtables-addons/xt_geoip_dl:
http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip;
root@VM-host:~#


4) In theory 
geofeeds(http://tools.ietf.org/html/draft-google-self-published-geofeeds-02)
would be a nice solution, but as I understand the RFC, it would work
for my example only in case all the IP address users would provide
their geofeed and there is a centralized database to query.


5) Use prefix AS path. However, there seems to be no reliable way to
determine source country based on information in BGP routing tables.


Are there any other possibilities to geolocate IPv4 addresses with
higher accuracy?


regards,
Martin

Re: most accurate geo-IP source to build country-based access lists

[Martin T]

John,

> At a brute force country level it is possible to use the Delegated
> ranges lists but that runs into the problem where IP ranges are
> subnetted and allocated to other countries.

Yeah.

In addition, to illustrate the point in my initial post, sometimes
inetnum objects contain more than one "country" attribute and only the
first country code is inserted into RIR delegated list. For example:

$ for deleg in $(wget -qO -
ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest | grep ipv4 |
cut -d '|' -f 4 | tail -1); do
>   [[ $(whois -rh whois.ripe.net -T inetnum "$deleg") = *country:*country:* ]] 
> && echo "$deleg"
> done
193.104.217.0
193.110.48.0
193.111.228.0
193.218.114.0
194.33.109.0
194.34.64.0
194.42.56.0
194.150.168.0
194.153.74.0
195.14.23.0
195.39.208.0
195.85.254.0
195.95.150.0
195.158.230.0
$


Blake,

> Have you thought about application layer tests - e.g. is the client's
> character set/language set to Swedish? Has the user identified
> himself/herself/henself as living in or being from Sweeden?

Unfortunately I need this on network layer, i.e. it should work for
other traffic besides HTTP/HTTPS.


Anyway, thanks for all the replies!


Martin

Is it possible to roughly estimate network traffic distribution for given ASN?

[Martin T]

Hi,

there are various tools out there which show the prefix distribution
among the peers/uplinks for given ASN. For example
https://radar.qrator.net/as/graph#96311 or
http://bgp.he.net/AS#_asinfo. As far as I know, those tools build
the graphs mainly based on data from route servers. Am I correct that
at best this data could give very rough estimation on ingress traffic
for ASN as those graphs indicate announced prefixes? I mean for
example if ASN 1 announces 1.1.0.0/16, 2.2.0.0/16 and 3.3.0.0/16 to
ASN 2, but only 1.1.0.0/16 to ASN 3, then one could assume that more
ingress data to ASN 1 goes over ASN 2. What about egress traffic? In
general, are there ways to roughly estimate network traffic
distribution for given ASN among its peers/uplinks? I would say it is
not possible.


thanks,
Martin

Re: Is it possible to roughly estimate network traffic distribution for given ASN?

[Martin T]

Thanks for confirming this! One last question- am I correct that those
graphs referred in my initial e-mail indicate announced prefixes? Only
way to have some insight about received prefixes for particular ASN is
to check the RIR database aut-num object and hope that this is
up-to-date and all the routing policies are describe there in detail?
Again, RIPE Atlas or the NLNOG RING or looking-glass could also help a
little.


thanks,
Martin

On 8/14/15, Baldur Norddahl  wrote:
> You may be able to view what routes I announce but you still have no idea
> what my route policy is like. I might prefer one upstream over another due
> to pricing, latency, capacity or any other unknown reason. And that is
> never published.
>
> If you can not know my egress, you will not know my ingress either as that
> would be someone else egress and you can not know their egress
>
> You could use RIPE Atlas or the NLNOG RING to do traceroutes. That would
> give you an idea of how traffic actually flows.
>
> Knowing the routes tells you nothing about how much traffic will be
> exchanged. How do you know which ASN has a deal with a big CDN or which
> ASNs are content heavy vs eyeball heavy? Only the source or destination ASN
> can know for sure how much traffic is exchanged.
>
> Regards,
>
> Baldur
>

How ISP's in ARIN region create automatic prefix-filters?

[Martin T]

Hi,

as I understand, ARIN whois database does not contain "route" objects,
which are used for example in RIPE region for automatic BGP prefix
filter generation. How does this work in ARIN region? I know that at
least some ISP's operating in ARIN region use their own whois
databases(for example rr.level3.net) which mirror content from other
RIR databases, but are there other methods how they update their
internal databases with records?


regards,
Martin

Re: How ISP's in ARIN region create automatic prefix-filters?

[Martin T]

Joe,

ok, so in ARIN region there are two separate databases- "ARIN’s
Registration database" and "ARIN’s Routing Registry database". If there is
a database containing routing policy information in ARIN region as well,
then why do you suggest to use RIPE database? I mean shouldn't most ISP's
in RIPE region use radb or their own whois database which mirrors all major
IRR databases and thus rr.arin.net among the others?


regards,
Martin


2013/6/12 Joe Abley 

>
> On 2013-06-12, at 13:38, Martin T  wrote:
>
> > as I understand, ARIN whois database does not contain "route" objects,
> > which are used for example in RIPE region for automatic BGP prefix
> > filter generation.
>
> whois.arin.net:43 is for assignment/allocation information. Does not use
> RPSL.
>
> rr.arin.net:43 is a routing registry that uses RPSL.
>
> > How does this work in ARIN region? I know that at
> > least some ISP's operating in ARIN region use their own whois
> > databases(for example rr.level3.net) which mirror content from other
> > RIR databases, but are there other methods how they update their
> > internal databases with records?
>
> My general advice for anybody who cares to listen is to use the RIPE db
> for your objects if you are based in the ARIN region. It saves time if/when
> you come to peer with an organisation based in the RIPE region, and it
> makes your objects easy to find for anybody who wants to look for them.
>
> You can install a route in the RIPE db corresponding to number resources
> assigned elsewhere by authenticating against the RIPE-NCC-RPSL-MNT
> maintainer object, for which the plain-text password is "RPSL". Since your
> new route object will specify mnt-by MAINT-YOURS you will also need to
> authenticate against that (my favourite method is PGP).
>
>
> Joe
>
> mntner: RIPE-NCC-RPSL-MNT
> descr:  This maintainer may be used to create objects to represent
> descr:  routing policy in the RIPE Database for number resources
> not
> descr:  allocated or assigned from the RIPE NCC.
> admin-c:RD132-RIPE
> auth:   MD5-PW # Filtered
> remarks:***
> remarks:* The password for this object is 'RPSL', without the *
> remarks:* quotes. Do NOT use this maintainer as 'mnt-by'. *
> remarks:***
> mnt-by: RIPE-DBM-MNT
> referral-by:RIPE-DBM-MNT
> source: RIPE # Filtered

common practice for IP address announcement agreement if addresses belong to other ISP

[Martin T]

Hi,

as probably many of you know, it's possible to create a route object
to RIPE database for an address space which is allocated outside the
RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example
an address space is from APNIC or ARIN region and AS is from RIPE
region. However, what if customer, who has it's own AS number, wants
to buy IP transit from RIPE region ISP using addresses from APNIC
region and customer claims that owner of those addresses in APNIC
region allows him to do so? Common sense suggest that if one wants to
announce someone else address space, then they should inform the owner
of the address space and the owner of the address space needs to
agree. Is there a common practice how this agreement should look like?
A simple e-mail? A signed document, which is scanned and sent from
address space owner to ISP who wants to announce those addresses?


regards,
Martin

questions regarding prefix hijacking

[Martin T]

Hi,

as probably many of you know, it's possible to create a "route" object
to RIPE database for an address space which is allocated outside the
RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example
an address space is from APNIC or ARIN region and AS is from RIPE
region. For example a LIR in RIPE region creates a "route" object to
RIPE database for 157.166.266.0/24(used by Turner Broadcasting System)
prefix without having written permission from Turner Broadcasting
System and as this LIR uses up-link providers who create prefix
filters automatically according to RADb database entries, this ISP is
soon able to announce this 157.166.266.0/24 prefix to Internet. This
should disturb the availability of the real 157.166.266.0/24 network
on Internet? Has there been such situations in history? Isn't there a
method against such hijacking? Or have I misunderstood something and
this isn't possible?


regards,
Martin

Re: questions regarding prefix hijacking

[Martin T]

Ok. And such attacks have happened in the past? For example one could
do a pretty widespread damage for at least short period of time if it
announces for example some of the root DNS server prefixes(as long
prefixes as possible) to it's upstream provider and as upstream
provider probably prefers client traffic over it's peerings or
upstreams, it will prefer those routes by malicious ISP for all the
traffic to root DNS servers?


regards,
Martin

2013/8/7, Paul Ferguson :
> Unfortunately, it is way too easy for people to inject routes into the
> global routing system.
>
> I think most of the folks on the list can attest to that. :-)
>
> - ferg
>
>
> On Wed, Aug 7, 2013 at 1:20 AM, Martin T  wrote:
>
>> Hi,
>>
>> as probably many of you know, it's possible to create a "route" object
>> to RIPE database for an address space which is allocated outside the
>> RIPE region using the RIPE-NCC-RPSL-MNT maintainer object. For example
>> an address space is from APNIC or ARIN region and AS is from RIPE
>> region. For example a LIR in RIPE region creates a "route" object to
>> RIPE database for 157.166.266.0/24(used by Turner Broadcasting System)
>> prefix without having written permission from Turner Broadcasting
>> System and as this LIR uses up-link providers who create prefix
>> filters automatically according to RADb database entries, this ISP is
>> soon able to announce this 157.166.266.0/24 prefix to Internet. This
>> should disturb the availability of the real 157.166.266.0/24 network
>> on Internet? Has there been such situations in history? Isn't there a
>> method against such hijacking? Or have I misunderstood something and
>> this isn't possible?
>>
>>
>> regards,
>> Martin
>>
>
>
>
> --
> "Fergie", a.k.a. Paul Ferguson
>  fergdawgster(at)gmail.com
>

Re: questions regarding prefix hijacking

[Martin T]

Saku,


> In most cases upstream does not do any automatic prefix filter generation, 
> it's maybe somewhat popular in mid-sized european shops but generally not too 
> common.

What do you mean? In most cases upstreams do not filter prefixes at all?


> There is active on-going work to secure BGP and you may want to read up on 
> 'RPKI' which is further along that track.

Thanks for mentioning this! Very interesting effort. I validated some
routes in LIR portal, verified that those are validated using RIPE
rpki-validator tool and a Juniper router connected to validator:

r...@lr1.ham1.de> show validation session detail
Session 195.13.63.18, State: up, Session index: 2
  Group: eurotransit-testbed, Preference: 100
  Local IPv4 address: 193.34.50.25, Port: 8282
  Refresh time: 120s
  Hold time: 180s
  Record Life time: 3600s
  Serial (Full Update): 559
  Serial (Incremental Update): 559
Session flaps: 0
Session uptime: 00:11:35
Last PDU received: 00:00:27
IPv4 prefix count: 4921
IPv6 prefix count: 833

r...@lr1.ham1.de> show route protocol bgp 5.11.81.0

inet.0: 456407 destinations, 456408 routes (456407 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.11.81.0/24   *[BGP/170] 00:11:59, localpref 110, from 79.141.168.1
  AS path: 33926 25577 43532 I, validation-state: valid
> to 193.34.50.1 via em0.0

RPKI-valid.inet.0: 11440 destinations, 11440 routes (11440 active, 0
holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.11.81.0/24   *[BGP/170] 00:11:11, localpref 110, from 79.141.168.1
  AS path: 33926 25577 43532 I, validation-state: valid
> to 193.34.50.1 via em0.0

r...@lr1.ham1.de>



Massimiliano, Paul, Indra:

thanks for pointing out those interesting cases!



regards,
Martin

2013/8/8, Carlos Martinez-Cagnazzo :
> They do happen, but they get little publicity. People that I've talked to
> about this say, for reasons mostly unspecified, they'd rather not talk
> about it.
>
>
> On Wed, Aug 7, 2013 at 6:06 PM, Christopher Morrow
> wrote:
>
>> On Wed, Aug 7, 2013 at 4:59 PM, Marsh Ray  wrote:
>> >
>> > It would be incredibly useful for someone to start a page or a category
>> on Wikipedia "List of Internet Routing and DNS Incidents" that would
>> include both "accidental" and malicious events.
>> >
>>
>> do we really need that? they seem to occur often enough that that
>> isn't really required :(
>>
>>
>
>
> --
> --
> =
> Carlos M. Martinez-Cagnazzo
> h ttp://cagnazzo.me
> =
>

common method to count traffic volume on IX

[Martin T]

Hi,

many Internet exchange points post publicly available graphs which
describe aggregated traffic volumes on IX. For example:

Netnod: http://www.netnod.se/ix-stats/sums/
AMS-IX: https://www.ams-ix.net/technical/statistics
LINX: https://www.linx.net/pubtools/trafficstats.html


Is there a common method to count this traffic on a switch-fabric?
Just read all the switch interface "packets input" counters with an
interval to get the aggregated input traffic and read all the switch
interfaces "packets output" counters to get the aggregated output
traffic?


regards,
Martin

common checks performed when passing on an IPv4 PA allocation from one end-customer to another

[Martin T]

Hi,

when one end-customer has been using for example /24 IPv4 allocation
for a while and returns this(for example changes an ISP) to LIR, then
are there some good practices before handing out this same /24 to a
new customer? I guess LIR should:

1) remove all the DNS PTR records, classless of classful delegations
2) check if some of the IP addresses are in DNSBL(maybe the previous
customer was a spammer). Example with 93.184.216.0/24:

$ for ip in {0..255}.216.184.93;\
> do for addr in \
> cbl.abuseat.org \
> dnsbl.inps.de \
> no-more-funn.moensted.dk \
> dnsbl.sorbs.net \
> bl.spamcannibal.org \
> bl.spamcop.net \
> psbl.surriel.com \
> dnsrbl.swinog.ch; \
> do dig @8.8.8.8 "$ip"."$addr" +short | grep -q "^127.0.0." && \
> echo "DNSBL-Alarm: $ip is listed on $addr"; done; done
$


Anything else?


regards,
Martin

Re: common method to count traffic volume on IX

[Martin T]

Thanks for all the replies!


Nick,

counting traffic on inter-switch links is kind of cheating, isn't it?
I mean if "input bytes" and "output bytes" on all the ports facing the
IX members are already counted, then counting traffic on links between
the switches in fabric will count some of the traffic multiple times.



Patrick,

how does smaller sampling period help to show more traffic volume on
switch fabric? Or do you mean that in case of shorter sampling periods
the traffic peaks are not averaged out and thus peak in and peak out
traffic levels remain higher?


regards,
Martin

On 9/17/13, Nick Hilliard  wrote:
> On 17/09/2013 14:43, Patrick W. Gilmore wrote:
>> And yes, DE-CIX is more than well aware everyone thinks this is .. uh ..
>> let's just call it "silly" for now, although most would use far more
>> disparaging words. Which is probably why no serious IXP does it.
>
> It's not silly - it's just not what everyone else does, so it's not
> possible to directly compare stats with other ixps.  I'm all in favour of
> using short (but technically sensible) sampling intervals for internal
> monitoring, but there are good reasons to use 300s / ingress sum for
> prettypics intended for public consumption.
>
> Nick
>
>
>