Showing posts with label route redistribution. Show all posts
Showing posts with label route redistribution. Show all posts

Saturday, February 14, 2009

Watch the RIP metric when summarizing redistributed routes

I was reading through the GS archives and saw this interesting issue about the metrics of summarized routes after being redistributed into RIP.

Scenario:

R1---RIP---R2---OSPF---R5---5.5.5.5/32

R2 is redistributing OSPF to RIP as follows:
R2#sho run | sec router rip
router rip
version 2
redistribute ospf 1 metric 2
network 192.168.0.0
no auto-summary
R1 has the following route:
R1#sho ip route | sec 5.0.0.0
5.0.0.0/32 is subnetted, 1 subnets
R 5.5.5.5 [120/2] via 192.168.0.2, 00:00:11, FastEthernet0/0
1) Manual Summary
R2(config)#int f0/0
R2(config-if)#ip summary-address rip 5.0.0.0 255.0.0.0

R1#sho ip route | sec 5.0.0.0
R 5.0.0.0/8 [120/3] via 192.168.0.2, 00:00:01, FastEthernet0/0
The metric increased by 1.

2) Auto-summary
R2(config-if)#router rip
R2(config-router)#auto-summary

R1#sho ip route | sec 5.0.0.0
R 5.0.0.0/8 [120/2] via 192.168.0.2, 00:00:05, FastEthernet0/0
The metric is the same as when redistributed.

Saturday, November 29, 2008

Mobile ARP

Well seeing as how I just missed a 4-point task on mobile ARP, I thought now was a good time to learn it. It's actually very simple and pretty cool once you get it working.

Topology is a little confusing so here it is in 2 parts:

PHYSICAL:

R1---CAT1===dot1q===CAT2---R8

LOGICAL:

VLAN 100---R1---R2---R5---R7---R8---VLAN 200

The task says that users on R8's LAN occasionally mover over to R1's LAN. They still need access to the network. What we do is configure R1 to listen for ARP packets from R8's subnet (VLAN 200).

We can test this by creating an SVI for VLAN 100 and giving it an IP in R8's subnet. When it tries to contact anyone, we will see a mobile route appear in R1's route table. This route then gets redistributed into the routing protocol (OSPF in this case). It appears as a /32 route so the longer match wins over any other route advertisement of VLAN 200.

All configuration is on R1:

1) CREATE THE ACL

R1(config)#access-list 8 permit 172.31.80.0 0.0.0.255


2) CONFIGURE MOBILE ARP ON INTERFACE

R1(config)#interface f0/0
R1(config-if)# ip mobile arp access-group 8



3) REDISTRIBUTE

R1(config)#router ospf 1
R1(config-router)# redistribute mobile subnets



4) VERIFY

Ceate an SVI on VLAN 100 with VLAN 200 IP address:

CAT1(config)#int vlan 100
CAT1(config-if)#ip address 172.31.80.100 255.255.255.0
CAT1(config-if)#^Z
CAT1#ping 172.31.80.8

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.80.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/219/1016 ms


Run debug and show commands on R1:

R1#debug ip mobile
IP mobility events debugging is on
Nov 29 21:17:14.138: Local MobileIP: route add 172.31.80.100

R1#show ip route mobile
172.31.0.0/16 is variably subnetted, 11 subnets, 6 masks
M 172.31.80.100/32 [3/1] via 172.31.80.100, 00:11:05, FastEthernet0/1
R1#


Traceroute shows how many hops we are actually going through:

CAT1#trace 172.31.80.8

Type escape sequence to abort.
Tracing the route to 172.31.80.8

1 172.31.10.1 4 msec 4 msec 0 msec
2 172.31.12.2 0 msec 4 msec 0 msec
3 172.31.100.5 12 msec 8 msec 12 msec
4 172.31.200.7 12 msec 8 msec 12 msec
5 172.31.78.8 12 msec * 8 msec
CAT1#

Monday, November 24, 2008

Routing Loop - Part I

I was reading "Optimal Routing Design" by Cisco Press today and a routing loop scenario was described (chapter 2), but they had it all wrong and screwy and it gave me a routing loop in my brain. So I wanted to actually do a similar scenario some justice. This hopefully will be first part in maybe a series of posts that deal with routing loops, since they can be real buggers.

The Topology:



The Scenario:

R2 is hub with R5 and R6 as OSPF neighbors.
R5 and R6 are also EIGRP neighbors with R7.
R7 is redistributing it's serial interface with R8 into the EIGRP domain.
R5 and R6 are mutually redistributing between OSPF and EIGRP.

