CCIE Pursuit Blog

January 13, 2008

Internetwork Expert Volume II: Lab 4 – Section 7

 QoS – 7 Points

7.1 Congestion Avoidance

“…configure r1 to start dropping packets with an IP precedence of routine on this link when there are at least 15 packets in the queue.”

Sounds like WRED to me.

Configuring Weighted Random Early Detection

“routine” traffic is IP Prec 0:

r1(config-cmap)#match ip prec ?
  <0-7>           Enter up to 4 precedence values separated by white-spaces
  critical        Match packets with critical precedence (5)
  flash           Match packets with flash precedence (3)
  flash-override  Match packets with flash override precedence (4)
  immediate       Match packets with immediate precedence (2)
  internet        Match packets with internetwork control precedence (6)
  network         Match packets with network control precedence (7)
  priority        Match packets with priority precedence (1)
  routine         Match packets with routine precedence (0)

r1(config)#int fa0/0
r1(config-if)#random-detect ?
  dscp-based  Enable dscp based WRED on an inteface
  prec-based  Enable prec based WRED on an interface

r1(config-if)#random-detect prec-based

Now we have a few more options:

r1(config-if)#random-detect ?
  dscp                            parameters for each dscp value
  dscp-based                      Enable dscp based WRED on an inteface
  exponential-weighting-constant  weight for mean queue depth calculation
  flow                            enable flow based WRED
  prec-based                      Enable prec based WRED on an interface
  precedence                      parameters for each precedence value

r1(config-if)#random-detect precedence 0 15 ?
  <1-4096>  maximum threshold (number of packets)

Shit.  What is the standard queue size?  It’s easy enough to find:

r1(config-if)#do sh queueing int fa0/0
Interface FastEthernet0/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

  class          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
      0      0/0              0/0           20      40  1/10
      1      0/0              0/0           22      40  1/10
      2      0/0              0/0           24      40  1/10
      3      0/0              0/0           26      40  1/10
      4      0/0              0/0           28      40  1/10
      5      0/0              0/0           31      40  1/10
      6      0/0              0/0           33      40  1/10
      7      0/0              0/0           35      40  1/10
   rsvp      0/0              0/0           37      40  1/10

r1(config-if)#random-detect prec 0 15 40 ?
  <1-65535>  mark probability denominator
  <cr>

Let’s leave that at the default of 10.

r1#sh queueing int fa0/0
Interface FastEthernet0/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

  class          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
      0      0/0              0/0           15      40  1/10
      1      0/0              0/0           22      40  1/10
      2      0/0              0/0           24      40  1/10
      3      0/0              0/0           26      40  1/10
      4      0/0              0/0           28      40  1/10
      5      0/0              0/0           31      40  1/10
      6      0/0              0/0           33      40  1/10
      7      0/0              0/0           35      40  1/10
   rsvp      0/0              0/0           37      40  1/10

7.2 Congestion Avoidance

“…configure r5 so that all SMTP packets are guaranteed at least 1.5Mbps of the output queue on int fa0/1.”
“Do not use an access-list to accomplish this.”

The only twist on this task is whether to use LLQ or bandwidth.  “at least” screams ‘bandwidth’ to me.

r5(config-pmap-c)#bandwidth ?
  <8-2000000>  Kilo Bits per second <- Be careful
r5(config-pmap-c)#bandwidth 1500

class-map match-all SMTP
  match protocol smtp
!
policy-map SMTP
  class SMTP
   bandwidth 1500
!
interface FastEthernet0/1
 service-policy output SMTP

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

  Service-policy output: SMTP

    Class-map: SMTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol smtp
      Queueing
        Output Queue: Conversation 265
        Bandwidth 1500 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

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

7.3 Rate Limiting

“…configure r5 so that packets over 1250 bytes are limited to 2.5Mbps outbound on interface fa0/1.”

This is definitely policing.

r5(config-cmap)#match packet length ?
  max  Maximum length of packet
  min  Minimum length of packet

1250 or 1251….I chose 1251 (“over 1250″), but I would ask the proctor for clarification.

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

Ooops!!!  I didn’t notice the interface.  I already have an outbound policy on fa0/1:

interface FastEthernet0/1
 service-policy output SMTP

No problem.  I can just add this class to the existing policy-map (I should have read more carefully) rather than creating a new one.

class-map match-all POLICE_1250
  match packet length min 1251
!
policy-map SMTP
  class SMTP
   bandwidth 1500
  class POLICE_1250
   police 2500000

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

  Service-policy output: SMTP

    Class-map: SMTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol smtp
      Queueing
        Output Queue: Conversation 265
        Bandwidth 1500 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: POLICE_1250 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: packet length min 1251
      police:
          cir 2500000 bps,
