CCIE Pursuit Blog

September 17, 2008

EIGRP Offset-Lists and Show IP Protocols

Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 8:12 am
Tags: , , , , ,

It’s funny how you may have done a task many times and not noticed an IOS feature.  I applied an offset-list to some EIGRP routes and stumbled across some output I had never noticed before (to be fair I usually use offset-lists with RIP and not EIGRP):

No EIGRP offset-list(s) applied:

Rack17SW1#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.27.2           90      00:24:46
    156.17.67.6           90      00:24:46
  Distance: internal 90 external 170

With the offset-lists applied (different paths based on whether the 3rd octet is even or odd):

router eigrp 10
 timers active-time 5
 offset-list ODD in 666666666 Vlan18
 offset-list EVEN in 666666666 Vlan58

 network 0.0.0.0
 no auto-summary
!
ip access-list standard EVEN
 permit 0.0.0.0 255.255.254.255
ip access-list standard ODD
 permit 0.0.1.0 255.255.254.255

Notice the difference?  🙂

Rack17SW2#sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Incoming routes in Vlan18 will have 666666666 added to metric if on list ODD
  Incoming routes in Vlan58 will have 666666666 added to metric if on list EVEN

  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 10
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    156.17.18.1           90      00:17:55
    156.17.58.5           90      00:17:55
  Distance: internal 90 external 170

September 15, 2008

Disabling EIGRP Unequal-Cost Load-Balancing

Filed under: Cisco,Cisco Certification,EIGRP,IOS — cciepursuit @ 6:53 am
Tags: , , , , ,

This may be old news to you guys but I had never seen the “traffic-share min across-interfaces” command before.  I was messing about with EIGRP unequal cost load-sharing the other day and came across it.

r1(config-router)#traffic-share ?
  balanced  Share inversely proportional to metric
  min       All traffic shared among min metric paths <-what’s this?

r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config-router)#traffic-share min across-interfaces

Weird.  It turns off unequal-cost load balancing by not allowing traffic over the Feasable Successor route(s) regardless of the variance command:

r1(config-router)#var 4
*Mar  2 00:05:02.000: %FIB-4-UNEQUAL: Range of unequal path weightings too large for prefix 150.1.6.0/24. Some available paths may not be used.

r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
Routing entry for 164.1.26.0/24
  Known via “eigrp 100”, distance 90, metric 3026432, type internal
  Redistributing via eigrp 100
  Last update from 164.1.12.2 on Serial0/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:03 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    164.1.12.2, from 164.1.12.2, 00:00:03 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

r1(config-router)#var 40
r1(config-router)#do sh ip route 164.1.26.0 255.255.255.0
Routing entry for 164.1.26.0/24
  Known via “eigrp 100”, distance 90, metric 3026432, type internal
  Redistributing via eigrp 100
  Last update from 164.1.12.2 on Serial0/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 164.1.13.3, from 164.1.13.3, 00:00:02 ago, via Serial0/1
      Route metric is 3026432, traffic share count is 1
      Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
    164.1.12.2, from 164.1.12.2, 00:00:02 ago, via Serial0/0
      Route metric is 10514432, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Here’s the explanation:

Similarly, when you use the traffic-share command with the keyword min, the traffic is sent only across the minimum-cost path, even when there are multiple paths in the routing table.

router eigrp 1
 network x.x.x.x
 variance 3
 traffic-share min across-interfaces

In this situation, EIGRP sends packets only through E-C-A, which is the best path to the destination network. This is identical to the forwarding behavior without use of the variance command. However, if you use the traffic-share min command and the variance command, even though traffic is sent over the minimum-cost path only, all feasible routes get installed into the routing table, which decreases convergence times. 

It turns out that this command is available for all routing protocols.

r1(config)#router os 100
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths
r1(config)#router rip
r1(config-router)#traffic-share min ?
  across-interfaces  Use different interfaces for equal-cost paths

August 26, 2008

Lab Tip: Clear Your EIGRP Process

