CCIE Pursuit Blog

February 19, 2009

IPexpert: Free Graded Mock Lab – Plus Two Free Rack Rental Sessions

I checked my inbox today and found this great deal from IPexpert:

FREE CCIE R&S Graded Lab Assessment

Are you wondering if you are ready for the real lab exam? Here is the perfect opportunity to find out – FREE – while test-driving IPexpert’s training material and Proctor Labs’ online vRacks!

You will receive FREE access to electronic files for the following training components:

* Graded Assessment Mock Lab: You will receive a full-scale, 8-hour “Mock Lab” designed to deliver the true challenge of the actual CCIE lab exam. The configuration files are included, allowing you to compare your work to that of our instructors that created the industry-leading practice lab scenarios seen in our lab preparation workbooks.
* Proctor Guide: This is the detailed solution guide providing you with detailed written explanations for the Mock Lab taks.
* Video Tutorials: After you complete the Mock Lab, you will receive a detailed grading report, listing each section of the lab with your results. On that page, with the click of a button, you can watch videos of the instructor walking you through each section, step by step! You will be amazed by the level of detail as the instructor painstakingly walks through every task and solution involved in the lab. There is nearly 10 hours of video included for THIS FREE LAB SCENARIO (as well as every lab included in IPexpert’s lab mentoring kit)!

Online Rack Rental Sessions:

Included with this free offering, you will also receive:

* TWO Online Rack Sessions for you to test your skills using a full rack of the latest and greatest Cisco gear at Proctor Labs.
* Both sessions provided are 8 hours in length and can be scheduled back-to-back or at different times.
* At the end of each session, you will receive a detailed grading report breaking down every section of the lab.
* See exactly what you got right and compare your work to the Verified Labs™ grading engine to see what you got wrong and why.

CLICK HERE to get started!

If you click on the link above, you’ll go to a page where you can get access to the mock lab materials:

To get started, simply click the green “Buy Now” button below. You will see that the price remains at $0.00 through the checkout process. When your order is complete, you will have immediate access to the lab, solution guide and configuration files. You will get an email with two voucher codes for easy scheduling of your vRack sessions.

This is an amazing deal.  You’re basically getting the “$35 Mock Lab” that I reviewed here but for free…plus another 8 hours of rack time thrown in for free as well.  You’re getting $70 worth of free rack time, plus a graded mock lab.  I would strongly recommend this for candidates who are just dipping their toes into the CCIE waters to get a taste of a full-scale mock lab, as well as candidates on their final approach using a different vendor who want to be exposed to another vendor’s labs.

***Update***

I received my vouchers for the two free rack sessions within 15 minutes of ordering.

August 17, 2008

Internetwork Expert Volume II: Lab 8 – Section 9

Section 9 – IP Services – 8 Points

9.1 Default Gateways

Users in VLAN 26 have their default-gateway set to their own IP address instead of r6′s address.  Configure r2 and r6 to support them.

WTF?  No clue.

The answer: turn off proxy-arp on those segments.

UPDATE:

It turns out that I read the question wrong. The requirement is:

“Configure r2 and r6 not [sic] support these users.”

It make sense to disable proxy-arp so as NOT to support these users.  The users are set up to ARP for everything.  Proxy-ARP is enabled by default so r2 and r6 will respond to ARPs with their own MAC address if they have a route for the address that the users ARP for. By disabling proxy-arp, the routers will not respond to those ARP requests.

9.2 Web Caching

Configure WCCP for users in VLAN 4.  The web servers are out the Frame link.

“Configure r4 to support this setup, but don not attempt to cache HTTP traffic between VLANs 4 and 45.”

How to Configure WCCP

r4(config)#int fa0/0
r4(config-if)#ip wccp web-cache redirect in
r4(config-if)#int s0/0
r4(config-if)#ip wccp web-cache redirect out

r4(config)#ip wccp ?
  <0-254>             Dynamically defined service identifier number
  check               Enable a WCCP check
  outbound-acl-check  Enable acl check on original outbound interface
  version             protocol version
  web-cache           Standard web caching service

r4(config)#ip wccp web-cache ?
  group-address  Set the multicast group
  group-list     Set the access-list used to permit group membership

  password       Authentication password (key)
  redirect-list  Set the access-list used to permit redirection
  <cr>

The three options that stand out as possibly being useful for the last requirement are the outbound-acl-check, the group-list, and the redirect-list.

I peeked the solution guide. 

Huh?

IE just enabled WCCP globally and then set s0/0 to redirect out???  Does that last requirement mean ALL HTTP request on VLANs 4 and 45 or just the traffic between those two VLANs (as I understood it)?

I get it now.  There are only two egress point for traffic from VLAN 4 or 45.  They can either egress the other VLAN or out the Frame link.  So IE’s solution makes sense.

9.3 IP SLA

This is a basic IP SLA task in which you must set up IP SLA on r6 to ping 115.0.0.1 every 30 seconds with 1250 byte packets and a timeout of 25ms.

I kept getting failures:

r6#sh ip sla mo stat
Round trip time (RTT)   Index 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *05:04:09.895 UTC Mon Mar 18 2002
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 4
 
Operation time to live: 3503 sec

The reason was simple.  My packets were not fast enough.  :-)

r6#p 115.0.0.1 si 1250

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

9.4 Gateway Redundancy

You need to use the SLA monitor in the last task with HSRP.  R6 should be VLAN 26′s default gateway but only if the SLA monitor is successful, otherwise they should use r2.

r6(config)#track 1 rtr 1

r6(config-track)#int f0/1.26
r6(config-subif)#stand 1 track 1decre 20
r6(config-subif)#stand 1 ip 174.1.26.1
r6(config-subif)#stand 1 preempt

r2(config)#int g0/0.26
r2(config-subif)#stand 1 ip 174.1.26.1
r2(config-subif)#stand 1 preempt
r2(config-subif)#stand 1 prio 90

