Category Archives: CCNP ROUTE – Derp Moment

Failed first Route attempt, not due to content here being incorrect, but some Cisco gotchas and the timer beat me up!

First and foremost, I think saying that taking the route and failing the first time should be actually fairly standard, unless you use brain dumps or study / lab from CCIE level material (and even then…).

That being said, lets get into my thoughts:

It has the same old Cisco gotchas, so always compare the output / commands shown to the question context, as they may be two completely different things. Along with that, there are the classic Cisco gotchas that you can’t hardly prepare for unless as said you brain dump / come from a STRONG routing background / study at a CCIE level for years.

Also the allotted time seems like so much at first you can cozy up in your first sim and take your time, and that is not the case – Gas pedal to the floor until your exam is being scored!! Seriously do not make this mistake, I had to skip an entire sim due to time because of this and this really set me back!

 

I was glad to see that got some of that terrible English sentences out of the exam, but they still find a way to make a question clearly tricky, or the answers themselves.

If you are finding it difficult to read output or answers separately, use your dry erase board to cover the lines below it, the exam room is no place to look cool.

I’ve said it before, but write done some sort of subnet shortcut you’ve learned on the dry erase board provided before beginning the exam, it helps a lot to have a quick reference when your staring at a lot of numbers you need to decipher quickly.

Verification commands are just as important to know, as these are how you find the source of an issue or a question, so be familiar with how to use them to immediately identify which router you need to look at for the answer / configuration.

Also, I’d say relax, I was so worked up and its just not as hard of an exam as you would think it to be. It’s just some questions you’ll see and mouth “wtf” at the screen, and that is why I say a first time Fail should almost be expected, and then a quick brush up on that miscellaneous knowledge they throw in there and round number two should be a Pass!

(I hope)

If you have any questions about the exam, my experience, or any pointers before you go in for your attempt please feel free to email me at my ‘about me’ page with (loopedback) in the subject line!

Exam # 2 scheduled for 6/9 in the afternoon, which is when I pass this beast and move onto the other two beasts, SWITCH and TSHOOT!

 

Part 1: Configuration of this new Topology in IPv6

ospfv3_multiarea_topology

We have a lot to accomplish, but first since I did a “wr er” like a nerd I have to reconfigure all the IP addresses again (as you see in the Topology I changed them to make them a bit more intuitive).

One thing I wanted to point out while configuring this whole lab (and it’s painful to configure and remember all the addressing and formatting), I got this output on the Ethernet segment after I took one of the interfaces out of the Area # they were neighbors in:

R2(config-if)#
*Mar  1 20:45:38.645: %OSPFv3-4-AREA_MISMATCH: Received packet with incorrect area from FE80::20F:23FF:FE09:B180, FastEthernet0/0, area 0.0.0.0, packet area 0.0.0.23
R2(config-if)#
*Mar  1 20:45:48.645: %OSPFv3-4-AREA_MISMATCH: Received packet with incorrect area from FE80::20F:23FF:FE09:B180, FastEthernet0/0, area 0.0.0.0, packet area 0.0.0.23

So if that is seen, you may just need to adjust that interfaces area to resolve.

Now, I’ve been at this believe it or not for about an hour troubleshooting an issue, that was simply resolved because an interface was shut down on R4, so I am going to just put a halt here as I am mentally fried.

A couple things I wanted to point out, first I’d like to post the entire “sh run” of R3:

R3#sh run
Building configuration…

*Mar  2 05:37:15.963: %SYS-5-CONFIG_I: Configured from console by console
Current configuration : 1329 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$QFdX$9tC33yHOlq4pSVjJcmMnd0
!
no aaa new-model
!
resource policy
!
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
!
!
no ip domain lookup
ipv6 unicast-routing
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
controller T1 0/0
 framing sf
 linecode ami
!
controller T1 0/1
 framing sf
 linecode ami
!
!
!
!
!
!
interface Loopback3
 no ip address
 ipv6 address 2033::1/128
 ipv6 ospf 1 area 3
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2023::3/64
 ipv6 enable
 ipv6 ospf 1 area 0
!
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 ipv6 address 2034::3/64
 ipv6 enable
 ipv6 ospf 1 area 34
!
interface Serial0/2
 no ip address
 shutdown
 ipv6 address 2001::3/64
 ipv6 enable
 ipv6 ospf priority 0     <- Turning off OSPF Priority for NBMA requires ipv6 in command
 ipv6 ospf 1 area 123
!
interface Serial0/3
 no ip address
 shutdown
!
!
!
ip http server
no ip http secure-server
!
ipv6 router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 password CCNP
 logging synchronous
 login
!
!
end

R3#

So it’s basically the same, but those IPv6 addresses can be absolute brain murder to work with and configure when your tired. The only way I actually caught my issue before I entirely gave up, was through “debug ipv6 ospf pack” and noticed I wasn’t getting any.

That led to a “sh ip int bri” just to check if stuff is Up/Down or Down/Down, and sure enough Fa0/1 was Administratively down, and of course after a length of troubleshooting the answer was that easy.

Anyways, check it out:

R4#ping 2022::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2022::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/3/8 ms
R4#sh ipv6 ospf nei

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
3.3.3.3           1   FULL/BDR        00:00:30    5               FastEthernet0/1
R4#sh ipv6 route ospf
IPv6 Routing Table – default – 7 entries
Codes: C – Connected, L – Local, S – Static, U – Per-user Static route
       B – BGP, HA – Home Agent, MR – Mobile Router, R – RIP
       I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
       D – EIGRP, EX – EIGRP external, NM – NEMO, ND – Neighbor Discovery
       l – LISP
       O – OSPF Intra, OI – OSPF Inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
       ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
OI  2022::1/128 [110/2]
     via FE80::20F:23FF:FE09:B181, FastEthernet0/1
OI  2023::/64 [110/2]
     via FE80::20F:23FF:FE09:B181, FastEthernet0/1
OI  2033::1/128 [110/1]
     via FE80::20F:23FF:FE09:B181, FastEthernet0/1
R4#

So I am able to ping across the world from R4 thus far, or the Area 34 / 0 world, I am not touching R1 tonight as I’d like to dig into Redistribution when I go there, however I’d like to see R3’s “sh ipv6 ospf” output which is surprisingly pretty little:

R3#sh ipv6 ospf
 Routing Process “ospfv3 1” with ID 3.3.3.3
 It is an area border router
 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of areas in this router is 4. 4 normal 0 stub 0 nssa
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 1
        SPF algorithm executed 5 times
        Number of LSA 10. Checksum Sum 0x058EAA
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
    Area 3
        Number of interfaces in this area is 1
        SPF algorithm executed 7 times
        Number of LSA 6. Checksum Sum 0x03BE1F
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
    Area 34
        Number of interfaces in this area is 1
        SPF algorithm executed 5 times
        Number of LSA 10. Checksum Sum 0x052BC0
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
    Area 123
        Number of interfaces in this area is 1
        SPF algorithm executed 2 times
        Number of LSA 6. Checksum Sum 0x03D444
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

R3#

So next lab is finishing off the config with a quick config on S0/0 on R1, then move into Redistribution of IPv6 addresses, WOOOOOOOO!!! 😀

VRF-Lite: Complete configuration and explanation of behaviors, OSPF and EIGRP demonstration and how they work (or why the don’t work)

vrf_top_plain_vrf_labeled

To note I used the same color I have previously for IPSec VPN tunnels, however that color is more just one of the few colors not reserved for protocols (as I generally use blue for OSPF, red for RIP, and orange for EIGRP), so this time green is for VRF-Lite.

So I wanted to pull quick from the last lab quickly the two pieces of setup already done on the equipment from the last post:

R1:

R1(config)#int fa0/0
R1(config-if)#no shut
R1(config-if)#int fa0/0.2
R1(config-subif)#encap dot1q 2
R1(config-subif)#ip add 10.2.2.1 255.255.255.0
R1(config-subif)#int fa0/0.3
R1(config-subif)#encap dot1q 3
R1(config-subif)#ip add 10.3.3.1 255.255.255.0
R1(config-subif)#int fa0/0.4
R1(config-subif)#encap dot1q 4
R1(config-subif)#ip add 10.4.4.1 255.255.255.0
R1(config-subif)#

SW1:

SW1(config)#int fa0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 2
SW1(config-if)#int fa0/3
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 3
SW1(config-if)#int fa0/4
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 4
SW1(config-if)#

Now to demonstrate something, I have removed sub-interface .3 and .4’s IP address, which will later be revisited.

Now as VRF previously described is separating networks with virtual routing instances, the first part of the configuration is to just simply create those instances:

R1(config)#ip vrf VRF2
R1(config-vrf)#?
IP VPN Routing/Forwarding instance configuration commands:
  bgp           Commands pertaining to BGP
  context       Associate SNMP context with this vrf
  default       Set a command to its defaults
  description   VRF specific description
  exit          Exit from VRF configuration mode
  export        VRF export
  import        VRF import
  maximum       Set a limit
  mdt           Backbone Multicast Distribution Tree
  no            Negate a command or set its defaults
  rd            Specify Route Distinguisher
  route-target  Specify Target VPN Extended Communities
  vpn           Configure VPN ID as specified in rfc2685

R1(config-vrf)#exit
R1(config)#ip vrf VRG3
R1(config-vrf)#EXIT
R1(config)#no ip vrf VRG3
% IP addresses from all interfaces in VRF VRG3 have been removed

R1(config)#ip vrf VRF3
R1(config-vrf)#exit
R1(config)#ip vrf VRF4
R1(config-vrf)#exit
R1(config)#

So I left the output from the VRF mode it drops you into, to show the more advanced options not covered in the CCNP ROUTE exam, more geared to non-Lite VRF (however we may see them in the BGP section). Also I highlighted an error from my first configuration derp of the night, and this illustrates a behavior of VRF I wanted to cover first.

Unlike a majority of configurations on Cisco routers, with VRF, it does matter the order in which you enter commands because that may lead to it removing your IP addresses.

This is because the way VRF takes the route out of the “global route table” and into its own, is by removing the IP address literally from the interface (thus removing it from the global route table), making you manually re-enter it (thus putting it into its VRF instances route table). So I am wondering if the error in red will force VRF enabled interfaces to lose their IP address – I will test this quickly after step # 2 in our configuration.

Being that entering VRF on the interfaces is step #2 in configuration, I took the liberty of showing you how it will react to fa0/0.2 when I enter it on an interface with a current IP, as compared to me enabling VRF on the interface and then entering the IP address:

R1(config)#int fa0/0.2
R1(config-subif)#ip vrf forwarding VRF2
% Interface FastEthernet0/0.2 IP address 10.2.2.1 removed due to enabling VRF VRF2
R1(config-subif)#int fa0/0.3
R1(config-subif)#ip vrf forwarding VRF3
R1(config-subif)#ip add 10.3.3.1 255.255.255.0
R1(config-subif)#int fa0/0.4
R1(config-subif)#ip vrf forwarding VRF4
R1(config-subif)#ip add 10.4.4.1 255.255.255.0
R1(config-subif)#exit
R1(config)#do sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  up                    up
FastEthernet0/0.2          unassigned      YES NVRAM  up                    up
FastEthernet0/0.3          10.3.3.1        YES manual up                    up
FastEthernet0/0.4          10.4.4.1        YES manual up                    up
Serial0/0                  unassigned      YES NVRAM  administratively down down
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial0/1                  unassigned      YES NVRAM  administratively down down
R1(config)#

So as you can see, the order of the commands allowed the IP not to be stripped off .3 and .4, and will now need to be re-entered on .2:

R1(config)#int fa0/0.2
R1(config-subif)#ip add 10.2.2.1 255.255.255.0
R1(config-subif)#exit
R1(config)#do show ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  up                    up
FastEthernet0/0.2          10.2.2.1        YES manual up                    up
FastEthernet0/0.3          10.3.3.1        YES manual up                    up
FastEthernet0/0.4          10.4.4.1        YES manual up                    up
Serial0/0                  unassigned      YES NVRAM  administratively down down
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial0/1                  unassigned      YES NVRAM  administratively down down
R1(config)#

There we go, now lets delete an instance and see if it strips the ip address off the interface:

R1(config)#no ip vrf VRF4
% IP addresses from all interfaces in VRF VRF4 have been removed
R1(config)#do sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  up                    up
FastEthernet0/0.2          10.2.2.1        YES manual up                    up
FastEthernet0/0.3          10.3.3.1        YES manual up                    up
FastEthernet0/0.4          unassigned      YES manual up                    up
Serial0/0                  unassigned      YES NVRAM  administratively down down
FastEthernet0/1            unassigned      YES NVRAM  administratively down down
Serial0/1                  unassigned      YES NVRAM  administratively down down
R1(config)#

It certainly did, and there are a few things here I want to cover, bullet point style:

  • Adding VRF to an interface with an IP, and removing a VRF instance will strip the IP address off any interface running that VRF instance
  • Any IP address removed will have to be manually re-entered on that interface
  • If the VRF instance was removed, the IP address / network will be back in the route table after manually re-adding, if it was stripped due to adding VRF to an interface, it will no longer be in the global routing table after manual re-entering it
  • VRF-Lite configurations, at least in this demonstration, are completely locally significant and downstream routers are completely unaware and will not need special commands when trying to ping R1 or when adding dynamic routing protocols (Only R1 will require them).

So then where do they all go? Good question! They go into their VRF instances routing table, which after adding a route protocol we will see a bit more illustrated:

R1#sh ip route

Gateway of last resort is not set

There be nothing here in the global route table, and that is because the only IP addresses this router knows of are the connected sub-interfaces, and they are now in their own VRF routing instances.

That being said, here is how to see them, with some ? output left in there to see options available for later use in higher level studies (or later in the current course):

R1#show ip route ?

  Hostname or A.B.C.D  Network to display information about or hostname
  bgp                  Border Gateway Protocol (BGP)
  connected            Connected
  dhcp                 Show routes added by DHCP Server or Relay
  eigrp                Enhanced Interior Gateway Routing Protocol (EIGRP)
  isis                 ISO IS-IS
  list                 IP Access list
  mobile               Mobile routes
  odr                  On Demand stub Routes
  ospf                 Open Shortest Path First (OSPF)
  profile              IP routing table profile
  rip                  Routing Information Protocol (RIP)
  static               Static routes
  summary              Summary of all routes
  supernets-only       Show supernet entries only
  track-table          Tracked static table
  update-queue         Queue of RIB updates
  vrf                  Display routes from a VPN Routing/Forwarding instance
  |                    Output modifiers
  <cr>

R1#show ip route vrf ?

  WORD  VPN Routing/Forwarding instance name

R1#show ip route vrf VRF4 ?
  Hostname or A.B.C.D  Network to display information about or hostname
  bgp                  Border Gateway Protocol (BGP)
  connected            Connected
  dhcp                 Show routes added by DHCP Server or Relay
  eigrp                Enhanced Interior Gateway Routing Protocol (EIGRP)
  isis                 ISO IS-IS
  list                 IP Access list
  mobile               Mobile routes
  odr                  On Demand stub Routes
  ospf                 Open Shortest Path First (OSPF)
  profile              IP routing table profile
  rip                  Routing Information Protocol (RIP)
  static               Static routes
  summary              Summary of all routes
  supernets-only       Show supernet entries only
  track-table          Tracked static table
  update-queue         Queue of RIB updates
  |                    Output modifiers
  <cr>

R1#show ip route vrf VRF4

Routing Table: VRF4

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.4.4.0 is directly connected, FastEthernet0/0.4
R1#

And there it is, I highlight my commands (and the options I chose) as with that much modifier output from ?, it is hard to see where the actual command is.

Alright, so our router now has 3 of these VRF instances running, and I think at this point we should know our options to view our VRF information that is configured:

R1#show ip vrf
  Name                             Default RD          Interfaces
  VRF2                             <not set>           Fa0/0.2
  VRF3                             <not set>           Fa0/0.3
  VRF4                             <not set>           Fa0/0.4

R1#sh int fa0/0.2
FastEthernet0/0.2 is up, line protocol is up
  Hardware is AmdFE, address is 000e.8475.04e0 (bia 000e.8475.04e0)
  Internet address is 10.2.2.1/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID  2.
  ARP type: ARPA, ARP Timeout 04:00:00
  Last clearing of “show interface” counters never

HUGE DISCLAIMER TO THE ABOVE OUTPUT : I believe because my WAN routers for the NBMA are running IOS code 12.x it does not show the VRF forwarding instance on my “show int” output but on 15.x IOS code I believe it does.

You can also see the VRF instance in each interfaces output in “sh run” but do not count on that being an available command on exam day.

MOVING RIGHT ALONG.

To ping neighbors that are in a particular VRF instance will fail, because a general ping only tests connectivity in the global route table:

R1#ping 10.4.4.4

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

For this, we need to add some VRF commands to the ping, to make it use our virtual routing instances route table:

R1#ping ?
  WORD       Ping destination address or hostname
  appletalk  Appletalk echo
  clns       CLNS echo
  decnet     DECnet echo
  ip         IP echo
  ipv6       IPv6 echo
  ipx        Novell/IPX echo
  srb        srb echo
  tag        Tag encapsulated IP echo
  vrf        Select VPN routing instance
  <cr>

