Re: DHCPv6-PD relay route injection - standard?

[Radu-Adrian Feurdean]

On Wed, May 15, 2019, at 04:28, Brandon Martin wrote:
> Is there a standard that defines/recommends behavior for route injection 
> of snooped DHCPv6-PD (or IA, I guess) assignments on routers running 
> relay agents?  That is, snooping or otherwise examining a relayed DHCPv6 
> response for a delegated prefix (or IA, if you want) and installing a 
> quasi-static route toward the relevant next-hop based on the lifetime of 
> the delegation.  Typical redistribution can then be used to put it in 
> IGP if you want.

This feature is usually found packed with the BNG/BRAS/broadband termination 
functionality. The keyword you need to search is "subscriber". The feaure pack 
is usually subject to additional licensing. Cisco, Juniper, Nokia/ALU, all have 
product ranges supporting that.

Those being said, I'm interested in how that feature is supported on gear that 
is not "subscriber-aware" (you were talking about Arista), since generating 
routing information from relayed DHCP(v6) is a big/important part of the 
"subscriber management" functionality.

--
R-A.F.

Re: Free Program to take netflow

[Hugo Slabbert]

Also was a favourite last time this discussion popped up (in recent 
memory):


https://mailman.nanog.org/pipermail/nanog/2018-March/094490.html

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

On Fri 2019-May-17 21:19:02 -0700, Crist Clark  wrote:


Been loving Elastiflow. Way overkill for what you need, but it's
actually pretty easy to setup.

https://github.com/robcowart/elastiflow


On Fri, May 17, 2019 at 7:25 AM Dennis Burgess via NANOG
 wrote:


I am looking for a free program to take netflow and output what the top traffic 
ASes to and from my AS are.   Something that we can look at every once in a 
while, and/or spin up and get data then shutdown..  Just have two ports need 
netflow from currently.



Thanks in advance.





Dennis Burgess, Mikrotik Certified Trainer

Author of "Learn RouterOS- Second Edition”

Link Technologies, Inc -- Mikrotik & WISP Support Services

Office: 314-735-0270  Website: http://www.linktechs.net

Create Wireless Coverage’s with www.towercoverage.com




signature.asc
Description: Digital signature

Re: Free Program to take netflow

[Crist Clark]

Been loving Elastiflow. Way overkill for what you need, but it's
actually pretty easy to setup.

https://github.com/robcowart/elastiflow


On Fri, May 17, 2019 at 7:25 AM Dennis Burgess via NANOG
 wrote:
>
> I am looking for a free program to take netflow and output what the top 
> traffic ASes to and from my AS are.   Something that we can look at every 
> once in a while, and/or spin up and get data then shutdown..  Just have two 
> ports need netflow from currently.
>
>
>
> Thanks in advance.
>
>
>
>
>
> Dennis Burgess, Mikrotik Certified Trainer
>
> Author of "Learn RouterOS- Second Edition”
>
> Link Technologies, Inc -- Mikrotik & WISP Support Services
>
> Office: 314-735-0270  Website: http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
>

Re: DHCPv6-PD relay route injection - standard?

[Brandon Martin]

On 5/17/19 2:41 PM, Tim Howe wrote:

I'm curious if you got any off-list replies of interest.


Unfortunately no.  Only inquiry I got was one related to support for it 
in Arista EOS which unfortunately I can't speak well toward since I 
don't have Arista gear.  For those keeping tabs at home, though, I think 
the feature appeared in EOS 4.20.1f.


Sounds like this may be an area that could use some standardization or 
best practice documentation even if it's basically just to condense 
existing practice into something concrete.

--
Brandon Martin

Re: BGP prefix filter list

[Blake Hudson]

I would argue that one can generally safely add information to his
or her router's RIB (such as adding a local preference, weight, or
advertising with prepends to direct traffic toward a better
performing, less utilized, or lower cost peer), but that removing
information from a router's RIB always comes at some cost (and
some may find this cost perfectly acceptable).