Since my SLA monitor is failing, r2 should be active and r6 should have a priority of 80:

r2#sh stand
GigabitEthernet0/0.26 – Group 1
  State is Active
    1 state change, last state change 00:01:12
  Virtual IP address is 174.1.26.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.556 secs
  Preemption enabled
  Active router is local
  Standby router is 174.1.26.6, priority 80 (expires in 7.556 sec)
  Priority 90 (configured 90)
  IP redundancy name is “hsrp-Gi0/0.26-1″ (default)

r6#sh stand
FastEthernet0/1.26 – Group 1
  State is Standby
    4 state changes, last state change 00:01:22
  Virtual IP address is 174.1.26.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.232 secs
  Preemption enabled
  Active router is 174.1.26.2, priority 90 (expires in 7.232 sec)
  Standby router is local
  Priority 80 (default 100)
    Track object 1 state Down decrement 20
  IP redundancy name is “hsrp-Fa0/1.26-1″ (default)

Just to see if it will come up I deleted the SLA monitor and re-added it with a timeout and threshold of 50ms:

no ip sla monitor 1
ip sla monitor 1
type echo protocol ipIcmpEcho 115.0.0.1
request-data-size 1250
timeout 50
threshold 50
freq 5

ip sla monitor schedule 1 start-time now

r6#sh ip sla monitor stat
Round trip time (RTT)   Index 1
        Latest RTT: 28 ms
Latest operation start time: *05:14:18.275 UTC Mon Mar 18 2002
Latest operation return code: OK
Number of successes: 12 
Number of failures: 0

Operation time to live: 3543 sec

r6#sh stand
FastEthernet0/1.26 – Group 1
  State is Active
    8 state changes, last state change 00:01:09
  Virtual IP address is 174.1.26.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.296 secs
  Preemption enabled
  Active router is local
  Standby router is 174.1.26.2, priority 90 (expires in 7.296 sec)
  Priority 100 (default 100)
    Track object 1 state Up decrement 20
  IP redundancy name is “hsrp-Fa0/1.26-1″ (default)

r2#sh stand
GigabitEthernet0/0.26 – Group 1
  State is Standby
    5 state changes, last state change 00:01:33
  Virtual IP address is 174.1.26.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.280 secs
  Preemption enabled
  Active router is 174.1.26.6, priority 100 (expires in 8.276 sec)
  Standby router is local
  Priority 90 (configured 90)
  IP redundancy name is “hsrp-Gi0/0.26-1″ (default)

Internetwork Expert Volume II: Lab 8 – Section 8

Section 8 – Security – 7 Points

8.1 Router Hardening

Configure r5 to:

Drop all source-routed packets
Disable proxy-arp and CDP support on the connections to BB2 and BB3
Drop all HTTP an telnet sessions destined for 174.x.0.0/16 and 150.x.0.0/16 from BB2 or BB3
Drop all inbound echo requests coming from BB2 or BB3

In the real lab I would just eat the 3 points rather than mess with connections to the backbone routers.  But this task is pretty easy so I gave it a shot.

The first requirement:

ip source-route
To allow the Cisco IOS software to handle IP datagrams with source routing header options, use the ip source-route command in global configuration mode.

r5(config)#no ip source-route

The second one:

r5(config-subif)#no cdp en
r5(config-subif)#no ip proxy-arp

And the rest:

r5(config)#ip access-list ex TASK_8_1
r5(config-ext-nacl)#deny tcp any 174.1.0.0 0.0.255.255 eq www
r5(config-ext-nacl)#deny tcp any 174.1.0.0 0.0.255.255 eq telnet
r5(config-ext-nacl)#deny tcp any 150.1.0.0 0.0.255.255 eq www
r5(config-ext-nacl)#deny tcp any 150.1.0.0 0.0.255.255 eq telnet
r5(config-ext-nacl)#deny icmp any any echo
r5(config-ext-nacl)#permit ip any any

8.2 Traffic Filtering

Drop all traffic from BB2 to BB3 and vice versa on r5 but do not use any access-lists to do this.

We can police inbound, but how to match on the destination without an ACL?

r5(config)#class-map TASK_8_2
r5(config-cmap)#match ?
  destination-address  Destination address
  input-interface      Select an input interface to match

r5(config-cmap)#match destination-address ?
  mac  MAC address

That will not work:

r5(config-cmap)#do sh int f0/1.52 | i bia
  Hardware is AmdFE, address is 0011.93b0.7521(bia 0011.93b0.7521)
r5(config-cmap)#do sh int f0/1.53 | i bia
  Hardware is AmdFE, address is 0011.93b0.7521(bia 0011.93b0.7521)
r5(config-cmap)#do sh int f0/1 | i bia
  Hardware is AmdFE, address is 0011.93b0.7521(bia 0011.93b0.7521)

Let’s check out the input-interface:

r5(config-cmap)#match input-interface fa0/1.52
                                           ^
% Invalid input detected at ‘^’ marker.

r5(config-cmap)#match input-interface fa0/1

Okay, so I can match on the interface, but only the physical interface (which makes sense). 

r5(config-cmap)#policy-map TASK_8_2
r5(config-pmap)#class TASK_8_2
r5(config-pmap-c)#drop

r5(config-pmap-c)#int fa0/1.52
r5(config-subif)#service-policy out TASK_8_2
r5(config-subif)#int fa0/1.53
r5(config-subif)#service-policy out TASK_8_2

8.3 Traffic Filtering

Open the filter you just configured to allow SMTP from 192.10.1.100 to 204.12.1.0/24

r5(config)#ip access-list ex TASK_8_3_FROM_SERVER
r5(config-ext-nacl)#permit tcp host 192.10.1.100 eq smtp 204.12.10.0 0.0.0.255
r5(config)#ip access-list ex TASK_8_3_TO_SERVER
r5(config-ext-nacl)#perm tcp 204.12.10.0 0.0.0.255 host 192.10.1.100 eq smtp