R1#ping vrf ?
  WORD  VPN Routing/Forwarding instance name

R1#ping vrf VRF4 ?
  WORD       Ping destination address or hostname
  appletalk  Appletalk echo
  clns       CLNS echo
  decnet     DECnet echo
  ip         IP echo
  ipv6       IPv6 echo
  ipx        Novell/IPX echo
  srb        srb echo
  tag        Tag encapsulated IP echo
  <cr>

R1#ping vrf VRF4 10.4.4.1

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

So at this point, it can be noticed that when using VRF, you need to define its instance in basically everything that you do on the router it is configured on, and routing protocols are not immune to this either. So, speaking of which, lets configure us some OSPF first, then we’ll remove it and try EIGRP.

What I like about this demonstration, is that it shows a purpose for both having different locally significant processes for OSPF and VRF. It also shows that when configuring OSPF for VRF, it makes you define the VRF instance ensuring that networks in other VRF instances stay in their own VRF instances:

R1(config)#router ospf 2 ?
  vrf  VPN Routing/Forwarding Instance
  <cr>

R1(config)#router ospf 2 vrf ?
  WORD  VPN Routing/Forwarding Instance (VRF) name

R1(config)#router ospf 2 vrf VRF2 ?
  <cr>

R1(config)#router ospf 2 vrf VRF2
R1(config-router)#network 10.2.2.0 0.0.0.255 area 0
R1(config-router)#exit
R1(config)#router ospf 3 vrf VRF3
R1(config-router)#network 10.3.3.0 0.0.0.255 area 0
R1(config-router)#exit
R1(config)#router ospf 4 vrf VRF4
R1(config-router)#network 10.4.4.0 0.0.0.255 area 0
R1(config-router)#exit
R1(config)#

Notice from the ? output, VRF is the only thing proceed “router ospf (process #)” that can be configured, so that extended command is made solely for VRF. So I put in our VRF instances 2 / 3 / 4 in their own OSPF processes 2 / 3 / 4 but made them all be in Area 0 which makes this technically makes this 2 different types of OSPF router:

  • A backbone router = Must have at least one interface in Area 0
  • An Internal router = Only has OSPF interfaces in a single Area
  • Not an ABR (Area Boarder Router) because that must have one interface in Area 0 and another interface in a non-0 Area

Really wanted to stress that it isn’t an ABR, as I thought it was also that, and after double checking my OSPF Fundamentals in a can post the definition does not fit – THIS IS IT IS WHY IT IS GOOD TO CONTINUOUSLY INCORPORATE OLD LESSONS WITH NEW LESSONS TO KEEP THE KNOWLEDGE UP IN THE OL STEEL TRAP ON YOUR SHOULDERS!

Now, in R2, R3, and R4 I will put them in OSPF Process 1 because the process is locally significant only so it will not matter. I will also create a quick loopback on them to make sure we are advertising routes back to R1:

R2(config)#int lo2
R2(config-if)#
*Mar  1 21:20:51.863: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback2, changed state to up
R2(config-if)#ip add 2.2.2.2 255.255.255.0
R2(config-if)#router ospf 1
R2(config-router)#network 10.2.2.0 0.0.0.255 area 0
*Mar  1 21:21:51.777: %OSPF-5-ADJCHG: Process 1, Nbr 10.2.2.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
R2(config-router)#network 2.2.2.0 0.0.0.255 area 2
R2(config-router)#

You can see the adjacency back to R1 form before the loopback network can even be added, I’ll save the output from the other two routers as it is the exact same except their loopbacks will be 3.3.3.0/24 and 4.4.4.0/24.

  • One other note, R2 / R3 / R4 are now ABR’s because they have their fa0/0 interface in Area 0 and their loopback interface in Area #, so they are both a Backbone router and a ABR router in OSPF terminology

However from the above output, I wanted to show there are no extended VRF commands on the remote routers from R1 or matching process #’s needed, so lets see how R1 see’s everything:

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           1   FULL/DR         00:00:33    10.4.4.4        FastEthernet0/0.4
3.3.3.3           1   FULL/DR         00:00:38    10.3.3.3        FastEthernet0/0.3
10.2.2.2          1   FULL/DR         00:00:31    10.2.2.2        FastEthernet0/0.2
R1#

As can be seen, “sh ip ospf nei” shows them whether they are in their own VRF’s or not, they are still OSPF neighbors, however even after a “clear ip ospf proc” on both R1 and R2 it is still showing 10.2.2.2 as it’s RID instead of the highest logical address 2.2.2.2.

So first from R1, lets see if we are getting routes advertised from all 3 neighbors:

R1#show ip route vrf VRF2

Routing Table: VRF2

Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/2] via 10.2.2.2, 00:02:39, FastEthernet0/0.2
     10.0.0.0/24 is subnetted, 1 subnets
C       10.2.2.0 is directly connected, FastEthernet0/0.2
R1#show ip route vrf VRF3

Routing Table: VRF3

Gateway of last resort is not set

     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/2] via 10.3.3.3, 00:03:00, FastEthernet0/0.3
     10.0.0.0/24 is subnetted, 1 subnets
C       10.3.3.0 is directly connected, FastEthernet0/0.3
R1#show ip route vrf VRF4

Routing Table: VRF4

Gateway of last resort is not set

     4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/2] via 10.4.4.4, 00:03:04, FastEthernet0/0.4
     10.0.0.0/24 is subnetted, 1 subnets
C       10.4.4.0 is directly connected, FastEthernet0/0.4
R1#

After going back to R2 and doing “sh ip route” and confirming 2.2.2.0/24 is in the global route table, and “sh ip proto” shows 10.2.2.2 as the RID, and “sh ip int bri” confirms 10.2.2.2 is NOT on a logical interface I have no idea what’s going on.

I’d normally dig into that a little more, but it’s getting late, and I need to wrap this up, but want to test EIGRP as well so I’m going to quickly change the routing protocol to EIGRP to see if it works the same:

R1(config)#
R1(config)#
R1(config)#router eigrp ?


  <1-65535>  Autonomous system number

R1(config)#router eigrp 200 ?

  <cr>

R1(config-router)#no auto

R1(config-router)#?

Router configuration commands:
  address-family       Enter Address Family command mode
  auto-summary         Enable automatic network number summarization
  bfd                  BFD configuration commands
  default              Set a command to its defaults
  default-information  Control distribution of default information
  default-metric       Set metric of redistributed routes
  distance             Define an administrative distance
  distribute-list      Filter networks in routing updates
  eigrp                EIGRP specific commands
  exit                 Exit from routing protocol configuration mode
  help                 Description of the interactive help system
  maximum-paths        Forward packets over multiple paths
  metric               Modify EIGRP routing metrics and parameters
  neighbor             Specify a neighbor router
  network              Enable routing on an IP network
  no                   Negate a command or set its defaults
  offset-list          Add or subtract offset from RIP metrics
  passive-interface    Suppress routing updates on an interface
  redistribute         Redistribute information from another routing protocol
  timers               Adjust routing timers
  traffic-share        How to compute traffic share over alternate paths
  variance             Control load balancing variance

R1(config-router)#network ?

  A.B.C.D  Network number

R1(config-router)#network 10.2.2.0 0.0.0.255 ?

  <cr>

R1(config-router)#network 10.2.2.0 0.0.0.255
R1(config-router)#exit
R1(config)#router eigrp 300
R1(config-router)#network 10.3.3.0 0.0.0.255
R1(config-router)#exit
R1(config)#router eigrp 400
R1(config-router)#network 10.4.4.0 0.0.0.255
R1(config-router)#exit

I’ve highlight my output again in red, as there is a lot of output here that I want to illustrate mentions ABSOLUTELY NOTHING ABOUT VRF ANYWHERE WITH EIGRP.

So I just put them in their own AS’s, but I am not feeling good about this, as not defining the virtual routing process, I am assuming it is going to try to pull from the global route table. So on the neighbors I will use matching AS numbers (as required to match to form an adjacency with EIGRP neighbors, along with k weights), and lets see if we get some neighbors to form:

R2(config)#router eigrp 200
R2(config-router)#no auto
R2(config-router)#network 10.2.2.0 0.0.0.255
R2(config-router)#network 2.2.2.0 0.0.0.255
R2(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1(config)#do sh ip eigrp nei
IP-EIGRP neighbors for process 200
IP-EIGRP neighbors for process 300
IP-EIGRP neighbors for process 400
R1(config)#

Yeah, it looks like EIGRP is not going to work with VRF instances like OSPF did, I assume BGP will as well be we have yet to get into BGP yet in my studies. So I won’t go on to configure the other routers as we know it’s not going to work.

That concludes VRF-Lite, lots of good information to go with the configurations, now onward to IPv6! 🙂

Part 5: Turning “IP Routing” on for Layer 3 SW1, Policy / Local Policy Routing, found sub-optimal routing due to AD! (Will be 6th lab to troubleshoot)

labbers_delight_rev3

I took a quick moment to post before this, advising not to study or lab tired, cause as can be seen towards the end of my Part 4 of this lab I am just tired and swinging at air.

Anyway, we now have R1 and R3 both acting as ASBR’s, with R1 doing 2-way route-tagged Distribution and R3 doing 3-way tagged Route Redistribution. We even still have authentication running on all routing domains, life does not get much better than this!

Honestly the fact that I have all protocol Authentication configurations documented, and how that all fits together, in addition to a solid understand of Distribute-List configuration I am very happy. The fact that I was able to get Multi-Point 2-way and 3-way routing to play nice (with some troubleshooting) is awesome, so Policy Routing is going to be my wrap up here to this lab because I have wanted to make the Summary Route do sub-optimal for half the routes since this began! 🙂

 

Quickly turning on L3 functionality for SW1 and testing connectivity

 

I probably didn’t need the new topic blue header for this, but I never know what I’m in for starting out with something new to the lab, so I put SW1 on the RIP network and want to see if it’s pingable with just a management IP for Vlan1.

So the quick config on SW1:

SW1(config)#ip routing
SW1(config)#router rip
SW1(config-router)#no auto
SW1(config-router)#network 172.12.23.0

And then a quick test from R5 to see if it can see it all the way down there:

R5#ping 172.12.23.1

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

Woohoo! Sweet Sweet connectivity, now to path selection / manipulation with PBR.

 

Policy Routing Configuration / Local Policy Routing configuration

 

Again once you know route-map configuration, PBR is a walk in the park to setup and apply, which is what I say right before I run into 1000 unforseen problems. So I would like half the traffic from our Summary Route to take a different path over the NBMA, as it won’t do equal cost load balancing by default the way EIGRP will, so I’ll set it myself:

R1(config)#$ 105 permit ip 100.1.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#$ 105 permit ip 100.2.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#$ 105 permit ip 100.3.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#$ 105 permit ip 100.4.0.0 0.0.255.255 172.12.23.0 0.0.0.255
R1(config)#route-map SummaryTrafficHop permit 10
R1(config-route-map)#match ip add 105
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#int fa0/1
R1(config-if)#ip policy route SummaryTrafficHop
R1(config-if)#

So it is now set up on R1 to filter said networks in the summary route, let’s test the preferred route in general from R5, then the networks involved in the Policy Route:

R5#traceroute 172.12.23.1

Type escape sequence to abort.
Tracing the route to 172.12.23.1

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 32 msec 36 msec 32 msec
  3 172.12.23.1 32 msec *  32 msec
 
R5#traceroute 172.12.23.1 source 100.4.0.1

Type escape sequence to abort.
Tracing the route to 172.12.23.1

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 32 msec 32 msec 36 msec
  3  *
    172.12.23.1 32 msec *
R5#traceroute 172.12.23.1 source 100.5.0.1

Type escape sequence to abort.
Tracing the route to 172.12.23.1

  1 172.12.15.1 4 msec 0 msec 4 msec
  2 172.12.123.3 32 msec 32 msec 32 msec
  3 172.12.23.1 32 msec *  32 msec
R5#

This really surprised me at first, as when there was a Router connected to R2 and R3 via FastEthernet, we would see those traceroute returns up to R1 and back to the other spoke even using OSPF across the board. With a switch on the Ethernet segment however, it is that “One and Done” I was talking about wasn’t possible to truly configure PBR along a network path. I personally think Chris Bryant did a really horse sh*t job of teaching that section, and as much as I love his training, I would say that right to his face 🙂

So for future reference, if this type of Topology pops up with Policy Routing in question, you will need to configure Policy Routes on the next-hop Router to then direct traffic onto the Ethernet to its destination rather than back over the NBMA.

THAT BEING SAID, I THINK WE NEED TO INTRODUCE A LITTLE ANARCHY TO THE NETWORK, AND DOING SO WITH A POLICY ROUTE:

R1(config)#access-list 111 permit ip 11.11.11.0 0.0.0.255 host 4.4.4.4
R1(config)#route-map LocalNextHop permit 10
R1(config-route-map)#match ip add 111
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#

Now I know I don’t even NEED to tell you at this point, but that is a sub-optimal path even if it zip across the FastEthernet instead of across the Serial Link and Back to R3 to reach R4’s loopback address of 4.4.4.4, but lettuce see what happens when we traceroute it:

R1(config)#access-list 111 permit ip 11.11.11.0 0.0.0.255 host 4.4.4.4
R1(config)#route-map LocalNextHop permit 10
R1(config-route-map)#match ip add 111
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#do traceroute 4.4.4.4 source 11.11.11.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.3 76 msec 32 msec 32 msec
  2 172.12.34.4 33 msec *  32 msec
R1(config-route-map)#

… The result of this traceroute displeases me. However, after staring at that configuration for a moment, I realize I completely spaced putting in the actual local policy statement.

This is why I made a post about studying tired, and why I am wrapping this up !

R1(config)#ip local policy route LocalNextHop
R1(config)#do traceroute 4.4.4.4 source 11.11.11.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.2 32 msec 32 msec 32 msec
  2 172.12.123.1 24 msec 24 msec 24 msec
  3 172.12.123.3 56 msec 52 msec 57 msec
  4 172.12.34.4 56 msec *  52 msec
R1(config)#

I am a bit surprised by this, I would have thought it would take the ethernet segment over to R3, I must advice R3’s route table quick to understand this madness of sending back over the Serial Link rather than through the Ethernet:

R2#show ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 02:03:41, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 02:03:41, Serial0/0
     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/2] via 172.12.123.3, 02:03:41, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 02:03:41, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/20] via 172.12.123.3, 02:03:42, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E2    172.12.34.0 [110/20] via 172.12.123.3, 02:03:44, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 02:03:44, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 02:03:44, Serial0/0
R2#

I smell a 6th lab needed for sub-optimal routing, and changing AD’s! This should have taken the path through the RIP domain to get to R4 (along with other traffic), however it’s the tie breaker (it’s AD) beat RIP 110 vs 120 so the OSPF route is in the route table as an E2 route.

This is a good note to end it on for me, next lab I will be troubleshooting some sub-optimal routing I find around the network with PBR and AD changes, then it is time to learn about and configure some VPN’s on our Authenticated and Redistributed monster of a network 🙂

Part 4: The right ACL for the right job (Distribute-List vs Route-Map), Configuring 3-way Route Redistribution with a lot of failures but final success!!!

labbers_delight_rev3