If R5 and R6 redistribute OSPF into EIGRP with equal metrics, everything stabilizes, even though you have a suboptimal path. This is because External OSPF (AD=110) is preferred over External EIGRP (AD=170). So whichever device (R5 or R6) redistributes R7's serial network into OSPF first, will keep it's route via EIGRP but the other router will learn it via OSPF.

Let's take a look at R5 and R6 OSPF and EIGRP config (there both the same):

R5#show run | sec router ospf|eigrp
router eigrp 1
redistribute ospf 1 metric 1 1 1 1 1
network 150.100.0.0
no auto-summary
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets
network 150.100.100.0 0.0.0.255 area 0
R5#


This results in the following route entries for 150.100.78.0

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:10:23 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:10:23 ago, via Serial1/0
Route metric is 20, traffic share count is 1


R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:01:21 ago
Routing Descriptor Blocks:
150.100.56.7, from 150.100.56.7, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
* 150.100.56.5, from 150.100.56.5, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1


R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 76 msec 72 msec 20 msec
2 150.100.56.7 48 msec * 72 msec
R2#


Notice that R5 has learned the route via OSPF and has advertised it back into EIGRP with the same metric that R7 is originally advertising it with. R6 has installed them both. So far it's not impacting anything.

Now let's suppose we had a task that said R7 should prefer R5 to reach the OSPF domain and you must configure the solution on R5. How could we do that? We could adjust the metric when redistributing. Let's do this by increasing the bandwidth metric on R5:

R5(config)#router eigrp 1
R5(config-router)#redistribute ospf 1 metric 2 1 1 1 1


Now let's look at R6's entry:

R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 1280002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.5 on FastEthernet0/0, 00:01:37 ago
Routing Descriptor Blocks:
* 150.100.56.5, from 150.100.56.5, 00:01:37 ago, via FastEthernet0/0
Route metric is 1280002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 2 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1


Its' pointing back to R5!! Let's look at R5:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 2 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:15:35 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:15:35 ago, via Serial1/0
Route metric is 20, traffic share count is 1


It's still pointing to R2!! Trace from R2:


R2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 40 msec 76 msec 16 msec
2 150.100.56.5 96 msec 28 msec 44 msec
3 150.100.100.2 44 msec 36 msec 44 msec
4 * * *
5 * * *
6 * * *


So...how would you fix it?

R5 and R6 should learn this route via EIGRP...but last time I tried you could not alter AD for specific external routes...but you can do it for OSPF.

access-list 78 permit 150.100.78.0 0.0.0.255
router ospf 1
distance 180 0.0.0.0 255.255.255.255 78


Now the OSPF route will never be preffered but we do have failover should R5 or R6 lose its LAN connection. Doing this on one side actually fixes it, but leaves R6 with a suboptimal route. I prefer to do it on both.

Final verification of the solution:

R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:16 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:16 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1


R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:12 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:12 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1


2#trace 150.100.78.7

Type escape sequence to abort.
Tracing the route to 150.100.78.7

1 150.100.100.6 44 msec
150.100.100.5 104 msec
150.100.100.6 20 msec
2 150.100.56.7 56 msec * 72 msec
R2#


If you know any other scenarios, please let me know.

Saturday, November 22, 2008

Route Redistribution - Tagging like an Expert

The inspiration for this post comes directly from IPexpert's wonderfully insane Volume 1 Section 12 Lab. THIS LAB IS INSANE. Not too bad really, but see for yourself :)

Here is the topology:


All I am going to do in this post is explain how I go about "prepping" for redistribution. These are just a random set of miscellaneous notes, in no particular order. I will number them just for identification purposes :)

Also, remember you can do ALL of this in a notepad file before you configure the routers. I try to do it like that, that way my head is truly "around" the whole scenario. Of course, there is some tweaking that will always need to be done once you do get down to business.

1) ASSIGN TAGS

First thing I like to do is think about tagging a routing domain. Remember we always drop the tag coming in so if you like to use the AD for a tag, be careful if you have multiple domains with the same protocol.

For example, if you set a tag of 110 on R4 and R7 for OSPF routes going into EIGRP. If you deny this tag from EIGRP into OSPF, you prevent R7 and R4 from learning about each other's OSPF networks. In this lab I used 110 for the R2/R4 process. And I used 115 for the R5/R6/R7 process.

Here are the tags I assigned, these were applied at the END of every redistribution route-map.

RIP = 110
OSPF AREA 0 = 110
BGP = 256
OSPF AREA 567 = 567
EIGRP 7800 = 7800
EIGRP 12348 = 12348

On R4, I might have something like this:

route-map ospf2eigrp permit 50
set tag 110

2) WHEN TO DENY TAG ON RE-ENTRY