r5(config)#class-map TASK_8_3_FROM_SERVER
r5(config-cmap)#match access-group name TASK_8_3_FROM_SERVER

r5(config-cmap)#class-map TASK_8_3_TO_SERVER
r5(config-cmap)#match access name TASK_8_3_TO_SERVER

Because I did not create separate policy-maps per backbone router, I had to go back and do that:

r5(config-cmap)#policy-map OUT_TO_BB2
r5(config-pmap)# class TASK_8_3_FROM_SERVER
r5(config-pmap-c)# class TASK_8_2
r5(config-pmap-c)#   drop

r5(config-pmap-c)#policy-map OUT_TO_BB3
r5(config-pmap)# class TASK_8_3_TO_SERVER
r5(config-pmap-c)# class TASK_8_2
r5(config-pmap-c)#   drop

Then I had to go in and remove the old class and policy maps and add the new service-policies:

r5(config)#int fa0/1.52
r5(config-subif)#service-policy out OUT_TO_BB2
r5(config-subif)#int fa0/1.53
r5(config-subif)#service-policy out OUT_TO_BB3

IE went with a few less lines of configuration by using a ‘match not’ statement.

Internetwork Expert Volume II: Lab 8 – Section 5

Section 5 – IP Multicast – 11 Points

5.1 PIM

Basic multicast task. We are not told which PIM mode to use, but by reading ahead we can see that we’ll be using Auto-RP so we’ll need sparse-dense mode.

Sparse-Dense Mode for Auto-RP

5.2 Auto-RP

Configure r1 and r2 to use Auto-RP and announce their lo0 interfaces as candidate RP’s.

Configuring Sparse Mode with Auto-RP

“Configure r3 to map all multicast groups with an even numbered first octet to r1 and odd-numbered to r2.”

There’s no “minimal configuration” stipulation so let’s just make so basic access-lists:

r1(config)#ip access-list standard TASK_5_2_EVEN
r1(config-std-nacl)#permit 224.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 226.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 228.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 230.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 232.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 234.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 236.0.0.0 0.255.255.255
r1(config-std-nacl)#permit 238.0.0.0 0.255.255.255

r1(config)#ip pim send-rp-announce lo0 scope 16 group-list TASK_5_2_EVEN

On r3(mapping agent) you will need to apply those same ACLs and then:

r3(config)#ip pim send-rp-discovery lo0 scope 16

Now we need to set up our rp-list ACLs:

r3(config)#ip access-list standard R1_LOOP
r3(config-std-nacl)#permit 150.1.1.1
r3(config-std-nacl)#ip access-list standard R2_LOOP
r3(config-std-nacl)#permit 150.1.2.2

Finally, we set our rp-announce-filters:

r3(config)#ip pim rp-announce-filter rp-list R1_LOOP group-list TASK_5_2_EVEN
r3(config)#ip pim rp-announce-filter rp-list R2_LOOP group-list TASK_5_2_ODD

For some reason I could not get the r2 to map even though my configuration was correct and r2 saw itself elected:

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

The problem was that there was no multicast path to r2.  I forgot to configure PIM on the Multilink interfaces on r2 and r3.  DOH!!!

5.3 Multicast Distribution

Multicast traffic should switch to a source based tree once a source is sending 128Kbps or more.

ip pim spt-threshold

r1(config)#ip pim spt-threshold 128

5.4 Multicast Testing

Users in VLAN 4 cannot receive multicast feeds from VLAN 52. 

“Configure…so that r4 responds to ICMP echo requests sent the multicast group 224.4.4.4 from VLAN 52.”

First things first:

r4(config)#int f0/0
r4(config-if)#ip igmp join-group 224.4.4.4

These VLANs are on the spokes.  PIM NBMA mode is needed on the hub.

Before:

r5#p 224.4.4.4 source 174.1.45.5

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

r1(config-if)#ip pim nbma-mode
PIM nbma-mode is not recommended for sparse-dense-mode

After:

r5#p 224.4.4.4 source 174.1.45.5

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

Reply to request 0 from 174.1.145.4, 52 ms

5.5 Broadcast Distribution

This is a common scenario in which we need to map a multicast feed to a broadcast address using the ‘ip multicast helper-map’ command.

Internetwork Expert Volume II: Lab 8 – Section 4

Section 4 – Exteriour Gateway Routing – 13 Points

4.1 BGP

Easy BGP peering task.  Only “twist” is that you’ll be configuring confederations.

SubAS 65145 has a full mesh. 65267 does not.  You’ll need make r6 a route-reflector.

You’ll also need to remember to set ‘next-hop-self’ between inter-confederation peers where needed (unlike true EBGP peerings, inter-confederation peers do not automatically set ‘next-hop-self’).  Or not…this will be addressed in later tasks.  :-)

For some reason IE peered between the loopbacks on the routers in SubAS 65145.

4.2 BGP Summarization

Advertise a summary of 174.x.0.0/16 to the backbone routers.

“Do not allow any other devices in your BGP network to see this prefix.”
“Use one static router on r5 and r6 to accomplish this.”

So we’ll need to create a static route to Null0 on r5 and r6 and redistribute it into BGP…while filtering it for the rest of the BGP routers.

First, create the static route:

r5(config)#ip route 174.1.0.0 255.255.0.0 null0

Next, match that route in a prefix-list and create route-maps to filter it for our network:

r5(config)#ip prefix-list TASK_4_2 permi 174.1.0.0/16

r5(config)#route-map OUT_TO_R4 deny 10
r5(config-route-map)#match ip add pre TASK_4_2
r5(config-route-map)#route-map OUT_TO_R4 permi 1000
r5(config-route-map)#do sh hist

r5(config-route-map)#route-map OUT_TO_R1 deny 10
r5(config-route-map)#match ip add pre TASK_4_2
r5(config-route-map)#route-map OUT_TO_R1 permi 1000