(Added interface #’s to the Topology as we increase working with both IP’s and interfaces)

I wanted to touch this quick before moving on to policy routing, whether Distribute-Lists can block certain networks from a Summary Route, or if it’s possibly at all. So I’ll run through it quick here to move on:

 

Distribute-List vs Summary Route on R5, Standard vs Extended ACL’s

 

First I want to confirm that my Distribute-List configured in OSPF is still blocking 5.5.5.5 from Redistributing into OSPF from the vantage of R2:

R2#show ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:05:28, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:05:28, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:05:28, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:05:28, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:05:28, Serial0/0
R2#

It looks like the Distribute-List is still rocking, so I am going to attempt to add onto the existing ACL on R1 for it:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#do sh access-list 5
Standard IP access list 5
    10 deny   5.5.5.5 (1 match)
    20 permit any (3 matches)
R1(config)#access-list 5 ?
  deny    Specify packets to reject
  permit  Specify packets to forward
  remark  Access list entry comment

R1(config)#access-list 5 deny ?
  Hostname or A.B.C.D  Address to match
  any                  Any source host
  host                 A single host address

R1(config)#access-list 5 deny 100.3.0.0 ?
  A.B.C.D  Wildcard bits
  log      Log matches against this entry
  <cr>

R1(config)#access-list 5 deny 100.3.0.0 0.0.255.255 ?
  log  Log matches against this entry
  <cr>

This is to demonstrate that with Standard Access-Lists you cannot add lines where you need them, that is going to require an Extended Access-Lists. Any new / additional statements to ACL 5 will be tacked onto the end, and they will be useless due to the permit any already on the ACL.

SO, I will blow away that ACL and try an Extended ACL that just uses ‘any’ for a destination addy, to simulate the feel of a Standard ACL. I’m also going to give it a name, to see if Distribute-Lists will accept named ACL’s, and it’s name will be “Bob”.

Now I have a couple piece of output here, as I was curious after I remove the list, will the Distribute-List dynamically be pulled from the OSPF config once it is removed from the router, and if it is isn’t will R2 then be able to see 5.5.5.5 anyways:

R1(config)#no access-list 5
R1(config)#ip access-list extended Bob
R1(config-ext-nacl)#10 deny ip host 5.5.5.5 any
R1(config-ext-nacl)#20 deny ip 100.4.0.0 0.0.255.255 any
R1(config-ext-nacl)#30 deny ip 100.6.0.0 0.0.255.255 any
R1(config-ext-nacl)#40 permit ip any any
R1(config-ext-nacl)#exit

ACL 5 is gone and Bob is now rampant on R1, lets look at the running config:

R1(config)#do show run
Building configuration…

(run output)
!
router ospf 1
 log-adjacency-changes
 area 0 authentication message-digest
 redistribute eigrp 100 subnets route-map EIGRP2OSPF
 network 1.1.1.1 0.0.0.0 area 0
 network 172.12.123.0 0.0.0.255 area 0
 neighbor 172.12.123.2
 neighbor 172.12.123.3
 distribute-list 5 out eigrp 100
!
(More run output)

R1(config)#

And it is still referencing ACL 5, so we will want to remove that as well (which we do anyways as best practice before adding our Bob Distribute-List), but to confirm on R2:
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:40:24, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:40:24, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:40:24, Serial0/0
     5.0.0.0/32 is subnetted, 1 subnets
O E1    5.5.5.5 [110/84] via 172.12.123.1, 00:03:34, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:40:24, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:40:24, Serial0/0
R2#

Sure enough 5.5.5.5 returns to the route table. So time to see if we can apply Bob in ACL 5’s stead and see what happens:

R1(config-router)#no distribute-list 5 out eigrp 100
R1(config-router)#distribute-list Bob out eigrp 100
Access-list type conflicts with prior definition
% This command only accepts named standard IP access-lists.
R1(config-router)#

So the lesson learned here – ***DISTRIBUTE-LISTS ONLY ACCEPT STANDARD ACL’S!!!***

My training materials only instructed to use Standard ACL’s for distribute-lists but did not specifically mention that Extended ACL’s would not take, so I am going to keep Bob around for another test here but first lets see about making a new ACL 5 and applying it:

R1(config-router)#exit
R1(config)#access-list 5 deny host 5.5.5.5
R1(config)#access-list 5 deny 100.4.0.0 0.0.255.255
R1(config)#access-list 5 deny 100.6.0.0 0.0.255.255
R1(config)#access-list 5 permit any
R1(config)#router ospf 1
R1(config-router)#distribute-list 5 out eigrp 100
R1(config-router)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:57:03, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:57:03, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:57:03, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:57:03, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:57:03, Serial0/0
R2#ping 100.4.0.1

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

So it worked for 5.5.5.5, but it didn’t even touch the connectivity of the Summary Route, so I am going for the full on block of the Summary itself as one last try with Distribute-Lists:

R1(config-router)#exit
R1(config)#no access-list 5
R1(config)#access-list 5 deny host 5.5.5.5
R1(config)#access-list 5 deny 100.0.0.0 0.7.255.255
R1(config)#access-list 5 permit any
R1(config)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#show ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:59:53, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:59:53, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:00:08, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:0008, Serial0/0
R2#

Aaaaaaaaaand it’s gone! Notice I didn’t need to touch the distribute-list config as it’s already reference ACL 5, I just had to recreate ACL 5, and it kicked right in. So I want to keep my Summary Route in the mix, so I’ll set the Distribute-List back to only filtering 5.5.5.5 and see what we can do with Route-maps:

R1(config)#no access-list 5
R1(config)#access-list 5 deny 5.5.5.5
R1(config)#access-list 5 permit any
R1(config)#

So to move things right along, what’s see if we can use our Redistribution Route-Map to enforce Bob on our unsuspecting victim the Summary-Route:

 

Extended ACL blocking certain networks in a Summary Route on Route-map via Redistribution

 

Since we already have a route-map on our routes redistributing into OSPF, I wanted to see if I could possibly sneak a “Bob”clause in there to stop connectivity to 100.4.0.0 and 100.6.0.0, and of course to start this we want to examine our route-maps for the proper sequence spot for it to be inserted:

R1(config)#do sh route-map
route-map EIGRP2OSPF, deny, sequence 5
  Match clauses:
    tag 110
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
(Right here before the (‘permit all’) tagging traffic)
route-map EIGRP2OSPF, permit, sequence 10
  Match clauses:
  Set clauses:
    metric-type type-1
    tag 100
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, deny, sequence 10
  Match clauses:
    tag 100
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, permit, sequence 15
  Match clauses:
  Set clauses:
    tag 110
  Policy routing matches: 0 packets, 0 bytes
R1(config)#

We want it before sequence 10 because that clause will permit all traffic and tag it with a 100, so I’ll put it between our tag deny and permit sequences:

R1(config)#route-map EIGRP2OSPF deny 8
R1(config-route-map)#match ip add Bob
R1(config-route-map)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 01:22:53, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 01:22:53, Serial0/0
R2#

So it sort of worked, I guess, but now we are missing every external route despite my ‘permit ip any any’ at the end of the Bob. So I review Bob on R1 to see if anything looks wrong in the configuration in show run:

ip access-list extended Bob
 deny   ip host 5.5.5.5 any
 deny   ip 100.4.0.0 0.0.255.255 any
 deny   ip 100.6.0.0 0.0.255.255 any
 permit ip any any

And then R2 once Bob is removed:

R2#show ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 01:29:55, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:00:06, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 01:29:55, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:00:06, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:00:06, Serial0/0

So the interesting thing, is R1 is configured with 11.11.11.0 /24 and 172.12.15.0 /24 on it’s EIGRP configuration, however the access-list match on the route-map Redistributing EIGRP routes just blocks everything from EIGRP if applied at all.

So it turns out, there is no room in this network for Bob (yet), poor guy.

 

Configuring 3-way Route Redistribution with tagging via Route-Maps

 

I was going to move onto Policy Routing, but until all of my networks know of eachother, I don’t many hops around the network to mess with Policy Routing, so I am going to attempt to Redistribute OSPF / EIGRP / RIP into eachother on R3, again using the Tags listed in the Topology:

labbers_delight_rev3

I felt it was a good idea to post it down here as well, as it may belong down here for this even more. So lettuce not waste any time, and get right into the configuration, I’m going to start with 2-way between OSPF and EIGRP ensure our tagging is working to separate the 2 EIGRP domains:

R3#
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#route-map EIGRP2OSPF permit 10
R3(config-route-map)#set tag 200
R3(config-route-map)#route-map OSPF2EIGRP deny 10
R3(config-route-map)#match tag 200
R3(config-route-map)#route-map OSPF2EIGRP permit 20
R3(config-route-map)#set tag 110
R3(config-route-map)#router ospf 1
R3(config-router)#redistribute eigrp 100 route-map EIGRP2OSPF subnets
R3(config-router)#router eigrp 200
R3(config-router)#default-metric 1544 10 255 1 1500
R3(config-router)#redistribute ospf 1 route-map OSPF2EIGRP
R3(config-router)#

I am feeling pretty confident in this configuration, though I did delete a LOT of ? output for clarity sake of the configuration, I think we are going to see both EIGRP domains routes in each others route table with no route leaking (and of course OSPF will now have all EIGRP routes from the Topology). Lets check it out on R4:

R4#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.34.3, 00:04:17, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.34.3, 00:04:17, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D EX     3.3.3.3 [170/1662976] via 172.12.34.3, 00:04:17, FastEthernet0/1
      11.0.0.0/24 is subnetted, 1 subnets
D EX     11.11.11.0 [170/1662976] via 172.12.34.3, 00:04:17, FastEthernet0/1
      100.0.0.0/13 is subnetted, 1 subnets
D EX     100.0.0.0 [170/1662976] via 172.12.34.3, 00:04:17, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D EX     172.12.15.0/24
           [170/1662976] via 172.12.34.3, 00:04:17, FastEthernet0/1
D EX     172.12.123.0/24
           [170/1662976] via 172.12.34.3, 00:04:17, FastEthernet0/1
R4#

Beautiful, notice 5.5.5.5 is still being filtered by the Distribute-List, lets check R2 and R5 to confirm they are looking good as well:

R2#
R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:08:10, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:08:10, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:08:10, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:08:10, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:08:10, Serial0/0
R2#

Problem #1: Where the fudge are R4’s redistributed routes? So this is going to be an issue I need to look into, let’s see how R5 is looking:

R5#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.15.1, 02:33:22, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.15.1, 02:31:11, FastEthernet0/1
      11.0.0.0/24 is subnetted, 1 subnets
D        11.11.11.0 [90/156160] via 172.12.15.1, 02:33:22, FastEthernet0/1
      100.0.0.0/8 is variably subnetted, 15 subnets, 3 masks
D        100.0.0.0/13 is a summary, 02:33:27, Null0
      172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks
D EX     172.12.123.0/24
           [170/1662976] via 172.12.15.1, 02:33:22, FastEthernet0/1
R5#

Problem #2  Routes are also missing here!

So I am beginning to think that perhaps this is a config on R4 and what networks it is advertising in it’s EIGRP domain, so time to start the troubleshooting, so lets take a look at R4’s configurations to find the issue here:

R4#show ip proto

(Output)

  Automatic Summarization: disabled
  Maximum path: 4
  Routing for Networks:
    4.4.4.4/32
    172.12.34.0/24
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.12.34.3           90      00:19:03
  Distance: internal 90 external 170

R4#

So that should be working, was the redistribution messed up somehow?

R3#sh route-map
route-map EIGRP2OSPF, permit, sequence 10
  Match clauses:
  Set clauses:
    tag 200
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, deny, sequence 10
  Match clauses:
    tag 200
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map OSPF2EIGRP, permit, sequence 20
  Match clauses:
  Set clauses:
    tag 110
  Policy routing matches: 0 packets, 0 bytes
R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#route-map EIGRP2OSPF deny 5
R3(config-route-map)#match tag 110
R3(config-route-map)#

One glaring mistake, I forgot to put a sequence before the permit, to deny traffic back out into OSPF with it’s tag of 110 from EIGRP AS 200. Lets see if that (hopefully) did the trick here:

R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:16:06, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:16:06, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:16:06, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:16:06, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:16:06, Serial0/0
R2#

Nope, until I see 4.4.4.4 we on R2 it is not working, but how odd that R4 is rocking and rolling while R2 and R5 are not having any of it. Speaking of R1, or lack of it, I checked it’s route table and it is not seeing R4’s two networks either so it has to be on R3.

After some review, I found my first brain getting exhausted Derp of the night – I put “eigrp 100” in the redistribute command, after removing the palm from my face I fixed it and verified the fix as shown here:

R3(config-route-map)#router ospf 1
R3(config-router)#no redistribute eigrp 100 route-map EIGRP2OSPF subnets
R3(config-router)#redistribute eigrp 200 route-map EIGRP2OSPF subnets
R3(config-router)#

Aaaaaand on R2:

R2#sh ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:25:04, Serial0/0
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:25:04, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:25:04, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/20] via 172.12.123.3, 00:00:52, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E2    172.12.34.0 [110/20] via 172.12.123.3, 00:00:52, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:25:04, Serial0/0
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:25:04, Serial0/0
R2#