bc 78125 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)
      427 packets, 42622 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Internetwork Expert Volume II: Lab 4 – Section 6

Section 7 – IPv6 – 7 Points

6.1 IPv6 Addressing

“Enable OSPFv3 area 0 on this link.”

This is the first lab in which I’ve had to configure any IPv6 routing protocols.

Implementing OSPF for IPv6

ipv6 ospf area

Problems right out of the gate:

r1(config-if)#ipv6 address 2001:192:10:1::/64
% 2001:192:10:1::/64 should not be configured on FastEthernet0/0, a subnet router anycast

Use the eui-64 option:

r1(config-if)#ipv6 address 2001:192:10:1::/64 eui-64
r1(config-if)#ipv6 ospf 100 area 0

r1#sh ipv6 os neigh

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
192.10.1.254      1   FULL/DR         00:00:36    1019            Fa0/0

r1#sh ipv6 route os
IPv6 Routing Table – 5 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
       U – Per-user Static route
       I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
       O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
       ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
OE2  2001:51:51:51::/64 [110/20]
     via FE80::216:47FF:FE14:E441, FastEthernet0/0

6.2 OSPFv3

These were pretty easy tasks…on the routers.  Just remember to build your ipv6 frame maps where necessary.

Switches are another story:

Configuring IPv6 Addressing and Enabling IPv6 Routing

sw2(config)#sdm prefer dual-ipv4-and-ipv6 ?
  default  Default bias
  routing  Unicast bias
  vlan     VLAN bias

•default—Set the switch to the default template to balance system resources.
•routing—Set the switch to the routing template to support IPv4 and IPv6 routing, including IPv4 policy-based routing.
•vlan—Maximize VLAN configuration on the switch with no routing supported in hardware.

sw2(config)#sdm prefer dual-ipv4-and-ipv6 default
Changes to the running SDM preferences have been stored, but cannot take effect until the next reload.
Use ‘show sdm prefer’ to see what SDM preference is currently active.

sw2#sh sdm prefer | i template
 The current template is “desktop default” template.
 On next reload, template will be “desktop IPv4 and IPv6 default” template.
sw2#relo
Proceed with reload? [confirm]

After reload:
sw2#sh sdm prefer | i template
 The current template is “desktop IPv4 and IPv6 default” template.

sw2(config)#int vlan258
sw2(config-if)#ipv6 add ?
  X:X:X:X::X          IPv6 link-local address
  X:X:X:X::X/<0-128>  IPv6 prefix
  autoconfig          Obtain address using autoconfiguration

sw2(config-if)#ipv6 add 2001:141:1:25::8/64

Configuring OSPF for IPv6

Before you enable IPv6 OSPF on an interface, you must enable routing by using the ip routing global configuration command, enable the forwarding of IPv6 packets by using the ipv6 unicast-routing global configuration command, and enable IPv6 on Layer 3 interfaces on which you are enabling IPv6 OSPF.

I must not have sufficient code on my 3560 because I cannot configure ‘ipv6 unicast-routing':

sw2(config)#ipv6 ?
  access-list  Configure access lists
  hop-limit    Configure hop count limit
  host         Configure static hostnames
  icmp         Configure ICMP parameters
  mld          Global MLD Snooping enable for Catalyst Vlans
  neighbor     Neighbor
  route        Configure static routes

sw2(config)#ipv6 unicast-routing
                                ^
% Invalid input detected at ‘^’ marker.

sw2(config)#do sh ver | i IOS
Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(25)SEE2, RELEASE SOFTWARE (fc1)

I’m going to need to load new code on my switches.  :-(

Internetwork Expert Volume II: Lab 4 – Section 5

Section 5 – Multicast – 8 Points

IE mixed it up a bit on this lab.  Usually BGP comes directly after IGP, but I get to deal with Multicast instead.  Oh joy!

5.1 PIM

This was about as easy of a task as you could ask for in Multicast.  You are given the PIM mode to configure, the interfaces to configure, and the devices to configure.  Really straight-forward task.

5.2 Auto-RP

Since we’re going to be using auto-rp, we need to configure ‘ip pim autorp listener’ on all Mulitcast devices (even the potential RPs).  Then we can announce our RPs:

ip pim autorp listener(Cisco still hasn’t fixed the 12.4 links)

ip pim send-rp-announce

r2(config)#access-list 10 permit 225.0.0.0 0.255.255.255
r2(config)#ip pim send-rp-announce lo0 scope 16 group-list 10
Must first configure PIM mode on the interface: Loopback0

r2(config)#int lo0
r2(config-if)#ip pim sparse-mode
*Jan 13 21:02:08.192: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 150.1.2.2 on interface Loopback0
r2(config-if)#exit
r2(config)#ip pim send-rp-announce lo0 scope 16 group-list 10

r2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)

