Posts Tagged ‘bgp’

8 Great Resources that Every Computer Technician Should Know About

Tuesday, March 3rd, 2009

This post is a must read for computer technicians, and the resources can be used by both amateurs and professionals. I hereby share some of my clues for knowledge!

  1. The MAC address vendor search lets you identify the vendor for a MAC address, it is very helpful when troubleshooting ARP tables. Just insert the MAC address such as 00-00-01, you will see that it is identified as XEROX.
  2. Ever been on the lookout for a BGP looking glass? Wonder what your network look like on the Internet? Need to traceroute yourself? Thomas Kernen maintains traceroute.org, which is a public looking glass listing service. Alternatively you can use routeviews.org which also provides an excellent service!
  3. Need Cisco documentation? Ciscos own site can be a very good source for information, at least when you learn to find your way around. You can find an article about mostly every technology in a Cisco box on their website!
  4. Need something that can calculate your subnets on the fly? I have an Online IPv4 and IPv6 IP Calculator, and I also made an AJAX version of it which is available on ipv6calculator.net, it can be faster to use in some situations.
  5. The RIRs (Regional Internet Registry) can give you information about IP addresses, you can find out mostly anything you would like to know about the EU IP address space from querying for example RIPEs Whois Database.
    Here is a list of the RIRs and their respective Whois Database

    • RIPE Serves the EU Region
    • ARIN Serves the US Region
    • LACNIC Serves Latin America and the Carribean
    • AfriNIC serves the African Region
    • APNIC serves the Asian Region
    • If you just want to query one time, here is a free whois proxy
  6. To monitor your BGP announced prefix from the outside you can use the service BGPmon, which will monitor your prefixes and alert you in case of path changes.
  7. Dynamips is a Cisco emulator, it successfully emulates Cisco 7200, 3600 (3620, 3640 and 3660), 2691, 3725, 3745 and the 2600 platform. You can for example use it for testing network scenarios before deploying it!
  8. New software! Fresh meat! Check out freshmeat.net, this has been around forever now. New versions of open software projects are announced there, and it is also a browsable site for Open Software.

Now it is time for you to do your homework, let me know which sites you find useful or funny in your work or sites that you use on a daily basis, GO COMMENT!

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 IPv6 BGP Peering Sessions on Cisco IOS

Sunday, November 2nd, 2008

The future is closer than you think, are you ready?

Here is a little tutorial on configuring IPv6 BGP peering sessions on Cisco IOS.

First set the IP address on the interface, if this is a private peering session you can use a small network from your own PA block, on an exchange this IP address should be assigned by the exchange administrators.

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int fa 0/0
Router(config-if)#ipv6 address 3ffe:1234:1234::1/64

Then, it can be an idea to nullroute the prefix you are going to announce, I think it is good practice because it will also effectively blackhole traffic destined to unexisting networks. This will be announced into BGP with the redistribute static configuration item.

Router#conf t
Router(config)#ipv6 route 3ffe:2000::/32 null 0

Now we create a prefix list that permits only this network, this is very important to avoid leaks of prefixes to your peers. This prefix list is going to be applied outbound on to the BGP peering.

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ipv6 prefix-list announceAS65001-ipv6 seq 5 permit 3FFE:2000::/32
! better safe than sorry
Router(config)#ipv6 prefix-list announceAS65001-ipv6 seq 5000 deny ::/0 le 128

Now we are ready to configure the BGP peering session, this is just a simple example and most of these commands can be applied to peer groups, so that each configuration gets easier.

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router bgp 65001
Router(config-router)#redistribute static
Router(config-router)#neighbor 3ffe:1234:1234::2 remote-as 65002
Router(config-router)#address-family ipv6 unicast
Router(config-router-af)#neighbor 3ffe:1234:1234::2 activate
Router(config-router-af)#neighbor 3ffe:1234:1234::2 soft-reconfiguration inbound
Router(config-router-af)#redistribute static
Router(config-router-af)#neighbor 3ffe:1234:1234::2 prefix-list announceAS65001-ipv6 out

This will redistribute the static nullroute we made earlier to the peer at 3ffe:1234:1324::2, and the peering session should be up by now.

I can verify it on the other end:

Router2#sh ip bgp ipv6 unicast
BGP table version is 8, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
*> 3FFE:2000::/32 3FFE:1234:1234::1
0 0 65001 ?

