Subjects Covered On Monday 12/11/07

OSPF

When changing an interface from one area to another, if you change this under the routing process, ensure that there isn’t an”ip ospf 1 area (id)” command under the interface as this command takes precedence over the “network” command.  Under the routing process everything will look correct, under the output of “show ip ospf interface brief” you will see that the interface you wanted to change to another area will still show up as the old area and adjacencies won’t come up.

When mutual redistribution is occuring in a hub and spoke environment and the spokes are redistributing, to filter selected routes via AD use the following command:

access-list 1 permit 155.1.23.0 0.0.0.255
access-list 1 permit 155.1.37.0 0.0.0.255
access-list 1 permit 150.1.33.0 0.0.0.255
access-list 1 permit 150.1.3.0 0.0.0.255
!
distance 180 150.1.1.1 0.0.0.0 1

The IP address in the command is the RID of the router that is advertising the route in.  This will be the RID of the ASBR. 

I kept placing the RID of the hub and wondered why I was still seeing the routes as an E2 and not learned from RIP.  Look in the ospf database and look at the IP under the “ADV Router” column to see which IP address you need to specify in the above command.
Also, before the command goes on, ensure you look on both routers routing tables to see the E2 routes that you want to match.

 Also look at the Connected interface on each router that is part of the RIP domain, remember this will also show as an E2 route (as well all other RIP routes) when redistributed so make sure you take that into consideraton when viewing which routes to change the AD of.

Also started to cover some QoS as this is a weak subject of mine.

Amount of time studying today – 4hrs 50 mins
Total Studying hours so far since starting this blog – 32hrs 58 mins

Subjects Covered On Sunday 11/11/07

Playing around with NSSA

2 ABRs (R3 and R1)

When 1 ABR is configured with “area 2 nssa default-information-originate”
And the other is configured with “area 2 nssa no-summary”
The default route that will show in routing table will be the ABR with area 2 nssa no-summary configured.
Why??  Because it boils down to metric type – Intra over Inter over E1/N1 over E2/N2.

Because the “area 2 nssa default-information-originate” command injects the default as an N2, the Totally NSSA ABR will be preferred as this shows up in the OSPF database as an LSA 3 of an internal router of the NSSA area:

               Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         150.1.3.3       43          0x80000002 0x00BCDA

The other default shows as a type 7:

               Type-7 AS External Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         150.1.1.1       1017        0x80000001 0x00AC6B 0

Any INTER area routes will go via the router that injects the default as a Type 7 as these routes show up in routing table, and the Totally NSSA ABR will only inject a default route in for these.  The longest match will win!

The NSSA ABR with the highest RID will be the LSA 7 -> 5 translator.  I looked at the routing tables of both ABR’s and wondered why I was seeing the routes from the NSSA ASBR from a particular NSSA ABR in other areas.  It finally dawned on me (after 20 mins) that it will be the NSSA ABR with the highest RID that will translate and propagate the Type 7 routes out as Type 5.  I proved this by changing the NSSA ABR router with the lower RID to be the higher RID.  This then changed the advertisting

router of the Type 7 NSSA routes.

I also tried the “suppress-fa” on the translating NSSA ABR.  Very handy if the IP address of the NSSA ASBR isn’t advertised

out at all.  My topology was Area 2 (NSSA) -> Area 0 -> Area 1 (Normal Area)

The output of a router in Area 1 before the fa was suppressed:
Link State ID: 212.18.0.0 (External Network Number )
  Advertising Router: 150.11.11.11
  LS Seq Number: 80000001
  Checksum: 0x8E3E
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 155.1.146.6
        External Route Tag: 0
And after:

 Link State ID: 212.18.0.0 (External Network Number )
  Advertising Router: 150.11.11.11
  LS Seq Number: 80000002
  Checksum: 0xBF5
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

As you can see the Forwarding Address has changed from 155.1.146.6 (NSSA ABR) to 0.0.0.0.  Routers in other areas will simply

point to the Advertising Routers IP address which is the NSSA translating ABR (150.11.11.11)

I can still ping to the address:

SW4#ping 212.18.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 212.18.0.1, timeout is 2 seconds:
!!!!!
AUTHENTICATION

You can use more than 1 password with MD5 (type 2) but can only use one for text (type 1).  MD5 would be used on a hub if all spokes need to have different passwords.

There was an issue I ran into whilst using md5 authentication and using the “ip ospf dead-interval minimal” command.  This is the entry on sadikhov.com/forum that I posted:
Hey all.

