Bridging the gap between CCIE RS and SP

May 14, 2010

INE ospf traffic engineering challenge

Filed under: CCIE, Mini Labs, dynagen, dynamips — 21500 @ 11:38 pm

While browsing blogs, when I should be labbing, I came across INE’s OSPF Traffic Engineering challenge. I normally ignore these because I happen to see them when they usually already expired. Well this one somehow managed to pull me in. Petr has a very valid point, most often real network challenges are fixed with the first, quick and easy solution (or future problem). I know if this was a scenario in our network, static routes would definitely be the prime candidate.

My summarized version of the answer to Petr’s challenge is to use multiple ‘logical’ interfaces or in other words multiple subinterfaces, using only loopbacks for addressing or ip unnumbered loopback, since configuring additional ip addresses were not permitted. After the subinterfaces were configured all what was left to do is then manipulating the ospf cost on the R4-R1 link to 3 and set the maximum ospf paths. The net result: 6 paths to a subnet on R1, 3 going via R1, 2 paths via R3 and 1 path via R5:

Routing entry for 100.100.100.0/24
Known via “ospf 1″, distance 110, metric 4, type intra area
Last update from 3.3.3.3 on Serial1/0.1, 00:00:01 ago
Routing Descriptor Blocks:
* 5.5.5.5, from 1.1.1.1, 00:00:01 ago, via Serial1/3
Route metric is 4, traffic share count is 1
3.3.3.3, from 1.1.1.1, 00:00:01 ago, via Serial1/0.1
Route metric is 4, traffic share count is 1
3.3.3.3, from 1.1.1.1, 00:00:01 ago, via Serial1/0.2
Route metric is 4, traffic share count is 1
1.1.1.1, from 1.1.1.1, 00:00:01 ago, via Serial1/1.2
Route metric is 4, traffic share count is 1
1.1.1.1, from 1.1.1.1, 00:00:01 ago, via Serial1/1.1
Route metric is 4, traffic share count is 1
1.1.1.1, from 1.1.1.1, 00:00:01 ago, via Serial1/1.3
Route metric is 4, traffic share count is 1

The topology from URL above:

I fumbled a quick dynamips config together.

autostart=false

####################
# http://21500.net #
####################

[localhost:7200]

[[3725]]
image = /dyn/images/C3725-adv-ent-mz.124-23.BIN
ram = 160
mmap = true
idlepc = 0×60a8141c

[[Router R1]]
model = 3725
console = 2001
S1/0 = R2 S1/0
S1/1 = R4 S1/1
S1/2 = R5 S1/2
F0/0 = LAN 1

[[Router R2]]
model = 3725
console = 2002
S1/1 = R3 S1/1

[[Router R3]]
model = 3725
console = 2003
S1/0 = R4 S1/0

[[Router R4]]
model = 3725
console = 2004
S1/3 = R5 S1/3

[[Router R5]]
model = 3725
console = 2005

Completed config files if you want to run this minilab and perhaps find some more ways to solve the riddle.

R1.txt
R2,txt
R3.txt
R4.txt
R5.txt

Update: And what do you know, the solution gets the prize :)

June 16, 2009

BGP dmzlink-bw Unequal-cost load-balance

Filed under: CCIE, CCIE SP, Mini Labs, dynagen, dynamips — 21500 @ 9:37 pm

A few months back I made a post regarding the dmzlink-bw feature. Since the post is relatively simple and receive hits daily I decided to make a practical example and post the dynamips/dynagen minilab files. First things first, it is important to know what the feature does. In very brief terms it is a feature that will propagate the link bandwidth of the external links (ebgp) to the ibgp peers via an extended community. What this does is make it possible for the ibgp peers to load balance traffic out the AS in a ratio based on the external link bandwidth value. Imagine a network that reach the limit of fiber or atm links or possibly a scenario where a device run out of routing capacity. In these situations dmzlink-bw could be helpful to load balance traffic out in the ratio based on the configured bandwidth of the external links.

The configuration is straight forward:
1) Enable the feature on the devices that need to consider the bandwidth value (CE1,CE2,C):

bgp dmzlink-bw

2) Enable the feature on the external peer neighbor statements (CE1,CE2):

neighbor ebgp-peer-ip dmzlink-bw

3) Send the extended community to the ibgp peers that need to consider the bandwidth value (CE1,CE2):

neighbor ibgp-peer-ip send-community extended

4) Enable bgp multipath where necessary (CE2,C)