I spent a good chunk of my weekend going over EIGRP metric manipulation and how it affects EIGRP unequal-cost load-balancing.  More than a few times I ran into weird output like routes dropping, metric values not changing, and even this doozy:

r1#sh ip ei top 164.1.26.0 255.255.255.0
IP-EIGRP (AS 100): Topology entry for 164.1.26.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2693120
  Routing Descriptor Blocks:
  164.1.13.3 (Serial0/1), from 164.1.13.3, Send flag is 0x0
      Composite metric is (3026432/2514432), Route is Internal
      Vector metric:
        Minimum bandwidth is 1280 Kbit
        Total delay is 40100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  164.1.12.2 (Serial0/0), from 164.1.12.2, Send flag is 0x0
      Composite metric is (10514432/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 256 Kbit
        Total delay is 20100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

The AD of the successor is not equal to the FD????

By clearing the EIGRP process, these discrepancies go away.  You can do this the soft way:

r1#clear ip eigrp 100 neighbors soft
*Mar  2 05:22:13.522: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is resync: manually cleared

Or the rough way:

r1#clear ip eigrp 100 neighbors
*Mar  2 05:22:48.708: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is down: manually cleared
*Mar  2 05:22:49.782: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 164.1.12.2 (Serial0/0) is up: new adjacency

I like it rough.  🙂

In the case of EIGRP it really doesn’t matter as the protocol reconverges so quickly.

August 16, 2008

Internetwork Expert Volume II: Lab 8 – Section 3

Section 3 – Interior Gateway Routing – 16 Points

3.1 OSPF

Simple OSPF task.  The only odd bit is that you’ll be configuring OSPF over the PPPoFR network.  It makes sense that the OSPF network type is point-to-point.  🙂

r3(config-router)#do sh ip os int | i proto|Type
Multilink1
is up, line protocol is up
  Process ID 100, Router ID 150.1.3.3, Network Type POINT_TO_POINT, Cost: 1

r2#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3         0   FULL/  –        00:00:38    174.1.23.3      Multilink1

“Authenticate the OSPF adjacency between r2 and r6 using OSPF type 1 authentication.”

Crap.  I think that type 1 is just clear-text (type 0 = null and type 7 = md5).  It’s weird that the task does not mention a password.  I used the old standby of “CISCO”

r6(config-router)#int FastEthernet0/1.26
r6(config-subif)#ip ospf authentication
r6(config-subif)#ip ospf authentication-key CISCO

r2(config-subif)#do sh ip os int Gi0/0.26 | i proto|authe
GigabitEthernet0/0.26 is up, line protocol is up
  Simple password authentication enabled 

3.2 OSPF

Configure area 38 so that “external LSAs” are not advertised in.

We know that we’re done to stub or totally stubby at this point.

“Ensure that devices in OSPF area 38 still have specific forwarding information about prefixes originated in other OSPF areas.”

So we need to allow IA routes (LSA 3).  That sounds like a stub area to me.

3.3 OSPF

Create area 67 and then summarize 150.1.6.6 and 150.1.7.7 with no overlapping address space:

7 0000011|1
6 0000011|0

150.1.6.0/23 or 150.1.6.0 255.255.254.0

Summary will move from area to area so use…..area range.  🙂

r6(config)#router os 100
r6(config-router)#area 67 range 150.1.6.0 255.255.254.0

r3#sh ip route 150.1.6.6
Routing entry for 150.1.6.0/23
  Known via “ospf 100”, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:36 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:36 ago, via Multilink1
      Route metric is 3, traffic share count is 1

r3#sh ip route 150.1.7.7
Routing entry for 150.1.6.0/23

  Known via “ospf 100”, distance 110, metric 3, type inter area
  Last update from 174.1.23.2 on Multilink1, 00:00:50 ago
  Routing Descriptor Blocks:
  * 174.1.23.2, from 150.1.6.6, 00:00:50 ago, via Multilink1
      Route metric is 3, traffic share count is 1

3.4 EIGRP

Basic EIGRP task.  The only confusing bit is that the task asks you to advertise the lo0 interface of all of the EIGRP devices into EIGRP.  r3 is already advertising its lo0 interface into OSPF.  They must have meant all of the EIGRP devices except r3 (the solution guide bears this out).

Remember to disable split-horizon on the Frame Relay hub (r1):

r1(config-router)#int s0/0
r1(config-if)#no ip split-horizon eigrp 1024

3.5 RIP

Easy RIP task with authentication.

3.6 IGP Redistribution

Redistribute between RIP and EIGRP on r5 and then between OSPF and EIGRP where needed.

Remember that OSPF area 38 is a stub area so it’s not going to let in any external routes.  That means our OSPF<->EIGRP redistribution needs to happen on r3.

I ran into one issue.  I had a route to 174.1.31.0/24 on r1 (connected) as well as r2-3(OSPF).  But r4 and r5 did not have the route.

The problem is that r3 gets that route via OSPF and then advertises it to r1.  R1 does not install the route from r3 because it has that network as connected.  The route does not get passed on to the EIGRP routers behind r1.

I need to either redistribute that connected interface into EIGRP on r1 or find some way to have r1 prefer the route to r3 over the connected route.

r1(config)#route-map CONN->EIGRP
r1(config-route-map)#match int Fa0/0.13

r1(config-route-map)#router ei 1024
r1(config-router)#redist conn met 1 1 1 1 1 route-map CONN->EIGRP

r4#sh ip route 174.1.31.1
Routing entry for 174.1.31.0/24

  Known via “eigrp 1024”, distance 170, metric 2560512256, type external
  Redistributing via eigrp 1024
  Last update from 174.1.145.1 on Serial0/0, 00:00:30 ago
  Routing Descriptor Blocks:
  * 174.1.145.1, from 174.1.145.1, 00:00:30 ago, via Serial0/0
      Route metric is 2560512256, traffic share count is 1
      Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

r4#trace 174.1.31.1

Type escape sequence to abort.
Tracing the route to 174.1.31.1

  1 174.1.145.1 4 msec *  4 msec

I ended up with full reachability by only redistributing RIP<->EIGRP on r5, OSPF<->EIGRP on r3, and Connected (fa0/0.13) -> EIGRP on r1.

IE went a different route.  Then redistributed OSPF->EIGRP on r1, OSPF<->EIGRP on r3, as well as RIP<->EIGRP on r5.

3.7 Load Distribution

Configure the network so that traffic from r4 to r5 is distributed in a 4:1 ratio between the Ethernet connection and the Frame Relay connection.

I messed with this for tooooooooo long.  I tried messing with the metric weight and I was still mindfucked.  I’ll just eat the 3 points and move on.

Update:

I have to try this tomorrow:

Becoming a CCIE: EIGRP Unequal path load balancing

April 28, 2008

Question Of The Day: 28 April, 2008

Topic: Frame Relay Traffic Shaping

Here is the current configuration for r1’s Frame Relay connection:

interface Serial1/0
 no ip address
 encapsulation frame-relay
!
interface Serial1/0.12 point-to-point
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102

Configure r1 to match this output:

r1#show traffic-shape

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 25 April, 2008 

Topic: EIGRP

r1 and r2 are directly connected via their respective fa0/0 interfaces:

r1:
interface FastEthernet0/0
  ip address 10.1.12.1
  ip hold-time eigrp 100 30
  ip hello-interval eigrp 100 5
!
router eigrp 100
  no auto-summary
  network 10.1.12.1 0.0.0.0

r2:
interface FastEthernet0/0
  ip address 10.1.12.2
  ip hold-time eigrp 100 60
  ip hello-interval eigrp 100 10
!
router eigrp 100
  no auto-summary
  network 10.1.12.2 0.0.0.0

Will r1 and r2 for an EIGRP neighbor relationship over the Ethernet link between them?

Answer: Yes

I have to admit that this one seems counter-intuitive to me.  If you create a mismatch of the EIGRP hello and hold-times (provided that you do not configure a hold-time that is less than the hello interval) on each side of a link, the EIGRP neighbor relationship will not be affected.

r1#show ip eigrp interfaces detail | i Inter|Fa0/0|Hello
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0              1        0/0       249       0/10         856           0
  Hello interval is 5 sec

r2#show ip eigrp interfaces detail | i Inter|Fa0/0|Hello
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0              1        0/0       295       0/10        1216           0
  Hello interval is 10 sec

I did a ‘debug ip packet detail’ on r1.  You can see that the EIGRP hellos are going out every (approximately) every 5 seconds:

r1#sh log | i s=10.1.12.1
*Mar  1 00:32:29.383: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:33.999: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:38.895: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:43.323: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:48.075: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:52.743: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:57.287: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:33:01.815: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:33:06.619: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88

Same thing on r2.  The EIGRP hellos are going out (approximately) every 10 seconds:

r2#sh log | i s=10.1.12.2
*Mar  1 00:37:30.755: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:37:39.931: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:37:49.467: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:37:58.447: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:07.831: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:16.371: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:25.899: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:34.755: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:43.463: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88

The EIGRP neighbors are up and stable, and routes are be advertised:

r1#show ip eigrp neighbors detail fa0/0
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.1.12.2               Fa0/0             59 00:41:49  249  1494  0  6
   Version 12.3/1.2, Retrans: 1, Retries: 0, Prefixes: 2

r1#sh ip route eigrp
     100.0.0.0/24 is subnetted, 1 subnets
D       100.1.4.0 [90/158720] via 10.1.12.2, 00:43:13, FastEthernet0/0
     10.0.0.0/24 is subnetted, 4 subnets
D       10.1.24.0 [90/30720] via 10.1.12.2, 00:43:14, FastEthernet0/0

r2#show ip eigrp neighbors detail fa0/0
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.1.12.1               Fa0/0             26 00:45:17  249  1494  0  5
   Version 12.3/1.2, Retrans: 1, Retries: 0, Prefixes: 1

r2#show ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/156160] via 10.1.12.1, 00:00:16, FastEthernet0/0

So the answer is yes.  🙂

 

April 25, 2008

Question Of The Day: 25 April, 2008

Topic: EIGRP

r1 and r2 are directly connected via their respective fa0/0 interfaces:

r1:
interface FastEthernet0/0
  ip address 10.1.12.1
  ip hold-time eigrp 100 30
  ip hello-interval eigrp 100 5
!
router eigrp 100
  no auto-summary
  network 10.1.12.1 0.0.0.0

r2:
interface FastEthernet0/0
  ip address 10.1.12.2
  ip hold-time eigrp 100 60
  ip hello-interval eigrp 100 10
!
router eigrp 100
  no auto-summary
  network 10.1.12.2 0.0.0.0

Will r1 and r2 for an EIGRP neighbor relationship over the Ethernet link between them?

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 24 April, 2008 

Topic: Route-Maps

The engineer in charge of r1 is tasked with routing packets to r2 (10.1.1.2) if they meet any of the following conditions:

1) Any packets coming in r1’s fa0/0 interface
2) Any packets with the tag 1234
3) Any D EX routes (r1 is only running EIGRP)