I’ve run into interesting problem whilst labbing up ip ospf authentication with md5.
I have a hub (R5) and 4 spokes running over FR.  I have configured the network type of point-to-multipoint.
The hubs interface is configured as:

interface Serial0/0
 ip address 155.1.0.5 255.255.255.0
 encapsulation frame-relay
 ip ospf authentication message-digest
 ip ospf message-digest-key 15 md5 CISCO15
 ip ospf message-digest-key 45 md5 CISCO45
 ip ospf message-digest-key 35 md5 CISCO35
 ip ospf message-digest-key 25 md5 CISCO25
 ip ospf network point-to-multipoint
 ip ospf hello-interval 5
 frame-relay map ip 155.1.0.1 501 broadcast
 frame-relay map ip 155.1.0.2 502 broadcast
 frame-relay map ip 155.1.0.3 503 broadcast
 frame-relay map ip 155.1.0.4 504 broadcast

Now when I configure just the “type” everything comes up fine which I expected.  When I configure the keys on the hub and spokes, the authentication flaps.  The error on one of the spokes shows as:

Nov  8 19:12:52.859: OSPF: Rcv pkt from 155.1.0.5, Serial0/0 : Mismatch Authentication Key – No message digest key 45 on interface
*Nov  8 19:12:52.891: OSPF: Rcv pkt from 155.1.0.3, Serial0/0 : Mismatch Authentication Key – No message digest key 35 on interface
*Nov  8 19:12:52.915: OSPF: Rcv pkt from 155.1.0.5, Serial0/0 : Mismatch Authentication Key – No message digest key 45 on interface
*Nov  8 19:12:52.943: OSPF: Rcv pkt from 155.1.0.5, Serial0/0 : Mismatch Authentication Key – No message digest key 35 on interface

Obviously R5 is sending out all keys so R1 is complaining that it doesn’t have the keys R5 has for the other 2 spokes.

The config of R1 (identical to all my other spokes that are having exactly the same issue):

interface Serial0/0
 ip address 155.1.0.1 255.255.255.0
 encapsulation frame-relay
 ip ospf authentication message-digest
 ip ospf message-digest-key 15 md5 CISCO15
 ip ospf network point-to-multipoint
 ip ospf dead-interval minimal hello-multiplier 3
 frame-relay map ip 155.1.0.5 105 broadcast
 no frame-relay inverse-arp
end

I have changed the timers down from using the “dead-interval minimal” command to 5 secs for hello and 20 secs for the dead-interval.  The relationships now come up:

R5#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.4.4         0   FULL/  –        748 msec    155.1.45.4      Serial0/1
150.1.3.3         0   FULL/  –        00:00:18    155.1.0.3       Serial0/0
150.11.11.11      0   FULL/  –        00:00:16    155.1.0.1       Serial0/0
150.1.2.2         0   FULL/  –        00:00:15    155.1.0.2       Serial0/0
150.1.4.4         0   FULL/  –        00:00:15    155.1.0.4       Serial0/0
150.1.8.8         1   FULL/DR         00:00:29    155.1.58.8      FastEthernet0/0

Has anyone else run into this issue at all with authentication whilst using the “ip ospf dead-interval minimal hello-multiplier”.
There must be 2 much traffic running over the WAN from the spokes to the hub for the hub to be able to handle it.  I was also seeing DBD sequence errors on the hub with the timers at the minimal value.
There aren’t any dropped packets on the hubs interface either.
Would be interesting to see if anyone else has run into this issue, if not then just be aware that this could happen!!

Rgds,

RR

Amount of time studying today – 7hrs 38 mins
Total Studying hours so far since starting this blog – 28hrs 8 mins

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

Subjects Covered on Thursday 08/11/2007

Started at 06:20 this morning, so thats an hour and a half done already!  Went through the IEWB Volume I OSPF Lab scenarios.  Started from the filtering section as there are many ways to filter routes with OSPF.  Biggest problem I had was actually putting the base config on all the routers in the lab, think this was due to me being tired!!  Kept putting the wrong IP’s on interfaces, found that out.  Then I found that I had put these wrong IP’s under the routing process.  Found that out.  Then realised I had put these into the wrong area!!!  All school boy errors!!  Went through the following ways of filtering routes:

Inter-Area filtering using prefix lists
Type 3 LSA filtering with network ranges (no-advertise)
Distribute lists (stops the routes entering the routing table, not the propagation of LSA’s)
Distribute lists with route-maps (so you can specify the route-source)
Filtering with AD using ACLs so the source can be matched – look in the ospf database for the source IP address.  If it’s an external route, the source will be the IP of the ASBR.  If the route comes from a router in a different area than the router you are configuring, the route-source will be the ABR(s) that have advertised the Network Summary LSA.

