CCIE Pursuit Blog

August 13, 2008

Internetwork Expert Volume II: Lab 12 – Section 7

Section 7 – IPv6 – 16 Points

7.1 IPv6 Addressing

Very basic IPv6 addressing task.  The only confusing bit:

“Use the address 2001:CC1E:X:3::Y/64 for r3’s Ethernet interface.”

Ummm…r3 has TWO Ethernet interfaces?  Which one do they mean?  It turns out that they only mean e0/0 (VLAN3).

7.2 IPv6 over Frame Relay

This is a basic IPv6 Frame Relay hub-and-spoke task.  They even go so far as to tell you what to use for the link-local addresses.  I always read ahead in the IPv6 section to see if we will be running an IPv6 IGP over the Frame Relay network.  In this case task 7.4 will require exactly that.  SO….if there are no requirements against it, I hardset the link-local addresses to Fe80::Y (where Y is the router number) AND I go ahead and create frame maps for the link-local addresses.  It’s not required in this task, but we might as well do it now.

R1 (spoke) before:

Rack16R1(config-if)#do sh run int s0/0 | i face|add|rame
interface Serial0/0
 ip address 129.16.124.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 129.16.124.2 104
 frame-relay map ip 129.16.124.4 104 broadcast
 no frame-relay inverse-arp

R1 after:

Rack16R1(config-if)#do sh run int s0/0 | i face|add|rame
interface Serial0/0
 ip address 129.16.124.1 255.255.255.0
 encapsulation frame-relay
 ipv6 address 2001:CC1E:16:124::1/64
 ipv6 address FE80::1 link-local
 frame-relay map ipv6 FE80::2 104
 frame-relay map ipv6 FE80::4 104
 frame-relay map ipv6 2001:CC1E:16:124::2 104
 frame-relay map ipv6 2001:CC1E:16:124::4 104 broadcast
 frame-relay map ip 129.16.124.2 104
 frame-relay map ip 129.16.124.4 104 broadcast
 no frame-relay inverse-arp

7.3 RIPng

This is a simple RIPng task.

“Configure r2 so that RIPng routes learned from BB2 with a mask longer than /64 will not be passed on to r3.”

Here are the RIPng routes that we’re receiving from BB2:

Rack16R2#sh ipv6 route rip
IPv6 Routing Table – 12 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
R   2001:205:90:31::/64 [120/2]
     via FE80::200:CFF:FE4A:689C, FastEthernet0/0
R   2001:220:20:3::/64 [120/2]
     via FE80::200:CFF:FE4A:689C, FastEthernet0/0
R   2001:222:22:2::/64 [120/2]
     via FE80::200:CFF:FE4A:689C, FastEthernet0/0

R   2001:CC1E:16:3::/64 [120/2]
     via FE80::206:D7FF:FEBD:1741, Serial0/1

We need to filter some routes.  Our old filtering friends from RIPv1/2 are still available although the offset-list has been moved to the interface level and renamed:

Rack16R2(config)#ipv6 router rip RIPng
Rack16R2(config-rtr)#?
  distance         Administrative distance
  distribute-list  Filter networks in routing updates

Rack16R2(config-if)#ipv6 rip RIPng ?
  metric-offset        Adjust default metric increment

Well…the metric-offset is not quite as flexible as the old skool offset-list because you can’t specify the routes to offset.  It’s an “all or nothing” solution:

Rack16R2(config-if)#ipv rip RIPng metric-offset 16 ?
  <cr>

ipv6 rip metric-offset

Let’s use a distribute list instead:

distribute-list prefix-list (IPv6 RIP)

The first thing that we need to do is write an IPv6 prefix-list to match any IPv6 routes that are /64 or less:

Rack16R2(config)#ipv6 prefix-list TASK_7_2 perm 0::0/0 le 64

Then apply the distribute-list under the RIPng process:

Rack16R2(config)#ipv6 router rip RIPng
Rack16R2(config-rtr)#distribute-list prefix-list TASK_7_2 out s0/1