We need to make sw2 “responsible for the group to RP mappings”:

ip pim send-rp-discovery

sw2(config)#ip pim send-rp-discovery lo0 scope 16
Non IP or PIM interface ignored in accepted command.

sw2(config)#int lo0
sw2(config-if)#ip pim sparse-mode
sw2(config-if)#exit
sw2(config)#ip pim send-rp-discovery lo0 scope 16

auto-rp is on the job:
sw2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 225.0.0.0/8
  RP 150.1.2.2 (?), v2v1
    Info source: 150.1.2.2 (?), elected via Auto-RP
         Uptime: 00:01:25, expires: 00:02:31
Group(s) 239.0.0.0/8
  RP 150.1.5.5 (?), v2v1
    Info source: 150.1.5.5 (?), elected via Auto-RP
         Uptime: 00:02:01, expires: 00:02:55

5.3 Multicast Testing

“Configure r3’s interface fa0/0 as a member of the multicast group 225.25.25.25 and interface fa0/1 as a member of 239.39.39.39.”
“Ensure that r3 responds to pings sent to these multicast groups from VLANs 12 and 43″

ip igmp join-group

r3(config)#int fa0/0
r3(config-if)#ip igmp join-group 225.25.25.25

r3#sh ip igmp groups
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Gr
oup Accounted
225.25.25.25     FastEthernet0/0          00:00:14  00:02:45  141.1.37.3
224.0.1.40       FastEthernet0/0          00:42:49  00:01:58  141.1.37.7

r1#ping 225.25.25.25 re 1 source 192.10.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 225.25.25.25, timeout is 2 seconds:
Packet sent with a source address of 192.10.1.1

Reply to request 0 from 141.1.123.3, 16 ms

Everything was going great, until: 

r4#ping 225.25.25.25 re 1 source 204.12.1.4

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 225.25.25.25, timeout is 2 seconds:
Packet sent with a source address of 204.12.1.4
.

r4#sh ip mroute 225.25.25.25

(*, 225.25.25.25), 00:00:20/stopped, RP 150.1.2.2, flags: SPF  
  Incoming interface: FastEthernet0/0, RPF nbr 141.1.145.5
  Outgoing interface list: Null

I had to look at the solution guide on this one.  I figured out that I needed ‘ip pim nbma-mode’ on r2, but I completely missed the fact that I needed to configure each end of the tunnel with ‘ip pim spare-mode’

5.4 Multicast Rate Limiting

“configure sw1 so that no more than 1Mbps of multicast traffic is sent out towards r3.”

Okay…this is new.  Time to mine the DOC.

ip multicast rate-limit

To control the rate a sender from the source list can send to a multicast group in the group list, use the ip multicast rate-limit command in interface configuration mode. To remove the control, use the no form of this command.

sw1(config-if)#int vlan7
sw1(config-if)#ip multicast rate-limit ?
  in   Rate limit incoming packets
  out  Rate limit outgoing packets

sw1(config-if)#ip multicast rate-limit out ?
  <0-4294967>  Rate in kilobits per second
  group-list   Rate limit for groups
  source-list  Rate limit for sources
  video        Rate limit video only
  whiteboard   Rate limit whiteboard only
  <cr>

sw1(config-if)#ip multicast rate-limit out 1000 ?
  <cr>

sw1(config-if)#ip multicast rate-limit out 1000

Internetwork Expert Volume II: Lab 4 – Section 4

Section 4 – Interior Gateway Routing – 24 Points

4.1 OSPF

Easy Hub-and-Spoke OSPF network. You aren’t allowed to change the OSPF network type on r2(hub).  You can change the network type on the spokes though.

r2#sh ip os int | i Type
  Process ID 100, Router ID 150.1.2.2, Network Type NON_BROADCAST, Cost: 64
r1#sh ip os int | i Type
  Process ID 100, Router ID 150.1.1.1, Network Type POINT_TO_POINT, Cost: 65
r3#sh ip os int | i Type
  Process ID 100, Router ID 150.1.3.3, Network Type POINT_TO_POINT, Cost: 65

Change the network type on the spokes to match the hub and use neighbor statements on the hub.  Remember to configure “ip ospf priority 0″ on the spokes so that the hub is elected as the DR.

4.2 OSPF

“…configure r1 so that the only recipient of its hello packets is bb2.”

Sounds like another job for the “neighbor command”:

r1(config)#router os 100
r1(config-router)#net 192.10.1.1 0.0.0.0 are 51
r1(config-router)#neighbor 192.10.1.254
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
 

r1(config-if)#do sh ip os int fa0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.1.1, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