The engineer asks you to peer review his solution:

route-map LOOPBACK_AND_VLAN6 permit 10
 match interface FastEthernet0/0
 match tag 1234
 match route-type external
 set ip next-hop 10.1.1.2

Will this route map meet the requirements?

Answer: No.

In a route-map clause with multiple match statements, ALL match statements must be fullfilled. 

Route-Maps for IP Routing Protocol Redistribution Configuration

A match or set command in each clause can be missed or repeated several times, if one of these conditions exist:

If several match commands are present in a clause, all must succeed for a given route in order for that route to match the clause (in other words, the logical AND algorithm is applied for multiple match commands).

In our case only routes with a next-hop out fa0/0 AND a route tag of of 1234 AND a route-type of external will have their next-hop set to 10.1.1.2.  The task requires that ANY of those conditions must be met.

Steve makes a nice catch:

“Is it wrong because the ‘match interface FastEthernet0/0 line will match packets routed _out_ Fa0/0 not in?”

He’s right.  I boned up the first requirement of the question:

match interface (IP)

“To distribute any routes that have their next hop out one of the interfaces specified, use the match interface command in route-map configuration mode.”

We can write the route-map to meet the requirements by putting each requirement in its own separate clause:

route-map LOOPBACK_AND_VLAN6 permit 10
 match interface FastEthernet0/0
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 20
 match tag 1234
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 30
 match route-type external
 set ip next-hop 10.1.1.2