Since we don’t have any routes greater than /64 coming from BB2, there is really no good way to validate this.  BUT make sure that the this doesn’t break your IPv6 routing by making sure that the RIPng routes from BB2 are getting to r3:

Rack16R3#sh ipv route rip
IPv6 Routing Table – 10 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
R   2001:192:10:16::/64 [120/2]
     via FE80::211:92FF:FE17:C860, Serial1/3
R   2001:205:90:31::/64 [120/3]
     via FE80::211:92FF:FE17:C860, Serial1/3
R   2001:220:20:3::/64 [120/3]
     via FE80::211:92FF:FE17:C860, Serial1/3
R   2001:222:22:2::/64 [120/3]
     via FE80::211:92FF:FE17:C860, Serial1/3

7.4 OSPFv3

OSPFv3 is enabled under the interface as well:

Rack16R2(config)#int s0/0
Rack16R2(config-if)#ipv os 666 area 0

If you did not create frame maps for the link-local addresses then you will need to do this now (IPv6 IGPs use the link-local address for next-hop processing).

We need to get our neighbor adjacencies up, but we’re not allowed to change the default OSPF type.  This means we need neighbor statements on the hub (and priority 0 statements on the spokes).  The only deviation form the OSPFv2 process is that this is done under the interface:

Rack16R4(config-rtr)#int s0/0.124
Rack16R4(config-subif)#ipv6 ospf ?
  <1-65535>            Process ID
  authentication       Enable authentication
  cost                 Interface cost
  database-filter      Filter OSPF LSA during synchronization and flooding
  dead-interval        Interval after which a neighbor is declared dead
  demand-circuit       OSPF demand circuit
  flood-reduction      OSPF Flood Reduction
  hello-interval       Time between HELLO packets
  mtu-ignore           Ignores the MTU in DBD packets
  neighbor             OSPF neighbor
  network              Network type
  priority             Router priority
  retransmit-interval  Time between retransmitting lost link state
                       advertisements
  transmit-delay       Link state transmit delay

Rack16R4(config-subif)#ipv6 ospf neigh 2001:CC1E:16:124::2
OSPFv3: Neighbor address needs to be a link-local address

Doh!

Rack16R4(config-subif)#ipv6 ospf neigh FE80::2
Rack16R4(config-subif)#ipv6 ospf neigh FE80::1

Rack16R4#sh ipv os neigh

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
150.16.1.1        0   FULL/DROTHER    00:01:42    5               Serial0/0.124
150.16.2.2        0   FULL/DROTHER    00:01:32    5               Serial0/0.124

7.5 OSPv3

Create two new OSPFv3 areas and:

“r6 should see only one router for both the Frame Relay segment and VLAN 17 of r1.”

Here’s what we see on r6 right now:

Rack16R6#sh ipv route os
IPv6 Routing Table – 6 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
OI  2001:CC1E:16:1::/64 [110/66]
     via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0
OI  2001:CC1E:16:124::/64 [110/65]
     via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0

So…is the task asking us to summarize these two routes or is it asking for a single default route?  I would ask the proctor on this one.

Since making this a totally-stubby area is the easier solution, that’s the one I chose.  🙂  IE also went this route.

Rack16R4(config-if)#ipv6 router ospf 666
Rack16R4(config-rtr)#area 2 stub no-summ

Rack16R6(config)#ipv6 router ospf 666
Rack16R6(config-rtr)#area 2 stub

Rack16R6#sh ipv 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
OI  ::/0 [110/2]
     via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0

7.6 IPv6 Redistribution

Oh fun.  🙂  At least there are only two IPv6 protocols and one point of redistribution (r2).

I tried to build a TCL script and quickly found out that there is no ‘show ipv6 alias” command.  😦  I just did a “show ipv6 int brief” and copied the addresses:

foreach x {
2001:CC1E:16:1::1
2001:CC1E:16:124::1
2001:CC1E:16:3::3
2001:CC1E:16:23::3
2001:192:10:16::2
2001:CC1E:16:124::2
2001:CC1E:16:23::2
2001:CC1E:16:124::4
2001:CC1E:16:46::4
2001:CC1E:16:46::6
2001:222:22:2::1} {ping $x re 2}