r1(config-if)#int fa0/0
r1(config-if)#ip os net non-broadcast

Remember to change the hello interval (the neighbor is going to have a hello interval of 10 because that’s the default for Broadcast)

r1(config-if)#do sh ip os int fa0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 1
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    Hello due in 00:00:03

r1(config-if)#ip os hello 10

r1(config-if)#do sh ip os int fa0/0 | i Type|Hello
  Process ID 100, Router ID 150.1.1.1, Network Type NON_BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:03

r1(config-if)#do sh ip os neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.2.2         1   FULL/DR         00:01:32    141.1.123.2     Serial0/0.1
192.10.1.254      1   FULL/DR         00:00:30    192.10.1.254    FastEthernet0/0

r1(config-if)#do sh ip route os
     51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 192.10.1.254, 00:02:08, FastEthernet0/0

There is an excellent breakdown for this task in the IE solution guide.

4.3 OSPF

“sw3 and sw4 should use sw2 as their default-gateway.”

sw3(config)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan255                141.1.255.9     YES manual up                    up

sw4(config)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan255                141.1.255.10    YES manual up                    up

sw2(config-router)#do sh ip int br | i Vlan255
Vlan255                141.1.255.8     YES manual up                    up

Use 141.1.255.8 as the default-gateway,

sw3(config)#ip default-gateway ?
  A.B.C.D  IP address of default gateway

sw3(config)#ip default-gateway 141.1.255.8

sw3#p 141.1.255.8

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

sw3#sh ip route
Default gateway is 141.1.255.8

Host               Gateway           Last Use    Total Uses  Interface
ICMP redirect cache is empty

Weird.  I couldn’t find “ip default-gateway” in either the 3550 or 3560 command guide.

4.4 OSPF

“configure the network so that route in OSPF area 1 do not see any inter-area or external OSPF routes.”

area nssa

Configuring OSPF NSSA

NSSAs

With the no-summary keyword, the NSSA ABR will not advertise the inter-area routes (Type 3 and Type 4 summary routes) inside the NSSA, instead will advertise a default route. This default route will be propagated inside the NSSA as Type 3 LSA.

Before:
sw2#sh ip route os
     51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 141.1.0.2, 13:05:22, Vlan258
     141.1.0.0/24 is subnetted, 5 subnets
O IA    141.1.123.0 [110/65] via 141.1.0.2, 13:05:22, Vlan258
O IA 192.10.1.0/24 [110/66] via 141.1.0.2, 13:05:22, Vlan258
     150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA    150.1.3.3/32 [110/66] via 141.1.0.2, 13:05:22, Vlan258
O IA    150.1.2.2/32 [110/2] via 141.1.0.2, 13:05:22, Vlan258
O IA    150.1.1.1/32 [110/66] via 141.1.0.2, 13:05:22, Vlan258

area nssa only:
sw2#sh ip route os
     141.1.0.0/24 is subnetted, 5 subnets
O IA    141.1.123.0 [110/65] via 141.1.0.2, 00:00:18, Vlan258
O IA 192.10.1.0/24 [110/66] via 141.1.0.2, 00:00:18, Vlan258
     150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA    150.1.3.3/32 [110/66] via 141.1.0.2, 00:00:18, Vlan258
O IA    150.1.2.2/32 [110/2] via 141.1.0.2, 00:00:18, Vlan258
O IA    150.1.1.1/32 [110/66] via 141.1.0.2, 00:00:18, Vlan258

I’m still seeing inter-area routes.  Let’t try:

area nssa no-summary
 (Optional) Allows an area to be a not-so-stubby area but not have summary routes injected into it.

area nssa no-summary (configured on ASRs only):
sw2#sh ip route os
O*IA 0.0.0.0/0 [110/2] via 141.1.0.2, 00:00:05, Vlan258

Remember the loopback that we redistributed into OSPF on sw2 (area 1)?  It shows up on the ASRs as an N1 route:

r2#sh ip route | i 150.1.8.0
O N2    150.1.8.0/24 [110/20] via 141.1.0.8, 00:11:09, GigabitEthernet0/0

r5#sh ip route | i 150.1.8.0
O N2    150.1.8.0 [110/20] via 141.1.0.8, 00:13:57, FastEthernet0/1

It will show up as an E2 route in area 0:
r3#sh ip route | i 150.1.8.0
O E2    150.1.8.0/24 [110/20] via 141.1.123.2, 00:18:12, Serial0/0:0.1

4.5 OSPF

“Configure OSPF area 2 on the Ethernet, Frame Relay, and PPP segments between r4 and r5.”
“Advertise the Loopback0 interfaces of r4 and r5 into OSPF area 2.”
“You are allowed to add one additional IP subnet to accomplish this.”