Done a quick lab with NSSA, simple one with being able to choose the NSSA 7 LSA to External Type 5 LSA – Highest RID wins!!

Off now to get ready for work.

Total Studying hours so far since starting this blog – 7hrs 15 mins

Entry @ 22:30
 Just covered some more security subjects and some QinQ Tunneling.
With Dynamic ACLs I used the following on my lab:

ip access-list extended TELNET
permit tcp any host 155.1.23.3 eq 23
dynamic R2_LO0 permit tcp host 150.1.2.2 any eq 80
deny tcp any any eq 80
permit ip any any
deny tcp any any log
deny udp any any log
deny icmp any any log
!
line vty 0 4
autocommand access-enable host
!
interface e0/0
ip access-group TELNET in
!

Get “% Source 155.1.23.2 is not in mask(150.1.2.2, 0.0.0.0) in the ACL
[Connection to 155.1.23.3 closed by foreign host]”.  Even when telnetting from the source of 150.1.2.2 I still couldn’t get this to work.  The reason being that I had specified the “host” keyword after the “access-enable” keyword.
To rectify this is left this off:

ip access-list extended TELNET
permit tcp any host 155.1.23.3 eq 23
dynamic R2_LO0 permit tcp host 150.1.2.2 any eq 80
deny tcp any any eq 80
permit ip any any
deny tcp any any log
deny udp any any log
deny icmp any any log
!
line vty 0 4
autocommand access-enable host
!
interface e0/0
ip access-group TELNET in
!

After this I could telnet to 155.1.23.3 using an ip that wasn’t 150.1.2.2.  This then activated the dynamic entry and threw me out.  Telnetting to 150.1.3.3 (loopback on the router with the acl on it) I couldn’t do it.  I then tried with the source of loopback 0 and still couldn’t do it.  Under the ACL the entry was:

R3#show access-list
Extended IP access list TELNET
    10 permit tcp any host 155.1.23.3 eq telnet (90 matches)
    20 Dynamic R2_LO0 permit tcp host 150.1.2.2 any eq www
       permit tcp host 155.1.23.2 any eq www

I telnetted to 155.1.23.3 with the source of 150.1.2.2.  It added the following entry:

R3#show access-list
Extended IP access list TELNET
    10 permit tcp any host 155.1.23.3 eq telnet (117 matches)
    20 Dynamic R2_LO0 permit tcp host 150.1.2.2 any eq www
       permit tcp host 150.1.2.2 any eq www
       permit tcp host 155.1.23.2 any eq www
I could then telnet to 150.1.3.3 via port 80:

R2#telnet 150.1.3.3 80 /source-interface lo 0
Trying 150.1.3.3, 80 … Open
get
HTTP/1.1 400 Bad Request
Date: Thu, 08 Nov 2007 21:20:32 GMT
Server: cisco-IOS
Accept-Ranges: none

400 Bad Request
I then configured the “autocommand” command using the username command:

ip access-list extended TELNET
permit tcp any host 155.1.23.3 eq 23
dynamic R2_LO0 permit tcp any any eq 80
deny tcp any any eq 80
permit ip any any
deny tcp any any log
deny udp any any log
deny icmp any any log
!
username R2 password R2
username R2 autocommand access-enable
!
This worked straight away. Once it’s open, after the user enters the correct username and password, it’s now open for all ip addresses.  I could telnet to any IP address from any IP address.  To make sure there are no unauthorised entries, use the “host” keyword after the “autocommand access-enable” command.  This will place the host’s source IP address under the “dynamic” line via the “show access-lists” output and only allow this source IP for the existing session.
QinQ Tunneling

Weird thing happened here.  I configured trunking through all 4 of my switches (3750’s).  The link was SW1->SW2->SW3->SW4.  Before any tunnels were configured, I tested end2end connectivity using Layer 3 SVIs on SW1 and SW4.  Vlan 14 & Vlan 41 had IP addresses 155.1.14.x and 155.1.41.x respectively.  I could ping all the way through.  I then configured the SP switches with dot1q tunnels.  Weird thing happened here, SW1 and SW4 lost their config on the trunked links that connected to the SP switches.  This happend on both SW1 and SW4.  Strange!!!  Anyway, I put the config back on and tested end2end connectivity.  I could ping all the way through.  I also allowed cdp and stp through the SP network.  So even if SW1 and SW4 aren’t directly connected, they still participate in the same SPT domain and can see each other as CDP neighbours as well.

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