The redistribution is pretty straight-forward except I couldn’t decide if I needed “include-connected” as well.  I voted “no” – which ended up being a mistake.   I need to review IPv6 redistribution to find out why.

Rack16R2(config-rtr)#ipv6 router ospf 666
Rack16R2(config-rtr)#redistribute rip RIPng include-conn

Rack16R2(config-rtr)#ipv6 router rip RIPng
Rack16R2(config-rtr)#redist ospf 666 metric 1 include-conn

Rack16R1#sh ipv route os
IPv6 Routing Table – 13 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:192:10:16::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:205:90:31::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:220:20:3::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:222:22:2::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:CC1E:16:3::/64 [110/20]
     via FE80::2, Serial0/0
OE2  2001:CC1E:16:23::/64 [110/20]
     via FE80::2, Serial0/0

OI  2001:CC1E:16:46::/64 [110/74]
     via FE80::4, Serial0/0

Advertisements

Internetwork Expert Volume II: Lab 12 – Section 8

Section 8 – QoS – 6 Points

8.1 Frame Relay Traffic Shaping

Oooh.  A VoIP issue with an interface running at less than 768K.  Time for some packet interleaving.  🙂

The task tells us that r2 and r4 have been provisioned at 512K and that we should “ensure that neither of these devices send traffic beyond this rate on this circuit.”

We also have this requirement:

“Additional VCs on r4 (DLCIs 401 and 405) should equally share the remaining bandwidth of its T1 interface to the Frame Relay cloud.”

Okay.  That bit confused me.  Basically we need to split the the remaining bandwidth (1544 – 512)/2.  In the end we’re assigning a CIR of 512 to each of the three circuits on int s0/0 of r4.

It’s the last requirement that gives us the most “actionable information”:

“In order to allow VoIP traffic to be interleaved between larger data converstions ensure that the maximum time that it takes to transmit a packet across the Frame Relay network is 10ms.”

All of that just basically means that we need to use a Tc of 10ms.

We aren’t asked to allow a burst, so we can set Be to 0.  Bc can be determined by the following formula:

Bc =  CIR * (Tc/1000)
Bc = 512000 * (10/1000)
Bc = 512000 * .01
Bc = 5120

So our map-class should be:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 5120
 frame-relay be 0

Now we need to enable interleaving:

frame-relay fragment

Rack16R2(config-map-class)#frame ?
  fragment           fragmentation – Requires Frame Relay traffic-shaping to be configured at the interface level

Rack16R2(config-map-class)#frame frag ?
  <16-1600>  Define fragment size, Bytes
  <cr>

Okay.  So how do we come up with this value?  There’s a chart of suggested values in the frame-relay fragement documentation.  As long as the speed is under 768K We just need to convert the Bc of the lowest speed link in the path (in our case both sides are 512K) to bytes (divide by 8):

5120/8 = 640 bytes

So now we have:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 5120
 frame-relay be 0
 frame-relay fragment 640
 frame-relay fair-queue <- IOS added this

Now apply the map-class to the DLCI:

Rack16R2(config)#int s0/0
Rack16R2(config-if)#frame interface-d 204
Rack16R2(config-fr-dlci)#class FRTS

I generally only apply traffic shaping to the specific DLCI, IE likes to apply it to the all DLCIs on the interface.  Ask your proctor. 🙂

Rack16R2(config-if)#do sh traffic

Interface   Se0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
201           56000     875    7000      0         125       875       –
203           56000     875    7000      0         125       875       –
205           56000     875    7000      0         125       875       –
213           56000     875    7000      0         125       875       –
204           512000    640    5120      0         10        640       –  

