Posts Tagged ‘route filtering’

A Word About BGP Bogons Filtering

Tuesday, December 9th, 2008

BGP4 filtering is important, but how can you keep track of the prefixes and do active filtering on them?

It has been a while since my last blog post now, it’s partly because I have been (honestly) pretty lazy lately, yes, I have been trying to cool down on all my working because I started to get some problems with keeping track of my own feelings.
..and also because I have been trying to spend a little more time with the girl that actually can stand living with such a busy internet lunatic, we went to see the Norwegian setup of the musical Grease and also a Norwegian talk show named Senkveld, and along with all the xmas preparations and that it has been kind of hectic, but very very nice.
While I am still talking freely here, why is it that while I can see people reading around, I never see any comments from you guys?

Anyways, enough with the excuses and all that – on with the show, right?
[*APPLAUSE*]

The point about this post is to inform about the problems with bogon IPv4 (and probably IPv6 too, I haven’t looked at that yet) prefixes being announced into the Internet, and the problem about Internet Service Providers accepting these prefixes and adds them to their routing table. The worst case scenario would be like spam from 127.0.0.1

But, what are bogons.. or bogon prefixes?
I am glad to be asked that question sometimes, it is good – it shows that someone paid attention.
Bogon prefixes are for example unassigned prefixes, or RFC1918 networks and there are also other reserved ranges.

The assignment process for IPv4 is somewhat like this:

  1. IANA allocates a block of IPv4 addresses to a Regional Internet Registry (usually /8 to i.e. RIPE)
  2. The RIR then makes suballocations of this block to a LIR, a LIR is a Local Internet Registry (i.e. your ISP)

The ISP can then announce this IPv4 prefix in the BGP table on the Internet.
All these IANA to RIR assignments are public information, you can find it at cymru.com, they have regular updates.

The problem with bogons
The problem exists when networks listed as RESERVED or UNALLOCATED in this list are being announced and produces internet traffic.
For example, if you want to send out totally anonymous spam, what could you possibly do to ISPs without proper filtering?
Yeah, you could see someone announcing 192.168.0.0/22 and start spamming from 192.168.1.0.

Do you keep track of every announcement ever done to you? (In that case, how do you do it?)
I run a quagga router which also sees all announcements to our network and logs these to a logfile, and I am insterested to hear about other solutions – I know there are some java based applications.

To be consistent; you do not want bogons announced to you, you do not want to accept bogon networks and start routing traffic to them.

How to fix?
There’s a bogons prefix-list that Team Cymru creates that is very useful for Cisco enthusiasts like me.
They have constructed a secure BGP template.

So let us hope maybe there’s at least one extra bogon filter in place tomorrow, and let me know about it!

Configuring Cisco redistribution of OSPF to BGP with community filtering route-map

Tuesday, September 9th, 2008

I was wondering about something to write about, and I hope this is an interesting subject.
If there is anything you want me to write about, or something you wonder about or think I am mistaking about – please don’t be shy.. Just use the comment box! :-)

Quick overlook:

Router1
ASN: 1
Prefix from OSPF: 192.168.0.0/24
IP for BGP: 172.16.1.1/24

Router2
ASN: 2
IP for BGP: 172.16.1.200/24

Verify OSPF route
Router1#sh ip route | include ^O
O E2 192.168.0.0/24 [110/20] via 10.0.10.2, 00:02:10, FastEthernet0/0

Redistribute OSPF route to BGP table with a community
I created a prefix-list to match the prefixes in the route-map:
ip prefix-list ourPrefixes seq 5 permit 192.168.0.0/24

Then I went on and created the route-map that matches this prefix-list and set the community 1:150 (65686)
route-map ospfTag permit 10
match ip address prefix-list ourPrefixes
set community 65686

Then I did redistribution of OSPF into BGP with this command (in config-router (bgp configuration)):
redistribute ospf 1 route-map ospfTag

So I go on and verify the prefix is in the BGP table with the right community:
Router1#sh ip bgp 192.168.0.0/24 | i Comm
Community: 65686

Perfect!  Now I went on to create a community list for matching the communities in a route-map
ip community-list 1 permit 1:150

As you can see, the router converted this number to the long format number again for me:
Router1(config)#do sh run | i community-list
ip community-list 1 permit 65686

Current announcement to Router2:
Router2(config)#do sh ip bgp | i \*\>
*> 10.20.30.0/24    172.16.1.1               0             0 1 ?
*> 192.168.0.0      172.16.1.1               0             0 1 ?