!
route-map LOOPBACK_AND_VLAN6 permit 1000

Each clause of the route-map will be evaluated until a match is made.  The last clause is included to override the implicit deny.  That way any packets that do not meet any of the clauses will be routed normally.

April 12, 2008

Internetwork Expert Volume III: Lab 5 – Section 4

Interior Gateway Routing – 25 Points

4.1 EIGRP

“Do not send multicast EIGRP updates within VLAN 14”

neighbor (EIGRP)

Remember that you need to configure this on both routers (unlike OSPF):

r1
router eigrp 10
 network 128.1.14.1 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.1.1
 neighbor 128.1.14.4 FastEthernet0/0.2

r4
router eigrp 10
 network 128.1.14.4 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.4.4
 neighbor 128.1.14.1 FastEthernet0/0

4.2 OSPF

Configure OSPF area 0.0.0.0.  This is just the dotted decimal equivalent of area 0.

r1(config-router)#do sh run | sec router os
router ospf 100
 router-id 150.1.1.1
 log-adjacency-changes
 network 128.1.136.1 0.0.0.0 area 0.0.0.0

r1(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0        128.1.136.1/24     1     WAIT  0/0

4.3 OSPF

“Without enabling OSPF on r3’s interface fa0/0.2 or r6’s interface fa0/0.2, ensure that they will still receive OSPF routers from each other in the event that they lose their connectivity with r1.”

Basically, we need to make sure that r3 and r6 can communicate over their redundant LAN connection if the primary one fails.

I’m thinking that we can tunnel over that second LAN.  The only problem is that you’d need to an a new subnet to do this.  I peeked the solution guide and that exactly what they did, so I guess that it’s alright.

r6(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0         128.1.136.6/24     1     DROTH 2/2
Tu0          100   0.0.0.0         128.1.63.6/24      11111 P2P   1/1

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.1.1         1   FULL/DR         00:00:31    128.1.136.1     FastEthernet0/0.1
150.1.3.3         1   FULL/BDR        00:00:32    128.1.136.3     FastEthernet0/0.1
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

r6(config)#int fa0/0.1
r6(config-subif)#shut
r6(config-subif)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

4.4 OSPF

Configure OSPF on the PPPoFR network.

The current OPSF network type is point-to-point, which makes sense considering we’re running PPP.  🙂

r5(config-router)#do sh ip os int | i proto|Type
Virtual-Access2 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Template1 is down, line protocol is down
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Access1 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1

I’m going to need to change the network type because this is a hub-and-spoke network.  Let’s use point-to-multipoint:

r2(config)#int virtual-template 1
r2(config-if)#ip os net non-broadcast

After all is said and done:

r2#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/3] via 128.1.125.5, 00:00:58, Virtual-Access1
O IA    128.1.63.0/24 [110/11114] via 128.1.125.5, 00:00:58, Virtual-Access1
O       128.1.125.1/32 [110/2] via 128.1.125.5, 00:00:58, Virtual-Access1

4.5 OSPF

Configure an OSPF stub area.  You’re also going to need a virtual-link as this new stub area is not connected to area 0 (or area 0.0.0.0 in this case 🙂 ).

r2(config-router)#area 125 virtual-link 150.1.1.1

r2(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
VL0          100   0               128.1.125.2/24     2     P2P   1/1
Gi0/0        100   12              128.1.27.2/24      1     BDR   1/1
Vi1          100   125             128.1.125.2/24     1     P2MP  1/1
Vt1          100   125             128.1.125.2/24     1     DOWN  0/0

sw1#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/4] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.63.0/24 [110/11115] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.125.5/32 [110/2] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.1/32 [110/3] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.2/32 [110/1] via 128.1.27.2, 00:01:08, Vlan72
O*IA 0.0.0.0/0 [110/2] via 128.1.27.2, 00:01:08, Vlan72

Why all of the virtual-links in the IE solution guide?:

Task 4.5

4.6 OSPF

You’re asked to configure area 51 (hehe) between sw1 and bb2.  The problem is that this new area is non connected to area 0 and you cannot use a virtual-link because area 12 is a stub area.

Another tunnel?  Yup.

Steps:
1) Create tunnel through area 12.
2) Enable OSPF on the tunnel interfaces.  Place them in area 0 (0.0.0.0).

I had to ‘ip os mtu-ignore’ on tu0 on r2.

4.7 OSPF Loopback Advertisements

Advertise a bunch of loopbacks into a couple of non-existant areas.  If everything is configured correctly you should see all of the loopbacks on sw1:

sw1(config-router)#do sh ip route os | i 150.1.
     150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    150.1.6.6/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.5.5/32 [110/11113] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.3.3/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.2.2/32 [110/11112] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.1.1/32 [110/11114] via 128.1.72.2, 00:00:09, Tunnel0

4.8 RIPv2

A straight-forward, easy task.  Thankfully!  🙂

4.9 Default Routing

Configure r4 to generate a default router to sw2 but not to r5.  Don’t use a distribute-list.

We can add a route-map to the ‘default-information-originate’ under the RIP process:

r4(config-router)#default-information originate ?
  route-map  Route-map reference
  <cr>

default-information originate (RIP)

So how do I write a route-map to only advertise to sw2?

r4(config-router)#do sh ip proto | sec Default version
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/1       2     2
    Dialer0               2     2

I want to send the default out fa0/1 and not dialer0 interface.

r4(config-route-map)#set ?
  interface         Output interface

route-map RIP_DEFAULT permit 10
 set interface FastEthernet0/1
!
router rip
 default-information originate route-map RIP_DEFAULT

sw2#sh ip route rip | i 0.0.0.0
R*   0.0.0.0/0
[120/1] via 128.1.48.4, 00:00:06, Vlan48

r5#sh ip route rip | i 0.0.0.0
r5# <-no default route on r5

4.10 Route Filtering

“Configure sw2 so that it will use the default route advertised by r4 to reach the 128.1.14.0/24 network.”
“Use an offset-list on sw2 to accomplish this task.”

This is just a wordy way of telling you to bitbucket the existing route to 128.1.14.0:

Before:
sw2#sh ip route 128.1.14.0
Routing entry for 128.1.14.0/24
  Known via “rip”, distance 120, metric 1
  Redistributing via rip
  Last update from 128.1.48.4 on Vlan48, 00:00:21 ago
  Routing Descriptor Blocks:
  * 128.1.48.4, from 128.1.48.4, 00:00:21 ago, via Vlan48
      Route metric is 1, traffic share count is 1

After:
access-list 71 permit 128.1.14.0 0.0.0.255
!
router rip
  offset-list 71 in 16 vlan48

sw2#sh ip route 128.1.14.0
% Subnet not in table
sw2#p 128.1.14.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.1.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

4.11 IGP Redistribution

Perform mutual redistribution on three different devices.  As with most of the Volume III labs, you may as well do the next task (the redistribution ‘gotcha’) at the same time.

4.12 Redistribution Loop Prevention

“Ensure that the RIP routes redistributed into EIGRP on r4 do not get passed back into RIP from OSPF on r5.”
“Use route tagging to accomplish this task.”

Sweet.  Route tagging is my preferred method.

So I’m going to tag RIP routes on r4 and then filter those same routes with r5:

r4#sh run | sec route-map RIP->EIGRP
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
route-map RIP->EIGRP permit 10
 set tag 4120

r5#sh run | sec route-map RIP->OSPF
 redistribute ospf 100 metric 1 route-map RIP->OSPF
route-map RIP->OSPF deny 10
 match tag 4120
route-map RIP->OSPF permit 20

Everything was working fine except for 128.1.14.4 (f0/0 on r1).  I finally had to filter this route from passing to OSPF on r1 and everything was fine.

r1#sh run | sec 128_|EIGRP->OSPF
 redistribute eigrp 10 subnets route-map EIGRP->OSPF
ip prefix-list 128_1_14_0 seq 5 permit 128.1.14.0/24
route-map EIGRP->OSPF deny 10
 match ip address prefix-list 128_1_14_0
route-map EIGRP->OSPF permit 20

This didn’t break the requirements of the task, but I still bothered that I couldn’t figure out why this address was unreachable.

The IE solution guide is a mess for these tasks:

Task 4.13

The task asks you to use route tags to accomplish this task but the IE solution shows r5 changing the AD for OSPF external routes???

r5:
router ospf 1
 distance ospf external 121

 

March 25, 2008

Question Of The Day: 25 March, 2008

Topic: EIGRP

Which of the following commands will make EIGRP AS 100 consider delay only when calculating the EIGRP metric?

1) router eigrp 100
    default metric 1 1 0 1 1500