That last subtask had me confused.  Area 2 will be configured on three separate links between r4 and r5.  Further complicating issues is that that area 2 has no connection to area 0.  I’ll need to configure a virtual-link across area 1.

The first issue is getting the peering up over the FR link.  I changed the OSPF network type from non-broadcast to point-to-point on each side of the link to accomplish this.

Once the peerings were established, I advertised in the loopbacks on r4 and r5.  At this point the only OSPF route that r4 could see was r5’s loopback:

r4#sh ip route os
     150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
O       150.1.5.5/32 [110/2] via 141.1.145.5, 00:00:05, FastEthernet0/0

Time to establish the virtual-link.  Is this where the additional subnet will come into play?  Will there be a problem because area 1 is a NSSA Totally Stub Area?

Well, here’s one problem:

r5#sh ip route 141.1.123.2
% Subnet not in table

My virtual-link is not going to work if I don’t have connectivity to area 0. 

Even if I did have connectivity, I cannot build a virtual-link through a stub area:

Creating Virtual Links

Note that virtual links cannot be configured through stub areas.

I think that giving me a subnet means that I can use it to set up a tunnel through area 1. 

tunnel

Since we’re going to tunnel from r5 to r2, let’s use 141.1.25.0/24.

r5
interface Tunnel25
 description ->tunnel to r2 (area2 to area0)
 ip address 141.1.25.5 255.255.255.0
 tunnel source FastEthernet0/1
 tunnel destination 141.1.25.2

r2
interface Tunnel25
 description ->tunnel to r5 (area0 to area2)
 ip address 141.1.25.2 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 141.1.25.5

One last thing.  I need to advertise the tunnel interfaces into OSPF.  This is where I boned up.  I initially advertised r5’s tunnel interface into area 2.  Doh!!!  It needs to be in area 0.  I fixed that and everything looked great until:

*Mar  1 22:13:16.319: %TUN-5-RECURDOWN: Tunnel25 temporarily disabled due to recursive routing