One needs to remember that removing information from RIB is how BGP 
works. If you have the common setup of two BGP edge routers, each with 
a directly connected transit provider link, the routers will only tell 
the other one about the routes it actually uses. Neither router has a 
complete view.



I manage a network like you describe: Two BGP edge routers, both routers 
accept a full eBGP feed from transit, both share routing information via 
iBGP. Both edge routers in my network have a complete view. If one 
transit provider is down or there is an upstream peering change, both 
still have a complete view. The only time they wouldn't have a complete 
view is during convergence or when there is a simultaneous outage of 
both transit providers at different physical facilities.


I could certainly use a default route (configured statically or received 
via BGP) instead, but that reduces my network's ability to make informed 
decisions. When one of my upstream transit providers is performing 
maintenance and loses a peer, I want that to be reflected in my routing 
so that traffic can be directed via the shortest path. When my transit 
provider's edge router loses upstream connectivity, but maintains 
connectivity to my equipment, I want that reflected in my routing so 
that traffic doesn't go towards the path that leads to the bit bucket. I 
can't detect those conditions and route around them if my router only 
has a default route.

Re: DHCPv6-PD relay route injection - standard?

[Ross Tajvar]

On Fri, May 17, 2019 at 2:44 PM Tim Howe  wrote:

> Getting native dual-stack fully working
> has been a long, strange road as a small ISP.  I'm thinking about
> writing something up about my experience so far.
>


I would definitely read that.

Re: BGP prefix filter list

[Baldur Norddahl]

On Fri, May 17, 2019 at 9:44 PM Blake Hudson  wrote:

> Baldur, I believe most routing platforms already make use of clever
> shortcuts or techniques to reduce their FIB usage, but I don't think anyone
> has found a good, reliable method of reducing their RIB at zero cost. For
> example, what happens in your above configuration when your
> "better/default" transit provider is down due to maintenance or outage and
> your equipment continues to use its default route to direct traffic that
> direction?
>

You will of course have two default routes, one to each transit provider.
Using route priorities to program which one is actually used. If that link
goes down, that default becomes invalid and the router will use the other
one. A more advanced setup can use triggers, such as ping, bfd or BGP, to
mark the route as valid or invalid.



> What happens if the transit provider that you normally only retain the
> best paths for becomes the best path for all destinations (for example if
> your connection to the better/default transit provider is down for
> maintenance or there is an upsteam peering change) and your router that
> normally only has a few thousand routes in RIB suddenly gets tasked with a
> 768k-1M route RIB?
>

I am not sure I am following that question. Nothing happens, you will have
a default plus a bunch of redundant routes, but not any more than you had
before the primary transit went down.


>
> I would argue that one can generally safely add information to his or her
> router's RIB (such as adding a local preference, weight, or advertising
> with prepends to direct traffic toward a better performing, less utilized,
> or lower cost peer), but that removing information from a router's RIB
> always comes at some cost (and some may find this cost perfectly
> acceptable).
>
>
One needs to remember that removing information from RIB is how BGP works.
If you have the common setup of two BGP edge routers, each with a directly
connected transit provider link, the routers will only tell the other one
about the routes it actually uses. Neither router has a complete view.

Regards,

Baldur

Re: BGP prefix filter list

[Blake Hudson]

Baldur Norddahl wrote on 5/17/2019 11:05 AM:



On Fri, May 17, 2019 at 3:28 PM Blake Hudson > wrote:


 From my perspective one's ability to intelligently route IP
traffic is
directly correlated to the data they have available (their routing
protocol and table)


One point perhaps being missed by some is that routing decisions are 
not always best made in the very last moment when you have a packet 
and need to decide on the destination. The culling of routing table I 
wanted to do is on a full feed from my upstream providers. I am not 
taking a default, but I may add a default manually.


