Wednesday, July 9, 2008

EIGRP – Summarization & Leak-map

EIGRP summarization is configured on interface:

R2(config-if)#int fa0/0


R2(config-if)#ip summary-address eigrp 100 2.2.4.0 255.255.252.0

Before summarization (2.2.4.0/22)

image

After summarization (2.2.4.0/22)

image

Leak-map is a features that allows us to advertise a component route (specific route + summary route) that you don’t want to suppressed by manual summarization.

ip summary-address eigrp 100 2.2.4.0 255.255.252.0 5 leak-map LEAKTEST

There are 3 rules to remember:

Rule 1 – Leak-map is configured to reference a route-map that DOES NOT EXIST

image

Result: Only summary route is advertised.

Rule 2 – Leak-map is configured to reference a route-map and it is referencing to an access-list that DOES NOT EXIST

image

Result: Summary route + ALL specific routes are advertised.

Rule 3 – Leak-map is configured to reference a route-map and it is referencing to an access-list that exists

image

Result: Summary route + networks permitted in ACL will be advertised. In this case the summary route + 2.2.5.0/24 permitted in ACL is advertised.

Sunday, July 6, 2008

OSPF - Summarization

OSPF summarization can be configured on 2 types of routers:

ABR – Internal OSPF routes

ABSR – External OSPF routes

My topology:

R1 --- FR --- R2

|

R4 --- FR --- R3

Example 1 – Summarizing External routes

I have created several loopback interfaces on R4 (ABSR),

lo0: 4.4.0.4/24

lo1: 4.4.1.4/24

lo2: 4.4.2.4/24

lo3: 4.4.3.4/24

Now I will redistribute the directly connected loopback interfaces addresses to OSPF:

R4(config-if)#access-list 4 permit 4.4.0.0 0.0.3.255


R4(config)#route-map REDIS permit 10


R4(config-route-map)#match ip addr 4


R4(config-route-map)#router ospf 1


R4(config-router)#redistribute connected subnets route-map REDIS

on R3, we can see the redistributed routes as external routes:

image

To summarize the external routes, use the “summary-address” on R4
R4(config-router)#summary-address 4.4.0.0 255.255.252.0

You can see those redistributed external routes are summarized:

image

Example 2 – Summarizing Internal Routes

In this example I will try to summarize internal routes from area 1 on ABR (R2)

R1

lo0 – 1.1.0.1/24 (area 1)
lo1 – 1.1.1.1/24 (area 1)

lo2 – 1.1.2.1/24 (area 1)
lo3 – 1.1.3.1/24 (area 1)
s1/0.12 – area 1

R2
lo0 – area 0
s1/0.21 – area 1
fa0/0 – area 0

To summarize internal routes, use the “area X range” command:
R2(config-router)#area 1 range 1.1.0.0 255.255.252.0

on R3, you can see the summarized route 1.1.0.0/22:

image

Example 3 – Discard-route

The discard route is created automatically when you configure a summary route.

On R2 (ABR where Internal route summarization takes place):

image

O 1.1.0.0/22 is a summary, 00:08:54, Null0

On R4 (ASBR where External route summarization takes place)

image


O 4.4.0.0/22 is a summary, 00:15:05, Null0

The discard routes are created to stop forwarding loop.

Use the “no discard-route” command to remove the discard-route:

R2(config-router)#no discard-route internal

R4(config-router)#no discard-route external

On R2 and R4, the discard route is gone.

R2

image

R4

image

Friday, July 4, 2008

OSPF - Cost

OSPF Cost = Reference Bandwidth / Interface Bandwidth


The default reference bandwidth is 100Mbps, so for instance the OSPF cost for a T1 serial line is:

OSPF Cost 

= 100,000,000 / 1,544,000


= 64.7 (remove decimal)


~ 64

For loopback address, the cost is 1 because:

OSPF Cost


= 100,000,000 / 8,000,000,000


= 0.125 


~ round off to 1

If you want to override the formulated cost, you can use the interface command:

ip ospf cost <cost>

Let's see this example:

R1 is directed connected to R2 with a T1 serial link. R1 has its network 1.0.0.0/8 advertised to R2 and from R2 we can see that the metric (cost) is 65. 1.0.0.0/8 is on R1 loopback interface.

image

So loopback0 metric (1) + serial1/0 metric (64) = 65 on R2

Let's change R1 loopback0 cost so the configured value will override the formulated value:

image

Go back to R2 and see the output of show ip route:

image

The metric becomes 84 because:

loopback0 metric (20) + serial1/0 metric (64) = 84

Another way to influence the cost is changing the reference-bandwidth from default 100Mbps to some other numbers.

auto-cost reference-bandwidth <bandwidth in Mbps>

image

Let's change the reference bandwidth to 1000Mbps. Make sure you do it across all network.

image

Wednesday, July 2, 2008

CCDE

For those who wanna pursue CCDE, here is a presentation from Cisco Live! 2008 give you a glance on how it will look like:

CCDE Networkers Presentation

Another preview from Michael Morris' blog:

http://www.networkworld.com/community/node/29094

Tuesday, July 1, 2008

BGP – Route-reflector Resilience Design

There are 2 major forms of route-reflector clustering:

1. Two or more RRs in the same cluster

2. Client is a member of multiple clusters

Let’s take a look at how it works in these 2 cases.  Assuming I have 2 RRs, RR1 and RR2 and 2 route reflector client C1 and C2. 

- RR1 has a peer session with RR2

- C1 has 2 peer sessions one to RR1 another to RR2

- C2 has 2 peer sessions one to RR1 another to RR2

Case 1 – Same Cluster, When everything is fine

- C1 gets an update from somewhere and advertise to RR-1 and RR-2

- Both RRs will advertise the update to C2

- RRs will send update to each other, but since the same cluster-id in the update message and it is identical to its own, it will discard the update

Case 2 – Same Cluster, C1-RR2 and C2-RR1 links down

- C1 gets update and advertises to RR1

- C1 can’t advertise to RR2 as the link is down

- RR1 can’t advertise to RR2 as the cluster-id is the same

- As a result C2 can’t get the update (50% of the routers in the cluster)

Case 3 – Different Cluster, When everything is fine

- C1 gets update and advertises to RR1 and RR2

- RR1 will advertise to RR2 and it will process it as the cluster-ids are different, and vice versa

- C2 gets the update

Case 4 – Different Cluster, C1-RR2 and C2-RR1 links down

- C1 gets update and advertise to RR1

- RR1 advertises to RR2 and it is accepted, as cluster-ids are different

- C2 will gets the update

- Therefore it provides better redundancy

If you want to know more on different forms of RR redundancy design, here is a good presentation on this topic:

http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-eof-bgp/index.html

BGP – Local Preference

Local preference is used to prefer an exit point for local AS when there are multiple exit points. 

My topology:

R1 – FR – R2

|             |

R4 – FR – R3

R1 in AS100 and R2, R3 and R4 in AS200.

Now I want to make sure that routers in AS200 uses R4 to reach network 1.0.0.0/8 in AS 100 using local preference.

R4(config)#access-list 1 permit 1.0.0.0
R4(config)#route-map setlocalpref permit 10
R4(config-route-map)#match ip addr 1
R4(config-route-map)#set local-preference 1000
R4(config-route-map)#route-map setlocalpref permit 20
R4(config-route-map)#router bgp 200
R4(config-router)#nei 123.1.14.1 route-map setlocalpref in

The route-map should be configued in the IN direction since the local preference affects the routers within the AS.

Before and After (on R2) – show ip bgp

image