Crap!  I need to change my tunnel destination addresses.  I make this mistake so often when configuring tunnels.  :-(

r5#sh run int tu25
interface Tunnel25
 description ->tunnel to r2 (area2 to area0)
 ip address 141.1.25.5 255.255.255.0
 tunnel source FastEthernet0/1
 tunnel destination 141.1.0.2

r2#sh run int tu25
interface Tunnel25
 description ->tunnel to r5 (area0 to area2)
 ip address 141.1.25.2 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 141.1.0.5

Now the peering is up:

r5#sh ip os neigh | i 150.1.2.2
150.1.2.2         0   FULL/  –        00:00:34    141.1.25.2      Tunnel25
150.1.2.2         1   FULL/DROTHER    00:00:38    141.1.0.2       Fa0/1

Let’s see if r4 is getting all of the OPSF routes now:

r4#sh ip route os
     51.0.0.0/32 is subnetted, 1 subnets
O E2    51.51.51.51 [110/20] via 141.1.145.5, 00:02:14, FastEthernet0/0
     141.1.0.0/16 is variably subnetted, 10 subnets, 2 masks
O IA    141.1.255.0/24 [110/3] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.8.0/24 [110/3] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.0.0/24 [110/2] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.25.0/24 [110/11112] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.88.0/24 [110/3] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    141.1.123.0/24 [110/11176] via 141.1.145.5, 00:02:19, FastEthernet0/0
O IA 192.10.1.0/24 [110/11177] via 141.1.145.5, 00:02:19, FastEthernet0/0
     150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O       150.1.5.5/32 [110/2] via 141.1.145.5, 00:02:39, FastEthernet0/0
O IA    150.1.3.3/32 [110/11177] via 141.1.145.5, 00:02:19, FastEthernet0/0
O IA    150.1.2.2/32 [110/11113] via 141.1.145.5, 00:02:19, FastEthernet0/0
O IA    150.1.1.1/32 [110/11177] via 141.1.145.5, 00:02:20, FastEthernet0/0
O E2    150.1.8.0/24 [110/20] via 141.1.145.5, 00:02:15, FastEthernet0/0

Nice!  It took me a while to struggle through this task, but I am pretty proud to have solved it on my own.

There is a nice breakdown in the solution guide.

4.6 OSPF

This task asks you to load balance over the Frame Relay and Ethernet segments between r4 and r5 without using ‘ip ospf cost’.

We are currently using the Ethernet segment between the routers:

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100″, distance 110, metric 2, type intra area
  Last update from 141.1.145.5 on FastEthernet0/0, 00:05:53 ago
  Routing Descriptor Blocks:
  * 141.1.145.5, from 150.1.5.5, 00:05:53 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1

I can’t change the cost.  The cost is based on bandwidth, so what if I changed the bandwidth statement to match on the Frame Relay and Ethernet links?  I’ll set the bandwidth statement on s0/0 to 100000 to match fa0/0:

r4(config)#int s0/0
r4(config-if)#band 100000

r4#sh int fa0/0| i BW
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
r4#sh int s0/0| i BW
  MTU 1500 bytes, BW 100000 Kbit, DLY 20000 usec,

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100″, distance 110, metric 2, type intra area
  Last update from 141.1.145.5 on FastEthernet0/0, 00:46:33 ago
  Routing Descriptor Blocks:
  * 141.1.145.5, from 150.1.5.5, 00:46:33 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1
    141.1.54.5, from 150.1.5.5, 00:46:33 ago, via Serial0/0
      Route metric is 2, traffic share count is 1

Just need to do the same thing on r5.

4.7 OSPF

This task asks you to configure the PPP link between r4 and r5 to come up only if the Ethernet and Frame Relay connections are down.  You need to detect a failure within 10 seconds.

You have to read this task carefully.  It states that you need to “DETECT a failure of EITHER the Frame or Ethernet link WITHIN10 seconds”, but bring up the PPP link only if “BOTH the Frame and Ethernet segments are down.”

That second bit is normal behavior.  We have three links between r4 and r5, so if two of them go down then traffic will be routed over the PPP link.  When either of the other two links come back up, traffic will stop routing over the PPP link and use either/or both of the other links (better metric).

So it’s the “detect within 10 seconds” part that is the problem.

r5#sh ip os int s0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
r5#sh ip os int fa0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

We’ll need to change our dead timers to be less than 10 seconds.  The dead timer is 4x the Hello interval, so we’ll set our hello interval to 2 seconds on each side of the Frame and Ethernet links.

r5(config)#int fa0/0
r5(config-if)#ip os hello-interval ?
  <1-65535>  Seconds

r5(config-if)#ip os hello-interval 2
r5(config-if)#int s0/0
r5(config-if)#ip os hello-interval 2

r5#sh ip os int s0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
  Timer intervals configured, Hello 2, Dead 8, Wait 8, Retransmit 5
r5#sh ip os int fa0/0 | i Type|Dead
  Process ID 100, Router ID 150.1.5.5, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 2, Dead 8, Wait 8, Retransmit 5

Test:

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100″, distance 110, metric 2, type intra area
  Last update from 141.1.145.5 on FastEthernet0/0, 00:14:19 ago
  Routing Descriptor Blocks:
  * 141.1.145.5, from 150.1.5.5, 00:14:19 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1
    141.1.54.5, from 150.1.5.5, 00:14:19 ago, via Serial0/0
      Route metric is 2, traffic share count is 1

r4(config)#int s0/0
r4(config-if)#shutdown
r4(config-if)#int fa0/0
r4(config-if)#shutdown

r4#sh ip route 150.1.5.5
Routing entry for 150.1.5.5/32
  Known via “ospf 100″, distance 110, metric 66, type intra area
  Last update from 141.1.45.5 on Serial0/1, 00:00:03 ago
  Routing Descriptor Blocks:
  * 141.1.45.5, from 150.1.5.5, 00:00:03 ago, via Serial0/1
      Route metric is 66, traffic share count is 1

4.8 RIP

Very basic RIP configuration.  The only “twist” is that you need to suppress RIP updates on some interfaces by using ‘passive-interface’.

“Enable RIP on all other interfaces of SW1″ – make sure you advertise the 150.1.0.0 network

Routing Protocol is “rip”
  Sending updates every 30 seconds, next due in 18 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface                 Send  Recv  Triggered RIP  Key-chain
    Vlan7                     2     2
    Vlan77                    2     2
    FastEthernet0/3           2     2
    Loopback0                 2     2

  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    141.1.0.0
    150.1.0.0

4.9 RIP

“Routes learned from BB1 that have an even third octet should be seen with a metric of 10 on r6.”
“The access-list used to accomplish this should only have one line and should be effective for any additional networks learned from bb1 in the future.”

How do I compute complex wildcard masks for access-lists?

offset-list (RIP)

These are the routes that r6 is receiving from bb1:

r6#sh ip route rip | i 54.1.1.254
R    212.18.1.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0
R    212.18.0.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0
R    212.18.3.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0
R    212.18.2.0/24 [120/1] via 54.1.1.254, 00:00:21, Serial0/0

The “secret” to filtering even or odd routes is: “The least significant bit of a binary number determines whether the number is even or odd.  If the least significant bit is not set, then the number must be even.  If the least significant bit is set, then the number must be odd.”

r6(config)#access-list 69 permit 0.0.0.0 255.255.254.255
r6(config)#router rip
r6(config-router)#offset-list 69 in 9 s0/0

r6#clear ip route *
r6#sh ip route rip | i 54.1.1.254
R    212.18.1.0/24 [120/1] via 54.1.1.254, 00:00:03, Serial0/0
R    212.18.0.0/24 [120/10] via 54.1.1.254, 00:00:03, Serial0/0
R    212.18.3.0/24 [120/1] via 54.1.1.254, 00:00:03, Serial0/0
R    212.18.2.0/24 [120/10] via 54.1.1.254, 00:00:03, Serial0/0

4.10 IGP Redistribution

Perform mutual redistribution on r3 and r4.  Well, the good news is that we’re only running RIP and OSPF. :-)

