CCIE Pursuit Blog

August 2, 2008

Internetwork Expert Volume II: Lab 3 – Section 11

Section 11 – IP Services – 4 Points

11.1 Local Authorization

Set r2’s default privilege level to 0 for telnet users.  Allow them to also ping and traceroute. If they need level 1 access, then have them authenticate with the password CISCO prior to being given access.

This is easy except for that last bit.  I couldn’t get my head around it.  Turns out that this was easy as well, you just need to set the privilege level for the enable password:

r2(config)#enable secret level 1CISCO

r2#sh privilege
Current privilege level is 15
r2#disable 0
r4>?
Exec commands:
  <1-99>      Session number to resume
  disable     Turn off privileged commands
  enable      Turn on privileged commands
  exit        Exit from the EXEC
  help        Description of the interactive help system
  logout      Exit from the EXEC
  ping        Send echo messages
  traceroute  Trace route to destination

Normal commands available at privilege level 0:

r4#disa 0
r4>?
Exec commands:
  call     Voice call
  disable  Turn off privileged commands
  enable   Turn on privileged commands
  exit     Exit from the EXEC
  help     Description of the interactive help system
  logout   Exit from the EXEC

r4>

I could not get the “CISCO” password to work.

r2#sh run | i enabl
enable secret level 1 5 $1$2rnn$RVQJmvNqbzBPxtZhsm7Ga0
enable password cisco

I tried to use a ‘non-secret’ method, but the IOS cried “foul”:

r2(config)#enable pass level 1 CISCO
% Converting to a secret.  Please use “enable secret” in the future.

r2(config)#do sh run | i enable
enable secret level 1 5 $1$smcE$u7rQfwYvoPYAtd7.d38qO/
enable password cisco

Hmmmm….I telnetted in and found that I needed to specify level 1 and it worked:

r2>enable 1
Password: CISCO
r2>sh privi
Current privilege level is 1

r2>?
Exec commands:
  <1-99>           Session number to resume
  access-enable    Create a temporary Access-List entry
  access-profile   Apply user-profile to interface
  clear            Reset functions
  connect          Open a terminal connection
  crypto           Encryption related commands.
  disable          Turn off privileged commands
  disconnect       Disconnect an existing network connection
  dot11            IEEE 802.11 commands
  enable           Turn on privileged commands
  exit             Exit from the EXEC
  help             Description of the interactive help system
  lat              Open a lat connection
  lock             Lock the terminal
  login            Log in as a particular user
—output truncated—-

11.2 Local Authorization

Set up NOC users to telnet to r5 at privilege level 1, but allow them to be able to “turn on and disable RIP debugging”.

IE just set up level 1 with the ability to debug ip rip and then stop all debugs:

privilege exec level 1 debug ip rip
privilege exec level 1 undebug all

r5#ena 1
r5>debug ip ?
  rip  RIP protocol transactions