Finally, redistribute the static route into BGP and apply the route-maps outbound to the neighbors we need to filter for:

r5(config-route-map)#router bgp 65145
r5(config-router)#redistribute static
r5(config-router)#neigh 174.1.145.4 route-map OUT_TO_R4 out
r5(config-router)#neigh 174.1.145.1 route-map OUT_TO_R1 out

We are advertising the summary to BB3:

r5#sh ip bgp neigh 204.12.1.254 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 174.1.0.0        0.0.0.0                  0         32768 ?

Total number of prefixes 1

But we’re not advertising the summary to r4 and r1:

r5#sh ip bgp neigh 174.1.145.4 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i

Total number of prefixes 2

r5#sh ip bgp neigh 174.1.145.1 adv| b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.1.254             0             0 54 i
*> 28.119.17.0/24   204.12.1.254             0             0 54 i

Total number of prefixes 2

4.3 BGP Next-Hop Processing

“Configure the network in such a way that all devices throughout your network have reachablility to the BGP prefixes learned from AS54.”

Ugh.  That “all devices” bit had me worried that I would need to redistribute BGP into IGP. But the only devices not running BGP are sw3 and sw4 and they are in an OSPF stub area so they will just send traffic for unknown destinations to r3.  So we should be cool.

“Do not advertise the Frame Relay link to BB1 or the Ethernet link to BB3 into IGP or BGP to accomplish this.”

Not a problem I just use ‘next-hop-self’

“Do not use the next-hop-self command to accomplish this.”

Oh poop. I’m stumped.  Should I summarize the routes?  Create a default route? 

Nope. IE was being a bit tricky.  I need to use next-hop modification BUT I cannot use the command ‘next-hop-self’.  Instead I can set the next-hop in a route-map with ‘set ip next-hop peer-address’:

We can use the route-maps that we created for the last task and just add the line:

r6(config)#route-map OUT_TO_R2 perm 1000
r6(config-route-map)#set ip next-hop peer-address

I can ping prefixes from BB1 and BB3 from sw3 even though BGP is not running:

sw3#p 28.119.17.1

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

sw3#p 112.0.0.1

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

sw3#sh ip proto sum
Index Process Name
0     connected
1     static
2     ospf 100
*** IP Routing is NSF aware ***

4.4 BGP Bestpath Selection

Advertise some networks into BGP and then make the routes to some of these networks be preferred via one of the AS 54 backbone routers.

We’re affecting inbound traffic so we have a choice of AS-Path or MED. I picked AS-Path.

We also have this requirement:

“Other AS’s beyond AS 54 should not see these specific subnets, but instead should only see the previously advertised aggregate.”

This task would be very difficult without our good friend the BGP community attribute.  :-)

r6(config)#ip prefix-list VLAN3 permi 174.1.3.0/24
r6(config)#ip prefix-list VLAN4 permi 174.1.4.0/24
r6(config)#ip prefix-list VLAN7 permi 174.1.7.0/24

r6(config)#route-map OUT_TO_BB1
r6(config-route-map)#match ip add pre VLAN3 VLAN7
r6(config-route-map)#set as-path prepend 100 100 100 100
r6(config-route-map)#set community no-export
r6(config-route-map)#route-map OUT_TO_BB1 20
r6(config-route-map)#match ip add pre VLAN4
r6(config-route-map)#set community no-export
r6(config-route-map)#route-map OUT_TO_BB1 permit 1000

r6(config)#router bgp 65267
r6(config-router)#neigh 54.1.2.254 send-community
r6(config-router)#neigh 54.1.2.254 route-map OUT_TO_BB1 out

IE used MED instead of AS-Path (although they noted that both were acceptable).  They did drop this on me (I can’t believe that I didn’t know this):

MED is only compared (by default) between prefixes learned from the same autonomous system.

4.5 BGP Filtering

Advertise VLAN 1001 into BGP but make sure that devices outside of AS 65145 don’t have reachbility to this VLAN.

“Do not use any access-lists or prefix-lists to accomplish this.”

Another job for the BGP community attribute.  r1 is inside a confederation so we should use local-AS.

r1(config)#route-map TASK_4_5
r1(config-route-map)#set community local-AS

r1(config)#router bgp 65145
r1(config-router)#net 174.1.1.0 ma 255.255.255.0 route-map TASK_4_5
r1(config-router)#neighbor 174.1.145.4 send-comm
r1(config-router)#neighbor 174.1.145.5 send-comm

We see the route in AS 65145:

r4#sh ip bgp 174.1.1.0 255.255.255.0
BGP routing table entry for 174.1.1.0/24, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised outside local AS)
Flag: 0×880
  Not advertised to any peer
  Local
    174.1.145.1 from 174.1.145.1 (150.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, confed-internal, best
      Community: local-AS

We do not see it outside of AS 65145:

r2#sh ip bgp 174.1.1.0 255.255.255.0
% Network not in table

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

August 14, 2008

Internetwork Expert Volume II: Lab 12 – Section 5

Section 5 – Exterior Gateway Routing – 20 Points

5.1 BGP Peering
5.2 BGP Route Reflection
5.3 BGP Origination

Thus begins the monster BGP section.  20 points!  Plus we get to deal with a network in which there is not end-to-end IGP reachability.  WHEE!!!

I drew out my BGPpeering diagram and spotted four possible route-reflectors.  I needn’t have bothered as the next task explicitly pointed them out. :-)  The only twist is that these route-reflectors should not treat each other as clients.

All of these first three tasks were very basic, so I just did them all together.

Because of the broken IGP you’ll need to configure “next-hop-self” for all of the iBGP peerings behind routers with EBGP peerings.

The IE solution for r2 shows a ‘next-hop-self’ statement for the EBGP peering from r2 to BB2.  They do the same thing for the EBGP peering between r6 and BB1 as well as the EBGP peering between sw2 and BB3.  This seems redundant to me.  Watch the network masks (/25) when advertising in VLANs 3 and 33.  That task also asks you to use r2, but that’s a typo as it should be r3.  VLAN 45 is a /29 so watch that one as well.