2) router eigrp 100
    metric weights 0 1 0 0 0 0    

3) router eigrp 100
    metric weights 0 0 1 0 0 0

4) router eigrp 100
    metric weights 0 0 0 1 0 0

Click here for the answer.

January 27, 2008

Internetwork Expert Volume III: Lab 4 – Section 4

Interior Gateway Routing – 27 Points

4.1 Bridging

“Disable ip routing on r6”

r6(config)#no ip routing

“Bridge IP between the Frame Relay and Ethernet segments on r6”

That explains why fa0/0 does not have an IP address configured. 🙂

After this task, I can finally ping bb1:

r6#p 54.1.10.254

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

4.2 Bridging

This task confused the crap out of me.  My bridging skills are pretty poor.

“Configure the IP address of 54.1.10.6/24 on r6.”

Ummmm….that’s already configured as the IP address of the Frame connection to bb1.  I guess that we’re going to use the same IP address for fa0/0 as well.

“r6 should have reachability to any address of the 54.1.10.0/24 subnet.”
“Don’t use IRB for this task.”

No IRB.  CRB?  Actually, the IE solution doesn’t use IRB or CRB.  The last two subtasks are basically red herrings.  I will need to review bridging.

r6#sh bridge 1 group

Bridge Group 1 is running the IEEE compatible Spanning Tree protocol

   Port 4 (FastEthernet0/0) of bridge group 1 is forwarding
   Port 11 (Serial0/0.1 Frame Relay) of bridge group 1 is forwarding