Another thing to remember is when to deny the tag. I only deny the tag when it's entering that protocol from which it came. Unless, of course, I am specifically asked to block routes from entering a certain domain.

Example Rip routes are tagged with 120 going into OSPF (or community 120 in BGP). The only place I deny 120 from entering a routing domain is on R2 from OSPF to RIP, or BGP to RIP (matching community value, not tag).

So building on the above route-map I would have this now:

route-map ospf2eigrp deny 10
match tag 12348
route-map ospf2eigrp permit 50
set tag 110

Everything else is allowed.

3) ALLOW TAGS TO PASS THROUGH

Another thing to remember is to allow the tags to "pass through" each domain. In the above route-map, R4 removes any tags that R2 may have placed on RIP routes from R1. This prevents us from identifying and blocking the re-entry RIP routes in BGP on R2!

So on R4 we could do this:

route-map ospf2eigrp deny 10
match tag 12348
route-map ospf2eigrp permit 20
match tag 120
route-map ospf2eigrp permit 30
match tag 567
route-map ospf2eigrp permit 40
match tag 7800
route-map ospf2eigrp permit 45
match tag 115
route-map ospf2eigrp permit 50
set tag 110

Here I have "pre-identified" or "pre-classified" all the tags I want pass-through. This way we can identify the originating protocol of every route in the EIGRP 12348 domain.

4) WHEN TO CONVERT TAGS

Another note to remember is that BGP does not use tags, but it does community values to identify routes. So on R2, R5, and R6 we will need to "convert" the tag to community value. And when we redistribute the other way, we need to make a community-list to match and drop that route.

For example on R2 we set the community of OSPF routes into BGP as follows:

route-map ospf2bgp permit 50
set community 110

On R5 and R6 this community is converted to a tag as follows:

ip community-list 1 permit 110

route-map bgp2ospf permit 20
match community 1
set tag 110

Now as long as we allow this tag to pass through on R7 and R8, R4 can identify these OSPF routes so it will not redistribute them back into OSPF area 0.

5) OPTIMAL ROUTING

Lastly, we are not concerned with optimal routing here. If you are tasked with making paths optimal, you will have to work with metrics or administrative distances to do so. But that's easy right? :)

Tuesday, August 26, 2008

IPV6 - OSPFv3, default route, RIPng, redistribution

This is the third of three ipv6 posts today. The others are below. Here we configure OSPFv3 over an nbma cloud, adevrtise a default route, and redistribute with RIPng.

Here is the topology:

|---RIPng---|-------OSPFv3 area 0---------|

[BB2]------[R5]---[FRAME]---[R1]---VLAN1001

Addressing:

R5-BB2 : 2001:192:10:1::/64
R1-R5 : 2001:CC1E:1:1515::/64
VLAN1001: FEC0:CC1E:1:1::/64

