Category Archives: CCNP ROUTE – Static Routing

Part 1: Setting up the new, bigger, and better lab to configure everything we’ve learned up to this point!

 

labbers_delight

As previously mentioned I believe, this will be a multi-part lab in which I will configure “Multi-Point” 2-way Redistribution / Policy-Routing / Distribute-Lists / Route-Maps / and troubleshooting all along the way.

Here are a few things I know I want to achieve over the several parts of this lab:

  • Authentication deep dive for all 3 protocols in Topology
  • DEEP Dive look at Redistribution with Route-Map tagging and Distribute-Lists
  • Policy Routing and Local Policy Routing configuration
  • 3-way Redistribution on R3 if possible, things might get crazy
  • Deep Dive into Policy Routing capabilities, applying around the network
  • Random other topics as I can think of them

I will be working as much with route-maps as possible, as they really are a huge chunk of all of those topics, so I believe those are critical to understand inside out. I have done a “wr er” and “reload” on all routers, and am going to configure the core network in the Topology, but I may review some of my previous posts to get my brain tuned up to lab until my brain melts out of my skull.

That being said I will just configure it for tonight, and add to it slowly while I am fresh, I don’t want to do anything while I am in zombie mode (like now) after a long work day.

So this will all be review, and as I said, saturate this network completely with all the concepts I have posted about and troubleshoot issues as needed.

I am going to whip up this Topology now, and we will get this party started on my next post, see you there 🙂

Part 4: Fixed OSPF Redistribution and NBMA, EIGRP Redistribution with a side of static routing (to begin with)

redistribution_frenzy

It is late so I am going to crunch in a quick lab to get everything reconfigured so it is pinging and happy, so I can get into EIGRP, and forget troubleshooting the NBMA was such a painfully simple answer. Thinking doing these labs in the middle of the night / morning is probably not too productive, but it did help me learn valuable lessons, namely DO NOT GLOSS OVER THE SIMPLE DETAILS EVER!

Even with the more complex show commands, and the debugs with the troubleshooting output in bulk, all it took was “show run” to have the problem glaring in my face.

Anyways, the topology is back on, a new (same looking) topology coming soon! I put RIP back on there, with Area 51 on R4’s loopback connecting the virtual-link to R3 (making Area 34 the transit area), and here are the results when I got on a spoke first (!!!) and pinged the other spoke to begin with (!!!!!!!!) to make sure layers 1 and 2 where not an issue:

R2#sh ip route
(Route codes redacted)

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
R       1.1.1.1 [120/1] via 172.12.123.1, 00:00:16, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
R       3.3.3.3 [120/2] via 172.12.123.3, 00:00:16, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
R       4.4.4.4 [120/3] via 172.12.123.3, 00:00:13, Serial0/0
     172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
R       172.12.34.0/24 [120/2] via 172.12.123.3, 00:00:17, Serial0/0
R       172.12.33.3/32 [120/2] via 172.12.123.3, 00:00:17, Serial0/0
R       172.12.44.4/32 [120/3] via 172.12.123.3, 00:00:17, Serial0/0
R       172.12.15.0/24 [120/1] via 172.12.123.1, 00:00:17, Serial0/0
C       172.12.123.0/24 is directly connected, Serial0/0
R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R2#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
…..

Again just to point out the difference in RIP metric in hop count / metric, preceded by its Administrative Distance 120. So as can be seen OSPF was Redistributed into the RIP domain by the routes we’re seeing, and I already know R4 has no RIP routes being injected into it’s domain. As like yesterday before we had the epic NBMA fail, I am going to try assigning a default route once more, and see if R2 can get a response:

R4(config)#ip route 0.0.0.0 0.0.0.0 172.12.34.3
R4(config)#^Z
*Jan 12 03:42:39.043: %SYS-5-CONFIG_I: Configured from console by console
R4#
ASR#2
[Resuming connection 2 to r2 … ]

R2#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/129/132 ms
R2#

And there it is, I love when things work, and now that everything is working I shall see if I can break it by Redistributing all protocols into each other and dropping the default route off R4. Here is all it takes:

R3(config)#router ospf 1
R3(config-router)#redistribute rip subnets metric-type 1 <- NO DEFAULT METRIC
R3(config-router)#
ASR#3
[Resuming connection 1 to r1 … ]

R1(config)#router eigrp 100
R3(config-router)#redistribute rip metric 1544 10 1 255 1500

And that should be it, RIP should be routing into OSPF and EIGRP. So as per my new tradition, I will ping from R4 first to my spoke R2 to make sure it’s still alive, and then to 5.5.5.5 – The ultimate test:

R4#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/128/132 ms
R4#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/68 ms
R4#

Along with that I found a notable behavior from R4’s E1 routes that should not have a default metric of 20:

R4#sh ip route
(Route codes redacted)

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O E1     1.1.1.1 [110/21] via 172.12.34.3, 00:01:28, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
O E1     2.2.2.2 [110/21] via 172.12.34.3, 00:01:28, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
O E1     3.3.3.3 [110/21] via 172.12.34.3, 00:01:28, FastEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
      5.0.0.0/32 is subnetted, 1 subnets
O E1     5.5.5.5 [110/21] via 172.12.34.3, 00:01:28, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1     172.12.15.0/24 [110/21] via 172.12.34.3, 00:01:28, FastEthernet0/1
O        172.12.33.3/32 [110/2] via 172.12.34.3, 00:49:37, FastEthernet0/1
C        172.12.34.0/24 is directly connected, FastEthernet0/1
L        172.12.34.4/32 is directly connected, FastEthernet0/1
C        172.12.44.0/24 is directly connected, Loopback44
L        172.12.44.4/32 is directly connected, Loopback44
O E1     172.12.123.0/24 [110/21] via 172.12.34.3, 00:01:28, FastEthernet0/1
R4#