Think about this way to save at least half the size of the FIB with 
two transit providers: Find out which provider has the most prefixes 
going their way. Make a default to them and a route-map that drops 
every route. For the other provider, keep only the routes where they 
have better routing. This way you only use FIB space for the smaller 
provider. Everything else goes by default through the larger provider.


Now doing that in practice is hard because router vendors did 
generally not make route-map or similar constructs flexible enough for 
the needed logic.


But we can do other things, some of which have already been proposed 
in this thread. Like before have a default to the "best" of your 
transit providers and using culling to drop routes. Are we not all 
doing something like that already, with route maps to give some routes 
higher priority instead of always going strict shortest AS-path? Only 
difference is that you can fully drop the routes from FIB if you 
install defaults to handle it instead.


Or what if I know that one of my transit providers are really good 
with Asia? I just want traffic to Asia by default go to them. I can 
install my own covering routes from the APNIC address space and then 
save a ton of FIB space by dropping routes within that space. I can 
have exceptions if needed.


The above does not give you poorer routing decisions and may give you 
better.


Regards,

Baldur



Baldur, I believe most routing platforms already make use of clever 
shortcuts or techniques to reduce their FIB usage, but I don't think 
anyone has found a good, reliable method of reducing their RIB at zero 
cost. For example, what happens in your above configuration when your 
"better/default" transit provider is down due to maintenance or outage 
and your equipment continues to use its default route to direct traffic 
that direction? What happens if the transit provider that you normally 
only retain the best paths for becomes the best path for all 
destinations (for example if your connection to the better/default 
transit provider is down for maintenance or there is an upsteam peering 
change) and your router that normally only has a few thousand routes in 
RIB suddenly gets tasked with a 768k-1M route RIB?


I would argue that one can generally safely add information to his or 
her router's RIB (such as adding a local preference, weight, or 
advertising with prepends to direct traffic toward a better performing, 
less utilized, or lower cost peer), but that removing information from a 
router's RIB always comes at some cost (and some may find this cost 
perfectly acceptable).

Re: DHCPv6-PD relay route injection - standard?

[Tim Howe]

On Tue, 14 May 2019 22:27:09 -0400
Brandon Martin  wrote:

> Is there a standard that defines/recommends behavior for route injection 
> of snooped DHCPv6-PD (or IA, I guess) assignments on routers running 
> relay agents?  That is, snooping or otherwise examining a relayed DHCPv6 
> response for a delegated prefix (or IA, if you want) and installing a 
> quasi-static route toward the relevant next-hop based on the lifetime of 
> the delegation.  Typical redistribution can then be used to put it in 
> IGP if you want.
> 
> It seems to be a common feature - Cisco ("Relay Agent Notification" on 
> IOS-XE), Juniper ("DHCPv6-PD Route injection" on JunOS), and Arista 
> ("ipv6 dhcp relay install routes" on EOS), and Ruckus ("Relay Agent 
> Prefix Delegation Notification" on FastIron) all seem to support it.
> 
> Google has, however, failed me at finding any standard that defines or 
> recommends corresponding behavior.  RFC 8415 punts on the issue:


I went through that same search a little over a year ago.  I'm
curious if you got any off-list replies of interest.  We use dhcpv6
relay on Juniper ACX5048 (should be same on MX series).  It did not
work out of the box for me; Juniper had to fix a fundamental way it
worked in order to work with some clients (pretty much anything
Broadcom based at least).  I'm running working code now (17.4R2.4).  I
was very pleased Juniper took the problem so seriously and fixed it...
That hasn't been my experience with every vendor.

I can provide some info about how it works and what "working"
looks like if you are curious.  Getting native dual-stack fully working
has been a long, strange road as a small ISP.  I'm thinking about
writing something up about my experience so far.

--TimH

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 18 May, 2019

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  754540
Prefixes after maximum aggregation (per Origin AS):  289575
Deaggregation factor:  2.61
Unique aggregates announced (without unneeded subnets):  360661
Total ASes present in the Internet Routing Table: 64226
Prefixes per ASN: 11.75
Origin-only ASes present in the Internet Routing Table:   55252
Origin ASes announcing only one prefix:   23799
Transit ASes present in the Internet Routing Table:8974
Transit-only ASes present in the Internet Routing Table:266
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  34
Max AS path prepend of ASN (  8697)  27
Prefixes from unregistered ASNs in the Routing Table:26
Number of instances of unregistered ASNs:30
Number of 32-bit ASNs allocated by the RIRs:  27012
Number of 32-bit ASNs visible in the Routing Table:   22035
Prefixes from 32-bit ASNs in the Routing Table:   98302
Number of bogon 32-bit ASNs visible in the Routing Table:23
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:243
Number of addresses announced to Internet:   2850395904
Equivalent to 169 /8s, 229 /16s and 151 /24s
Percentage of available address space announced:   77.0
Percentage of allocated address space announced:   77.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.2
Total number of prefixes smaller than registry allocations:  252512

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   203617
Total APNIC prefixes after maximum aggregation:   60182
APNIC Deaggregation factor:3.38
Prefixes being announced from the APNIC address blocks:  199801
Unique aggregates announced from the APNIC address blocks:82445
APNIC Region origin ASes present in the Internet Routing Table:9758
APNIC Prefixes per ASN:   20.48
APNIC Region origin ASes announcing only one prefix:   2719
APNIC Region transit ASes present in the Internet Routing Table:   1455
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4745
Number of APNIC addresses announced to Internet:  773674496
Equivalent to 46 /8s, 29 /16s and 86 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-139577
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:225014
Total ARIN prefixes after maximum aggregation:   104849
ARIN Deaggregation factor: 2.15
Prefixes being announced from the ARIN address blocks:   224054
Unique aggregates announced from the ARIN address blocks:105452
ARIN Region origin ASes present in the Internet Routing Table:18470
ARIN Prefixes per ASN:12.13
ARIN Regio

Re: BGP prefix filter list

[Baldur Norddahl]

On Fri, May 17, 2019 at 3:28 PM Blake Hudson  wrote:

>  From my perspective one's ability to intelligently route IP traffic is
> directly correlated to the data they have available (their routing
> protocol and table)
>

One point perhaps being missed by some is that routing decisions are not
always best made in the very last moment when you have a packet and need to
decide on the destination. The culling of routing table I wanted to do is
on a full feed from my upstream providers. I am not taking a default, but I
may add a default manually.

Think about this way to save at least half the size of the FIB with two
transit providers: Find out which provider has the most prefixes going
their way. Make a default to them and a route-map that drops every route.
For the other provider, keep only the routes where they have better
routing. This way you only use FIB space for the smaller provider.
Everything else goes by default through the larger provider.

Now doing that in practice is hard because router vendors did generally not
make route-map or similar constructs flexible enough for the needed logic.

But we can do other things, some of which have already been proposed in
this thread. Like before have a default to the "best" of your transit
providers and using culling to drop routes. Are we not all doing something
like that already, with route maps to give some routes higher priority
instead of always going strict shortest AS-path? Only difference is that
you can fully drop the routes from FIB if you install defaults to handle it
instead.

Or what if I know that one of my transit providers are really good with
Asia? I just want traffic to Asia by default go to them. I can install my
own covering routes from the APNIC address space and then save a ton of FIB
space by dropping routes within that space. I can have exceptions if needed.

The above does not give you poorer routing decisions and may give you
better.

Regards,

Baldur

Re: Free Program to take netflow

[Niels Bakker]

* nanog@nanog.org (Dennis Burgess via NANOG) [Fri 17 May 2019, 16:25 CEST]:
I am looking for a free program to take netflow and output what the  
top traffic ASes to and from my AS are.  Something that we can look  
at every once in a while, and/or spin up and get data then  
shutdown..  Just have two ports need netflow from currently.


It sounds like 
https://blog.apnic.net/2017/01/26/traffic-analysis-better-peering/ 
would be right up your alley.



-- Niels.

Re: BGP prefix filter list

[Karsten Elfenbein]

Can you check the actual FIB usage? With 2m IPv4 divided into v4 and v6 *
Fast ReRoute could hit the limit.

Baldur Norddahl  schrieb am Mi., 15. Mai 2019,
20:24:

> Hello
>
> On Wed, May 15, 2019 at 3:56 PM Mike Hammett  wrote:
>
>> What is the most common platform people are using with such limitations?
>> How long ago was it deprecated?
>>
>>
>>
> We are a small network with approx 10k customers and two core routers. The
> routers are advertised as 2 million FIB and 10 million RIB.
>
> This morning at about 2 AM CET our iBGP session between the two core
> routers started flapping every 5 minutes. This is how long it takes to
> exchange the full table between the routers. The eBGP sessions to our
> transits were stable and never went down.
>
> The iBGP session is a MPLS multiprotocol BGP session that exhanges IPv4,
> IPv6 and VRF in a single session.
>
> We are working closely together with another ISP that have the same
> routers. His network went down as well.
>
> Nothing would help until I culled the majority of the IPv6 routes by
> installing a default IPv6 route together with a filter, that drops every
> IPv6 route received on our transits. After that I could not make any more
> experimentation. Need to have a maintenance window during the night.
>
> These routers have shared IPv4 and IPv6 memory space. My theory is that
> the combined prefix numbers is causing the problem. But it could also be
> some IPv6 prefix first seen this night, that triggers a bug. Or something
> else.
>
> Regards,
>
> Baldur
>
>
>

Re: BGP prefix filter list

[Blake Hudson]

Radu-Adrian Feurdean wrote on 5/17/2019 9:15 AM:

On Fri, May 17, 2019, at 15:28, Blake Hudson wrote:


  From my perspective one's ability to intelligently route IP traffic is
directly correlated to the data they have available (their routing
protocol and table). For example, with static default routes one can

For me, routing table and available routing protocols are not the only things needed for 
intelligent routing. And the router is not the only component involved in 
"intelligent routing". Not these days/not anymore.

One thing that can help immensely in an internet environment is knowing where the data 
goes and where it comes from. Knowing your "important" traffic 
source/destinations is part of it.

You can say "I can no longer keep all the routes in FIB, so I'll drop the 
/24s", then come to a conclusion that that you have loads of traffic towards an 
anycast node located in a /24 or that you exchange voice with a VoIP provider that 
announces /24. you just lost the ability to do something proper with your important 
destination. On the other hand, you may easily leave via default (in extreme cases even 
drop) traffic to several /16s from Mulgazanzar Telecom which which you barely exchange a 
few packets per day except the quarterly wave of DDoS/spam/scans/[name your favorite 
abuse]. Or you may just drop a few hundred more-specific routes for a destination that 
you do care about, but you cannot do much because network-wise it is too far away.

Of course, such an approach involves human intervention, either for selecting the 
important and non-important destinations or for writing the code that does it 
automagically. Or both. There is no magic potion. (as a friday afternoon remark, there 
used to be such a potion in France, the "green powder", but they permanently 
ran out of stock in 2004 - see http://poudreverte.org/ - site in fr_FR).



Radu, you're absolutely correct that BGP does not include the metrics 
often needed to make the best routing decisions. I mentioned metrics 
like bandwidth, delay, and loss (which some other routing protocols do 
consider); and you mentioned metrics like importance (I assume for 
business continuity or happy eyeballs) or the amount or frequency of 
data exchanged with a given remote AS/IP network. BGP addresses some 
problems (namely routing redundancy), but it has some intentional 
shortcomings when choosing the cheapest path, best performing path, or 
load balancing (not to mention its security shortcomings). Some folks 
choose to improve upon BGP by using BGP "optimizers", manual local pref 
adjustments, or similar configurations. And as this discussion has 
shown, other folks choose to introduce their own additional shortcomings 
by ignoring part of what BGP does have to offer. Perhaps in the future 
we will be able to agree on a replacement to (or improvements upon) BGP 
that addresses some of these shortcomings; we may also find that 
technology solves the limitations that currently force some folks to 
discard potentially valuable routing information.

Re: Free Program to take netflow

[Denys Fedoryshchenko]

Fastnetmon have that: 
https://fastnetmon.com/fastnetmon-advanced-traffic-persistency/

I used it for such purposes.

On 2019-05-17 17:26, Dennis Burgess via NANOG wrote:

I am looking for a free program to take netflow and output what the
top traffic ASes to and from my AS are.   Something that we can look
at every once in a while, and/or spin up and get data then shutdown..
Just have two ports need netflow from currently.

Thanks in advance.

DENNIS BURGESS, MIKROTIK CERTIFIED TRAINER

Author of "Learn RouterOS- Second Edition"

LINK TECHNOLOGIES, INC -- Mikrotik & WISP Support Services

OFFICE: 314-735-0270  Website: http://www.linktechs.net [1]

Create Wireless Coverage's with www.towercoverage.com [2]



Links:
--
[1] http://www.linktechs.net/
[2] http://germany.nuclearcat.com/www.towercoverage.com

Free Program to take netflow

[Dennis Burgess via NANOG]

I am looking for a free program to take netflow and output what the top traffic 
ASes to and from my AS are.   Something that we can look at every once in a 
while, and/or spin up and get data then shutdown..  Just have two ports need 
netflow from currently.

Thanks in advance.


[LTI-Full_175px]
Dennis Burgess, Mikrotik Certified Trainer
Author of "Learn RouterOS- Second Edition"
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270  Website: 
http://www.linktechs.net
Create Wireless Coverage's with www.towercoverage.com

Re: BGP prefix filter list / BGP hijacks, different type

[Christopher Morrow]

Did this get resolved? if not please email me directly.

On Fri, May 17, 2019 at 9:46 AM Denys Fedoryshchenko
 wrote:
>
> I wanted to mention one additional important point in all these
> monitoring discussion.
> Right now, for one of my subnets Google services stopped working.
> Why? Because it seems like someone from Russia did BGP hijack, BUT,
> exclusively for google services (most likely some kind of peering).
> Quite by chance, I noticed that the traceroute from the google cloud to
> this subnet goes through Russia, although my country has nothing to do
> with Russia at all, not even transit traffic through them.
> Sure i mailed noc@google, but reaching someone in big companies is not
> easiest job, you need to search for some contact that answers. And good
> luck for realtime communications.
> And, all large CDNs have their own "internet", although they have BGP,
> they often interpret it in their own way, which no one but them can
> monitor and keep history. No looking glass for sure, as well.
> If your network is announced by a malicious party from another country,
> you will not even know about it, but your requests(actually answers from
> service) will go through this party.

Re: BGP prefix filter list

[Radu-Adrian Feurdean]

On Fri, May 17, 2019, at 15:28, Blake Hudson wrote:

>  From my perspective one's ability to intelligently route IP traffic is 
> directly correlated to the data they have available (their routing 
> protocol and table). For example, with static default routes one can 

For me, routing table and available routing protocols are not the only things 
needed for intelligent routing. And the router is not the only component 
involved in "intelligent routing". Not these days/not anymore.

One thing that can help immensely in an internet environment is knowing where 
the data goes and where it comes from. Knowing your "important" traffic 
source/destinations is part of it.

You can say "I can no longer keep all the routes in FIB, so I'll drop the 
/24s", then come to a conclusion that that you have loads of traffic towards an 
anycast node located in a /24 or that you exchange voice with a VoIP provider 
that announces /24. you just lost the ability to do something proper with your 
important destination. On the other hand, you may easily leave via default (in 
extreme cases even drop) traffic to several /16s from Mulgazanzar Telecom which 
which you barely exchange a few packets per day except the quarterly wave of 
DDoS/spam/scans/[name your favorite abuse]. Or you may just drop a few hundred 
more-specific routes for a destination that you do care about, but you cannot 
do much because network-wise it is too far away.

Of course, such an approach involves human intervention, either for selecting 
the important and non-important destinations or for writing the code that does 
it automagically. Or both. There is no magic potion. (as a friday afternoon 
remark, there used to be such a potion in France, the "green powder", but they 
permanently ran out of stock in 2004 - see http://poudreverte.org/ - site in 
fr_FR).

Re: BGP prefix filter list / BGP hijacks, different type

[Denys Fedoryshchenko]

I wanted to mention one additional important point in all these 
monitoring discussion.

Right now, for one of my subnets Google services stopped working.
Why? Because it seems like someone from Russia did BGP hijack, BUT, 
exclusively for google services (most likely some kind of peering).
Quite by chance, I noticed that the traceroute from the google cloud to 
this subnet goes through Russia, although my country has nothing to do 
with Russia at all, not even transit traffic through them.
Sure i mailed noc@google, but reaching someone in big companies is not 
easiest job, you need to search for some contact that answers. And good 
luck for realtime communications.
And, all large CDNs have their own "internet", although they have BGP, 
they often interpret it in their own way, which no one but them can 
monitor and keep history. No looking glass for sure, as well.
If your network is announced by a malicious party from another country, 
you will not even know about it, but your requests(actually answers from 
service) will go through this party.

Re: BGP prefix filter list

[Blake Hudson]

Radu-Adrian Feurdean wrote on 5/17/2019 5:10 AM:

On Thu, May 16, 2019, at 16:38, Blake Hudson wrote:

offloading that responsibility onto the transit provider. IMHO, what's
the point of being multi-homed if you can't make intelligent routing
decisions and provide routing redundancy in the case of a transit
provider outage?

Speaking of "intelligent routing", this is why doing some targeting on what you 
filter by some criteria other than prefix or as-path length is a good idea. Either 
manually every once in a while (just make sure that you at least check the situation 
every few weeks), or in an automated manner (better). You just need more data (usually 
*flow/ipfix based) in order to be able to take the good decisions.

You can use traffic levels (or better - lack of traffic), traffic criticality 
(?!?! cirticity ?!?!) and prefix count saving as criteria.

--
R-A.F.


From my perspective one's ability to intelligently route IP traffic is 
directly correlated to the data they have available (their routing 
protocol and table). For example, with static default routes one can 
only make the simplest of routing decisions; with dynamic default routes 
one can make more informed decisions; with a partial view of the 
internet one can make even better decisions; with a full view of the 
internet one can make good decisions; and with a routing protocol that 
takes into account bandwidth, latency, loss, or other metrics one can 
make the very best decisions.


Determining how intelligent one wants his or her decisions to be, and 
how much he or she is willing to spend to get there, is an exercise for 
the reader. Not all routers need a full view of the internet, but some 
do. The cost of routers that hold a full routing table in FIB is 
generally more than those that do not, but overall is not cost 
prohibitive (in my opinion) for the folks that are already paying to be 
multihomed. Single homed networks (or those with a single transit 
provider and additional peers), probably won't benefit from holding more 
than a default route to their transit provider and therefore may be able 
to get by with a less capable router. Each network is different and the 
choices driven by the needs for redundancy, availability, performance, 
and cost will come out differently as well.

Any current comments on PacketViper?

[Allen McKinley Kitchen (gmail)]

Users? Detractors? Off-list responses preferred. Will summarize if there’s an 
indication of interest.

..Allen
allen.mckinley.kitc...@gmail.com
Butler, PA

Re: BGP prefix filter list

[Radu-Adrian Feurdean]

On Thu, May 16, 2019, at 16:38, Blake Hudson wrote:
> offloading that responsibility onto the transit provider. IMHO, what's 
> the point of being multi-homed if you can't make intelligent routing 
> decisions and provide routing redundancy in the case of a transit 
> provider outage?

Speaking of "intelligent routing", this is why doing some targeting on what you 
filter by some criteria other than prefix or as-path length is a good idea. 
Either manually every once in a while (just make sure that you at least check 
the situation every few weeks), or in an automated manner (better). You just 
need more data (usually *flow/ipfix based) in order to be able to take the good 
decisions.

You can use traffic levels (or better - lack of traffic), traffic criticality 
(?!?! cirticity ?!?!) and prefix count saving as criteria.

--
R-A.F. 

Re: BGP prefix filter list

[Jörg Kost]

Hi,

I did this tool a few years ago to download and built ASN filter lists 
by region automatically:


https://github.com/ipcjk/asnbuilder/releases

The tricky part was to build regular expressions for devices, that don't 
understand number ranges.


For some of our routers we (un)select ASNs manually by reading and 
comparing CIDR-reports to current Sflow traffic:


E.g.
https://github.com/ipcjk/asnbuilder/blob/master/customASN.txt
will become
https://github.com/ipcjk/asnbuilder/blob/master/saveTheFIB.txt

Jörg


On 17 May 2019, at 10:59, Jared Brown wrote:

There are a few approaches to culling the routing table. You can do it 
either statically or dynamically, according to your needs.


1. Filtering based on upstream communities

Slimming down the Internet routing table
https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html


2. Filtering based on region

BGP filter for North American routes
http://gregsowell.com/?p=5505

Substitute prefixes for applicable region(s). Each region is about 
200k prefixes. For more granularity use a geolocation service to 
select prefixes and/or ASNs.



3. Using flow information to install only top routes

SDN Internet Router – Part 2
https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/
https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html


4. Aggregate the routing table

According to the weekly routing table report you can aggregate 
announcements to about half the number of prefixes. You need to roll 
your own software to preprocess the BGP feed. There are some tools out 
there, but I couldn't find a blog post about it with a quick search. 
If you have one, please share!




Jared

Re: BGP prefix filter list

[Jared Brown]

There are a few approaches to culling the routing table. You can do it either 
statically or dynamically, according to your needs.

1. Filtering based on upstream communities
   
Slimming down the Internet routing table
https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html


2. Filtering based on region

BGP filter for North American routes
http://gregsowell.com/?p=5505

Substitute prefixes for applicable region(s). Each region is about 200k 
prefixes. For more granularity use a geolocation service to select prefixes 
and/or ASNs.


3. Using flow information to install only top routes

SDN Internet Router – Part 2
https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/
https://blog.ipspace.net/2015/01/sdn-router-spotify-on-software-gone-wild.html


4. Aggregate the routing table

According to the weekly routing table report you can aggregate announcements to 
about half the number of prefixes. You need to roll your own software to 
preprocess the BGP feed. There are some tools out there, but I couldn't find a 
blog post about it with a quick search. If you have one, please share!



Jared

On 05/15/19 13:43 +0200, Baldur Norddahl wrote:
>Hello
>
>This morning we apparently had a problem with our routers not handling 
>the full table. So I am looking into culling the least useful prefixes 
>from our tables. I can hardly be the first one to take on that kind of 
>project, and I am wondering if there is a ready made prefix list or 
>similar?
>
>Or maybe we have a list of worst offenders? I am looking for ASN that 
>announces a lot of unnecessary /24 prefixes and which happens to be 
>far away from us? I would filter those to something like /20 and then 
>just have a default route to catch all.
>
>Thanks,
>
>Baldur
>