r6#sh ip int br | i 54.1.10.6
FastEthernet0/0            54.1.10.6       YES manual up                    up
Serial0/0.1                54.1.10.6       YES manual up                    up

r6#p 54.1.10.254

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

r6#p 54.1.10.100

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

I can’t ping r4 but I can ping bb1.  This poster has the opposite problem:

Task 4.2 can not ping 54.1.10.254

r6#sh cdp neigh
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
                  S – Switch, H – Host, I – IGMP, r – Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
BB1              Ser 0/0.1          147       R T S I     2821      Ser 0/0/0:0.401
sw2              Fas 0/0            174         S I       WS-C3560- Fas 0/6
r6#

sw2#sh run int fa0/6
interface FastEthernet0/6 <-that’s a minimal configuration 🙂
end

How did I miss this?????  Because the port on r6 was initially shut down so I didn’t see it with “show cdp neighbor” on sw2.  Arrgh!!!  I need vlan 46 assigned to this port.

sw2(config)#int fa0/6
sw2(config-if)#swit acc vl 46

r6#p 54.1.10.100

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

I guess that I can take solace in the fact that I was able to find my mistake.  I just barely missed going down a deep rabbit hole chasing bridging options.

4.3 RIPv2

I initially thought that there was an error in the IE lab because although r6 was shown as running RIP on the protocol diagram, there was no mention of r6 in the task.  That’s because r6 is bridging the 54.1.10.0/24 network.  I turned off ip routing in task 4.1 so I wouldn’t be able to configure RIP on r6:

r6(config)#router rip
IP routing not enabled

This means that we should be able to see the routes from bb1(54.1.10.254) on r4:

r4#sh ip route rip | i 54.1.10.254
R    212.18.1.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.0.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.3.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0
R    212.18.2.0/24 [120/1] via 54.1.10.254, 00:00:12, FastEthernet0/0

4.4 Network Redundancy

backup interface

Hmmmm….this is the reason for the point-to-point subinterface on r4 back in task 3.2

r4#sh ip int br | i Serial
Serial0/0                  unassigned      YES NVRAM  up                    up
Serial0/0.1                unassigned      YES unset  up                    up
Serial0/1                  152.1.54.4      YES NVRAM  standby mode          down

r4#sh backup
Primary Interface   Secondary Interface   Status
—————–   ——————-   ——
Serial0/0.1         Serial0/1             normal operation

4.5 EIGRP

Basic.

4.6  OSPF

“Use the OSPF network type that was specifically designed to handle issues with routers on the same logical IP subnet not having direct communication with each other.”

Remember that we have a multipoint subinterface on the hub (r3) and point-to-point subinterfaces on the hubs (r1 and r2).  The task calls for the point-to-multipoint OSPF network type.

r3#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.2.2         0   FULL/  –        00:01:49    152.1.123.2     Serial0/0:0.1
150.1.1.1         0   FULL/  –        00:01:54    152.1.123.1     Serial0/0:0.1