***All of my E1 routes, with a distance of 21, the same as if you turn N2 routes into N1 routes in an NSSA OSPF Area, when the next connected router is an ASBR***

Now that I know this lab is fully configured and capable of routing across multiple protocols, I will start back on studying matching ACL’s and Route-Maps.

I aimed for Jan 1st to be all caught up, but I will take Jan 11th, next up I will be adding some routes (and adding an updated topology to these posts) to work with some new subjects!

Using Static Routes / Redistribution to overcome Stub to Stub communication

Topology_OSPF_Stubs

So I actually did not wr mem any routers from my previous lab where Area 15 and 34 were turned into virtual-links, so we are back to the NSSA for Area 15 and the Total Stub on Area 34. My goal is to figure out if and where static IP’s can be assigned to route traffic between Total Stub networks, and possibly get into Authentication and how it affects connectivity if time permits as I am fried already from work so going right back to the CLI is like pulling teeth some days 🙂 So the same old topology is shown that I will be working with.

So without reading the old post, I remember from R5 I could ping all the way to R4’s 172.12.34.4 FastEthernet interface, but couldn’t reach it’s loopback of 4.4.4.4 and vice versa to R5’s loopback of 5.5.5.5. So R1 and R3 are not learning these OSPF routes due to lack of a Virtual-Link, so I am thinking either a static route on each or a static route redistributed into OSPF (so this could get messy). Lets start on R1:

R1#ping 5.5.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1#conf t
R1(config)#ip route 5.5.5.5 255.255.255.255 fa0/1
R1(config)#do ping 5.5.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
R1(config)#

Easy as that, jump to R3 to create a static route to 4.4.4.4 and ping 5.5.5.5 from R4:

R4#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R4#

Where is my rage face emoji. There has to be a logical solution, and I think it is a static route needs to actually be added on those Non-Backbone routers as well, but I am going to confirm how far I can ping and not drop packets:
R4#ping 172.12.15.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.15.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms
R4#

Same thing as before, the return route needs to also be placed on the Stub routers to make this work I am hoping, that way I can say I learned something and get into Area Authentication. So I will just mirror the ip route statements on their stub routers:

R5(config)#ip route 4.4.4.4 255.255.255.255 fa0/1
R5(config)#do ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R5(config)#

So we have gone from U.U.U to complete packet loss, however I can still hit R4’s Fa0/1 IP:

R5#ping 172.12.34.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.34.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms
R5#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R5#

So something has got to give here, we went from an upstream router not knowing where to send traffic, to R4 and R5 dropping the others packets to the loopbacks. I first remove the static routes from R4 and R5 and ping again to confirm I am back to U.U.U, however I am going to get on the ASBR R1 and see if I can redistribute my was to routing success:

R1(config)#ip route 4.4.4.4 255.255.255.255 172.12.123.3
R1(config)#no ip route 5.5.5.5 255.255.255.255 fa0/1
R1(config)#ip route 5.5.5.5 255.255.255.255 172.12.15.5
R1(config)#router ospf 1
R1(config-router)#redistribute static subnets metric-type 1
R1(config-router)#

So as can be seen, to keep things consistent I changed the static route from an interface to the remote routers IP address, as I can’t send 4.4.4.4 traffic out the Serial interface as I have two spoke routers off of it and only one of them contains 4.4.4.4. Though it would be interesting to see if it would be 50% loss rate of packets or if they would all tank, I’ll try that out once I have this resolved. So here is how things look:

R3#show ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/65] via 172.12.123.1, 00:33:45, Serial0/2
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/65] via 172.12.123.2, 00:33:45, Serial0/2
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:33:45, Serial0/2
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/85] via 172.12.123.1, 00:07:17, Serial0/2
     172.12.0.0/24 is subnetted, 3 subnets
O IA    172.12.15.0 [110/65] via 172.12.123.1, 00:33:45, Serial0/2
     172.16.0.0/22 is subnetted, 1 subnets
O IA    172.16.8.0 [110/65] via 172.12.123.1, 00:33:45, Serial0/2
R3#

Ok, this HAS GOT TO WORK this time around, and yes I do just generally change the metric type to 1 automatically now with OSPF redistribution as not to get the seed metric of 20. So let the routing gods pass traffic between these two Stub networks so that I may move on:

R4#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms
R4#

YESSSSSS!!!!! YES YES YESSSSS!!!!!! TAKE THAT LOGICAL BEHAVIOR!!!

So that is awesome that I stumbled across that, worked through the issue, and learned a great lesson here about mixing static routing with Redistribution for Stub communication. That’s a lot of routing mechanisms working against a packet to get to it’s destination and back, but that packet was sent and returned! Now, I am going to break it again, because I am curious if I used interfaces instead of remote IP’s for the static routes:

R1(config)#no ip route 5.5.5.5 255.255.255.255 172.12.15.5
R1(config)#no ip route 4.4.4.4 255.255.255.255 172.12.123.3
R1(config)#ip route 5.5.5.5 255.255.255.255 fa0/1
R1(config)#ip route 4.4.4.4 255.255.255.255 s0/0

I first want to try pinging from R1 to 4.4.4.4 to see if there is connectivity at all:

R1(config)#do ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1(config)#

I do believe if this was an EIGRP topology (which I may check at some point), it would actually equal-cost load balance that traffic so we might see ping results like ..!.! or basically 50% packet loss sending the traffic to both neighbors and only one replying.

HOWEVER, this is not EIGRP, so I will add the static routes by remote IP again, and I am going to be a slacker and call it a night here on the equipment because my belly is grumbling feed me and I feel I have learned a LOT from this lab session.

Next up, Authentication, then Redistribution and I think we are caught up!