What’s odd is that the IOS added a few more privileges (including the dread “debug all”

r5(config)#do sh run | i privilege exec
privilege exec level 1 undebug ip rip
privilege exec level 1 undebug ip
privilege exec level 1 undebug all
privilege exec level 1 undebug
privilege exec level 1 debug ip rip
privilege exec level 1 debug ip
privilege exec level 1 debug all  <-yikes

privilege exec level 1 debug

r5>debug all

This may severely impact network performance. Continue? (yes/[no]):

I guess that we are to assume that only the NOC will be telnetting to the device:

r2#telnet 150.1.5.5
Trying 150.1.5.5 … Open

User Access Verification

Password:
r5>sh privi
Current privilege level is 1

Internetwork Expert Volume II: Lab 3 – Section 10

Section 10 – System Management – 6 Points

10.1  IOS Management

Configure r4 to be managed via HTTP:

Use TCP port 8080
Only permit access from the 136.1.2.0/24 subnet
Authenticate users using local username WEB and the password CISCO
This password should be stored in the router’s configuration as an MD5 hash.

ip http server

r4(config)#username WEB secretCISCO
r4(config)#do sh run | i access-list|ip http|username WEB
username WEB secret 5 $1$lzG6$LoWdN/bOqK9kZtQZZieV//
ip http server
ip http port 8080
ip http access-class 69
ip http authentication local
!
access-list 69 permit 136.1.2.0 0.0.0.255

Cool verification: 

r4#sh ip http server status
HTTP server status: Enabled
HTTP server port: 8080
HTTP server authentication method: local
HTTP server access class: 69
HTTP server base path:
Maximum number of concurrent server connections allowed: 5
Server idle time-out: 180 seconds
Server life time-out: 180 seconds
Maximum number of requests allowed on a connection: 1
HTTP server active session modules: ALL
HTTP secure server capability: Present
HTTP secure server status: Disabled
HTTP secure server port: 443
HTTP secure server ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5 rc4-128-sha
HTTP secure server client authentication: Disabled
HTTP secure server trustpoint:
HTTP secure server active session modules: ALL

10.2 File Management

Okay, this question completely mindfucked me.  Definitely read the breakdown on this task.  It combines an interesting bit of ROMMON magic with a neat trick with the alias command. 

10.3 Autoinstall

Autoinstall….another one of the technologies that I haven’t gotten around to playing with yet.  Another skipped task.  🙂  I did print out the PDF of the following page (all 54 pages 😦 ) and will review it later:

Using AutoInstall to Remotely Configure Cisco Networking Devices

Internetwork Expert Volume II: Lab 3 – Section 9

Section 9 – Security – 6 Points

9.1  Traffic Filtering

“Configure r6 so that it only allows TCP, UDP, and ICMP traffic in from BB1 if it was originated from behind R6.”

“Ensure that users behind r6 can still traceroute to hosts beyond the Frame Relay cloud.”

Confusing wording, but I think that it means that you need to filter traffic from BB1 so that it only allows TCP, UDP, and ICMP responses from devices behind r6 – but not r6.  This sounds like a reflexive ACL.

This is the type of task that I would probably skip in the actual lab.  I really don’t want to fuck up my connection to a backbone router to get 3 points in Security.  There’s an excellent breakdown for this task.  I’d still skip it though.  🙂

9.2 DOS Prevention

Argh!!!  I am SO weak in Security.

“…configure r4 to send a TCP reset to the webserver (136.1.4.100) for any TCP sessions that fail to reach the established state after 15 seconds.”

All I’m sure of in this task is that I’m going to be configuring fa0/0 on r4.

A quick look through the 12.4 Security Configuration Guide yields this document:

Configuring TCP Intercept (Preventing Denial-of-Service Attacks)

It looks like I need an ACL for traffic to the server:

r4(config)#access-list 192 perm tcp any host 136.1.4.100

Then it’s just a matter of picking the correct configuration items:

r4(config)#ip tcp intercept ?
  connection-timeout  Specify timeout for connection info
  drop-mode           Specify incomplete connection drop mode
  finrst-timeout      Specify timeout for FIN/RST
  list                Specify access-list to use
  max-incomplete      Specify maximum number of incomplete connections before
                      clamping
  mode                Specify intercepting mode
  one-minute          Specify one-minute-sample watermarks for clamping
  watch-timeout       Specify timeout for incomplete connections in watch mode

The task asks us to send a TCP reset, so that decides the TCP intercept mode that we will use:

The TCP intercept can operate in either active intercept mode or passive watch mode. The default is intercept mode.

In intercept mode, the software actively intercepts each incoming connection request (SYN) and responds on behalf of the server with an SYN-ACK, then waits for an ACK from the client. When that ACK is received, the original SYN is sent to the server and the software performs a three-way handshake with the server. When this is complete, the two half-connections are joined.

In watch mode, connection requests are allowed to pass through the router to the server but are watched until they become established. If they fail to become established within 30 seconds (configurable with the ip tcp intercept watch-timeout command), the software sends a Reset to the server to clear up its state.

r4(config)#ip tcp intercept mode ?
  intercept  Intercept connections
  watch      Watch connections

r4(config)#do sh run | i list 192|ip tcp
ip tcp intercept list 192
ip tcp intercept watch-timeout 15
ip tcp intercept mode watch
!
access-list 192 permit tcp any host 136.1.4.100

April 4, 2008

Internetwork Expert Volume II: Lab 3 – Section 8

QoS – 6 Points

8.1 FRTS

Configure FRTS with these parameters:

Data should be sent at a sustained rate of 256Kbps per DLCI.  <-CIR
In the event of congestion noticification fallback to no lower than 192Kbps  <-MINCIR with adaptive-shaping becn
Any FECNs received should be reflected back as a BECN. <-???

Not too hard to figure out the third one :-0

r1(config-map-class)#frame ?
  fecn-adapt         Enable Traffic Shaping reflection of FECN as BECN

frame-relay cir

frame-relay mincir

frame-relay adaptive-shaping

becn
 Enables rate adjustment in response to backward explicit congestion notification (BECN).

r1(config-map-class)#do sh run | sec FRTS
map-class frame-relay FRTS
 frame-relay cir 256000
 frame-relay mincir 192000
 frame-relay adaptive-shaping becn
 frame-relay fecn-adapt

Since we want to apply this to ALL DLCIs we just need two commands under the FR int:

r1(config-map-class)#int s0/0/0
r1(config-if)#frame traffic-shaping  <-don’t forget this!!!
r1(config-if)#frame class FRTS

r1(config-if)#do sh traffic

Interface   Se0/0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           256000    4000   256000    0         125       4000      BECN
104           256000    4000   256000    0         125       4000      BECN
105           256000    4000   256000    0         125       4000      BECN
106           256000    4000   256000    0         125       4000      BECN
107           256000    4000   256000    0         125       4000      BECN
108           256000    4000   256000    0         125       4000      BECN
109           256000    4000   256000    0         125       4000      BECN
—output truncated—

8.2 Rate Limiting

Limit HTTP responses out r4’s fa0/1 to 256Kbps between the hours of 8am to 5pm Monday through Friday.

We need to build a time-range first:

time-range
http://www.cisco.com/en/US/docs/ios/12_3t/fun/command/reference/cfrgt_12.html#wp1058115

r4(config)#time-range TASK82
r4(config-time-range)#periodic weekdays 08:00 to 17:00

NOTE: Clarify with the proctor about the start and end time (17:00 versus 16:59)

Now let’s match HTTP in an (extended named) access-list:

ip access-list extended TASK82
 permit tcp any eq www any time-range TASK82

Let’s pop that sucker into a class-map:

class-map match-all TASK82
 match access-group name TASK82

Then match that class in a policy-map and apply our policing:

policy-map TASK82
 class TASK82
    police 256000

Finally let’s put this on the interface:

r4(config)#int fa0/1
r4(config-if)#service-policy out TASK82

The reason that I use consistent naming throughout the process is so that I can quickly look at my configuation:

r4(config-if)#do sh run | sec TASK82
class-map match-all TASK82
 match access-group name TASK82
policy-map TASK82
 class TASK82
    police 256000
 service-policy output TASK82
ip access-list extended TASK82
 permit tcp any eq www any time-range TASK82
time-range TASK82
 periodic weekdays 8:00 to 17:00

IE uses:

policy-map TASK82
 class TASK82
    police cir 256000

Not sure why?

Task 8.2 quick question

With ‘police 256000’:

r4#sh policy-map int fa0/1
 FastEthernet0/1

  Service-policy output: TASK82

    Class-map: TASK82 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name TASK82
      police:
          cir 256000 bps, bc 8000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: class-default (match-any)
      84 packets, 7949 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

With ‘police cir 256000’:

r4#sh policy-map int fa0/1
 FastEthernet0/1

  Service-policy output: TASK82

    Class-map: TASK82 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name TASK82
      police:
          cir 256000 bps, bc 8000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: class-default (match-any)
      101 packets, 9793 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Any differences?

police

r4(config-pmap-c)#police ?
  <8000-2000000000>  Bits per second
  cir                Committed information rate
  rate               Specify police rate

8.3 Signalling

“…administrators have configured the client applications on these vlans to requrest bandwidth reservations…”

RSVP….Integrated Services

The good news is that RSVP is ridiculously easy to configure:

ip rsvp bandwidth

r4(config)#int s0/0/0
r4(config-if)#ip rsvp band 128 64

r4#sh ip rsvp int s0/0/0
interface    allocated  i/f max  flow max sub max
Se0/0/0      0          128K     64K      0

There is one ‘gotcha’ though: You need to enabled WFQ for RSVP.  When you turn on FRTS, WFQ is disabled.  You need to explicitly set it.

Internetwork Expert Volume II: Lab 3 – Section 7

IPv6 – 4 Points

7.1 IPv6 Addressing

Easy.

“The host portion of the IPv6 addresses should be based partly off of their interfaces’ respective MAC addresses.”

That’s your clue to use eui-64:

r4(config-if)#ipv6 add 2001:CC1E:1:404::/64 ?
  anycast  Configure as an anycast
  eui-64   Use eui-64 interface identifier
  <cr>

r4(config-if)#ipv6 add 2001:CC1E:1:404::/64 eui-64

r4(config-if)#do sh int fa0/0 | i bia
  Hardware is MV96340 Ethernet, address is 0017.0ee7.9058 (bia 0017.0ee7.9058)

r4(config-if)#do sh ipv6 int fa0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::217:EFF:FEE7:9058
  Global unicast address(es):
    2001:CC1E:1:404:217:EFF:FEE7:9058, subnet is 2001:CC1E:1:404::/64 [EUI]

This is the second time that this has happened to me in this lab:

“The network administrator has requested that VLAN 29 and VLAN 4 be configured to support IPv6.”

VLAN 4 is only configured (at L3) on r4’s fa0/0 interface.  VLAN 29 (at L3) is configured between r2’s fa0/0 and sw3’s vlan29 (SVI) interface.  Why doesn’t the solution include sw3?

7.2  IPv6 Tunneling

Create a GRE tunnel between VLAN 29 and VLAN 4.  Use any site-local address for the IPv6 addressing within the tunnel.  Configure an IPv6 static route to obtain reachability.

r4#sh run | sec Tunnel|ipv6 route
interface Tunnel0
 no ip address
 ipv6 address FEC0::4/64
 tunnel source 150.1.4.4
 tunnel destination 150.1.2.2
!
ipv6 route 2001:CC1E:1:202::/64 Tunnel0

r2#sh run | sec Tunnel|ipv6 route
interface Tunnel0
 no ip address
 ipv6 address FEC0::2/64
 tunnel source 150.1.2.2
 tunnel destination 150.1.4.4
!
ipv6 route 2001:CC1E:1:404::/64 Tunnel0

r2#p 2001:CC1E:1:404:217:EFF:FEE7:9058

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:404:217:EFF:FEE7:9058, timeout is
2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/138/140 ms

r4#p 2001:CC1E:1:202:217:EFF:FEE7:9940

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:202:217:EFF:FEE7:9940, timeout is
2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/137/140 ms

Internetwork Expert Volume II: Lab 3 – Section 5

Exterior Gateway Routing – 16 Points

5.1 BGP Peering

This was an easy section but there were a lot of AS’s and peerings.  There are two separate AS 100.

Remember ebgp-multihop between r4 and r5.

There is no need for RR in area 100 (r1, r6, r3) as there is a full mesh.

I did miss ‘neigh 136.1.109.10 next-hop-self’ on sw3  ARGH!!!!

5.2 BGP FIltering

AS100 cannot be used a transit to reach AS54.  Configure this only on r6.

I tried to filter the traffic with an as-path access-list and a route map.  IE has a better solution: use the no-export community.

set community

(Optional) Well know communities can be specified by using the following keywords:

•internet
•local-as
•no-advertise
•no-export

r6(config-route-map)#set community ?
  <1-4294967295>  community number
  aa:nn           community number in aa:nn format
  additive        Add to the existing community
  internet        Internet (well-known community)
  local-AS        Do not send outside local AS (well-known community)
  no-advertise    Do not advertise to any peer (well-known community)
  no-export       Do not export to next AS (well-known community)
  <cr>

Nice break down of the BGP communities in the IE solution guide.  This is good because I am still shaky on BGP communities.

r3#sh ip bgp 114.0.0.0
BGP routing table entry for 114.0.0.0/8, version 25
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)  <-
Flag: 0x880
  Advertised to update-groups:
     2
  54
    54.1.3.254 (metric 2560002816) from 136.1.136.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: no-export