r3#sh ip route os
     152.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
O       152.1.123.2/32 [110/65] via 152.1.123.2, 00:00:07, Serial0/0:0.1
O       152.1.123.1/32 [110/65] via 152.1.123.1, 00:00:07, Serial0/0:0.1

4.7 OSPF

Basic

4.8 OSPF

In this task you need to advertise the loopbacks on r1 and r2 into area 0.  But r1 and r2 are not in area 0.  Time for a couple of virtual circuits.

4.9 OSPF Loopback Advertisement

“Advertise the Loopback0 networks of r3 and sw1 into OSPF.”
“These networks should appear in each other routing tables as intra-area routes.”

Since I’m not told which area to advertise the loopbacks into, can’t I just make this simple by advertising both loopbacks into area 37?  Answer: YES!

sw1#sh ip route | i 150.1.3.
O       150.1.3.3/32 [110/2] via 152.1.37.3, 00:00:37, Vlan37

r3#sh ip route | i 150.1.7.
O       150.1.7.7/32 [110/2] via 152.1.37.7, 00:00:00, FastEthernet0/0

4.10 IGP Redistribution

Four points of mutual redistribution.  Ugh.  The first two points are no worry (discontiguous RIP).  The other two are dangerous though.  I’ll work on those in task 4.11

4.11 Redistribution Loop Prevention

“Ensure that EIGRP extenal routes that are redistributed into OSPF on r1 and r2 do not get redistributed back into EIGRP.”
“Use AD to accomplish this.”

Here is a (simplified) view of the the two network redistribution points on r1 and r2:
                         ————(D)r1(O)———–
r4(R<->D)—r5(D)                                     (O)r3—(O<->R)sw1
                         ————(D)r2(O)———–
If we do mutual redistribution between EIGRP and OSPF on r1 and r2 we’re going to have problems with D EX routes (AD of 170) being reflected back into the EIGRP domain.  We’re given the method for preventing this.

I missed an issue on sw1 though:

Task 4.11 Redist Loop Prevention

You need to change the RIP distance or SW1 sees the routes learnt from BB3 as OSPF external routes which it uses over the correct RIP routes. if you check the routing table on SW1, the next hop for all the BB3 subnets is R3. This is resolved by changing the AD [router rip – distance 109].

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.

Next Page »

Blog at WordPress.com.