Posts Tagged ‘routing’

Manipulate Routed Traffic With A Route-map

Wednesday, May 6th, 2009

Sometimes.. when everything is failing, you’ll need to do some dirty hacks to get things the way you want. I’m going to show you how to modify the next-hop (where the packet is routed) with a route-map

Let’s say you want to redirect web-traffic to a local cache running for example squid, but let other traffic pass on to its intended destination. As usual I have created an imaginary scenario, but this time I have used my creative skills (yeah, right!) to draw a little network map in dia also.

squidroutemap

The idea is to let all TCP port 80 traffic from all the clients to be sent to the web cache server on 10.0.0.2
To achieve this, we need to create an access-list to match web traffic from the clients.

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip access-list extended webtraffic
Router(config-ext-nacl)#deny tcp host 10.0.0.2 any eq www
Router(config-ext-nacl)#permit tcp 10.0.0.0 0.0.0.255 any eq www

To verify that this access-list now exists, run this command

Router#sh ip access-list webtraffic
Extended IP access list webtraffic
10 deny tcp host 10.0.0.2 any eq www
20 permit tcp 10.0.0.0 0.0.0.255 any eq www

As you can see, I have a deny on 10.0.0.2, this is because we can’t match traffic coming from the web caching server and redirect it to itself, that would create a loop.

The next thing we need to do is to create a route-map which uses the webtraffic access-list to match packets and do the intended modifications to it.

Router(config)#route-map webcache-redirect permit 10
Router(config-route-map)#match ip address webtraffic
Router(config-route-map)#set ip next-hop 10.0.0.2
Router(config-route-map)#route-map webcache-redirect permit 200

You can now verify this route-map by doing this

Router#sh route-map webcache-redirect
route-map webcache-redirect, permit, sequence 10
Match clauses:
ip address (access-lists): webtraffic
Set clauses:
ip next-hop 10.0.0.2
Policy routing matches: 0 packets, 0 bytes
route-map webcache-redirect, permit, sequence 200
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

The last thing that needs to be done for this to have effect is to apply policy routing on the interface on which you receive the traffic from the clients (the interface which acts as a gateway for the clients, in this case the one with the IP address 10.0.0.1).

Router(config)#int vlan 1
Router(config-if)#ip policy route-map webtraffic-redirect

You can now use the sh route-map command again to see that your webtraffic now is being policy-routed.

Read about how to setup a squid as a transparent proxy here.