5.3 BGP Bestpath Selection

Advertise VLAN3 on r3 into BGP.  AS400 should route through AS300 to get to this prefix.  Do this configuration in AS100.

Best Path Selection Table:

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

Before:
r5#sh ip bgp 136.1.3.0
BGP routing table entry for 136.1.3.0/24, version 27
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1          2
  300 100
    136.1.245.2 from 136.1.245.2 (150.1.2.2)
      Origin IGP, localpref 100, valid, external
  100
    136.1.15.1 from 136.1.15.1 (150.1.1.1)
      Origin IGP, localpref 100, valid, external, best

I went with MED….:-(

“To affect inbound traffic flow you must either prepend the AS-path attribute or set the MED value as the prefix is adveritised outside the AS.  However, since MED is only compared by default on prefixes learned from the SAME AS, AS-path prepending must be used in this case.”

ip prefix-list 53 seq 5 permit 136.1.3.0/24
!
route-map TASK_53_ASPATH permit 10
 match ip address prefix-list 53
 set as-path prepend 100 100
route-map TASK_53_ASPATH permit 1000
!
router bgp 100
 neigh 136.1.15.5 route-map TASK_53_ASPATH out

After:
r5#sh ip bgp 136.1.3.0
BGP routing table entry for 136.1.3.0/24, version 28
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1          2
  100 100 100
    136.1.15.1 from 136.1.15.1 (150.1.1.1)
      Origin IGP, localpref 100, valid, external
  300 100
    136.1.245.2 from 136.1.245.2 (150.1.2.2)
      Origin IGP, localpref 100, valid, external, best

5.4 BGP Attribute Manipulation

Advertise VLAN 29  on r2.

r5 should see this:

r5#sh ip bgp | i 136.1.29.0|Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 136.1.29.0/24    136.1.245.2                          100 300 i

Here’s what we currently see:

r5#sh ip bgp | i 136.1.29.0|Net
   Network          Next Hop            Metric LocPrf Weight Path
*  136.1.29.0/24    136.1.15.1                             0 100 300 i
*>                        136.1.245.2              0             0 300 i

I looks like we’re going to set the weight to 100 and filter the other route?

Attribute Direction Applied Traffic Flow Affected Prefer
Weight Inbound Outbound High
Local_Pref Inbound Outbound High
AS-Path Outbound Inbound Shortest
MED Outbound Inbound Lowest

bgp router 200
 neighbor 136.1.245.2 route-map TASK_54_WEIGHT in
!
ip prefix-list 54 seq 5 permit 136.1.29.0/24
!
route-map TASK_54_WEIGHT permit 10
 match ip address prefix-list 54
 set weight 100
route-map TASK_54_WEIGHT permit 1000

Hmmm….not quite what I got.

   Network          Next Hop            Metric LocPrf Weight Path

*  136.1.29.0/24    136.1.15.1                             0 100 300 i  <-not shown in IE
*>                             136.1.245.2              0           100 300 i

IE solution was the same as mine…kinda bad question.

5.5 BGP Bestpath Selection

YIKES!!!!

Nice breakdown though.

r2#sh ip bgp neigh 136.1.245.5 | i Cond
  Condition-map NON_EXIST, Advertise-map ADVERTISE, status: Withdraw

5.6 BGP AS Path

Advertise the EtherChannel subnet on sw3 into BGP.  Make sure that r3 and sw3 will accept BGP updates with AS100 in the AS-path.  Don’t alter r2’s configuration to accomplish this.

This is where our two AS100’s come back to haunt us.

neighbor allowas-in

January 20, 2008

Internetwork Expert Volume II: Lab 3 – Section 4

Interior Gateway Routing – 21 Points

4.1 OSPF

“Ensure that r2 (spoke) uses r5(hub) as the next hop to reach r4(spoke), and vice versa.”

OSPF Commands

This is a tailor-made case for the OSPF network type point-to-multipoint. 

I did have a strange error pop up during this configuration:

r5(config-router)#int s0/0.245
r5(config-subif)#ip os net point-to-mu
OSPF: Cost or database-filter option is required for point-to-multipoint broadcast network
OSPF: Neighbor 136.1.245.2 command options invalid – neighbor not configured
OSPF: Cost or database-filter option is required for point-to-multipoint broadcast network
OSPF: Neighbor 136.1.245.4 command options invalid – neighbor not configured
*Mar  1 01:23:14.170: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.0 on Serial0/0.245 from ATTEMPT to DOWN, Neighbor Down: Interface down or detached
*Mar  1 01:23:14.170: %OSPF-5-ADJCHG: Process 100, Nbr 0.0.0.0 on Serial0/0.245 from ATTEMPT to DOWN, Neighbor Down: Interface down or detached
*Mar  1 01:23:14.238: %OSPF-5-ADJCHG: Process 100, Nbr 150.1.2.2 on Serial0/0.245 from LOADING to FULL, Loading Done

r5(config-subif)#do sh run int s0/0.245
interface Serial0/0.245 multipoint
 description ->r2, r4 FR HnS
 ip address 136.1.245.5 255.255.255.0
 ip ospf network point-to-multipoint
 frame-relay map ip 136.1.245.2 502 broadcast
 frame-relay map ip 136.1.245.4 504 broadcast
end

There is an excellent breakdown on the point-to-multipoint network type in the IE solution guide.

4.2 OSPF

Read the task carefully:

“Do not use the ip ospf network type ON R5 to accomplish this.”

This doesn’t say anything about r1.

r5#sh ip os int Serial0/0.15 | i Type
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 64

Let’s change r1’s OSPF network type to point-to-point as well:

r1(config)#int s0/0
r1(config-if)#ip os net point-to-point

r1#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.5.5         0   FULL/  –        00:00:38    136.1.15.5      Serial0/0

r1#sh ip route os
     136.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
O       136.1.245.4/32 [110/129] via 136.1.15.5, 00:00:04, Serial0/0
O       136.1.245.5/32 [110/65] via 136.1.15.5, 00:00:04, Serial0/0
O       136.1.245.2/32 [110/129] via 136.1.15.5, 00:00:04, Serial0/0
O IA    136.1.4.0/24 [110/130] via 136.1.15.5, 00:00:04, Serial0/0
O IA    136.1.44.0/24 [110/130] via 136.1.15.5, 00:00:04, Serial0/0

4.3  OSPF

Easy task.  Advertise loopbacks into OSPF with /24 mask.  Just change the OSPF network type from LOOPBACK to POINT-TO-POINT on the loopback 0 interfaces.

4.4 OSPF

Configure the PTP connection from r4 to r5 in area 45 and use it only as a backup link when the Frame Relay link drops.

“Do not user the ‘backup interface’ command to accomplish this.”

I was stumped on this one initially.  I shut the Frame interface on r4 and the OSPF routes changed to the PTP link.  What I initially overlooked was that when that r4 Frame link drops, areas 4 and 44(on r4) will not have a connection to area 0.  I’ll need a virtual-link.

“Virtual-links can be used to repair broken connections to area 0, connect discontiguous area to area 0, and connect discontiguous area0s.”

The method to “trigger” the PTP connection: just give it a higher metric than the Frame Relay link.  When the Frame link drops, then traffic will route over the PTP.

ip ospf cost

area virtual-link

4.5 OSPF

“You are concerned about false routing information being injected into OSPF area 0.  In order to verify the legitimacy of routing information, configure all area 0 adjacencies to be authenticated with a secure hash value of the password CISCO.”

area authentication

Good to know:

Note:To remove the specified area from the software configuration, use the no area area-id command (with no other keywords). That is, the no area area-id command removes all area options, such as area authentication, area default-cost, area nssa, area range, area stub, and area virtual-link.

r1(config-router)#area 0 authentication ?
  message-digest  Use message-digest authentication
r1(config-router)#area 0 authentication message-digest ?
  <cr>

r1(config)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          100   0               150.1.1.1/24       1     P2P   0/0
Se0/0        100   0               136.1.15.1/24      65    P2P   1/1

r1(config)#int s0/0
r1(config-if)#ip os authentication-key CISCO

I did miss the “Pitfall”:

“A virtual-link is an area 0 adjacency.  If authentication is required for all OSPF area adjacencies, then it must also be configured on all virtual-links.”

I also used “ip os authentication-key CISCO” under the interfaces instead of ‘ip ospf message-digest-key md5 CISCO’.

ip ospf message-digest-key md5

4.6 OSPF

Change OSPF metrics to accommodate 10Gbps connections.

auto-cost

The OSPF metric is calculated as the ref-bw value divided by the bandwidth, with mbps equal to 108 by default, and bandwidth determined by the bandwidth (interface) command. The calculation gives FDDI a metric of 1.

If you have multiple links with high bandwidth (such as FDDI or ATM), you might want to use a larger number to differentiate the cost on those links.

The value set by the ip ospf cost command overrides the cost resulting from the auto-cost command. <-nice to know as per task 4.4

So, a bit of math:

10^8 = 100,000,000

I need to make the OSPF cost for 10Gbps (10,000,000,000) = 2

So:

x/10,000,000,000 = 2
x = 2 * 10,000,000,000
x = 20,000,000,000

r5(config-router)#auto-cost reference-bandwidth ?
  <1-4294967>  The reference bandwidth in terms of Mbits per second

Divide my answer by 1,000,000 (Mbit) = 20,000

r5(config-router)#auto-cost reference-bandwidth 20000
% OSPF: Reference bandwidth is changed.
        Please ensure reference bandwidth is consistent across all routers.

I don’t have a 10Gbps interface on my router…yet 🙂  But the task does show that a T1 should have a cost of 12953.  That I can check:

r5(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Vl1          100   0               136.1.45.5/24      65534 P2P   1/1
Lo0          100   0               150.1.5.5/24       1     P2P   0/0
Se0/0.15     100   0               136.1.15.5/24      12953 P2P   1/1 
Se0/0.245    100   0               136.1.245.5/24     12953 P2MP  2/2
Se0/1        100   45              136.1.45.5/24      65534 P2P   1/1

You can see that s0/1’s hard set cost (65534) is not affected.

You need to apply this command to ALL routers running OSPF in your network.

One interesting bit:

r1:
r1#sh int s0/0 | i BW
  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
r1#sh ip os int s0/0 | i Cost
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 13020

r5:
r5#sh int s0/0.15 | i BW
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
r5#sh ip os int s0/0.15 | i Cost
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 12953

This is another “Ask the proctor” issue.  You can easily change this:

r1(config)#int s0/0
r1(config-if)#bandwidth 1544
r1(config-if)#do sh int s0/0 | i BW
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
r1(config-if)#do sh ip os int s0/0 | i Cost
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 12953

4.7  EIGRP

“Do not send EIGRP hello packets out any other interfaces.”
“Do not use the ‘passive interface’ command under the EIGRP process”

“under the EIGRP process”…is there a way to do this under the interface itself?

EIGRP Commands

I couldn’t find anything like that.  What about the neighbor command?

That won’t work either.

I completely overthought this one.  😦

Just add a network mask to your EIGRP network statement:

router eigrp 100
 net 150.1.6.6 0.0.0.0

Why can’t I see r6’s loopback (150.1.6.6) on r2 or r3 or r1?

Did I forget a “no auto” statement? No. 
Something to do with router on a stick? No.
Ummmm….I forgot to advertise VLAN 16 and VLAN 36 on r6. (I caught this before consulting the solutions guide)

Nicely played.  I am learning to verify routes as I go.  🙂

4.8  RIPv2

“…use the strongest authentication on any RIP updates…”
“Do not enable RIP on any other interfaces.”

Configuring Routing Information Protocol

Enabling RIP Authentication

ip rip authentication mode
ip rip authentication mode {text | md5}

Usage Guidelines
RIP Version 1 does not support authentication. <- we use RIPv2 in the lab

passive-interface
passive-interface
 Disables sending routing updates on an interface. 

IE solution shows r5 and sw1 with “passive-interface default”, but not r6???  Why?

Answer: r6 has no overlapping classful interfaces:

r6#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/0                  54.1.3.6        YES NVRAM  up                    up
FastEthernet0/1            204.12.1.6      YES NVRAM  up                    up
BVI1                       136.1.136.6     YES manual up                    up
Loopback0                  150.1.6.6       YES NVRAM  up                    up

r5 and sw1 do:

r5#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.10.1.5      YES NVRAM  up                    up
Serial0/0.15               136.1.15.5      YES NVRAM  up                    up
Serial0/0.245              136.1.245.5     YES NVRAM  up                    up
FastEthernet0/1            136.1.57.5      YES NVRAM  up                    up
Serial0/1                  136.1.45.5      YES NVRAM  up                    up
Loopback0                  150.1.5.5       YES NVRAM  up                    up

sw1:
sw1#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan7                  136.1.7.7       YES NVRAM  down                  down
Vlan57                 136.1.57.7      YES NVRAM  up                    up
Loopback0              150.1.7.7       YES NVRAM  up                    up

Why is vlan7 down?

sw1#sh run int vlan7
interface Vlan7
 ip address 136.1.7.7 255.255.255.0
end

sw1#sh vlan id 7
VLAN id 7 not found in current VLAN database

That’s the reason.  🙂

Initial Configuration for switching …. IE Lab 3

I’ll go ahead and add vlan 7:

23:39:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan7, changed state to up

VLAN7 is not included in IE’s solution either.  They configured “no passive-interface vlan57”, but make no mention of vlan7.  Even though the task requires:

“Enable RIP on VLAN7…”

Task 4.8 – passive interface VLAN7 on SW1 

4.9  IGP Redistribution

ICK!!!

“Redistribute where necessary to obtain full IP reachabiltity to all advertised networks.”
“r5 should route through r1 to get to the prefixes learned from bb1”
“r5 should route through r2 to get to the prefixes learned from bb3”

Looking at my diagram, I have 4 possible point of redistribution:

r1 – OSPF 100 (110)  |  EIGRP 100 (90)
r2 – OSPF 100 (110)  |  EIGRP 100 (90)
r5 – OSPF 100 (110)  |  RIP (120)
r6 – EIGRP 100 (90)  |  RIP (120)

My AD matra: “Lower to higher is good.  Higher to lower is bad.”

Tasks 2 and 3 mean that I need to redistribute RIP into EIGRP on r6 and then redistribute EIGRP into OSPF on r1 and r2.  I’ll set up route maps to filter what routes are redistributed at those points.

I’m really proud of myself.  I finished this task by myself.  I met the requirements for each task, but I used a slightly different method than IE.

Differences:
1) I did not redistribute OSPF into EIGRP on both r1 and r2.  Only on r1.  There was no requirement to do it on both routers and it cut the chance of loops down.
2) I tagged the routes on r6 based on the incoming interface (fa0/1 for BB3 and s0/0 for BB1).  I redistributed all of the routes except the routes tagged from BB1 through r1 into OSPF.  I redistributed the BB1 routes into OSPF through r2 (thinking about this now, I could have probably gotten by just tagging the BB1 routes).