For now I will leave those as default E2 routes so I can tell them apart in the Route Table, lets see if R5 is on board as well and we have successfully configured “Multi-Point 2-way Redistribution” successfully with Route Tagging!! :

R5#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.15.1, 02:59:27, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.15.1, 02:57:16, FastEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
D EX     4.4.4.4 [170/1662976] via 172.12.15.1, 00:03:29, FastEthernet0/1
      11.0.0.0/24 is subnetted, 1 subnets
D        11.11.11.0 [90/156160] via 172.12.15.1, 02:59:27, FastEthernet0/1
      100.0.0.0/8 is variably subnetted, 15 subnets, 3 masks
D        100.0.0.0/13 is a summary, 02:59:32, Null0
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D EX     172.12.34.0/24
           [170/1662976] via 172.12.15.1, 00:03:29, FastEthernet0/1
D EX     172.12.123.0/24
           [170/1662976] via 172.12.15.1, 02:59:27, FastEthernet0/1
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 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms
R5#

This is great to see, the route-maps both came right to me how to configure the set / match, however lets see if this is the case with bringing the RIP domain into the mix:
R3(config-router)#exit
R3(config)#route-map OSPF2RIP permit 10
R3(config-route-map)#set tag 110
R3(config-route-map)#route-map OSPF2RIP deny 5
R3(config-route-map)#match tag 120
R3(config)#route-map RIP2OSPF deny 10
R3(config-route-map)#match tag 110
R3(config-route-map)#route-map RIP2OSPF permit 20
R3(config-route-map)#set tag 120
R3(config)#router ospf 1
R3(config-router)#redistribute rip route-map RIP2OSPF subnets metric 2
R3(config-router)#router rip
R3(config-router)#redistribute ospf 1 ?
  match      Redistribution of OSPF routes
  metric     Metric for redistributed routes
  route-map  Route map reference
  vrf        VPN Routing/Forwarding Instance
  <cr>

R3(config-router)#redistribute ospf 1 route-map OSPF2RIP metric 2
R3(config-router)#router ospf 1
R3(config-router)#no redistribute rip route-map RIP2OSPF subnets metric 2
R3(config-router)#redistribute rip route-map RIP2OSPF subnets
R3(config-router)#

I took out a lot of ? output once again to keep the config tight and concise, however I did highlight where along the configuration, I forgot the metric has to be set on the OSPF routes going into RIP because of its hop count limit, but I didn’t need to set a metric for RIP routes going into OSPF so I removed that from the config.

So lets take a look at R2 to see if we see any RIP networks at all:

R2#show ip route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/65] via 172.12.123.1, 00:43:21, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     100.0.0.0/13 is subnetted, 1 subnets
O E1    100.0.0.0 [110/84] via 172.12.123.1, 00:43:21, Serial0/0
     33.0.0.0/24 is subnetted, 1 subnets
O E2    33.33.33.0 [110/2] via 172.12.123.3, 00:07:39, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 172.12.123.3, 00:43:21, Serial0/0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/20] via 172.12.123.3, 00:19:09, Serial0/0
     172.12.0.0/24 is subnetted, 4 subnets
O E2    172.12.34.0 [110/20] via 172.12.123.3, 00:19:14, Serial0/0
O E1    172.12.15.0 [110/84] via 172.12.123.1, 00:43:27, Serial0/0
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
     22.0.0.0/24 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, Loopback22
     11.0.0.0/24 is subnetted, 1 subnets
O E1    11.11.11.0 [110/84] via 172.12.123.1, 00:43:27, Serial0/0

Alright!! That highlighted is a RIP network configured on R3, so we are officially getting RIP networks into OSPF, so now lets take a look at R5 and see if that is able to see them as well:

R5#show ip route eigrp

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.15.1, 03:18:59, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.15.1, 03:16:48, FastEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
D EX     4.4.4.4 [170/1662976] via 172.12.15.1, 00:23:01, FastEthernet0/1
      11.0.0.0/24 is subnetted, 1 subnets
D        11.11.11.0 [90/156160] via 172.12.15.1, 03:18:59, FastEthernet0/1
      22.0.0.0/24 is subnetted, 1 subnets
D EX     22.22.22.0 [170/1662976] via 172.12.15.1, 00:11:31, FastEthernet0/1
      33.0.0.0/24 is subnetted, 1 subnets
D EX     33.33.33.0 [170/1662976] via 172.12.15.1, 00:11:31, FastEthernet0/1
      100.0.0.0/8 is variably subnetted, 15 subnets, 3 masks
D        100.0.0.0/13 is a summary, 03:19:04, Null0
      172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX     172.12.23.0/24
           [170/1662976] via 172.12.15.1, 00:11:31, FastEthernet0/1
D EX     172.12.34.0/24
           [170/1662976] via 172.12.15.1, 00:23:01, FastEthernet0/1
D EX     172.12.123.0/24
           [170/1662976] via 172.12.15.1, 03:18:59, FastEthernet0/1
R5#

So at this point we have verified that R5 knows about both EIGRP AS 200 Routes, OSPF routes, and RIP routes!

With that, I am going to conclude for the night as my brain is starting to melt once again out of my ears, however very good practical material covered in here, and a good example that 3-way protocol Redistribution can be performed just by tagging traffic into one protocol so that it will redistribute into the other because it is not claused to deny the routes tag.

That was a mouth full of a summary of the lesson to say, anyways, that’s it for tonight, next we’ll mess with some Policy routing and then it’s time to get back into study mode and tackle everything about VPN on routers.

EDIT EDIT EDIT, DAG NAB IT :

On my way to “wr mem” the routers, I did a quick “sh ip route” on R4 just to quickly confirm it was working as well, and it is missing the loopback22 22.22.22.0 /24 on R2 being advertised by RIP:

R2#sh ip proto

Routing Protocol is “rip”

 (Output)
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    22.0.0.0
    172.12.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.12.23.3          120      00:00:01
  Distance: (default is 120)

And here is R4’s dag nab #Y&%$&* route table:

R4#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.34.3, 00:14:35, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.34.3, 00:14:35, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D EX     3.3.3.3 [170/1662976] via 172.12.34.3, 00:17:38, FastEthernet0/1
      11.0.0.0/24 is subnetted, 1 subnets
D EX     11.11.11.0 [170/1662976] via 172.12.34.3, 00:14:35, FastEthernet0/1
      100.0.0.0/13 is subnetted, 1 subnets
D EX     100.0.0.0 [170/1662976] via 172.12.34.3, 00:14:35, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D EX     172.12.15.0/24
           [170/1662976] via 172.12.34.3, 00:14:35, FastEthernet0/1
D EX     172.12.123.0/24
           [170/1662976] via 172.12.34.3, 00:17:38, FastEthernet0/1
R4#

So I saw this and just shut the routers down thinking I’ll get it next time, and I didn’t get to the bottom of the stairs before it was driving me crazy what it’s problem is. So I got food (getting cold) and a 5 hour energy, and time to go back at this and hopefully take it down with one more configuration here.

I am thinking because RIP is local to router EIGRP AS 200 is on, we need a Redistribution between those two as well, with their own route-maps. So my food isn’t getting any hotter (or probably colder at this point) so lets do this:

R3(config)#route-map EIGRP2RIP deny 10
R3(config-route-map)#match tag 120
R3(config-route-map)#route-map EIGRP2RIP permit 20
R3(config-route-map)#set tag 200
R3(config-route-map)#route-map RIP2EIGRP deny 10
R3(config-route-map)#set tag 200 <- WRONG – SHOULD BE MATCH TAG 200
R3(config)#route-map RIP2EIGRP permit 20
R3(config-route-map)#set tag 120
R3(config-route-map)#

That looks about right, now to Redistribute them into each other:

R3(config-route-map)#router eigrp 100
R3(config-router)#redistribute rip ?
R3(config-router)#redistribute rip route-map RIP2EIGRP
R3(config-router)#router rip
R3(config-router)#redistribute eigrp 200 route-map EIGRP2RIP metric ?
  <0-16>       Default metric
  transparent  Transparently redistribute metric

R3(config-router)#redistribute eigrp 200 route-map EIGRP2RIP metric 2
R3(config-router)#

Aaaaaaaand, let there be light? :

R4#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.34.3, 00:38:22, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.34.3, 00:38:12, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D EX     3.3.3.3 [170/1662976] via 172.12.34.3, 00:41:14, FastEthernet0/1
      11.0.0.0/24 is subnetted, 1 subnets
D EX     11.11.11.0 [170/1662976] via 172.12.34.3, 00:38:22, FastEthernet0/1
      100.0.0.0/13 is subnetted, 1 subnets
D EX     100.0.0.0 [170/1662976] via 172.12.34.3, 00:38:22, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D EX     172.12.15.0/24
           [170/1662976] via 172.12.34.3, 00:38:22, FastEthernet0/1
D EX     172.12.123.0/24
           [170/1662976] via 172.12.34.3, 00:41:14, FastEthernet0/1
R4#

Nope, still nothing, HOWEVER A QUICK SHOW RUN AND STARE DOWN OF R3 SAVES THE DAY!!! :

R3(config-router)#do sh run

(Output)
!
router eigrp 200
 redistribute ospf 1 route-map OSPF2EIGRP
 network 172.12.34.0 0.0.0.255
 default-metric 1544 10 255 1 1500
 no auto-summary
!
router eigrp 100
 redistribute rip route-map RIP2EIGRP
 auto-summary
!
router ospf 1
 log-adjacency-changes
 redistribute eigrp 200 subnets route-map EIGRP2OSPF
 redistribute rip metric 2 subnets route-map RIP2OSPF
 redistribute eigrp 100
 network 3.3.3.3 0.0.0.0 area 0
 network 172.12.123.0 0.0.0.255 area 0
!
router rip
 version 2
 redistribute eigrp 200 metric 2 route-map EIGRP2RIP
 redistribute ospf 1 metric 2 route-map OSPF2RIP
 network 33.0.0.0
 network 172.12.0.0
 no auto-summary
!

Iiiiiii, need to correct this, and stop labbing for the night as my stupid mistakes are now running rampant on my network:

R3(config-router)#exit
R3(config)#no router eigrp 100
R3(config)#router eigrp 200
R3(config-router)#redistribute rip route-map RIP2EIGRP
R3(config-router)#

AND NOW LETS SEE THAT NETWORK NUMBER 22.22.22.0 /24 ON R4!!! :

R4#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.34.3, 00:47:11, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.34.3, 00:47:01, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D EX     3.3.3.3 [170/1662976] via 172.12.34.3, 00:50:03, FastEthernet0/1
      11.0.0.0/24 is subnetted, 1 subnets
D EX     11.11.11.0 [170/1662976] via 172.12.34.3, 00:47:11, FastEthernet0/1
      100.0.0.0/13 is subnetted, 1 subnets
D EX     100.0.0.0 [170/1662976] via 172.12.34.3, 00:47:11, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D EX     172.12.15.0/24
           [170/1662976] via 172.12.34.3, 00:47:11, FastEthernet0/1
D EX     172.12.123.0/24
           [170/1662976] via 172.12.34.3, 00:50:03, FastEthernet0/1
R4#

It is still not there, so I highlighted the issue above from retrospect, however the issue was found using the route-map command, in conjunction with looking at the route-maps on “sh run” which makes them a bit easier to read for me without the extra output.

 

The answer to why R3 isn’t getting RIP routes

 

In my tired stupor, I did not closely review my route maps, or it would be clear that I set the RIP2EIGRP twice, meaning I put a “set” in each sequence for both matching a tag to deny and setting the RIP route tag #’s :

R3(config)#do sh route
route-map EIGRP2RIP, deny, sequence 10
  Match clauses:
    tag 120
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map EIGRP2RIP, permit, sequence 20
  Match clauses:
  Set clauses:
    tag 200
  Policy routing matches: 0 packets, 0 bytes
route-map RIP2EIGRP, deny, sequence 10
  Match clauses:
  Set clauses:
    tag 200
  Policy routing matches: 0 packets, 0 bytes
route-map RIP2EIGRP, permit, sequence 20
  Match clauses:
  Set clauses:
    tag 120

 

So I apply the fix and check on R4 with both fingers crossed:

R3(config)#no route-map RIP2EIGRP
R3(config)#route-map RIP2EIGRP deny 10
R3(config-route-map)#match tag 200
R3(config-route-map)#route-map RIP2EIGRP permit 20
R3(config-route-map)#set tag 120
R3(config-route-map)#
ASR#4
[Resuming connection 4 to r4 … ]

R4#sh ip route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D EX     1.1.1.1 [170/1662976] via 172.12.34.3, 00:15:04, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D EX     2.2.2.2 [170/1662976] via 172.12.34.3, 00:15:04, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D EX     3.3.3.3 [170/1662976] via 172.12.34.3, 00:17:56, FastEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
      11.0.0.0/24 is subnetted, 1 subnets
D EX     11.11.11.0 [170/1662976] via 172.12.34.3, 00:15:04, FastEthernet0/1
      22.0.0.0/24 is subnetted, 1 subnets
D EX     22.22.22.0 [170/1662976] via 172.12.34.3, 00:00:09, FastEthernet0/1
      33.0.0.0/24 is subnetted, 1 subnets
D EX     33.33.33.0 [170/1662976] via 172.12.34.3, 00:00:09, FastEthernet0/1
      100.0.0.0/13 is subnetted, 1 subnets
D EX     100.0.0.0 [170/1662976] via 172.12.34.3, 00:15:04, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX     172.12.15.0/24
           [170/1662976] via 172.12.34.3, 00:15:04, FastEthernet0/1
D EX     172.12.23.0/24
           [170/1662976] via 172.12.34.3, 00:00:09, FastEthernet0/1
C        172.12.34.0/24 is directly connected, FastEthernet0/1
L        172.12.34.4/32 is directly connected, FastEthernet0/1
D EX     172.12.123.0/24
           [170/1662976] via 172.12.34.3, 00:17:56, FastEthernet0/1
R4#

AND THERE IS OUR RIP ROUTES, FINALLY, 3-WAY REDISTRIBUTION ON ONE ROUTER!!!

Next lab I’ll look at sub-optimal routing all this redistribution may have caused, see if I can correct it with different mechanisms (Mainly Policy Routing), but for now that is all 🙂

