My Posts
Bogon filtering using BGP bogon route servers
Currently we are blocking bogon advertisements
by using a prefix-list which we are updating manually. The problem with
this approach is that whenever an address block is delegated by IANA to a RIR this list has to be updated manually. According to Team Cymru there is an easy fix for this problem and that's peering with there bogon route server.
In theory this looks like a nice solution to the problem, a centralized organ making sure the lists are up-to-date and spreaded to connected participants within a minute. However I was thinking about this today and there is a tiny glitch. And that is "what about more-specifics?". The bogon route server project makes sure you don't get another route matching the exact prefix, but a more-specific route will be accepted by your bgp process and nicely inserted in your routing table. So it looks like this approach only has very very little effect.
Some people use the argument that with the route set in your routing table packets destined for these locations will be blackholed, however in the DFZ you will never have these routes for starters so they already will be blackholed. And if they do appear they'll be routed to that destination, but that will also occur if we use the cymru bogon server (but only in the situation where this means more-specific routes).
The case that a more-specific bogon is announced is more common then that an entire /8 network is announced, so I think the bogon server is absolutely no solution for this problem, unless they are going to announce it in de-aggregates of say /27 it has some effect. (more)
In theory this looks like a nice solution to the problem, a centralized organ making sure the lists are up-to-date and spreaded to connected participants within a minute. However I was thinking about this today and there is a tiny glitch. And that is "what about more-specifics?". The bogon route server project makes sure you don't get another route matching the exact prefix, but a more-specific route will be accepted by your bgp process and nicely inserted in your routing table. So it looks like this approach only has very very little effect.
Some people use the argument that with the route set in your routing table packets destined for these locations will be blackholed, however in the DFZ you will never have these routes for starters so they already will be blackholed. And if they do appear they'll be routed to that destination, but that will also occur if we use the cymru bogon server (but only in the situation where this means more-specific routes).
The case that a more-specific bogon is announced is more common then that an entire /8 network is announced, so I think the bogon server is absolutely no solution for this problem, unless they are going to announce it in de-aggregates of say /27 it has some effect. (more)

Foundry Patch for Version6.net's LG
I just whipped up a patch for the version6.net's looking glass. to support foundry routers. It's currently being used in production at Unilogic Networks (AS28788). The patch can be found here.
The main problem was the inability to turn off the pager function on a foundry router in usermode. It is possible in enable mode, but hey we don't want our looking glass to login with full privileges now do we. So I added an extra check that checks for the pager and sends a space out. The problem is that my knowledge of Net::Telnet is very basic and I had no real clue on how to fix this nicely. So the timeout on waitfor has been set to 1 second to speed up this process. Another bug in the software is the newline it shows after every occurence of the pager.
Anybody that can or will fix this is welcome to do so and supply a patch to this patch. This patch has also been sent to the maintaner of version6.net's LG, so hopefully it will be in the next release.
The main problem was the inability to turn off the pager function on a foundry router in usermode. It is possible in enable mode, but hey we don't want our looking glass to login with full privileges now do we. So I added an extra check that checks for the pager and sends a space out. The problem is that my knowledge of Net::Telnet is very basic and I had no real clue on how to fix this nicely. So the timeout on waitfor has been set to 1 second to speed up this process. Another bug in the software is the newline it shows after every occurence of the pager.
Anybody that can or will fix this is welcome to do so and supply a patch to this patch. This patch has also been sent to the maintaner of version6.net's LG, so hopefully it will be in the next release.


Calendar
Personal
Recent Comments
Archives
Statistics
Links
default -