This task took me FOREVER, but I did complete it successfully.

I will say that the IE solution manual is VERY light on explaining their route redistribution answer.

January 1, 2008

Internetwork Expert Volume III: Lab 3 – Section 5

5 Exterior Gateway Routing

5.1 BGP Peerings

This task started out looking very straight-forward, then took an ugly turn.  😦

“All devices running BGP should have reachability to all BGP learned prefixes.”
“Don’t use tunnelling to accomplish this.”

This seemed really simple.  I set up my peerings and all of the BGP learned routes were valid best routes.

I had problems with the routes learned from the backbone routers:

r3#p 113.0.0.1

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

Type escape sequence to abort.
Tracing the route to 113.0.0.1

  1 190.1.135.532 msec 32 msec 28 msec
  2 190.1.135.5 !H  *  !H

I didn’t read enough into this question as “all devices running BGP” means ALL devices not just my devices.  Since the backbones are running BGP, I need to ensure that they have full reachability as well.

I threw in the towel here.  I reallyneed to review BGP.  Luckily, the answer guide has a breakdown for this task (the only breakdown in the guide).  It had a lot of good information, but I am still lacking in my BGP skills.

5.2 BGP Summarization

You are asked to summarize 112.0.0.0/8 – 119.0.0.0/8 into a single advertisement without overlapping any other networks.