The extended traceroute command, and Local Policy Routing Configuration!

policy_routing_top

Still working with the same Topology seen above, I want to round off the Policy Routing videos to see if I can bring that into some scenario or freestyle lab, and see how crazy one can get with Policy Routing.

The first thing to note that I have amazingly not known at all until this video, from a router there are two ways to do extended traceroutes (like extended pings):

  • Type “traceroute” and hit enter to fill in options exactly like an extended ping
  • “traceroute (dest IP) source (source IP)” to simulate traffic from that network

Also to note on the second method, you can actually source several different ways, shown with the extended options as I fill them out, so there shall be a bit of output:

R1#traceroute 4.4.4.4 ?
numeric  display numeric address
port     specify port number
probe    specify number of probes per hop
source   specify source address or name
timeout  specify time out
ttl      specify minimum and maximum ttl
<cr>

R1#traceroute 4.4.4.4 source ?
A.B.C.D            Source address
Async              Async interface
BVI                Bridge-Group Virtual Interface
CDMA-Ix            CDMA Ix interface
CTunnel            CTunnel interface
Dialer             Dialer interface
FastEthernet       FastEthernet IEEE 802.3
Lex                Lex interface
Loopback           Loopback interface
MFR                Multilink Frame Relay bundle interface
Multilink          Multilink-group interface
Null               Null interface
Port-channel       Ethernet Channel of interfaces
Serial             Serial
Tunnel             Tunnel interface
Vif                PGM Multicast Host interface
Virtual-PPP        Virtual PPP interface
Virtual-Template   Virtual Template interface
Virtual-TokenRing  Virtual TokenRing

R1#traceroute 4.4.4.4 source 10.20.30.40 ?
numeric  display numeric address
port     specify port number
probe    specify number of probes per hop
timeout  specify time out
ttl      specify minimum and maximum ttl
<cr>

R1#traceroute 4.4.4.4 source 10.20.30.40

% Invalid source address- IP address not on any of our up interfaces


R1#

It’s like a build your own sundae, you can just keep adding scoops of detail to your traceroute, but as can be seen highlighted in red text we have an important message. The source IP address must be on one of our “Up” interfaces on the local router, so beine this requires a Physical or Logical interface that is in “Up” status, it sounds like Loopback interfaces is the way to go as they won’t go down unless administratively.

However if we are using an extended traceroute, it is because we are simulating traffic from another network for testing the path, but as we well know Policy Routing requires an interface of the incoming traffic to Policy Route and this is where Local Policy Routing comes into play.

To makes things harder on my already exhausted brain, I assigned loopback names to match the IP addresses:

R1(config)#int lo ?
  <0-2147483647>  Loopback interface number (<- What!!!)

R1(config)#int lo1234
*Mar  1 17:00:40.658: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1234, changed state to up
R1(config-if)#ip add 10.20.30.40 255.255.255.0
R1(config-if)#int lo4321
*Mar  1 17:01:03.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback4321, changed state to up
R1(config-if)#ip add 40.30.20.10 255.255.255.0
R1(config-if)#

Another interesting thing, you can make an interface loopback 2,147,483,647 (2.1 billion), I have been setting my bar way too low for loopback interface numbers. Back to the matter at hand, I now have my two loopbacks just created as well as lo1 with IP address 1.1.1.1 /32 to use in the lab.

So the structure of of how you create the route-map is the same of making an ACL / matching it on a route-map / set ip next-hop (ip addy), however there is no incoming interface on the local router so we will examine where we apply this route-map if not to an incoming interface.

To start I will send an initial traceroute to see my current path so I know how to alter it:

R1(config)#do traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 172.12.123.3 32 msec 32 msec 36 msec
2 172.12.34.4 32 msec *  32 msec
R1(config)#do traceroute 4.4.4.4 source 40.30.20.10

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1  *  *  *
2  *  *  *
3  *  *  *
4  *  *  *
5  *

This is a good learning lesson, because I just made these loopbacks, but forgot to add them to OSPF so no other routers would know a route back, so I’ll add them to OSPF and we’ll try again:

R1(config)#router ospf 1
R1(config-router)#network 1.1.1.1 0.0.0.0 area 0
R1(config-router)#network 10.20.30.40 0.0.0.255 area 0
R1(config-router)#network 40.30.20.10 0.0.0.255 area 0
R1(config-router)#do traceroute 4.4.4.4 source 40.30.20.10

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.3 36 msec 33 msec 32 msec
  2 172.12.34.4 32 msec *  32 msec
R1(config-router)#

Much better. So being that 172.12.123.3 is the preferred path to R4’s loopback of 4.4.4.4, I want our 2 new loopback interfaces to route traffic towards R2 instead, so I will create a multi-line ACL this time for Policy Routing and create the Route-map:

R1(config)#access-list 105 permit ip host 10.20.30.40 host 4.4.4.4
R1(config)#access-list 105 permit ip host 40.30.20.10 host 4.4.4.4
R1(config)#route-map LocalNextHop permit 10
R1(config-route-map)#match ip add 105
R1(config-route-map)#set ip next-hop 172.12.123.2
R1(config-route-map)#

I am still not sure if you can have multiple route-maps on an interface, I will lab the scenario because I think it makes sense that one interface can have multiple networks coming into it that it needs to route different places, however for now I can confirm that 1 route-map can contain multi-line ACL’s to direct more than one line of traffic towards a next hop destination.

So no incoming interface, where do we configure the route-map? The answer is – Globally:

R1(config)#ip local ?
  policy  Enable policy routing
  pool    IP Local address pool lists

R1(config)#ip local policy ?
  route-map  Policy route map

R1(config)#ip local policy route-map ?
  WORD  Route map name

R1(config)#ip local policy route-map LocalNextHop ?
  <cr>

R1(config)#ip local policy route-map LocalNextHop
R1(config)#

And to test it out, we will use our new friend extended traceroute:

R1#traceroute 4.4.4.4 source 40.30.20.10

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.2 32 msec 32 msec 32 msec
  2 172.12.123.1 25 msec 24 msec 24 msec
  3 172.12.123.3 56 msec 56 msec 56 msec
  4 172.12.34.4 56 msec *  52 msec
R1#traceroute 4.4.4.4 source 1.1.1.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

  1 172.12.123.3 33 msec 32 msec 32 msec
  2 172.12.34.4 32 msec *  32 msec
R1#

I’ve highlighted first one of the IP addresses called out in the ACL, then our lo1, to show that we have not only sub-optimal routing (described in last post how to fix), but that it does in fact attempt to take R2 because of the Local Policy Routing happening whereas 1.1.1.1 goes right to R3.

As mentioned how to overcome that sub-optimal routing you see in the first trace is picked apart in detail in my last post, so please read up on how PBR is not one and done on a single router as taught in the video courses I am watching.

Just a couple more points on Local Policy Routing to wrap this up:

  • Local Policy Routing will not effect any other Policy Routing assigned to interfaces
  • Local Policy Route-maps must be named differently than any existing route-maps currently configured on the router

So basically for local policy routing, you just need to remember the global command to apply it, and off to the races you go. I will be doing one more freestyle lab with PBR to see its limitations, as you learn things like in my training materials it did not mention that error we saw saying it needs to be an “Up” interface on the router.

So I invite you or future me to check out the next post of just messing around with PBR in general to see what we can break and fix, and then it is onward to VPNs. Thee ya!

Break from studying turned into 6 months in the blink of an eye!

Due to the summer getting busy, and posts getting sporadic to the point that I was not retaining the material / labbing, I decided to take a short break which turned into a 6 month break.

A word to the wise, do not take time off from studying unless you need to (vacation, family emergency, etc) as starting again for me is almost harder than originally starting my studies, due to the fact that I feel like I’ve already failed at the follow through once – Don’t be that guy (me) and let your momentum slow to a stop!

Now that I have sucked it up and gotten back on the horse, this page will be regularly updated with very technical posts including a lot of router output but my communication and writing format is very relaxed – So don’t let that throw you off. I do know what I am talking about some of the time.

Going forward I will be removing route codes from “sh ip route” commands to focus more on the output, put router output in bold font (though some important text topics will be as well), and there will be a lot more console / debug / show command output from the routers to demonstrate what happens on live equipment when I configure something.

I will leave my posts prior to restarting in December, even though it’s a bad taste in my mouth to have that reminder of the time I almost gave up, but there is some good info that is repeated in more current posts but a different view of it (worth a quick once over to me).

If you are looking for a good quick reference guide to supplement some topics on your ROUTE studies, you have found your new home away from home, now lets make and break some networks shall we 🙂