In efforts to further protect us against threats I am considering
establishing Bogon peers to enable me to filter unallocated address
space. I am just wondering if this is a worthwhile step to take and if
anyone has ran into any issues or points of concern that I may want to
take into account. Thanks in advance for any input.
Thomas Magill
Network Engineer
Office: (858) 909-3777
Cell: (858) 869-9685
mailto:tmagill@providecommerce.com
provide-commerce
4840 Eastgate Mall
San Diego, CA 92121
ProFlowers <http://www.proflowers.com/> | redENVELOPE
<http://www.redenvelope.com/> | Cherry Moon Farms
<http://www.cherrymoonfarms.com/> | Shari's Berries
<http://www.berries.com/>
I've been doing this for some time on two routers injecting the null routes
into my AS. No issues. Beats the heck out of trying to use ACLs. However,
the prefix count is rapidly diminishing as more blocks are being released by
the various RIRs hence being pulled from the bogon list.
-b
Thomas Magill wrote:
In efforts to further protect us against threats I am considering
establishing Bogon peers to enable me to filter unallocated address
space. I am just wondering if this is a worthwhile step to take and if
anyone has ran into any issues or points of concern that I may want to
take into account. Thanks in advance for any input.
I've used the service for a couple of years, and I find it works
wonderfully. Newly distributed IANA blocks are removed promptly, so no
need to worry about that.
I peer with Cymru on my RTBH trigger boxes, which then redistribute the
list to all edge gear which blackholes it (dest and source) thanks to uRPF.
No manual config or rule manipulation.
Steve
I agree - quick setup and no issues. A++ Would Peer Again
-Jack Carrozzo
Thanks to everyone who replied. That settles it! I'm going to do it.
Hello All ,
In efforts to further protect us against threats I am considering
establishing Bogon peers to enable me to filter unallocated address
space. I am just wondering if this is a worthwhile step to take and if
anyone has ran into any issues or points of concern that I may want to
take into account. Thanks in advance for any input.
Thomas Magill
Network Engineer
Office: (858) 909-3777
Cell: (858) 869-9685
mailto:tmagill@providecommerce.com
provide-commerce
4840 Eastgate Mall
San Diego, CA 92121
I've been doing this for some time on two routers injecting the null routes
into my AS. No issues. Beats the heck out of trying to use ACLs. However,
the prefix count is rapidly diminishing as more blocks are being released by
the various RIRs hence being pulled from the bogon list.
-b
I've a question for the CYMRU Team , My reasoning for posting here is to get a much wide knowledge base .
Does or Is the 'Bogon Peering' Product(?) , Only at the IANA->RIR allocations level ? F.E.: IANA has allocated 1.0.0.0/8 to RIPE .
Or
Does the product also include the actual remaining non-allocated space at the RIR->EU level ? (**) F.E: RIPE has allocated 1.0.1.0/24 to anubusstupidity, inc.
Tia , JimL
ps: I am Very well aware that (so far) there is no standard format for returned requests from *whois daemons .
Current list of prefixes Cymru considers bogon:
http://www.cymru.com/Documents/bogon-bn-nonagg.txt
Does that answer the question?
-Jack Carrozzo
Jim & All,
The current bogon reference projects we have available only include the
first of your examples - netblocks which have not been allocated by IANA
to an RIR. However, we are currently in a beta testing phase of a
similar feed which also includes netblocks that have not yet been
allocated or assigned by the RIRs. We will also be offering the same
type of bogon feed for IPv6, something we've been asked about quite a
bit recently!
We will be releasing more information about this service once it is
ready for a wider audience. You can keep an eye on a number of places
for this type of announcement:
* Our web site, http://www.team-cymru.org/
* Our announcements mailing list, subscribe via
cymru-announce-subscribe@cymru.com
* Our Twitter feed, http://twitter.com/teamcymru
* Our weekly YouTube show, http://www.youtube.com/teamcymru
Thanks to all for your interest and feedback - we're glad to hear that
you are finding the bogon references useful in your networks!
Best Regards,
Tim Wilde
- --
Tim Wilde, Senior Software Engineer, Team Cymru, Inc.
twilde@cymru.com | +1-630-230-5433 | http://www.team-cymru.org/
While I have your attention, I've noticed there's been a bit of
instability lately with the BGP sessions (in fact one of mine right now
is down). With 30 routes it's not a big deal to have frequent churn, but
if you're going to expand that to a larger feed then it could become a
problem.
~Seth
eh, what are you talking about?
If you want to prefix-filter your bgp feeds using RPSL objects, you can
pull the "fltr-bogons" object from RADB or the RIPE IRRDB (which both
return objects in a standard format).
Nick
Seth Mattinen wrote:
I've a question for the CYMRU Team , My reasoning for posting here
is to get a much wide knowledge base .
Does or Is the 'Bogon Peering' Product(?) , Only at the IANA->RIR
allocations level ? F.E.: IANA has allocated 1.0.0.0/8 to RIPE .
Or
Does the product also include the actual remaining non-allocated
space at the RIR->EU level ? (**) F.E: RIPE has allocated 1.0.1.0/24
to anubusstupidity, inc.
Jim & All,
The current bogon reference projects we have available only include the
first of your examples - netblocks which have not been allocated by IANA
to an RIR. However, we are currently in a beta testing phase of a
similar feed which also includes netblocks that have not yet been
allocated or assigned by the RIRs. We will also be offering the same
type of bogon feed for IPv6, something we've been asked about quite a
bit recently!
While I have your attention, I've noticed there's been a bit of
instability lately with the BGP sessions (in fact one of mine right now
is down). With 30 routes it's not a big deal to have frequent churn, but
if you're going to expand that to a larger feed then it could become a
problem.
What time frame do you determine to be instability? The following is
from a box that has ~25 neighbours. Since the box was reloaded (6w3d
ago), I've had the same uptime with the Team Cymru neighbours as I do
with internal gear. I can't say that I've experienced any instability at
all. It is not uncommon for me to have noticed uptimes well beyond 30w.
trig-2#sh ip bgp sum
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
68.22.187.24 4 65333 81750 65849 67 0 0 6w3d 30
216.165.129.196 4 65333 81748 65849 67 0 0 6w3d 30
trig-2#sh ip bgp nei 68.22.187.24
Prefix activity: ---- ----
Prefixes Current: 0 30 (Consumes 1560 bytes)
Prefixes Total: 0 36
Implicit Withdraw: 0 0
Explicit Withdraw: 0 6
...snip...
Connections established 1; dropped 0
Last reset never
Steve
Mine are not so good:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
38.229.0.5 4 65333 115856 115859 16411814 0 0 01:33:51 30
68.22.187.24 4 65333 26968 29671 16311293 0 0 2w4d
30
I see you have 68.22.187.24 in your list too, but my uptime is less. Are
you using increased hold times?
~Seth
Nevermind BGP timers, do you normally do well holding TCP connections open for weeks on end across the Internet?
Seth Mattinen wrote:
What time frame do you determine to be instability? The following is
from a box that has ~25 neighbours. Since the box was reloaded (6w3d
ago), I've had the same uptime with the Team Cymru neighbours as I do
with internal gear. I can't say that I've experienced any instability at
all. It is not uncommon for me to have noticed uptimes well beyond 30w.
Mine are not so good:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
38.229.0.5 4 65333 115856 115859 16411814 0 0 01:33:51 30
68.22.187.24 4 65333 26968 29671 16311293 0 0 2w4d
30
I see you have 68.22.187.24 in your list too, but my uptime is less. Are
you using increased hold times?
No... I haven't changed anything. Here is my exact config from said box
(for that host):
router bgp 14270
!...snip...
neighbor cymru-bogon peer-group
neighbor cymru-bogon description Cymru BOGON peer group
neighbor cymru-bogon ebgp-multihop 255
neighbor cymru-bogon update-source Loopback99
!...snip...
neighbor 68.22.187.24 remote-as 65333
neighbor 68.22.187.24 peer-group cymru-bogon
neighbor 68.22.187.24 description Cymru route-server #2
!...snip...
address-family ipv4
redistribute static route-map RTBH-OUT
neighbor cymru-bogon prefix-list CYMRU-OUT out
neighbor cymru-bogon route-map CYMRU-MAP-IN in
neighbor cymru-bogon maximum-prefix 200
!...snip...
neighbor 68.22.187.24 activate
!...snip...
ip community-list expanded BOGON permit 65333:888
ip community-list expanded BLACKHOLE permit 14270:600
ip as-path access-list 10 permit ^65333*
!...snip...
ip prefix-list CYMRU-OUT seq 5 deny 0.0.0.0/0 le 32
!...snip...
route-map CYMRU-MAP-IN permit 10
description Null route BOGONS learnt from Cymru
match community BOGON
set community 14270:888 no-export additive
set ip next-hop 192.0.2.2
!...snip...
route-map RTBH-OUT permit 10
match tag 600
set local-preference 500
set origin igp
set community 14270:600 no-export
!__END__
Do you have any other peers on the same int that are dropping as well?
Steve
Hi, Seth.
While I have your attention, I've noticed there's been a bit of
instability lately with the BGP sessions (in fact one of mine right now
is down). With 30 routes it's not a big deal to have frequent churn, but
if you're going to expand that to a larger feed then it could become a
problem.
Alas, the joy of multihop BGP. 
This is why we recommend at least
two peering sessions to two disparate route-servers. We'll take the
same approach with the expanded IPv4 and IPv6 offerings.
If you could send me a list of outages with dates and times, I'll look
into those ASAP. I can see if other sessions were dropping at the same
time, upstream outages, etc.
Feel free to hit up noc@cymru.com with outage reports as they occur as well.
Thanks!
Rob.
Hi, Seth.
While I have your attention, I've noticed there's been a bit of
instability lately with the BGP sessions (in fact one of mine right now
is down). With 30 routes it's not a big deal to have frequent churn, but
if you're going to expand that to a larger feed then it could become a
problem.
Alas, the joy of multihop BGP. This is why we recommend at least
two peering sessions to two disparate route-servers. We'll take the
same approach with the expanded IPv4 and IPv6 offerings.
Yep, I have two. It's always one or the other, but never both
simultaneously.
If you could send me a list of outages with dates and times, I'll look
into those ASAP. I can see if other sessions were dropping at the same
time, upstream outages, etc.
Feel free to hit up noc@cymru.com with outage reports as they occur as well.
Thanks, I'll keep an eye on it.
~Seth