This is a case where you can quickly whip this up by utilizing the Windows Calculator in scientific mode. [You are allowed to use the Windows calculator in the CCIE lab.]

1) Open the Microsoft calculator (you can search for it in Programs or just type ‘calc’ in Start->Run).
2) Click ‘View’.  Make sure that that calculator is in ‘scientific’ mode.
3) Dec (decimal) should be selected.  Key in 112.
4) Now select Bin (binary).  You should get 1110000
5) Switch back to Dec and do the same for 119.  You should get 1110111

You want to summarize at the point where the bits no longer match

112  – 01110|000
119  – 01110|111

So your summarization will be 112.0.0.0/5 or 112.0.0.0 with a mask of 248.0.0.0.  Now it’s just a simple matter of using “aggregate-address” to advertise the summary:

aggregate-address  

router bgp 100
 aggregate-address 112.0.0.0 248.0.0.0

The IE answer key introduced me to a cool new verification command:

show ip bgp cidr-only

r6#sh ip bgp cidr-only
BGP table version is 30, local router ID is 150.11.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   54.11.1.254                            0 54 i
*> 28.119.17.0/24   54.11.1.254                            0 54 i
*> 112.0.0.0/5      0.0.0.0                            32768 i
s> 190.11.0.0/24    0.0.0.0                  0         32768 i

Internetwork Expert Volume III: Lab 3 – Section 4 Part 2

4 Interior Gateway Routing

4.13 IGP Redistribution

The dreaded IGP redistribution task.  In this lab task 4.13 explicitly tells you where and how to perform redistribution.  Task 4.14 then asks you to prevent loops:

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

I have the following points of redistribution:

r3: RIP 120      -> OSPF 110
    OSPF 110     -> RIP 120

r4: RIP 120      -> OSPF 110

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

r5 looks ugly.  I’ll do that one last.

r3 has mutual redistribution, but this should not be a problem because it’s on the same router.  There are no routes currently being redistributed on these routers so I shouldn’t break anything.  When I redistribute RIP into OSPF, this will introduce the BB2 routes into OSPF.  I am also using IE’s recommended tagging structure (router + protocol AD):

r3(config)#router os 100
r3(config-router)#redist rip sub tag 3120

I can see the BB2 routes on r1 now:

r1#sh ip ospf data external adv-router 150.1.3.3 | i Link State|Mask|Tag
                Type-5 AS External Link States
  Link State ID: 190.1.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 192.10.1.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 205.90.31.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 220.20.3.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120
  Link State ID: 222.22.2.0 (External Network Number )
  Network Mask: /24
        External Route Tag: 3120

I can safely redistribute the OSPF routes into RIP on r3.  The only concern is the BB2 routes reflecting back into RIP with a better AD (110 versus 120).  But the router will not install these routes.  [Basically because the RIP route would be replaced by OSPF route which would mean that the RIP route would not have been redistributed in the first place – “The Single Router Redistribution Paradox”  🙂 ]

Before redistribution:
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0 <-bb2 route

r3(config)#route-map OSPF->RIP_SET_TAG permit 10
r3(config-route-map)#set tag 3110
r3(config-router)#redist ospf 100 route-map OSPF->RIP_SET_TAG metric 2

After redistribution, the route is unchanged (as I expected):
r3#sh ip route | i 220.20.3.0
R    220.20.3.0/24 [120/7] via 192.10.1.254, 00:00:14, FastEthernet0/0

On to r4.  We have to redistribute RIP (120) into OSPF (110).  This should not be an issue as it is one-way redistribution (it may become an issue later when we redistribute OSPF into RIP on r5).  This will put the bb3 routes into OSPF.  BUT we do have a possible issue because we are currently redistributing Loop0 into OSPF via connected with a route-map:

route-map LOOP0->OSPF permit 10
 match interface Loopback0
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets tag 41 route-map LOOP0->OSPF
 network 190.1.34.4 0.0.0.0 area 34

So we know that redistribution uses a two step algorithm:

1) Take all of the RIP routes in the routing table and advertise them in OSPF.
2) Take all connected interfaces running RIP and advertise them into OSPF (implicit route-map)

In this case we will break the second step with our LOOP0->OSPF map.  We need to include the interfaces running RIP in that route-map.

  Default version control: send version 2, receive version 2
    Interface                    Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    FastEthernet0/1       2     2
    Serial0/1                      2     2