5.4 BGP Bestpath Selection

Configure AS 200 to affect traffic inbound from AS 100 so that traffic to VLAN 3 goes one route and traffic to VLAN 33 goes another.  If either link fails, use the other as a backup.  Make sure that a third link is not used at all.

Well we’re tasked with affecting inbound traffic by configuring AS 200.  We have two primary options to do this: AS-Path or MED.  Since we are affecting all traffic and AS 200 is the destination AS,  MED is the easier method to use.  We will need to change the MED on two of the three AS border routers and then either crank up the MED to an impossibly high value or just filter the routes (my preference) on the third.

First we need to create prefix-lists for the two VLANs:

Rack16SW1(config)#ip prefix-list VLAN33 permit 129.16.3.128/25
Rack16SW1(config)#ip prefix-list VLAN3 permit 129.16.3.0/25

Then match those prefixes in a route-map and set the metric value accordingly.  In the case of sw1 we want traffic destined for VLAN 3 to prefer this link:

sw1:

Rack16SW1(config)#route-map OUT_TO_SW2
Rack16SW1(config-route-map)#match ip add pre VLAN3
Rack16SW1(config-route-map)#set metric ?
  +/-<metric>     Add or subtract metric
  <0-4294967295>  Metric value or Bandwidth in Kbits per second
  <cr>

Remember that MED = metric and that the LOWER the value, the more preferred that route is.

Rack16SW1(config-route-map)#set metric 1

Now let’s make sure that VLAN33 traffic has a higher (therefore less preferred) MED:

Rack16SW1(config-route-map)#route-map OUT_TO_SW2 permit 20
Rack16SW1(config-route-map)#match ip add VLAN33
Rack16SW1(config-route-map)#set metric 666

Finally, do NOT forget to add an ‘explicit permit’ statement for the rest of the traffic:

Rack16SW1(config-route-map)#route-map OUT_TO_SW2 permit 1000

Our route-map now looks like this:

route-map OUT_TO_SW2 permit 10
 match ip address prefix-list VLAN3
 set metric 1
!
route-map OUT_TO_SW2 permit 20
 match ip address VLAN33
 set metric 666
!
route-map OUT_TO_SW2 permit 1000

We can configure r1 the same way, but just flip the metric values so the VLAN 33 is prefered.

Finally we just need to add the route-map to the neighbor statement:

Rack16SW1(config-route-map)#router bgp 200
Rack16SW1(config-router)#nei 129.16.78.8 route-map OUT_TO_SW2 out

Next we need to make meet the last requirement:

“The Frame Relay circuit between r2 and r4 should not be used as a transit path for either of these destinations.”

We just need to make sure that these two VLANs are not advertised out this link:

Rack16R2(config)#ip prefix-list VLAN33 permit 129.16.3.128/25
Rack16R2(config)#ip prefix-list VLAN3 permit 129.16.3.0/25
Rack16R2(config)#route-map OUT_TO_R4 deny 10
Rack16R2(config-route-map)#match ip add pre VLAN33
Rack16R2(config-route-map)#route-map OUT_TO_R4 deny 20
Rack16R2(config-route-map)#match ip add pre VLAN3
Rack16R2(config-route-map)#route-map OUT_TO_R4 permit 1000
Rack16R2(config-route-map)#router bgp 200
Rack16R2(config-router)#neigh 129.16.124.4 route-map OUT_TO_R4 out

The IE solution guide got fancy with a prefix list that matched both networks with a single line:

ip prefix-list VLANS_3_33 seq 5 permit 129.16.3.0/24 ge 25 le 25

Good to know and understand, but not required for this task.

Verification:

Rack16R6#trace 129.16.3.3

Type escape sequence to abort.
Tracing the route to 129.16.3.3

  1 129.16.46.4 4 msec 0 msec 0 msec
  2 129.16.45.5 4 msec 4 msec 0 msec
  3 129.16.58.8 4 msec 4 msec 4 msec <-sw2
  4 129.16.78.7 0 msec 4 msec 4 msec <-sw1

  5 129.16.17.1 [AS 200] 20 msec 20 msec 20 msec
  6 129.16.13.3 36 msec *  32 msec

Rack16R6#trace 129.16.3.133

Type escape sequence to abort.
Tracing the route to 129.16.3.133

  1 129.16.46.4 0 msec 4 msec 4 msec
  2 129.16.124.1 28 msec 32 msec 28 msec <-FR link between r1 and r4
  3 129.16.13.3 44 msec *  40 msec

Note that the route via r2 is not available:

Rack16R4#sh ip bgp 129.16.3.0 255.255.255.128
BGP routing table entry for 129.16.3.0/25, version 29
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0×4940
  Advertised to update-groups:
     2          3
  200
    129.16.58.8 (metric 2) from 150.16.5.5 (150.16.5.5)
      Origin IGP, metric 1, localpref 100, valid, internal, best
      Originator: 150.16.8.8, Cluster list: 150.16.5.5
  200
    129.16.124.1 from 129.16.124.1 (150.16.1.1)
      Origin IGP, metric 666, localpref 100, valid, external

5.5 BGP Filtering

Configure AS 200 to only route traffic destined for AS 254 (BB2) over the Frame Relay link between r2 and r4.  Do not allow traffic destined for AS 254 from AS 100 to route out any other connections even if the Frame Relay link between r2 and r4 is down.

This means that we need to filter all routes to destinations that have AS 254 in the AS-Path from using r1 and sw1 to enter AS 100.

Since we’re tasked with doing this in AS 100 AND we only want the traffic to AS 254 to use one link regardless of the state of that link, we just need to filter any advertisements with AS 254 in the path outbound on r1 and sw1.

