Subjects Covered on Friday 9th Nov 2007

Entry @ 07:47

OSPF

 Went through the last of the labs for OSPF using IEWB Vol I.  Spent some time on the NSSA section as this can cause a few issues.  Just getting my head round why you would suppress the forwarding address from an ASBR within the NSSA.  Reason being that internal routers within other areas may not have a route to the ASBR’s address.  So the Translating LSA 7 to 5 ABR removes the forwarding address when viewed in the OSPF database.  The receiving router will use the address shown in the “Advertising Router” section.

Also there are multiple ways of advertising a default into the NSSA.
1 – Just using the area 1 nssa on the ABR will advertise a default, it will be a Type 3 LSA
2 – Just using the area 1 nssa no-summary on the ABR will advertise a default, it will be a Type 3 LSA.  I did wonder about this as a Totally NSSA shouldn’t receive Type 3 LSA’s but the default route shows as an Inter-Area in the routing table of an internal Totally NSSA router and everything worked as it should.
3 – Use “area 1 nssa default-information-originate” on the ABR to advertise an LSA Type 7 Default route.
4- You can’t use “default-information-originate” on its own under the routing process as this advertises a type 5 LSA and these aren’t allowed in NSSA’s.

There was one issue I ran into with the “area 1 nssa” on the ABR.  The internal NSSA router was receiving the default route from 2 ABRs in the OSPF database but wasn’t installing them in the IP routing table!!  After about 10 minutes, I found out that I had earlier put a static default on the internal NSSA router!!!  That would be why then!!

TRACKING IP ROUTE REACHABILITY 

I had a quick look @ tracking as i’ve only really used it with SLA and HSRP/VRRP/GLBP
I configured the following:

track 1 ip route 150.1.5.5 255.255.255.255 reachability
ip route 150.1.5.5 255.255.255.255 155.1.146.1 200 track 1

The above will track the route to whatever subnet is stated in the “track 1 ip route” command
If this route is lost, the floating static route will be inserted into the routing table.
E.g. with the route learnt via OSPF still reachable:

The route to 150.1.5.5 is in the routing table via OSPF:

O IA    150.1.5.5/32 [110/66] via 155.1.146.4, 00:04:47, FastEthernet0/1

The tracking configuration can see that this is learnt via OSPF:

R6#show track 1
Track 1
  IP route 150.1.5.5 255.255.255.255 reachability
  Reachability is Up (OSPF)
    1 change, last change 00:24:39
  First-hop interface is FastEthernet0/1
  Tracked by:
    STATIC-IP-ROUTING 0

A trace takes the packet via 155.1.146.4:

R6#traceroute 150.1.5.5

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 155.1.146.4 0 msec 4 msec 4 msec
  2 155.1.0.5 28 msec *  28 msec
R6#

Now when R6 loses the route to 155.1.5.5 from R4 the tracking shows that the route is now reachable via the floating static route:

R6#show track 1       
Track 1
  IP route 150.1.5.5 255.255.255.255 reachability
  Reachability is Up (static)
    1 change, last change 00:26:05
  First-hop interface is FastEthernet0/1
  Tracked by:
    STATIC-IP-ROUTING 0

The floating static route is now in the routing table:

R6#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “static”, distance 200, metric 0
  Routing Descriptor Blocks:
  * 155.1.146.1

Now if I trace to it, the packet goes via R1:

R6#traceroute 150.1.5.5

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 155.1.146.1 0 msec 0 msec 4 msec
  2 155.1.0.5 28 msec *  28 msec
R6#

Once the route is learnt again via 155.1.146.4, this will be inserted back into the routing table.

GRE TUNNELS

I created a GRE tunnel between Routers 6 and 5 using 155.1.46.6 & 155.1.46.5/24 respectively.
The tunnels transits 2 routers before reaching each other

I established an OSPF adjacency over the tunnel, but because the 2 endpoints were learning each others source/destination over the tunnel the tunnel/ospf relationship went down because of recursive routing issues.

This happens because the router looks for a route to the destination of the tunnel (on R6 this was 150.1.5.5, loopback of R5), and the router sees a route for 150.1.5.5 out of the tunnel.  The tunnels destination is 150.1.5.5, how do I get to 150.1.5.5, I go out of the tunnel and so on – this is the recursive routing issue.  Its the same on the other end. 

So the router is going “DESTINATION OF TUNNEL = 150.1.5.5 GO VIA TUNNEL0 -> DESTINATION OF TUNNEL = 150.1.5.5 GO VIA TUNNEL0

To stop this happening I denied the learning of the destination of the tunnel via the tunnel.  To do this i used:

1 – AD set to 255 on both ends:

R6#sh run | include distance|access-list
 distance 255 155.1.56.5 0.0.0.0 1 (1st IP address relates to the source, the “1” refers to the ACL)
 access-list 1 permit 150.1.5.5 (loopback of R5 which is the tunnel destination)

Configured a mirror image on the other end (R5).  The tunnel and OSPF relationship stayed up indefinitely.

2 – Used a distribute list with a route-map to do exactly the same:

R6#sh run | s route-map|access-list|distribute-list

access-list 1 permit 150.1.5.5
!
route-map DENY_R5LO0 permit 10
 match ip address 1
 match ip route-source 155.1.46.5
!
router ospf 1
distribute-list route-map DENY_R5LO0 in

Configured a mirror image on the other end of the tunnel (R5).  Both tunnel and the OSPF relationship stayed up.
As a side note, you can’t just use a distribute-list without specifying the source address from which the destination of the tunnel is learnt.  If you configure “distribute-list 1 in”, this will deny the destination of the tunnel via ANY router, therefore the route will not be learnt and the tunnel will never come up!!

Total Studying hours so far since starting this blog – 13hrs 30 mins