BB2 and R5 are doing RIPng (config not shown, it's easy enough!)
R5,R1 are doing OSPFv3, area 0 everywhere else.

Here is how I configured the neighbors over the FR cloud:

R1#show run int s1/0

interface Serial1/0
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::1/64
ipv6 ospf neighbor FE80::CE01:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 FE80::CE01:9FF:FEE8:0 105 broadcast
frame-relay map ipv6 2001:CC1E:1:1515::5 105 broadcast

R5#show run int s1/0

interface Serial1/0
no ip address
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::5/64
ipv6 ospf neighbor FE80::CE00:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 2001:CC1E:1:1515::1 501 broadcast
frame-relay map ipv6 FE80::CE00:9FF:FEE8:0 501 broadcast

Notice that I use the link-local address as the neighbor address.

R1#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface
150.1.5.5 1 FULL/DR 00:01:44 5 Serial1/0
R1#


R5 is learning VLAN 1001:

R5#show ipv6 route ospf
O FEC0:CC1E:1:1::/64 [110/65]
via FE80::CE00:9FF:FEE8:0, Serial1/0


R5 is also learning some loopback networks from BB2 via RIP:

R5#show ipv6 route rip

R 2001:205:90:31::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:220:20:3::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:222:22:2::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0


Task is to advertise default route to R1 via OSPFv3 without "default-information originate always" command. R5 should drop traffic unless it has a longer match. Sounds like a summary route, eh?! WRONG! we can't summarize intra-area, but we are allowed on static route...hmmm....We can point it to null and redistribute!

R5(config)#ipv6 route 0::/0 null0
R5(config-rtr)#redistribute static


Let's check R1:

R1#show ipv6 route ospf

R1#


Nothing!...well. The task says not to use the "default-information originate always" command. What if we leave off the always!

R5(config-rtr)#no redistribute static
R5(config-rtr)#default-information originate

R1#show ipv6 route ospf
OE2 ::/0 [110/1], tag 1
via FE80::CE01:9FF:FEE8:0, Serial1/0


There we go and we didn't need to redistribute static either. If you delete that default route to NULL, then the LSA disappears too!

So now R1 has a default route but BB2 still has no route back to VLAN1001. So we can redistribute into RIPng on R5:

R5(config)#ipv6 router rip RIPNG
R5(config-rtr)#redistribute ospf 1 metric 1


Ping from R1:

R1#ping 2001:205:90:31::1 source FEC0:CC1E:1:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:205:90:31::1, timeo
Packet sent with a source address of FEC0:CC1E:1:1::1
!!!!!

Friday, July 25, 2008

Route Redistribution Issues Part I – RIP and OSPF

This is part of task I had on IEWB volume 3 workbook lab 1. I tweaked it a little. I wanted to get better idea of redistribution when there are multiple points of redistribution. It is always the hardest concept for me to get my head around because there so many things going on. I know the tasks may only be a few points, but it affects reachability which can hurt you later if you do not have it.

If you develop a thought process for it and recognize patterns and spot issues beforehand, you will be better off. I don't have any configurations here, just my thought flow. I was doing this practice lab at the same but I just wanted to document the thoughts.


Perform redistribution between RIP and OSPF on R4 and R5 and ensure reachability to the loopback interfaces on R1 and R9 from anywhere when R4 or R5’s frame link are down. If both are down then reachability to R9 and R1 cannot be achieved from R2.

Thought Process:

First thing I would do is identify which networks need to be learned via each protocol on each router, along with back up routes:

Router

Destination

Primary Route

Backup Route

R1

R9, LAN59

RIP via R4

n/a

R4

R9, LAN59

R1

RIP via R5

RIP via R1

OSPF via R5

n/a

R5

R1, LAN14

R9

RIP via R4

RIP via R9

OSPF via R4

n/a

R9

R1, LAN14

RIP via R5

n/a

R2

All

OSPF via R4 or R5

n/a


Next thing is to break down the redistribution into steps. These steps can be in various orders which may affect traffic flow, but I like to start with the edge networks in and resolve issues as we progress. We have 4 steps here:

Step 1: Redistribute RIP into OSPF on R5
R2 now has access to R9 loopback and LAN59 via R5
R5 has no changes to it’s routes
R4 now learns the route to R9 and LAN59 via OSPF through R5
R1 no longer has a route to R9 or LAN59 because R4 learns these via OSPF, not RIP anymore

Step 2: Redistribute RIP into OSPF on R4
R2 now has access to R1 loopback and LAN14 via R4.
R4 is the same as in step 1.
R5 now learns the route to R1 Loopback and LAN14 via OSPF through R4
R9 cannot reach R1 anymore because R5 is learning R1 and LAN14 through OSPF, not RIP

Issues remaining after steps 1 and 2:
R1 or R9 cannot respond to pings from R2 because they do not have a route for the OSPF network.
R1 and R9 cannot reach each other’s loopbacks or connected LANs.

Step 3: Redistribute OSPF into RIP on R4
Here is we encounter a loop. The reason is that once R4 does this it will now advertise RIP routes back to R1 and R5 that may have already been in RIP to begin with. So the problems will be with any existing RIP routes on these routers. R5 currently has a RIP route for R9 loopback with a metric of 1. R4 is going to redistribute this route back to R5 also with a mteric of 1 (the metric is up to use, but I use 1 for example). R5 now will load share between two routes to R9. One router will be a loop (the one through R4). R5 has no way of knowing that this route is the same route it redistributed into OSPF. We can resolve this by setting a higher metric on the routes that R4 redistributes into RIP. Setting the metric to 2 in this example resolves the issue.

R2 now has reachability to R1 and LAN14, but still no reachability to R9 because R9 has no route back. R9 also has no route to R1.

Step 4: Redistribute OSPF into RIP on R5
In the final step of redistribution R5, we may cause another loop by advertising R1’s loopback back to R4 over the serial link with a metric 1. However, we set the metric to 2 to rpevent this.

Shutting down serial link between R4 and R5:
Because this link is not used for any transit networks, this link does not affect reachability to R1 or R9 whether up or down.

Shutting down only R5 frame-relay interface:
R5 loses its OSPF networks and learns all routes via RIP through R4. R4 uses the RIP link to reach R9 and LAN59.

Shutting down only R4 frame-relay interface:
R4 loses it OSPF networks and learns all routes via RIP through R5. LAN14 and R1 are still learned directly from R1.