First we need an AS-Path statement matching traffic with AS 254 in the path.  We need to match any AS-Path that contains an instance of ’254′:

Rack16R1(config)#ip as-path access-list 55 permit _254_

Now we need to filter any prefixes that match that AS-Path in a route-map.  We already have an outbound route-map set up for r4:

route-map OUT_TO_R4 permit 10
 match ip address prefix-list VLAN3
 set metric 666
route-map OUT_TO_R4 permit 20
 match ip address VLAN33
 set metric 1
route-map OUT_TO_R4 permit 1000

So let’s just add our deny statement at the beginning of that existing route-map:

Rack16R1(config)#route-map OUT_TO_R4 deny 5
Rack16R1(config-route-map)#match as-path 55

Do the same on sw1:

Rack16SW1(config)#ip as-path access-list 55 permit _254_
Rack16SW1(config)#route-map OUT_TO_SW2 deny 5
Rack16SW1(config-route-map)#match as-path 55

SW2 now routes though r4 rather than sw1 (directly connected):

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

   Network          Next Hop            Metric LocPrf Weight Path
*>i205.90.31.0      150.16.4.4               0    100      0 200 254 ?
*>i220.20.3.0       150.16.4.4               0    100      0 200 254 ?
*>i222.22.2.0       150.16.4.4               0    100      0 200 254 ?

Rack16SW2#trace 222.22.2.1

Type escape sequence to abort.
Tracing the route to 222.22.2.1

  1 129.16.58.5 0 msec 8 msec 0 msec
  2 129.16.45.4 0 msec 0 msec 0 msec
  3 129.16.124.2 34 msec 25 msec 33 msec <-FR link from r4 to r2
  4 192.10.16.254 34 msec *  25 msec

R4 only has these routes via the Frame Relay connection to r2:

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

   Network          Next Hop            Metric LocPrf Weight Path
*> 205.90.31.0      129.16.124.2                           0 200 254 ?
*> 220.20.3.0       129.16.124.2                           0 200 254 ?
*> 222.22.2.0       129.16.124.2                           0 200 254 ?

And of course after all of that….IE uses a different AS-Path statement:

ip as-path access-list 1 permit ^254$

I’m a little confused on this.  This matches any paths where AS 254 is the first AS in the path.  Both solutions provide the same results, but mine does not assume that there will always be only one exit path to AS 254.  I say tomato, IE says tomato.

5.6 BGP Default Routing

Just read the last few lines of this task as the rest may confuse you (as it did me).  You need to configure As 100 do advertise a default route into AS 200 but “send AS 200 a full view along with a default out each BGP connection.”

Well, don’t bite and go for this option:

default-information originate (BGP)

We need to advertise it to our neighbors in AS 200 and we need to include the more specific routes so we want:

neighbor default-originate

Before:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   129.16.78.8                            0 100 54 i
*> 28.119.17.0/24   129.16.78.8                            0 100 54 i
*> 112.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 113.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 114.0.0.0        129.16.78.8                            0 100 54 i
*> 115.0.0.0        129.16.78.8                            0 100 54 i
*> 116.0.0.0        129.16.78.8                            0 100 54 i
*> 117.0.0.0        129.16.78.8                            0 100 54 i
*> 118.0.0.0        129.16.78.8                            0 100 54 i
*> 119.0.0.0        129.16.78.8                            0 100 54 i
*> 129.16.45.0/29   129.16.78.8                            0 100 i
*> 129.16.46.0/24   129.16.78.8                            0 100 i
*> 129.16.58.0/24   129.16.78.8              0             0 100 i

Total number of prefixes 13

Rack16SW2(config)#router bgp 100
Rack16SW2(config-router)#neigh 129.16.78.7 default-originate

After:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                            0 100 i
*> 28.119.16.0/24   129.16.78.8                            0 100 54 i
*> 28.119.17.0/24   129.16.78.8                            0 100 54 i
*> 112.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 113.0.0.0        129.16.78.8                            0 100 54 50 60 i
*> 114.0.0.0        129.16.78.8                            0 100 54 i
*> 115.0.0.0        129.16.78.8                            0 100 54 i
*> 116.0.0.0        129.16.78.8                            0 100 54 i
*> 117.0.0.0        129.16.78.8                            0 100 54 i
*> 118.0.0.0        129.16.78.8                            0 100 54 i
*> 119.0.0.0        129.16.78.8                            0 100 54 i
*> 129.16.45.0/29   129.16.78.8                            0 100 i
*> 129.16.46.0/24   129.16.78.8                            0 100 i
*> 129.16.58.0/24   129.16.78.8              0             0 100 i

Total number of prefixes 14

5.7 BGP Default Routing

Configure sw1 so that the only prefix that it sees from AS 100 is the default route.

“Additionally, ensure that sw1 is the most preferred exit point out of AS 200 for a prefix that no other device in AS 100 has a longer match for.”

Okay…so we need to filter all routes from sw2(AS 100) except for the default route. We also need to make sure that AS 200 prefers our default route over the ones advertised to r1 and r2.

First things first.  Let’s write a prefix-list to match the default route:

Rack16SW1(config)#ip prefix-list DEFAULT permit 0.0.0.0/0

Now let’s filter everything except this route from sw2:

Rack16SW1(config)#route-map IN_FROM_SW2
Rack16SW1(config-route-map)#match ip add pre DEFAULT

We might as well address our last requirement at this point.  We need to affect outbound traffic from AS 200 to prefer this default route.  We have a choice of Weight or Local Preference to do this.  Since we are limited to configuring sw1 and we need to affect all of AS 200 only we need to use local_pref.  We just need to set the local-preference for this default route to a high value (higher than the default of 100 at least):

Rack16SW1(config-route-map)#set local-preference 666666

Now we just need to apply this route map inbound from sw2:

Rack16SW1(config-route-map)#router bgp 200
Rack16SW1(config-router)#neighbor 129.16.78.8 route-map IN_FROM_SW2 in