UPDATE: Eirik Hjelle poked me and told me that the squid tutorial that I am refering to is outdated, and it sure is!
The basics of the squid.conf should be (was not going to cover it here, since it’s a cisco blog, but since Eirik was a nice fellow and just gave me a paste of the required I’ll include it:

http_port 3128 transparent
acl internal_network src 10.0.0.0/24
http_access allow internal_network

The traffic will still be directed to port 80 so it might be needed to change the http_port to

http_port 10.0.0.2:80 transparent

Multiple Area OSPF Networks on Cisco – Part 2 of 2

Friday, January 30th, 2009

Had a nice week everyone? I’ve been writing a lot and working a lot, but anyways here is part 2 of 2!

Link State Database / Topology Table
What’s that? you may ask – maybe only because I forgot to mention it in the previous article, well it’s a database which contains data on how the routers ‘see’ the network topology (link states), all the routers in an AS will have a copy of this table.
This table is getting changed as the network topology changes, as for example if a prefix is moved or an interface goes down.

VLSM
One time during this week I suddenly realized that I should probably mention that OSPF supports VLSM (Variable length Subnet Masks), that some people still stick to the usage of routing protocols that does not support VLSM is way beyond my understanding.

LSAs and LSA Types
There are 7 types of LSA (Link state advertisements) in OSPF;

  1. Router Link Advertisements, generated by each router and is flooded in a single area.
  2. Network Link Advertisements, flooded throughout the network and is generated by the DRs. Describes a set of routers connected to a network.
  3. Type 3 are summary link advertisements. These are generated by the Area Border Routers and describes Inter-area routes, generating a quad zero route by the command default information originate also generates a type 3 LSA.
  4. Type 3 and type 4 is very often described at the same time, the type 4 LSA describes routes to an ASBR.
  5. These are generated by the ASBR, and describes routes that are redistributed into OSPF from AS’s or routing protocols.  These are flagged in the routing table with O E1 and O E2 (external type 1 or 2) and are flooded to all areas except for stub areas.
  6. Group membership link entry LSAs are generated by multicast OSPF routers.
  7. Type 7 LSAs are only flooded to not-so-stubby-areas and are generated by ASBRs. When external routes are injected to areas other than the backbone area 0 are type 7, these are converted to type 5 by area border routers before they are injected into the backbone area.

Route summarization
My feeling is that at least once (a day?) in every network administrators life they’d wish the routing table was smaller and had a bunch of fewer prefixes, but what can we do?

We can use route summarization to make the routers summarize all routes in an area.

The configuration is as follows

Router(config-router)# network 10.0.0.0 0.0.0.255 area 0
Router(config-router)# network 10.0.1.0 0.0.0.255 area 1
Router(config-router)# area 0 range 10.0.0.0 255.255.255.0
Router(config-router)# area 1 range 10.0.1.0 255.255.255.0

This router will act as an area border router (ABR) between area 0 and area 1, the area areaid range command tells the router to summarize all routes that area to that summary address before advertising them in another area.

Multiarea OSPF Configuration on Cisco IOS

The scenario are 4 routers, preconfigured with IP addresses and daisy chained.
R1: Area 0
R2: Area 0
R3: Area 0 and area 1
R4: Area 1

Area 0 = 10.0.0.0/24
Area 1 = 10.0.1.0/24

We will use route summarization.

To configure R3 to be both in area 0 and area 1, let us say we use /30-ranges for connecting the routers.

R3(config-router)#network 10.0.0.0 0.0.0.3 area 0
R3(config-router)#network 10.0.1.0 0.0.0.3 area 1
R3(config-router)#area 0 range 10.0.0.0 255.255.255.0
R3(config-router)#area 1 range 10.0.1.0 255.255.255.0

Configure all the other routers as usual, but R4 should be configured as only area 1.
I configured all routers to redistribute connected and static subnets.

To verify that you see the area 1 as 10.0.1.0/24 instead of (now) 10.0.1.0/30.

R1#sh ip route
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/30 is directly connected, FastEthernet0/0
O IA 10.0.1.0/24 [110/2] via 10.0.0.2, 00:01:56, FastEthernet0/0

There you go!

Multiple Area OSPF Networks on Cisco – Part 1 of 2

Sunday, January 18th, 2009

Multi-area OSPF networks are widely used, in this article I am going to show some of the logic behind multi-area OSPF Networks. I will write a series of all 2 (yey!) posts about multiple area OSPF the next couple of weeks. Stay tuned in!

Single areas can be considered subsets of a larger autonomous system.

What are the benefits of splitting networks up in multiple areas?

You can solve situations like

  1. Every time a route flaps, it initiates shortest-path-first algorithm calculations on all routers in that area.
    This causes high CPU utilization that could be used for something more productive.
  2. The routing table is getting too large and equipment that can handle less IPv4 routes will have trouble operating.
  3. The Link-state Topology table (we will get back to this) is getting unmanageable.

Terms and definitions
There are some terms and definitions that you should know:

  1. Backbone area / Transit area / area 0
    This refers to the area with area id 0, which can be a group of routers acting as the main path for traffic between OSPF areas.
  2. ABR
    Area Border Router, technically – a router that is connected to area 0 and at least another area, and therefore maintains two link-state databases are considered ABRs.
  3. ASBR
    Autonomous System Border Router is a router that are between the OSPF network and another routing protocol network, for example BGP or IGRP.
  4. IR
    Internal router, this type have all its interfaces connected to a single area.

You should be familiar with terms like LSU, LSA and the different types.

This IMPORTANT rule applies to multiarea OSPF networks:
All areas needs to be connected to area 0, if it is impossible to physically connect an area directly to area 0, you can utilize a virtual-link to create a logical path for the traffic from this area to reach the backbone area.

Different area types

  1. Standard/normal area
    A default route (0/0) is generally not generated by routers in a normal area, but it can be forced with this command under router ospf

    Router( config-router)# default-information originate always

    Normal areas (like in single area setups) can receive external route information, link updates and route summaries.

  2. Stub area
    While stub areas can’t receive external routes, they can receive inter-area routes, intra-area routes and default routes.

  3. Totally stubby area
    This area does not receive summary routes from other areas in the network, and it does not receive external routes. To reach networks outside the area it will always use the default route (0/0)
  4. Not So Stubby Area (NSSA)
    This is a stubby area which can receive a part of external routes from outside the AS.
    The LSA it can receive is Type 7 LSA.

  5. Backbone area
    ..or “transit area” always has the area id 0, every other area must have a link to area 0. Either physically or via a logical ‘virtual-link’.
  6. That was the area types, these are defined under the router ospf configuration.
    So, every 30 minute all the OSPF routers floods the area with so called LSU (Link state updates) just to make sure that every router in that area agree about the link state database. These LSUs are received by the other routers and flooded across the area until all the routers agree about the current link-state database.

    Network events and LSA flooding
    When an event happens, for example an interface goes down; the router will send a LSA and a LSU packet to 224.0.0.6 – the multicast address for the BR and BDR – which in turn will flood this packet out on all their active interfaces on the multicast address 224.0.0.5 – which is the multicast address that all routers should listen on, and they will then do the same until the network agrees about the topology and is so called ‘converged’.

    In my next post I will cover the configuration and route summarization and LSA types.

    Have a nice OSPF Sunday!

How to setup a GRE tunnel on a Cisco Router

Tuesday, January 13th, 2009

Hey peeps, it has been a while now…
Sorry about that, I have had a lot of things on my mind lately.
Sometimes I also have issues figuring about a new subject to write about, but I will try to take on more advanced networking as someone requested it per email.  If you want me to write about something or need help with anything, don’t hesitate to contact me.

So, let’s warm up the new year with an easy tutorial on how to setup a GRE tunnel on a Cisco router.

Consider this scenario:
Router1 = 172.16.1.1
Router2 = 192.168.0.1

The routing between these routers are fixed so that they can reach each other, like on the internet.
Router2 will have the network 10.0.10.0/24 routed to it via a GRE tunnel.
The address on the tunnel interfaces will be 10.0.0.1 and 10.0.0.2 for Router1 and Router2 respectively.

Router1 configuration:

Router1(config)#interface Tunnel 0
Router1(config-if)#tunnel source 172.16.1.1
Router1(config-if)#tunnel destination 192.168.0.1
Router1(config-if)#tunnel mode gre ip
Router1(config-if)#ip address 10.0.0.1 255.255.255.252
Router1(config-if)#no shutdown
Router1(config-if)#exit
Router1(config)#ip route 10.0.10.0 255.255.255.0 10.0.0.2

Router1(config)#interface Tunnel 0
Router1(config-if)#tunnel source 192.168.0.1
Router1(config-if)#tunnel destination 172.16.1.1
Router1(config-if)#tunnel mode gre ip
Router1(config-if)#ip address 10.0.0.2 255.255.255.252
Router1(config-if)#no shutdown
Router1(config-if)#exit
Router1(config)#ip route 10.0.10.0 255.255.255.0 Null 0

You can now setup addresses within 10.0.10.0/24 on any interface you want and use them like as they were routed to your router directly.
The traceroute from Router2 to Router1 should look something like this:

Router2#traceroute 10.0.0.1

Type escape sequence to abort.
Tracing the route to 10.0.0.1

1 10.0.0.1 8 msec 8 msec 8 msec

Voila, we got routing over GRE!

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.

Understanding and Configuring IPv6 Routing on a Cisco Router

Saturday, September 27th, 2008

You do have a backup plan for IP addressing, now that we are running out of IPv4 space, right?

IPv6 isn’t something awfully new, but some of the ideas can be hard to grasp.
To understand IPv6 routing, I had to learn how to do subnetting of IPv6 address space.

Subnetting basics
To understand IPv6 subnetting, I took it from what I had learned about the basics of subnetting IPv4 addresses.

IPv4: The number 192.168.0.1 only represents a 32-bit number, split into 4 ‘octets’, which are groupings of 8 bits (256 combinations 0 – 255), each octet is separated with a dot ‘.’.
The network mask represents the subnet size, because the network mask eventuallyl decides who you can talk to (for example 255.255.255.0 means that all bits in the last octet can be freely manipulated, hence a subnet mask of 255.255.0.0 means you can change the tweak last octets to your hearts content.

IPv6 addresses and subnetting
This is basically just the same as for IPv4, except the address is now 128 bits compared to 32.
This makes room for 2^128 addresses while IP version 4 was limited to 2^32.
Just a little calculation, for the fun of it:

(2^128)-(2^32) = 340282366920938463463374607427473244160

This is how many MORE addresses the IP version 6 will give us.

In IPv6 the octets we all know from IPv4 are 8 groupings of 16 bits, and instead of being written in decimal format – they are written in hex.
So a valid IPv6 address could be 3ffe:1000:0000:0000:0000:0000:0000:0001/126.
How does this work?
/126 indicates that 2 bits left from the mask for host addressing, this will give four host addresses.

One thing you should notice is that while it can feel natural, it will not work to use addresses such as ::9, ::10, ::11, and ::12 for the same subnet.

The key here is hex, which ranges from 0 – 9 and a – f, so it’s counted like 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d,e and f.

To be certain, use the Online IPv4 and IPv6 calculator, it will calculate the subnets for you.
Just enter an IPv6 or IPv4 address with the corresponding CIDR (for example /24) and it will return the network range.

Enable forwarding of IPv6 Unicast Packets in Cisco IOS

Router(config)# ipv6 unicast-routing

Configure a static IPv6 default gateway/route

Router(config)# ipv6 route ::/0 3ffe:1::1

This would configure a default route to 3ffe:1::1.

Configuring an IPv6 address on an interface

Router(config-if)# ipv6 address 3ffe:1::1/64

Verifying configuration
Verify IPv6 Routing Table

Router# show ipv6 route

Pinging over IPv6 from Cisco IOS

Router# ping ipv6

Also check out these featured articles
Configuring IPv6 OSPF Routing In Cisco IOS

Get Support for IPv6 Rouing on the 3750 Platform

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.

Routing – Understanding And Tweaking the CAM

Thursday, September 18th, 2008

If you don’t pay attention to the CAM, your network could face serious problems.

What is the CAM and Why is it important?
The CAM is short for Content-Adressable Memory and is a type of memory for high speed searching applications. Other names are associative memory or when programming; associative arrays.

The CAM makes it possible to make routing decisions in hardware instead of bothering the CPU, routes are placed in the CAM so that the linecard ASIC or FPGA hardware can look up which interface to send the packet out on somewhat directly from the memory. This decreases routing latency drastically and makes wirespeed performance possible.

Imagine how your router would perform without this now..

OK, Why is it important?
Because every router have a limited amount of physical memory, and this memory space has to contain IPv4 routes, IPv6 routes and everything you are (or want to do) in hardware.
This makes partitioning of this memory important.

You have different ways of doing this, but it mostly involves a reload of the router.

CAM Profiles
On Foundry routers it’s called CAM profiles, here are the basics:

The Internet Routing table now have about 260K prefixes, so you should worry.

To check my CAM usage I use:

show cam-partition usage

On a Cisco 6500/7600 switch, you could use

show tcam details

When there are no more CAM space for a route, it will become unreachable.
So pay attention to your CAM/TCAM. :-)

Route overlaps, it’s dangerous!

Sunday, September 14th, 2008

Just wanted to tell you that I added a new page, it’s aIP subnet calculator tool.

It works with IPv4 and IPv6 addresses, just remember to add the network length in the end (/24) for a 255.255.255.0

The danger with dynamic routing is the possibility of route overlaps, by this I mean having the same subnet defined on two routers announcing it in a dynamic routing protocol like for example OSPF.

Let us say you have configured a customer as 10.0.0.48/28 and he uses 10.0.0.49 and 10.0.0.50

Then you get a new customer and configure for example a new subnet 10.0.0.48/30, which is a more specific route (CIDR wise).

You might end up effectively blackholing the old customers traffic, this is something one should consider.

Use my IP subnet calculator tool to be sure not to overlap networks!