maximum-paths ibgp 2

dmzIn the example I used the SP terms PE,P and CE, but in all practicality it could be any two routing domains with multiple links between them.

  • The three links between the two domains are 100mb, 30mb, 120mb.
  • P, PE1, PE2 are in AS 5
  • C, CE1 and CE2 are in AS 2
  • AS 2 want to make use of unequal load balance to send traffic to AS 5
  • CE1, CE2 and C are configured for bgp dmzlink-bw
  • CE2 is configured to accept two paths.
  • C is configured to accept two paths.
  • CE1 and CE2 send extended communities to C
  • CE2 uses the link bandwidth to load balance over 120mb and 30mb pipes in the ratio 4:1
  • CE2 sends the total bandwidth of the two links to C
  • C use a ratio of 3:2 between CE1 and CE2

The dynagen .net file zipped with the configuration stored in the nvram files can be downloaded here bgp-dmz.zip. AS2 has been preconfigure to do unequal cost load balancing to AS5. The objective of this mini lab is to configure AS5 to unequal cost load balance to AS2. To keep it simple, load balance only to the loopback address on router C.

A quick video to briefly run through the configuration and verification:

May 19, 2009

Initial thoughts on AMSoares scenarios

Filed under: CCIE SP, Mini Labs, dynagen, dynamips — 21500 @ 2:43 pm

I have started with the scenarios, so far so good. I would rather call them practical configuration examples and the best way to use them is probably debatable. Currently I load the configuration example, read the documentation, break it, fix it and then try alternative options.

Word of advice: The net files are setup for Windows, it will take a while to convert them to linux unless you don’t use something like perl or sed to run through and change the strings. Try to get the net files ready early in prep. I used the source of the mini scenario page to get a list of all the .zip files to download. Below is a script that might be useful in changing the .net files. Once the strings are changed, its a matter of point and shoot

#!/bin/bash

### Change directory to where you downloaded the net files
cd /dyn/ams/
### Create a list of net files
list=`find | grep .net | grep -v netflow`
for dir in $list
do
### Change the windows directory structure to linux
sed ’s/g:\\_CCIE\\Emulator\\Dynamips\\images\\c7200-p\.120-32\.S9\.bin/\/dyn\/images\/C7200-p-mz\.120-33\.S3\.bin/g’ < $dir > tmp.file

### Change an idlepc value
# sed ’s/0×60a600a8/0×623bbedc/g’ < $dir > tmp.file

### Move the temp file to the original
mv tmp.file $dir
done

January 13, 2009

Mini Lab – Dynamips version

Filed under: CCIE, Mini Labs — 21500 @ 3:09 pm

I had to take my RS rack down as it was taking up valuable rackspace and I was not going to use it for SP. I am now relying on dynamips to take me through to SP. While Im still learning the dynamips ropes I made a dynamips version of the mini lab, used to conduct the technical interview for a network engineer post.

The dynamips topology is slightly different regarding device names and interface numbers. The initial configs have also been updated and the dynamips .net file is provided:

minilab_dynamips

All files zipped:
Minilab.zip

Initial Configs:
R1
R2
Sw3
Sw4

Dynamips .Net file
Minilab.net

Other related posts:
Mini Lab – Question 1
Mini Lab – Question 2
Mini Lab – Question 3
Mini Lab – Question 4
Mini Lab – Question 5
Mini Lab – Question 6
Mini Lab – Question 7
Mini Lab – Question 8
Mini Lab – Question 9
Mini Lab – Question 10
Solutions based on live rack topology. Update pending:

December 1, 2008

Mini Lab – Summary

Filed under: Mini Labs — Tags: — 21500 @ 3:28 pm

Lab diagram and questions:

Interview Lab

Interview Lab

Initial configs:
R2
R4
Sw3
Sw2

Solution:
Mini Lab – Question 1
Mini Lab – Question 2
Mini Lab – Question 3
Mini Lab – Question 4
Mini Lab – Question 5
Mini Lab – Question 6
Mini Lab – Question 7
Mini Lab – Question 8
Mini Lab – Question 9
Mini Lab – Question 10

Final config:
Sw2

Mini Lab – Question 10

Filed under: Mini Labs — Tags: — 21500 @ 3:09 pm

A tricky question as the destination of the tunnel is unknown and no privilege to see the running configuration on Sw3. One option to determine the destination address:

Rack1SW3> show interface tunnel 0 | in source
Tunnel source 183.0.50.147 (Loopback3), destination 183.0.2.1

Configure the tunnel destination

Rack1SW2(config)#int tunnel 0
Rack1SW2(config-if)#tunnel destination 183.0.50.147

Verify that the tunnel is operational

Rack1SW2#ping 10.0.0.3
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms

Another but less elegant way was to do a ’show ip interface brief’ on Sw3

Mini Labs – Question 9

Filed under: Mini Labs — Tags: — 21500 @ 2:49 pm

The route-map is preconfigured. Only requirement is one line under the EIGRP process to tag all EIGRP routes.

Rack1SW2(config)#router eigrp 2
Rack1SW2(config-router)#distribute-list route-map TAG in

Verify:

Rack1SW2#sh ip route 183.0.50.0
Routing entry for 183.0.50.0/24
Known via “eigrp 2″, distance 90, metric 130816
Tag 4, type internal

Route tag 4

The question is not clear where the tag should be verified. Therefore setting the distribute-list in or out would be correct. Since all the configuration is done on Sw2, in is prefered.

Mini Lab – Question 8

Filed under: Mini Labs — Tags: — 21500 @ 2:34 pm

The keywrod ‘Originate’ or ‘transverse’ should indicate that an AS-path access-list should be used. The restriction should also indicate that the prefered solution should be an AS-path access-list. Also this should only apply to R4 and not R2. The filter should be two statements long:

Rack1SW2(config)#ip as-path access-list 4 deny _4_
Rack1SW2(config)#ip as-path access-list 4 permit .

Deny what originate or transverse AS 4 but permit everything else.

Rack1SW2(config)#router bgp 1
Rack1SW2(config-router)#neighbor 183.0.4.4 filter-list 4 out

Before:

Rack1R4>sh ip bgp | beg Network
Network            Next Hop        Metric      LocPrf        Weight     Path
*>i183.0.20.0/24            183.0.10.10        0        100        0    2 i
*>i183.0.40.0/24        183.0.10.10        0        100      0    2 4 i

After:

Rack1R4>sh ip bgp | beg Network
Network            Next Hop        Metric      LocPrf       Weight     Path
*>i183.0.20.0/24        183.0.10.10        0        100        0    2 i

From R2

Rack1R2>sh ip bgp | beg Network
Network            Next Hop        Metric      LocPrf        Weight     Path
*>i183.0.20.0/24            183.0.10.10        0        100        0    2 i
*>i183.0.40.0/24        183.0.10.10        0        100      0    2 4 i

Mini Lab – Question 7

Filed under: Mini Labs — Tags: — 21500 @ 1:53 pm

Rack1SW2(config)#router bgp 1
Rack1SW2(config-router)#neighbor 183.0.10.10 remote-as 2
Rack1SW2(config-router)#neighbor 183.0.10.10 ebgp-multihop

Verify:

Rack1SW2#sh ip bgp summary | in 183.0.10.10
183.0.10.10      4    2      8      6      3      0      0      00:03:11      2

183.0.20.20 should be reachable from R2 and R4:

Rack1R2>sh ip bgp | beg Network
Network      Next Hop      Metric LocPrf Weight Path
*>i183.0.20.0/24 183.0.10.10      0      100      0 2 i
*>i183.0.40.0/24 183.0.10.10      0      100      0 2 4 i
Rack1R2>ping 183.0.20.20
Sending 5, 100-byte ICMP Echos to 183.0.20.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 ms

Mini Lab – Question 6

Filed under: Mini Labs — Tags: — 21500 @ 1:44 pm

Two requirements: One configure iBGP neighbors and secondly Sw2 must be the router reflector.

Rack1SW2(config)#router bgp 1
Rack1SW2(config-router)#neighbor 183.0.2.2 remote-as 1
Rack1SW2(config-router)#neighbor 183.0.2.2 route-reflector-client
Rack1SW2(config-router)#neighbor 183.0.4.4 remote-as 1
Rack1SW2(config-router)#neighbor 183.0.4.4 route-reflector-client

Verify:

Rack1SW2#sh ip bgp summary
BGP router identifier 183.0.30.30, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor     V    AS    MsgRcvd     MsgSent    TblVer    InQ    OutQ     Up/Down    State/PfxRcd
183.0.2.2    4      1     9      5     1     0      0 00:01:41      0
183.0.4.4    4     1      9     5      1    0      0 00:01:20    0

Older Posts »

Powered by WordPress