I’ll start with r4:

r4(config)#route-map RIP->OSPF permit 10
r4(config-route-map)#desc Tag RIP with 4120
r4(config-route-map)#set tag 4120
r4(config-route-map)#router ospf 100
r4(config-router)#redist rip sub route-map RIP->OSPF

I should see the bb3 routes on r3 with a tag of 4120

r3#sh ip os data | i Tag|4120
Link ID         ADV Router      Age         Seq#       Checksum Tag
30.0.0.0        150.1.4.4       72          0x80000001 0x009B1F 4120
30.1.0.0        150.1.4.4       72          0x80000001 0x008F2A 4120
30.2.0.0        150.1.4.4       72          0x80000001 0x008335 4120
30.3.0.0        150.1.4.4       72          0x80000001 0x007740 4120
31.0.0.0        150.1.4.4       72          0x80000001 0x008E2B 4120
31.1.0.0        150.1.4.4       72          0x80000001 0x008236 4120
31.2.0.0        150.1.4.4       72          0x80000001 0x007641 4120
31.3.0.0        150.1.4.4       72          0x80000001 0x006A4C 4120
204.12.1.0      150.1.4.4       72          0x80000001 0x0021DD 4120

Sweet!

I shouldn’t have any problems on r4 so I’ll go ahead and redistribute OSPF into RIP:

r4(config)#route-map OSPF->RIP perm 10
r4(config-route-map)#desc Tag OSPF with 4110
r4(config-route-map)#set tag 4110
r4(config-route-map)#router rip
r4(config-router)#redist ospf 100 met 1 route-map OSPF->RIP

Okay…on to r3.  I can redist the OSPF routes into RIP (110 -> 120) with no worries as they will not be reflected back.  I also don’t think that I have to worry about the RIP routes because the RIP domain is not contiguous.

r3(config)#route-map RIP->OSPF perm 10
r3(config-route-map)#desc Tag RIP 3120
r3(config-route-map)#set tag 3120
r3(config-route-map)#router ospf 100
r3(config-router)#redist rip sub route-map RIP->OSPF

Those routes should appear on r4:

r4#sh ip os data | i Tag|3120
Link ID         ADV Router      Age         Seq#       Checksum Tag
54.1.1.0        150.1.3.3       26          0x80000003 0x00C1CA 3120
141.1.6.0       150.1.3.3       26          0x80000003 0x001B15 3120
141.1.7.0       150.1.3.3       26          0x80000003 0x00101F 3120
141.1.36.0      150.1.3.3       26          0x80000003 0x00CF42 3120
141.1.37.0      150.1.3.3       26          0x80000003 0x00C44C 3120
141.1.77.0      150.1.3.3       26          0x80000003 0x000BDD 3120
150.1.6.0       150.1.3.3       26          0x80000003 0x00A581 3120
150.1.7.0       150.1.3.3       26          0x80000003 0x009A8B 3120
212.18.0.0      150.1.3.3       26          0x80000003 0x00F1EB 3120
212.18.1.0      150.1.3.3       26          0x80000003 0x00E6F5 3120
212.18.2.0      150.1.3.3       26          0x80000003 0x00DBFF 3120
212.18.3.0      150.1.3.3       26          0x80000003 0x00D00A 3120

Now for OSPF->RIP:

r3(config)#route-map OSPF->RIP perm 10
r3(config-route-map)#desc Tag OSPF 3110
r3(config-route-map)#set tag 3110
r3(config-route-map)#router rip
r3(config-router)#redist ospf 100 met 1 route-m OSPF->RIP

r6#sh ip route 150.1.4.4
Routing entry for 150.1.4.4/32
  Known via “rip“, distance 120, metric 1
  Tag 3110
  Redistributing via rip
  Last update from 141.1.36.3 on FastEthernet0/0, 00:00:09 ago
  Routing Descriptor Blocks:
  * 141.1.36.3, from 141.1.36.3, 00:00:09 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1
      Route tag 3110