As you can see, the network 3ffe:2000::/32 is now announced on this peering session, the route is sourced from AS65001. You can also get this on the summary:

Router2#sh ip bgp ipv6 unicast summary
BGP router identifier 10.0.0.1, local AS number 65002
BGP table version is 8, main routing table version 8
1 network entries using 152 bytes of memory
1 path entries using 76 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 500 total bytes of memory
BGP activity 2/1 prefixes, 4/3 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
3FFE:1234:1234::1
4 65001 26 23 8 0 0 00:05:54 1

If you want to see the prefixes announced to a peer or received from a peer. (This requires soft reconfiguration inbound configured on the peering session, neighbor 3ffe:1234:1234::2 soft-reconfiguration inbound in configuration.

Router2#sh ip bgp ipv6 unicast neighbors 3ffe:1234:1234::1 received-routes
BGP table version is 8, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
*> 3FFE:2000::/32 3FFE:1234:1234::1
0 0 65001 ?

Total number of prefixes 1

The prefix 3ffe:2000::/32 is received from 3ffe:1234:1234::1.

Router#sh ip bgp ipv6 unicast neighbors 3ffe:1234:1234::2 advertised-routes
BGP table version is 3, local router ID is 10.0.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
*> 3FFE:2000::/32 :: 0 32768 ?

Total number of prefixes 1

Voila, a better understanding and some real life examples of IPv6 BGP peering in Cisco IOS.

BGP Configuration: Basic example in Cisco IOS

Tuesday, September 23rd, 2008

A lot of people are looking for bgp configuration information for cisco and foundry, so I’ll explain a bit about the different statements and also post a couple of configuration examples.

Cisco

01: ip route 10.0.0.0 255.0.0.0 null 0
02: router bgp 65000
03: network 10.0.0.0 mask 255.0.0.0
04: neighbor 192.168.0.1 remote-as 65001

  1. Line 01 adds a route to 10.0.0.0/8 to null, this will make BGP announce this prefix as it will per default on cisco not announce networks it does not reach.
  2. Line 02 starts a BGP process with a local AS number of 65000.
  3. Line 03 adds the network 10.0.0.0/8 to the local BGP table, the router will now announce this network into BGP.
  4. Line 04 sets up a peering session with 192.168.0.1 with their AS number defined as 65001.

Security issues in peering
I wrote a rant about this in August when the news papers put up their big posters about the Internet dying (again.) 😉
Peering sessions should have a password and it might also be wise to filter the outbound announcements with a prefix-list, to make sure not to announce full transit to every peering partner.
Also, you do not want this to happen to you either, so you should at least configure a maximum prefix count.

Cisco, more BGP configuration statements (beginning in global config)

ip prefix-list AS65000 seq 5 permit 10.0.0.0/8
ip prefix-list AS65000 seq 1000 deny 0.0.0.0/0 le 32
router bgp 65000
neighbor 192.168.0.1 password oursecret
neighbor 192.168.0.1 prefix-list AS65000 out
neighbor 192.168.0.1 maximum-prefix 5

The first two lines will define a prefix list which will match only 10.0.0.0/8
The third line enters BGP configuration while the fourth line sets a password, the same password has to be configured on the other end (for AS65000 on the remote peer) for the peering session to become active.
Line number 5 will apply a prefix-list and the last line will make the router accept NO MORE than 5 prefixes from this peering partner.

Foundry BGP Configuration
This is mostly the same, but the dry basics is as follows:

ip route 10.0.0.0/8 null0
router bgp
local-as 65000
neighbor 192.168.0.1 remote-as 65001
network 10.0.0.0 255.0.0.0

And the filtering BGP4 statements for Foundry

ip prefix-list AS65000 seq 5 permit 10.0.0.0/8
ip prefix-list AS65000 seq 1000 deny 0.0.0.0/0 le 32
router bgp
neighbor 192.168.0.1 password oursecret
neighbor 192.168.0.1 prefix-list AS65000 out
neighbor 192.168.0.1 maximum-prefix 5

So as you can see, the BGP configuration is mostly the same for both routers, so lets focus our attention to more BGP configurations on Cisco IOS.

BGP Peering From a Loopback Interface
Per default routers always use the IP address on interface directly connected to the peer as the source address for the peering session. Sometimes this is prefered configurable, for example not to drop peerings due to hardware failure, or when doing eBGP multihop peering.

This is very configurable in BGP configuration in Cisco IOS

neighbor 192.168.0.1 update-source Loopback0

Verification
At last, we need to verify the peering session. I usually use this command:

show ip bgp sum | i REMOTEAS

Substitute ‘REMOTEAS’ with the AS number of which you want to check, for example it will show this for AS65001 from our lab. (I will include the header also because it is usefull in this example, even though it won’t show up in your show command.)

Router#sh ip bgp sum | i 65001
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.0.1 4 65001 28 27 3 0 0 00:24:15 2

This session is now established and I receive two prefixes from the remote peer.
If you enable ‘neighbor 192.168.0.1 soft-reconfiguration inbound‘ you will also be able to check announcements.

Router#show ip bgp neighbors 192.168.0.1 routes
BGP table version is 3, local router ID is 192.168.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 192.168.0.1 0 0 65001 ?
*> 192.168.0.0 192.168.0.1 0 0 65001 ?

Total number of prefixes 2

Two prefixes received from 192.168.0.1, and you can also use the command show ip bgp neighbors 192.168.0.1 advertised-routes to check what your router is announcing to the remote peer.

That was it for today, hopefully the newer ones out there will have a better understanding of the BGP configuration.

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!

Understanding Cisco BGP Best Path Selection Algoritm

Sunday, September 7th, 2008

Do you completely understand the BGP Best Path Selection?

I know I have to look it up from time to time…

In BGP running on a Cisco router, this is the process:

  • Use paths with the highest Weight
  • Use paths with the highest Local Preference
  • Use paths sourced with the network or redistribute command over paths sourced from the aggregate-address command.
  • Choose the route with the shortest AS-Path
  • Use paths origined from (in this order) IGP, EGP and Unknown. (IGP paths are prefered over EGP, EGP over unknown)
  • Choose the path with the lowest MED (‘MED is cost’, so the path with the lowest MED is prefered)
  • Choose eBGP paths over iBGP
    If there are multiple prefered iBGP paths, use the one with the lowest IGP metric.
  • Now see if there are multiple paths , and if the router is running with the bgp-multipath command. (then they will be installed)
  • If there are multiple eBGP paths for the destination, choose the oldest one (the one first received).
    If there are no current best path, or you run the bgp best path compare-routerid command.
  • Choose the route originating from the router with the lowest router-id.
  • (Route Reflectors) If paths originate from the same router, choose the path with the lowest cluster list length.
  • At last, choose the route that originates from the lowest neighbor address

Why isn’t the prefix received and installed to the routing table?
This happens from time to time, this is often because there are no IGP route to the NEXT_HOP in the BGP UPDATE.  It can also occur if the local-as is present in the AS_PATH attribute.

How can I see which prefixes are filtered, and which are received?
You can use the command neighbor 10.20.30.40 soft-reconfiguration inbound to make the router store rejected, filtered and other routing information in memory for you. You can then use the show ip bgp neighbor 10.20.30.40 received-routes and show ip bgp neighbor 10.20.30.40 advertised-routes to see you received and advertised routes.

Please use the comment box if you have any additions or find any mistakes, or simply just want to say hi! :)

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 ?

Configuring BGP4 with filtering on Foundry NetIron

Thursday, September 4th, 2008

This is the environment in this example:
YOUR ASN is 65400
YOUR IP address is 10.0.0.1
Your UPSTREAMS ASN is 65500
Your UPSTREAMS IP address is 10.0.0.2

You want to announce 192.168.0.0/16, the router will automatically exchange all the routes that it holds in its BGP table, so it might be wise to shutdown the peer while configuring it.
router# conf t
router(config)# ip prefix-list announceAS65400 permit 192.168.0.0/16
router(config)# router bgp
router(config-bgp)# local-as 65400
router(config-bgp)# neighbor 10.0.0.2 remote-as 65500
router(config-bgp)# neighbor 10.0.0.2 shutdown
router(config-bgp)# neighbor 10.0.0.2 prefix-list announceAS65400 out
router(config-bgp)# clear ip bgp neighbor 10.0.0.2
router(config-bgp)# no neighbor 10.0.0.2 shutdown