Rack16R2#sh frame pvc 204

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 204, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 1026          output pkts 1092         in bytes 148630
  out bytes 148115         dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 254       out bcast bytes 90472
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 04:09:41, last time pvc status changed 04:08:32
  fragment type end-to-end fragment size 640
  cir 512000    bc   5120      be 0         limit 640    interval 10 
  mincir 256000    byte increment 640   BECN response no  IF_CONG no
  frags 74        bytes 9639      frags delayed 0         bytes delayed 0

  shaping inactive
  traffic shaping drops 0
  Queueing strategy: weighted fair
  Current fair queue configuration:
   Discard     Dynamic      Reserved
   threshold   queue count  queue count
    64          16           0
  Output queue size 0/max total 600/drops 0

One “gotcha” on r4 is that we already have a class applied to DLCI 504:

interface Serial0/0.54 point-to-point
 ip address 129.16.54.4 255.255.255.0
 ip ospf demand-circuit
 frame-relay interface-dlci 405
  class FREEK

We just need to add the additional FRTS configuration to that already existing map-class.  You could create only one additional map-class for both of the remaining DLCIs, but the next task will require two separate map-classes as you will tweak DLCI 402 only.

Rack16R4#sh traffic

Interface   Se0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
403           56000     875    7000      0         125       875       –
413           56000     875    7000      0         125       875       –

Interface   Se0/0.54
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
405           512000    640    5120      0         10        640       –

Interface   Se0/0.124
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
401           512000    640    5120      0         10        640       –
402           512000    640    5120      0         10        640       –

8.2 Priority Queueing

“…configure your network so that all VoIP traffic (UDP 16384 – 32767) coming from VLAN 46 going out the Frame Relay circuit to R2 gets priority over data traffic.”

“VoIP should be allocated a maximum of 192Kbps during periods of congestion on this link.”

It’s nice that IE included the VoIP protocol ports, but you should probably memorized that before the lab.  It’s pretty obvious that we’ll be configuring LLQ and mixing it with the existing FRTS configuration.

ip access-list extended TASK_8_2
 permit udp 129.16.46.0 0.0.0.255 any range 16384 32767

Rack16R4(config)#class-map TASK_8_2
Rack16R4(config-cmap)#match access-group name TASK_8_2

Rack16R4(config-ext-nacl)#policy-map TASK_8_2
Rack16R4(config-pmap)#class TASK_8_2
Rack16R4(config-pmap-c)#prio ?
  <8-2000000>  Kilo Bits per second <- KILO!!!

  percent      % of total bandwidth

Rack16R4(config-pmap-c)#prio 192

Rack16R4(config-pmap-c)#map-class frame-relay DLCI_402
Rack16R4(config-map-class)#service-policy out TASK_8_2

Configure the same thing on r2 (remember to alter the direction of your access-list).

Internetwork Expert Volume II: Lab 12 – Section 9

Section 9 – Security – 3 Points

9.1 Traffic Filtering

Allow telnet access to r6 only from an NMS at 129.16.46.100.  Log all attempts from unauthorized devices.

Let’s start with our ACL – remember that we need to add and explicit deny statement for logging:

Rack16R6(config)#ip access-list ex TASK_9_1
Rack16R6(config-ext-nacl)#perm tcp host 129.16.46.100 any eq 23
Rack16R6(config-ext-nacl)#deny tcp any any eq 23 log

Now just apply this to the vty lines:

Rack16R6(config-ext-nacl)#line vty 0 4
Rack16R6(config-line)#access-class TASK_9_1 in

Verify:

Rack16R4#telnet 150.16.6.6
Trying 150.16.6.6 …
% Connection refused by remote host

Rack16R6#sh log | b Log Buffer
Log Buffer (4096 bytes):

Aug 13 14:17:37.053: %SYS-5-CONFIG_I: Configured from console by console
Aug 13 14:17:42.285: %SEC-6-IPACCESSLOGP: list TASK_9_1 denied tcp 129.16.46.4(43572) -> 0.0.0.0(23), 1 packet

Internetwork Expert Volume II: Lab 12 – Section 10

Section 10 – System Management – 10 Points

10.1 Logging