So I need to add interfaces fa0/0, fa0/1, and s0/1 to my route-map.

The IE answer key is a little puzzling at first glance.  They show the following for r4:

router ospf 1
 redistribute rip subnets
!
route-map CONNECTED->OSPF permit 20
!
router rip
 redistribute ospf 1 metric 1  <-WTF???

The route-map CONNECTED->OSPF is what they used for task 4.7 (to get Lo0 into OSPF) so basically they are now adding a “permit all” line at the end of that route-map, so that we are redistributing ALL connected interfaces into OSPF.  Here is what they are effectively doing:

route-map CONNECTED->OSPF permit 10
 match interface loopback0
route-map CONNECTED->OSPF permit 20
!
router ospf 1
 redistribute rip subnets
 redistribute connected subnets route-map CONNECTED->OSPF

That makes sense.  I don’t know why they are redistributing the OSPF routes into RIP though?  The task requires one-way redistribution only.  Here’s my solution (I removed the old route-map and “redistribute connected” configurations):

route-map CONNECTED->OSPF permit 10
 description TASK 4.8 Lo0 into OSPF
 match interface Loopback0
 set tag 41
route-map CONNECTED->OSPF permit 20
 description TASK 4.13 RIP->OSPF redist connected
 match interface FastEthernet0/0 FastEthernet0/1 Serial0/1
 set tag 4120
!
router ospf 100
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute connected subnets route-map CONNECTED->OSPF
 redistribute rip subnets tag 4120
 network 190.1.34.4 0.0.0.0 area 34

Here are the redistributed RIP routes on r1:

r1#sh ip os data | i Tag|4120
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       653         0x80000001 0x004482 4120
10.5.5.5        150.1.4.4       653         0x80000001 0x00FAC4 4120
30.0.0.0        150.1.4.4       112         0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       112         0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       112         0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       112         0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       112         0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       112         0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       112         0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       112         0x80000001 0x006A4C 4120
190.1.4.0       150.1.4.4       653         0x80000001 0x003BD9 4120
204.12.1.0      150.1.4.4       653         0x80000002 0x001FDE 4120

This accomplishes the same thing, but with the benefit of unique tags on the routes.

Okay…no more putting it off…on to r5:

r5: RIP 120      -> EIGRP 90
    OSPF 110     -> RIP 120
    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

So…mutual redistribution between OSPF and EIGRP as well as one-way redistribution between OSPF and RIP as well as RIP and EIGRP.  Did I already say “yuck”? 🙂

“lower to higher = good”  so OSPF into RIP should be fine.  Let’s start with that one.

Current RIP configuration:
router rip
 version 2
 no validate-update-source
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Before we do this, we need to look at what’s happening with the BB3 routes.  They are being advertised from BB3 to r4 via RIP.  R4 then advertises them to r5 via RIP.

We have redistributed the RIP routes into OSPF on r4 so now they routes flow from BB3 to r4 via RIP.  They then get redistributed into OSPF.  r5 sees the routes from r4 via RIP and from r3 via OSPF.  Since OSPF has the lower AD, the OSPF routes are installed:

Before redistribution on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

R       30.2.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.3.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.0.0.0 [120/15] via 10.4.4.4, 00:00:00
R       30.1.0.0 [120/15] via 10.4.4.4, 00:00:00

After redistributing RIP->OSPF on r4:

r5#sh ip route 30.0.0.0
Routing entry for 30.0.0.0/16, 4 known subnets
  Redistributing via rip, ospf 100

O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:00:33, Serial0/0.1

So if we redistribute OSPF into RIP on r5 are we introducing a routing loop for the bb3 routes?  I don’t think so.  We’re really not doing much at all.  r4 and r5 both know all of the OSPF routes because they are running OSPF already.  Even the RIP routes learned from bb2 via r3 are already known by r5 and r3 via OSPF (RIP was redistributed into OSPF on r3 already).  I can’t see any problems with this redistribution.

route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110
!
router rip
 version 2
 no validate-update-source
 redistribute ospf 100 metric 2 route-map OSPF->RIP
 passive-interface default
 no passive-interface Serial0/1
 network 10.0.0.0
 network 150.1.0.0
 no auto-summary

Alright.  Let’s do the other one-way redistribution on r5: RIP 120 into EIGRP 90.

At first this looks like an issue because we’re going from a higher AD protocol (RIP 120) to a lower AD protocol (EIGRP 90), but we need to remember that EIGRP will give external routes an AD of 170 so we don’t need to worry about these routes coming back into RIP.

One other thing…there are no RIP routes in the r5 routing table  🙂

r5#sh ip route rip

r5#

So the only thing that we will be redistributing into EIGRP are the interfaces running RIP (only int s0/1):

Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Serial0/1             2     2

route-map RIP->EIGRP permit 10
 description Tag RIP routes with 5120
 set tag 5120
!
router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP

Before redistribution:

r2#sh ip route ei | sec D EX
r2#

After redistribution:

r2#sh ip route ei | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:04:24, GigabitEthernet0/0

We can’t ping 10.4.4.4 though:

r2#p 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)

That’s because there is no path back on r4:

r4#sh ip route 190.1.0.2
% Subnet not in table

Finally…the mutual redistribution on r5:

    OSPF 110     -> EIGRP 90
    EIGRP 90/170 -> OSPF 110

We should be covered here too because the OSPF routes redistributed into EIGRP will appear as D EX routes with an AD of 170.

I would filter any D EX routes from being redistributed back into OSPF

Before mutual redistribution:

r1#sh ip route | i E2
       E1 – OSPF external type 1, E2 – OSPF external type 2
O E2 222.22.2.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 204.12.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 220.20.3.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    190.1.3.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.4.4.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    10.5.5.5/32 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 192.10.1.0/24 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.3.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.2.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.1.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    31.0.0.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2    150.1.5.0 [110/20] via 190.1.135.5, 00:56:24, Serial0/0.1
O E2    150.1.4.0 [110/20] via 190.1.135.3, 00:56:24, Serial0/0.1
O E2 205.90.31.0/24 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.2.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.3.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.0.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1
O E2    30.1.0.0 [110/20] via 190.1.135.3, 00:56:25, Serial0/0.1

r2#sh ip route | sec D EX
D EX    10.5.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
D EX    10.4.4.4/32
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0
     150.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
D EX    150.1.5.0/24
           [170/2560002816] via 190.1.0.5, 00:18:48, GigabitEthernet0/0

We don’t have any D EX routes on r5:

r5#sh ip route ei | i D EX
r5#

We’re not redistributing connected under either protocol, so we should be good to go:

router eigrp 10
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
 network 190.1.0.5 0.0.0.0
 network 190.1.5.5 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.5.5
!
router ospf 100
 router-id 150.1.5.5
 log-adjacency-changes
 redistribute rip subnets tag 5120 route-map LOOP0->RIP-OSPF
 network 190.1.135.5 0.0.0.0 area 135
 neighbor 190.1.135.3
 neighbor 190.1.135.1

r1#sh ip os data | i Tag|590|5170
Link ID         ADV Router      Age         Seq#       Checksum Tag
54.1.1.0        150.1.5.5       42          0x80000001 0x001F57 590
150.1.2.0       150.1.5.5       42          0x80000001 0x002AEB 590
150.1.6.0       150.1.5.5       42          0x80000001 0x00FD14 590
150.1.8.0       150.1.5.5       42          0x80000001 0x00E728 590
190.1.0.0       150.1.5.5       42          0x80000001 0x003BB3 590
190.1.5.0       150.1.5.5       42          0x80000001 0x0004E5 590
200.0.0.0       150.1.5.5       42          0x80000001 0x00C421 590
200.0.1.0       150.1.5.5       42          0x80000001 0x00B92B 590
200.0.2.0       150.1.5.5       42          0x80000001 0x00AE35 590
200.0.3.0       150.1.5.5       42          0x80000001 0x00A33F 590