Verify:

Rack16SW1#sh ip bgp neigh 129.16.78.8 route | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                            0 100 i

R1 prefers the default route to sw1 over the default route it learns from EBGP peer r4 and iBGP peer r2:

Rack16R1#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 36
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0×840
  Advertised to update-groups:
     1          3
  100
    129.16.124.4 from 129.16.124.4 (150.16.4.4)
      Origin IGP, metric 0, localpref 100, valid, external
  100, (Received from a RR-client)
    129.16.17.7 from 129.16.17.7 (150.16.7.7)
      Origin IGP, metric 0, localpref 666666, valid, internal, best

5.8 BGP Bestpath Selection

Configure AS 200 so that it will only send traffic out the Frame Relay circuit between r2 and r4 that is destined for AS 100 and it’s directly connected customers.

“Configure this filtering in such a way that it can account for an arbitrary amount of new customers that may be connected to AS 100 int the future.”

All of this means that we need to write as AS-Path statement that will match paths that start with AS 100 and can have exactly one more AS in the path.  Ugh.

Well we know that we need to match for ^100 and x$.  This is where it helps to know where to find the documentation for regular expressions.

Here’s what I came up with:

ip as-path access-list ^100_[0-9]*_$

This seemed to work:

Rack16SW1#sh ip bgp reg ^100_[0-9]*_$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                666666      0 100 i
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i129.16.45.0/29   129.16.17.1              0    100      0 100 i
*>i129.16.46.0/24   129.16.17.1              0    100      0 100 i
*>i129.16.58.0/24   129.16.17.1              0    100      0 100 i

IE came up with ^100(_[0-9]+)?$

Rack16SW1#sh ip bgp reg ^100(_[0-9]+)$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i

I guess that I read the requirements wrong as I thought that we needed to include traffic destined for AS 100 AND AS 100 plus one more AS.

DOH!!!  Those of you with a keen eye will see where I fucked up.  I pasted in the IE regular expression.  If you look at my command you’ll notice that the question mark is missing.  You need to use ‘control+v’ to insert a question mark.  Here’s what the output should look like:

Rack16SW1#sh ip bgp reg ^100(_[0-9]+)?$
BGP table version is 39, local router ID is 150.16.7.7
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          129.16.78.8                666666      0 100 i
*>i28.119.16.0/24   129.16.17.1              0    100      0 100 54 i
*>i28.119.17.0/24   129.16.17.1              0    100      0 100 54 i
*>i114.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i115.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i116.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i117.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i118.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i119.0.0.0        129.16.17.1              0    100      0 100 54 i
*>i129.16.45.0/29   129.16.17.1              0    100      0 100 i
*>i129.16.46.0/24   129.16.17.1              0    100      0 100 i
*>i129.16.58.0/24   129.16.17.1              0    100      0 100 i

There’s a nice breakdown on how they came up with this regular expression.

We just need to use a filter-list inbound on r2 to make the magic happen:

Rack16R2(config)#ip as-path access-list 58 perm ^100(_[0-9]+)$
Rack16R2(config)#router bgp 200
Rack16R2(config-router)#neigh 129.16.124.4 filter-list 58 in

“This link should still be able to be used to send traffic out to AS 100 if there are no longer matches throughout the BGP domain, but should only be preferred as a default exit point if sw1′s connection to AS 100 is down.”

All this is saying is that we should leave the default route to AS 100 alone (we already configured the AS 200 to prefer the default route to sw2).

5.9 BGP Bestpath Selection

At this point I was sick to death of BGP.  Only two more tasks to go:

I had a hell of a time deciphering this mess.  I think that we just need to make sure that the default route that r1 is learning from r4 is only used if the link between sw1 and sw2 as well as the link between r2 and r4 are down.  This seems like it should be as simple as setting the local-preference on the default to be less than those two links.  sw1-sw2 has a local-preference of 666666 and r2-r4 has the default of 100, so we just need to configure the default on r1 to a value less than 100.

Rack16R1(config)#ip prefix-list DEFAULT perm 0.0.0.0/0
Rack16R1(config)#route-map IN_FROM_R4
Rack16R1(config-route-map)#match ip add DEFAULT
Rack16R1(config-route-map)#set local 50
Rack16R1(config-route-map)#route-map IN_FROM_R4 perm 1000
Rack16R1(config-route-map)#router bgp 200
Rack16R1(config-router)#neigh 129.16.124.4 route-map IN_FROM_R4 in

This is similar to task 5.7 except that we want to allow in all of the routes, not just the default route.  That’s why we need to add the ‘explicit permit’ line in the route-map.

5.10 BGP Aggregation

Last BGP task!!!

Configure BGP summaries to the three BB routers, but don’t let any of your devices see these summaries.

Since there are no loopback prefixes currently advertised into BGP, we need to advertise those in:

Rack16R2(config-router)#net 150.16.0.0 mask 255.255.0.0

There’s no requirement about “no overlapping address space” so let’s just advertise a /16 for the devices and another for the loopbacks.  Should we use ‘summary-only’?  I’m not sure:

Rack16R2(config-router)#aggregate-address 150.16.0.0 255.255.0.0
Rack16R2(config-router)#aggregate-address 129.16.0.0 255.255.0.0

Now we need to set up filtering so that our other BGP peers do not see these summaries.  First write prefix-lists to match the summaries:

Rack16R2(config)#ip prefix-list INTERNAL permit 150.16.0.0/24
Rack16R2(config)#ip prefix-list INTERNAL seq 10  permit 129.16.0.0/24

Now write a route-map (r2 will be a special case as there is already an existing route-map outbound to r4 – just add a deny statement to that map):

Rack16R2(config)#route-map FILTER_AGGREGATE deny 10
Rack16R2(config-route-map)#match ip add INTERNAL
Rack16R2(config-route-map)#route-map FILTER_AGGREGATE permit 1000

On r2:

Rack16R2(config)#route-map OUT_TO_R4 deny 30
Rack16R2(config-route-map)#match ip add INTERNAL

Finally just add the route-map to a neighbor statement outbound for each peer (other than the BB):

Rack16R2(config-router)#neighbor 129.16.23.3 route-map FILTER_AGGREGATE out

I’ll have to review how to advertise a summary in BGP.  I thought that the network needed to be in the BGP table before you could advertise it as an aggregate.  Obviously, this in not the case:

IE method (sans loopback advertisement):

Rack16R6#sh ip bgp neigh 54.16.1.254 adv | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 129.16.0.0       0.0.0.0                            32768 i
*>i129.16.3.0/25    129.16.58.8              1    100      0 200 i
*>i129.16.3.128/25  129.16.46.4              1    100      0 200 i
*>i129.16.17.0/24   129.16.46.4              1    100      0 200 i
r>i129.16.45.0/29   129.16.46.4              0    100      0 i
r>i129.16.46.0/24   129.16.46.4              0    100      0 i
r>i129.16.58.0/24   129.16.58.8              0    100      0 i

Total number of prefixes 7

My method:

Rack16R6#sh ip bgp neigh 54.16.1.254 adv | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 129.16.0.0       0.0.0.0                            32768 i
*>i129.16.3.0/25    129.16.58.8              1    100      0 200 i
*>i129.16.3.128/25  129.16.46.4              1    100      0 200 i
*>i129.16.17.0/24   129.16.46.4              1    100      0 200 i
r>i129.16.45.0/29   129.16.46.4              0    100      0 i
r>i129.16.46.0/24   129.16.46.4              0    100      0 i
r>i129.16.58.0/24   129.16.58.8              0    100      0 i

Total number of prefixes 7

I’m also not sure why the 150.16.0.0/16 summary is not being advertised to this backbone router.  Oh well.  Too much BGP. 

I’ll revisit this later.

Internetwork Expert Volume II: Lab 12 – Section 6

Section 6 – IP Multicast – 8 Points

6.1 PIM

I doesn’t get any easier than this.  You’re asked to configure dense mode on specific interfaces.

6.2 Multicast Distribution

Users in VLAN 22 want access to a video feed on 225.25.25.25 (using UDP port 31337) from VLAN 17. For some reason (most likely because PIM is not configured on r3′s s1/3 :-)  ) r3 is not passing this traffic to r2.  Configure the network so that the users can receive traffic from this group.

“Do not enable PIM on any additional interfaces to accomplish this.”

Fuck.  There goes the easy solution.

This has me stumped.  The multicast path from VLAN 17 to VLAN 12 is broken at r3. Is there a way to change this traffic to unicast or broadcast traffic?  Yup.  :-)

ip multicast helper-map

To allow IP multicast routing in a multicast-capable internetwork between two broadcast-only internetworks, use the ip multicast helper-map command in interface configuration mode.

Configuring an Intermediate IP Multicast Helper Between Broadcast-Only Networks

r3:

Rack16R3(config)#ip access-list ex TASK_6_2
Rack16R3(config-ext-nacl)#permit udp any any eq 31337
Rack16R3(config)#ip forward-protocol udp 31337

Rack16R3(config)#int s1/3
Rack16R3(config-if)#ip directed-broadcast

Rack16R3(config)int s1/2
Rack16R3(config-if)ip multicast helper-map 225.25.25.25 129.16.23.255 TASK_6_2

r2:

Rack16R2(config)#ip forward-protocol udp 31337
Rack16R2(config)#ip access-list ex TASK_6_2
Rack16R2(config-ext-nacl)#permit udp any any eq 31337

Rack16R2(config-ext-nacl)#int s0/1
Rack16R2(config-if)#ip multicast helper-map broadcast 225.25.25.25 TASK_6_2

There are a lot of verification commands in the solution guide, but nothing as far a breakdown.

6.3 Static RP

Well you didn’t think that we were going to get away with just running dense-mode on three devices did you?  This task has you set up a pim-spare multicast network in the OSPF half of the network.

The weird bit is that we have to create loopback 1 on r4 and r5 and then give them the same address and advertise them into OSPF.

Then we need to configure r6 to use r4′s loopback 1 as the RP and sw2 to use r5′s loopback 1 as the RP.  If either should fail, then they should switch over to the other loopback 1 as the RP.  Remember, these loopbacks have the same /32 address.

Enter a command I’ve never heard of before”

ip msdp peer

To configure a Multicast Source Discovery Protocol (MSDP) peer, use the ip msdp peer command in global configuration mode.

Rack16R5(config)#ip msdp peer 150.16.4.4 connect-source lo0
Rack16R4(config)#ip msdp peer 150.16.5.5 connect-source lo0

Aug 12 14:05:14.346: %MSDP-5-PEER_UPDOWN: Session to peer 150.16.5.5 going up

After that bit is configured, just statically map your RP’s on r6 and sw2:

Rack16R6(config)#ip pim rp-address 150.16.0.255
Rack16SW2(config)#ip pim rp-address 150.16.0.255

Rack16R4#sh ip msdp peer
MSDP Peer 150.16.5.5 (?), AS 100
  Connection status:
    State: Up, Resets: 0, Connection source: Loopback0 (150.16.4.4)
    Uptime(Downtime): 00:00:37, Messages sent/received: 0/1
    Output messages discarded: 0
    Connection and counters cleared 00:00:37 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Input queue size: 0, Output queue size: 0

Rack16R4#sh ip msdp summary
MSDP Peer Status Summary
Peer Address     AS    State    Uptime/  Reset SA    Peer Name
                                Downtime Count Count
150.16.5.5       100   Up       00:01:05 0     0     ?

Rack16R6#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
    RP: 150.16.0.255 (?)

Rack16SW2#sh ip pim rp mapp
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
    RP: 150.16.0.255 (?)

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

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).

Next Page »

The Rubric Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 109 other followers