“Configure r6 to send its logged access-list hits to this device [129.x.46.100].”
“A log message should only be generated once 10 access-list hits have been accumulated.”

The first bit is easy:

Rack16R6(config)#logging 129.16.46.100

The second bit mindfucked me.  I looked through all of the logging option and couldn’t find a match.  That’s because the configuration is a global level ip access-list command.  😦

ip access-list log-update

To set the threshold number of packets that generate a log message if they match an access list, use the ip access-list log-update command in global configuration mode.

Rack16R6(config)#ip access-list log-update threshold ?
<0-2147483647>  Access list log-update threshold (number of hits)

Rack16R6(config)#ip access-list log-update threshold 10

10.2 NTP

Basic NTP task.  r4 and r6 get time from BB1.  r1-3 and sw1 from BB2. r5 and sw2 from BB3.

Don’t overthink this one.  🙂

ntp server

To allow the software clock to be synchronized by a Network Time Protocol (NTP) time server, use the ntp server command in global configuration mode.

Rack16R2#sh ntp status
Clock is synchronized, stratum 5, reference is 192.10.16.254
nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz, precision is 2**18
reference time is CC4DEE0D.A71E36DD (23:34:37.652 UTC Wed Aug 13 2008)
clock offset is 1.0901 msec, root delay is 7.06 msec
root dispersion is 1.63 msec, peer dispersion is 0.52 msec

Rack16R2#sh ntp ass

address         ref clock     st  when  poll reach  delay  offset    disp
*~192.10.16.254 127.127.7.1       4    49    64  377     7.1    1.09     0.5
* master (synced),# master (unsynced), + selected, – candidate, ~ configured

10.3 NTP

Configure devices in BGP AS 100 for CST -6 (Chicago – Brian McGahan) and devices in AS 200 for PST -8 (Reno – Brian Dennis). 🙂

clock timezone

Rack16R2(config)#clock timezone PST -8
Aug 13 23:38:00.742: %SYS-6-CLOCKUPDATE: System clock has been updated from 23:38:00 UTC Wed Aug 13 2008 to 15:38:00 PST Wed Aug 13 2008, configured from console by console.

Rack16R4(config)#clock timezone CST -6
Aug 13 16:39:06.862: %SYS-6-CLOCKUPDATE: System clock has been updated from 16:39:06 UTC Wed Aug 13 2008 to 10:39:06 CST Wed Aug 13 2008, configured from console by console.

Beware of this bit:

“Configure these devices to reflect the appropriate time zone and daylight savings time configuration.”

That daylight savings time needs to be configured:

clock summer-time

To configure the system to automatically switch to summer time (daylight saving time), use one of the formats of the clock summer-time command in global configuration mode.

Since I’m configuring this in August, the clocks will change to Daylight Savings Time:

Rack16R4(config)#clock summer-time CDT recurring
Aug 13 16:44:06.414: %SYS-6-CLOCKUPDATE: System clock has been updated from 10:44:06 CST Wed Aug 13 2008 to 11:44:06 CDT Wed Aug 13 2008, configured from console by console.

10.4 General Management

“Configure sw3 and sw4 in such a way that they will display the exact time and date of the last restart using the ‘show version’ command.”

One thing to note when addressing this task is that sw3 and sw4 are NOT configured for NTP. Does this task require turning NTP on for these devices?  Yes.

Internetwork Expert Volume II: Lab 12 – Section 11

Section 11  – IP Services – 2 Points

11.1 DNS

Configure all devices to use DNS server 129.x.3.100.

An easy task to end the lab.  🙂

ip name-server

To specify the address of one or more name servers to use for name and address resolution, use the ip name-server command in global configuration mode.

Rack16R1(config)#ip name-server 129.16.3.100

Verify:
Rack16SW4#fuck <- I truly am a child  🙂
Translating “fuck”…domain server (129.16.3.100)

The IE solution guide shows that you should apply the configuration to “r1 – sw2”.  Think that  this was an old lab converted from 2 switches to 4?  🙂

Create a free website or blog at WordPress.com.