So far, so good!   The 10.20.30.0/24 network is added as a twist, and it should disappear when the route-map outbound is working!  It is my test to see if things got applied.
Then I went on to create a route-map to match with this community list:
Router1(config)#route-map communityFilter permit 10
Router1(config-route-map)# match community 1

Then I applied the route map on to the BGP peer
Router1(config-route-map)#router bgp 1
Router1(config-router)#neighbor 172.16.1.200 route-map communityFilter out

Okay, after clearing the peer, do we have one less address in BGP then?
Router2#sh ip bgp | i \*\>
*> 192.168.0.0      172.16.1.1              20             0 1 ?
Router2#

Voila!  Please use the comment box if you spot errors, this tutorial was written kind of in a jiffy!

Cisco Configuring BGP With Peer-group and Filtering Routing in IOS

Saturday, September 6th, 2008

We are going to setup a peering session from AS 65500 with 65000, and we are going to announce the prefix 10.0.0.0/8

We have the IP address 172.16.1.200, while our peer have the IP address 172.16.1.1

There are different ways of filtering routes in IOS, but we’re going to focus on filtering with prefix-lists.

First enter global configuration mode by entering: ISP# conf t

To create a BGP process with AS number 65500 enter: ISP(config)# router bgp 65500

The following commands will create a peer group named IXPeers which will use the prefix-list announceAS65500 for outbound announcements.

ISP(config-router)#neighbor IXPeers peer-group
ISP(config-router)#neighbor IXPeers prefix-list announceAS65500 out

You should at best use an individual prefix-list for each and one of your peer to control inbound announcements to your autonomous system, but as this also means large administrative overhead, you can use a max prefix for the peers IXPeers.

Config: ISP(config-router)#neighbor IXPeers maximum-prefix 10

Set this to a number of prefixes you are comfortable with accepting from your peers, this is also a judgement of how much you trust your peers.

You can set a individual maximum-prefix for each peer by entering it in the neighbor statement for the peer in question.

(for example: Config: neighbor 10.20.30.40 maximum-prefix 50)

Now we are going to enter a static nullroute for the prefix 10.0.0.0/8, and redistribute it to BGP and also create the prefix-list announceAS65500

This static route to the virtual Null interface will also effectively blackhole any traffic destined for a not existing subnet in your network.

We are also going to add a static route for two more prefixes, so we can verify that the filtering works. (PS! You can apply a route map on the redistribute command to filter which prefixes that should enter the BGP table at all.)

ISP(config)#ip route 10.0.0.0 255.0.0.0 null 0
ISP(config)#ip route 192.168.0.0 255.255.255.0 null 0
ISP(config)#ip route 192.168.8.0 255.255.254.0 null 0
ISP(config)#ip prefix-list announceAS65500 seq 5 permit 10.0.0.0/8
ISP(config)#router bgp 65500
ISP(config-router)#redistribute static

You can now verify that the prefix 10.0.0.0/8 exists in your local BGP table.

ISP#sh ip bgp 10.0.0.0/8
BGP routing table entry for 10.0.0.0/8, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
Local
0.0.0.0 from 0.0.0.0 (172.16.1.200)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

Enter BGP configuration again with router bgp 65500 in global configuration mode, and configure the peering session:

ISP(config-router)#neighbor 172.16.1.1 remote-as 65000
ISP(config-router)#neighbor 172.16.1.1 peer-group IXPeers

*Sep 6 04:43:21.207: %BGP-5-ADJCHANGE: neighbor 172.16.1.1 Up

The peering session is now established, let us verify on the IXPeer side which prefixes that are announced. (PS! This only works with the neighbor 172.16.1.200 soft-reconfiguration inbound command in BGP configuration.)

IX-Peer#sh ip bgp neighbor 172.16.1.200 received-routes | include *>
*> 10.0.0.0 172.16.1.200 0 0 65500 ?

Voila, the only network announced from 65500 is now 10.0.0.0/8!

You can now modify the prefix-list to allow other prefixes to be announced:

ISP(config)#ip prefix-list announceAS65500 seq 10 permit 192.168.0.0/24
ISP#clear ip bgp 172.16.1.1 soft out

And verification from the IXPeer

IX-Peer#sh ip bgp neighbor 172.16.1.200 received-routes | include *>

*> 10.0.0.0 172.16.1.200 0 0 65500 ?
*> 192.168.0.0 172.16.1.200 0 0 65500 ?