Sweet.  I’m seeing EIGRP routes, but no D EX routes redistributed into OSPF.

Now the final step.  OSPF into EIGRP.  We should be fine because the OSPF routes will become D EX routes and not reflect back into OSPF.

So now we have a ton of D EX routes on r2:

r2#sh ip route | i D EX
D EX 222.22.2.0/24
D EX 204.12.1.0/24
D EX 220.20.3.0/24
D EX    190.1.135.0
D EX    190.1.34.0
D EX    190.1.17.0
D EX    190.1.4.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    190.1.3.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    10.5.5.0/24
D EX    10.4.4.0/24
D EX    10.4.4.4/32
D EX 192.10.1.0/24
D EX    31.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    31.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    150.1.7.0/24
D EX    150.1.5.0/24
D EX    150.1.4.0/24
D EX    150.1.3.0/24
D EX    150.1.1.0/24
D EX 205.90.31.0/24
D EX    30.2.0.0 [170/2560002816] via 190.1.0.5, 00:00:18, GigabitEthernet0/0
D EX    30.3.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.0.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0
D EX    30.1.0.0 [170/2560002816] via 190.1.0.5, 00:00:20, GigabitEthernet0/0

But still none on R5:

r5#sh ip route | i D EX
r5#

We can ping 10.4.4.4 from the EIGRP domain now:

r2#p 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 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms 

We can make one more sanity check.  Let’s create a new loopback on r2 and redistribute it into EIGRP.  This will create an external route that should show up in the OSPF domain.  We can then verify that our 5170 tags are working.

r2(config)#int lo1
r2(config-if)#ip add 2.2.2.2 255.255.255.0
r2(config-if)#route-map LOOP1->EIGRP perm 10
r2(config-route-map)#match int lo1
r2(config-route-map)#router eig 10
r2(config-router)#redist conn route-map LOOP1->EIGRP met 1 1 1 1 1

It shows up on r5:

r5#sh ip route | i D EX
D EX    2.2.2.0 [170/2560002816] via 190.1.0.2, 00:00:15, FastEthernet0/0

It should now appear on r1 as an E2 OSPF route with a tag of 5170:

r1#sh ip route 2.2.2.0
Routing entry for 2.2.2.0/24
  Known via “ospf 100”, distance 110, metric 20
  Tag 5170, type extern 2, forward metric 65
  Last update from 190.1.135.5 on Serial0/0.1, 00:01:46 ago
  Routing Descriptor Blocks:
  * 190.1.135.5, from 150.1.5.5, 00:01:46 ago, via Serial0/0.1
      Route metric is 20, traffic share count is 1
      Route tag 5170

Sweet!!!  My tagging system works.  Let’s remove that configuration and then work on task 4.14

4.14 Redistribution Loop Prevention

“Do not allow the RIP routes redistributed into OSPF on r4 to be passed back into RIP on r5.”
“Use route tagging to accomplish this.”

The RIP routes redistributed into OSPF on r4 should be tagged with 4120 (and lo0 will be tagged 41).  Let’s see if they show up on r5:

r5#sh ip os data | i Tag|41
Link ID         ADV Router      Age         Seq#       Checksum Tag
10.4.4.0        150.1.4.4       971         0x80000005 0x003C86 4120
10.5.5.5        150.1.4.4       971         0x80000005 0x00F2C8 4120
30.0.0.0        150.1.4.4       692         0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       691         0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       691         0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       691         0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       691         0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       691         0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       691         0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       691         0x80000001 0x006A4C 4120
150.1.4.0       150.1.4.4       971         0x80000005 0x005FD8 41
190.1.4.0       150.1.4.4       971         0x80000005 0x0033DD 4120
204.12.1.0      150.1.4.4       971         0x80000006 0x0017E2 4120

Here’s my OSPF->RIP redistribution on r5:

router rip
 redistribute ospf 100 metric 2 route-map OSPF->RIP
!
route-map OSPF->RIP permit 10
 description Tag OSPF routes with 5110
 set tag 5110

So basically, we just need to create a deny statement for routes tagged 4120 or 41:

route-map OSPF->RIP deny 10
 description Filter OSPF routes tagged 4120 or 41
 match tag 4120 41
route-map OSPF->RIP permit 20
 description Tag OSPF routes with 5110
 set tag 5110

Whew!!!  These two tasks took me awhile, but I feel like I had a very good understanding of what was going on.  I’m still painfully slow, but I the basics of route redistribution are finally baking into my brain.  🙂

Internetwork Expert Volume III: Lab 3 – Section 4 Part 1

4 Interior Gateway Routing

4.1 RIPv2

Very simple task.  Luckily they didn’t ask for a minimal configuration:

My answer:
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 no passive-interface Serial0/1
 network 10.0.0.0
 network 190.1.0.0
 network 204.12.1.0
 no auto-summary

IE’s answer:
router rip
 version 2
 passive-interface Serial0/0 <-much simpler  🙂
 network 10.0.0.0
 network 190.1.0.0
 network 204.12.1.0
 no auto-summary

4.2 RIPv3

“Allow r4 and r5 to send/receive RIP updates between each other across the Serial connection by disabling the validation of RIP updates.”

Remember that the r4 and r5 s1/0 are in different IP subnets.  The wording of the task gives you a huge clue.

validate-update-source

r4(config)#router rip
r4(config-router)#no validate-update-source

Now you’ll see r4’s RIP advertised networks on r5:

r5#clear ip route *
r5#sh ip route rip
R    204.12.1.0/24 [120/1] via 10.4.4.4, 00:00:03
     190.1.0.0/24 is subnetted, 5 subnets
R       190.1.34.0 [120/1] via 10.4.4.4, 00:00:03
R       190.1.4.0 [120/1] via 10.4.4.4, 00:00:03

4.3 RIPv2 Metric Manipulation

“Configure an inbound offset-list on r4so the RIP routes learned from BB3 appear in r5’s routering table with a hop count of 15.”  

This task illustrates one of the differences between the Volume II and Volume III labs: you are more likely to see tasks in the Volume III labs that explicitly tell what feature to use in order to accomplish a task.

offset-list (RIP)

I decided to just offset ALL of the RIP routes coming in fa0/0 rather than configure an explicit ACL.  You can do this by using ACL 0 in your offset-list: 

r4(config-router)#offset-list 0 in 14 fa0/0

This tells the router to add 14 to the hop count of all  RIP routes inbound on interface fa0/0 (to BB3):

r4#sh ip route rip
     31.0.0.0/16 is subnetted, 4 subnets
R       31.3.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       31.2.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       31.1.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       31.0.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
     30.0.0.0/16 is subnetted, 4 subnets
R       30.2.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       30.3.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       30.0.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0
R       30.1.0.0 [120/15] via 204.12.1.254, 00:00:01, FastEthernet0/0

I was confused when I saw the IE answer:

offset-list 0 in 13 fa0/0

I have no idea why they used 13?

SHIT!!!! YES I DO.  A quick reread the question shows how I lost some easy points by not reading the question carefully:

“Configure an inbound offset-list on r4 so the RIP routes learned from BB3 appear in r5’s router table with a hop count of 15.”

My “solution” not only lost me some easy points, but it also effectively filtered all of the BB3 routes from r5 because they now have a hop-count of 16 on r5 so they are not installed:

r5#sh ip route rip
R    204.12.1.0/24 [120/1] via 10.4.4.4, 00:00:22
     190.1.0.0/24 is subnetted, 5 subnets
R       190.1.34.0 [120/1] via 10.4.4.4, 00:00:22
R       190.1.4.0 [120/1] via 10.4.4.4, 00:00:22

After a quick change:

r4(config)#router rip
r4(config-router)#offset-list 0 in 13 fa0/0  

r5#sh ip route rip
—output truncated—
R       31.3.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.2.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.1.0.0 [120/15] via 10.4.4.4, 00:00:09
R       31.0.0.0 [120/15] via 10.4.4.4, 00:00:09
     30.0.0.0/16 is subnetted, 4 subnets
R       30.2.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.3.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.0.0.0 [120/15] via 10.4.4.4, 00:00:09
R       30.1.0.0 [120/15] via 10.4.4.4, 00:00:09

4.4 OSPF

Easy OSPF task.  You need to peer r1, r3, and r5 across Frame Relay.  r5 must be the DR and you are not allowed to change the OSPF network type.  You’ll need your old friend, the ‘neighbor’ command to change your OSPF traffic to unicast to get around the default NON_BROADCAST network type.

neighbor (OSPF)

NOTE: Looking at the protocol topology, I don’t see an OSPF area 0. ????

4.5 OSPF

Here’s where that missing area 0 comes back to bite me in the ass.  You are asked to configure two more non-zero areas and then:

“Without regard to network redundancy, use the minimal number of virtual links needed to support this OSPF domain.”

I’m lost.  I thought that you needed to have an area 0.  I have 3 areas: 17, 34, and 135.

I guess that the minimum number of links is one.  We just need to connect r1 (area 17) to r3 (area 35) through area 135.  I am missing a fundamental understanding of OSPF concerning virtual-links and area 0.  I’ll need to hit the books. [It turns out that my understanding was correct, but my lab strategy was flawed…see next task.]

I also changed the OSPF network type on r3 and r4’s Frame Relay interfaces to broadcast to establish an adjacency.  IE used the neighbor command.  Both methods work.

4.6 OSPF Loopback Advertisement

LESSON LEARNED!!!  READ THE ENTIRE LAB.

Well, now I know where to find area 0.  I am tasked with advertising a loopback into area 0 in this task. This makes 4.5 make sense and it makes the virtual link come up.

4.7 OSPF Loopback Advertisement

Advertise another loopback in to OSPF and advertise it with a /24 mask.  Then:

“This subnet should not be associated with any particular area.”

There are two ways to accomplish this, but I only remember one.  🙂

Redistributing Loopback 0 into OSPF will accomplish this task.  I need to keep this in mind when it comes time to do IGP redistribution.

r4(config)#route-map LOOP->OSPF permit
r4(config-route-map)#match int lo0
r4(config-route-map)#router os 100
r4(config-router)#redist conn sub route-map LOOP->OSPF tag 41

r3#sh ip route os | i E
O E2    150.1.4.0/24 [110/20] via 190.1.34.4, 00:01:17, Serial0/1:0

4.8 OSPF Loopback Advertisement

This task switches up the previous task.  This time you need to advertise a loopback with a /24 but it needs to be associated with an area (area not specified) and you cannot use “ip ospf network point-to-point” for this task.

This can be accomplished with the “area range” command.

area range

r3(config-router)#area 3 range 150.1.3.0 255.255.255.0 advertise

r5#sh ip route os | i 150.1.3.0
O IA    150.1.3.0 [110/65] via 190.1.135.3, 00:00:51, Serial0/0.1

r5#sh ip route 150.1.3.3
Routing entry for 150.1.3.0/24
  Known via “ospf 100”, distance 110, metric 65, type inter area
  Last update from 190.1.135.3 on Serial0/0.1, 00:00:54 ago
  Routing Descriptor Blocks:
  * 190.1.135.3, from 150.1.3.3, 00:00:54 ago, via Serial0/0.1
      Route metric is 65, traffic share count is 1

4.9 OSPF Loopback Advertisement

Another variation on a theme: Advertise a loopback into OSPF.  It should appear in all other OSPF routers with a /24 mask.  It should not be associated with any area.  Don’t use ‘redistribute connected’ to do this.

I’m out of ideas.  Maybe a summary route?  Tried it – didn’t work.

The answer is pretty ingenious:

1) Advertise lo0 into RIP
2) Match lo0 in a route-map
2) Redistribute only the lo0 RIP network into OSPF using the route-map

r3#sh ip route 150.1.5.5
Routing entry for 150.1.5.0/24
  Known via “ospf 100“, distance 110, metric 20, type extern 2, forward metric 65
  Last update from 190.1.135.5 on Serial0/0:0.1, 00:00:09 ago
  Routing Descriptor Blocks:
  * 190.1.135.5, from 150.1.5.5, 00:00:09 ago, via Serial0/0:0.1
      Route metric is 20, traffic share count is 1

On the actual lab, I would have simply matched the loopback in a route-map and redistributed connected (with route-map) into OSPF.  I would have lost the points for this task, but OSPF would still have the route with a /24 mask and not associated with any area.

4.10 EIGRP

Easy EIGRP task.  IE solution guide is missing the sw3 configuration.

4.11 EIGRP

Easy EIGRP authentication task.  You need to establish a neighbor relationship with BB1.  The only thing missing is whether you need to use md5 or not (you do).  I honestly don’t think that non-md5 EIGRP authentication is an option anymore, but I will need to research that.

4.12 EIGRP Summarization

Advertise some routers’ loopbacks into EIGRP but have them appear to other routers with a /23 mask rather than a /24 mask.

You need to do route summarization.  Remember that in EIGRP that this is done under the interface that the route will go out:

r2(config-if)#ip summary-address ?
  eigrp  Enhanced Interior Gateway Routing Protocol (EIGRP)
  rip    Routing Information Protocol (RIP)

ip summary-address eigrp

/23 = 255.255.254.0

Need to be careful with sw3 (150.1.9.9)

00001001 with /23 mask will be 150.1.8.0/23

Should I leak the actual loopback IP?  Will this fuck up my router-id?

Interesting:  IOS will change your summary-address statement for you:

sw3(config)#int vlan 2569
sw3(config-if)#ip summary-address eigrp 10 150.1.9.0 255.255.254.0
sw3(config-if)#do sh run int vlan 2569
interface Vlan2569
 ip address 190.1.0.9 255.255.255.0
 ip summary-address eigrp 10 150.1.8.0 255.255.254.0 5

 r5#sh ip route 150.1.2.2 | i Routing entry|Known
Routing entry for 150.1.2.0/23
  Known via “eigrp 10”, distance 90, metric 156160, type internal

r5#sh ip route 150.1.6.6 | i Routing entry|Known
Routing entry for 150.1.6.0/23
  Known via “eigrp 10”, distance 90, metric 156160, type internal

r5#sh ip route 150.1.9.9 | i Routing entry|Known
Routing entry for 150.1.8.0/23  <-note the third octet
  Known via “eigrp 10”, distance 90, metric 156160, type internal

IE solution guide shows 150.1.8.0 255.255.255.

Next Page »

Blog at WordPress.com.