At this point I created my ping scripts and tested connectivity (everything pinged) before completing the additional requirements:

“Routers in the OSPF domain should see two summary routes for the networks learned from BB3.”
“Do not overlap any address space when creating these summaries.”

Here are the routes learned from BB3:

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

Let’s figure out our summary routes:

Computing Access-List and Wildcard Pairs

31.0.0.0   00011111  00000000
31.1.0.0   00011111  00000001
31.2.0.0   00011111  00000010
31.3.0.0   00011111  00000011 
AND———————————
Network  00011111  00000000 31.0.0.0

31.0.0.0   00011111  00000000
31.1.0.0   00011111  00000001
31.2.0.0   00011111  00000010
31.3.0.0   00011111  00000011 
XOR———————————
Mask       00000000  00000011 0.3.255.255 – 255.253.0.0

30.0.0.0 00011110  00000000
30.1.0.0 00011110  00000001
30.2.0.0 00011110  00000010
30.3.0.0 00011110  00000011 
AND———————————
                00011110  00000000 30.0.0.0  

30.0.0.0 00011110  00000000
30.1.0.0 00011110  00000001
30.2.0.0 00011110  00000010
30.3.0.0 00011110  00000011 
XOR———————————
               00000000  00000011 0.3.255.255 –  255.252.0.0

So our two summaries will be:

summary-address (OSPF)

r4(config)#router ospf 100
r4(config-router)#summary-address 30.0.0.0 ?
  A.B.C.D  Summary mask

r4(config-router)#summary-address 31.0.0.0 255.252.0.0 tag 4120
r4(config-router)#summary-address 30.0.0.0 255.252.0.0 tag 4120

r4#sh ip ospf summary-address

OSPF Process 100, Summary-address

30.0.0.0/255.252.0.0 Metric 20, Type 2, Tag 4120
31.0.0.0/255.252.0.0 Metric 20, Type 2, Tag 4120

r3 sees theses routes as /14 routes now:

r3#sh ip route | i 30|31
     31.0.0.0/14is subnetted, 1 subnets
O E2    31.0.0.0 [110/20] via 141.1.123.2, 00:00:54, Serial0/0:0.1
     30.0.0.0/14is subnetted, 1 subnets
O E2    30.0.0.0 [110/20] via 141.1.123.2, 00:01:04, Serial0/0:0.1

Now the final subtask:

“The summaries should have a cumulative metric throughout the OSPF domain, while the route to VLAN 43 should always be seen with a metric of 100 throughout the OSPF domain.”

“cumulative metric” = E1 routes.  It looks like we’ll need to set the metric on the VLAN 43 route to 100 and make sure that it is an E2 route.  That route is already an E2, so I just need to change the metric:

r3#sh ip route | i 204.12.1.0
O E2 204.12.1.0/24 [110/20] via 141.1.123.2, 00:50:50, Serial0/0:0.1

I just need to add a line to my RIP->OSPF route-map to set the metric-type to 1.  BUT I need to use the route-map order of operations (which I am very well acquainted with after last week’s LFU) to ensure that I am setting the metric to 100 only for the VLAN43 route:

r4:
ip prefix-list VLAN34 perm 204.12.1.0/24
!
route-map RIP->OSPF permit 10
 description If VLAN43 set metric 100 tag 4120
 match ip address prefix-list VLAN43
 set metric 100
 set tag 4120
route-map RIP->OSPF permit 20
 description If not VLAN43 set E1 tag 4120
 set metric-type type-1
 set tag 4120

r3#sh ip route 204.12.1.0
Routing entry for 204.12.1.0/24
  Known via “ospf 100″, distance 110, metric 100
  Tag 4120, type extern 2, forward metric 11177
  Redistributing via rip
  Advertised by rip metric 1 route-map OSPF->RIP
  Last update from 141.1.123.2 on Serial0/0:0.1, 00:03:38 ago
  Routing Descriptor Blocks:
  * 141.1.123.2, from 150.1.4.4, 00:03:38 ago, via Serial0/0:0.1
      Route metric is 100, traffic share count is 1
      Route tag 4120

r3#sh ip route 30.0.0.0 255.252.0.0
Routing entry for 30.0.0.0/14
  Known via “ospf 100″, distance 110, metric 11197
  Tag 4120, type extern 1
  Redistributing via rip
  Advertised by rip metric 1 route-map OSPF->RIP
  Last update from 141.1.123.2 on Serial0/0:0.1, 00:02:58 ago
  Routing Descriptor Blocks:
  * 141.1.123.2, from 150.1.4.4, 00:02:58 ago, via Serial0/0:0.1
      Route metric is 11197, traffic share count is 1
      Route tag 4120

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 113 other followers