Bridging the gap between CCIE RS and SP

May 14, 2010

INE TE challenge – OSPF Unequal cost loadbalancing

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

May 8, 2010

Dynamips/Dynagen NET files for IPX SP workbooks

Filed under: CCIE, CCIE SP, dynagen, dynamips — 21500 @ 6:17 pm

Another item to scratch from my “to do” list. I built them before the Vol2 and Vol3 merge and not sure what changed to the topologies if any. If you are using the post-merge workbook I ‘assume’ that you will need to switch between the two .net files depending on the lab.

Here they are:
Dynamips / Dynagen NET file for IPexpert SP workbook vol1 and vol3
Dynamips / Dynagen NET file for IPexpert SP workbook vol2

Note they were built on linux, which gave me the best results, therefore to use them on MS, you’ll need to edit the file and change the directories e.g /dyn/images/ to c:\dyn\images\

Please leave a comment if you find a bug.

April 23, 2010

The best way to predict your future is to create it

Filed under: CCIE, CCIE SP — 21500 @ 10:56 pm

Well, I have been away from studying for two and a half months. It is hard to believe that time went by so quick. Time is one of the most mysterious things, one day you are preparing for a lab the next two years have passed. The last two months have been hectic, both at work with projects and becoming a dad. That was and still is an awesome experience and would not have traded it for two ccie’s. The little one is a month old today, this earmarks a new era for us, no more extended quality dad time for hopefully only a few short months (see quote 6). Need to roll up the sleeves and ‘make’ time, this is not going to be easy. In fact this is going to be hard, I wont hold it against the family if I am not awarded dad of the year this year. This is where I really appreciate my supporting wife. I have a new found respect for CCIE’s that did the journey with little ones in the house.

When coming out of a study slump I often first need to get myself motivated. I actually enjoy this part. I usually start meditating about what I want to achieve and why, some music might be involved and would probably start with something depressing like Scorpions – ‘Winds of change’ and end up with Bon Jovi – ‘Its my life’, perhaps even proclaiming “Aint gonna be just a face in the crowd!”. Some motivational quotes work to get the meditation going and by the way motivational posters dont work :)

I made a list of some quotes I read tonight that struck a cord:

1. “The best way to predict your future is to create it.” Unknown
2. “Success doesn’t come to you, you go to it.” Marva Collins
3. “Motivation is a fire from within. If someone else tries to light that fire under you, chances are it will burn very briefly. ” Stephen R. Covey
4. “Where the heart is willing, it will find a thousand ways. Where it is unwilling, it will find a thousand excuses.” Arlen Price
5. “Motivation is what gets you started. Habit is what keeps you going.” Jim Ryun
6. “You will never find time for anything. If you want time you must make it. ” Charles Buxton
7. “Will you look back on life and say, “I wish I had,” or “I’m glad I did”?” Zig Ziglar
8. “The only goal you can’t accomplish is the one that you don’t go after!” Vilis Ozols
9. “When you shoot for the moon and you come up short, you still end up among the stars.” Les Brown
10. “What the mind can conceive and believe, it can achieve.” Napoleon Hill
11. “Luck favors momentum.” Unknown
12. “Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful.” Albert Schweitzer
13. “A journey of a thousand miles must begin with a single step.” Chinese Proverb
14. “The belief in a thing makes it happen.” Frank Lloyd Wright
15. “Enthusiasm spells the difference between mediocrity and accomplishment.” Norman Vincent Peale
16. “In the confrontation between the stream and the rock, the stream always wins not by strength but by perseverance.” H. Jackson Brown
17. “When a man is willing and eager, the gods join in.” Aeschylus
18. “Always make a total effort, even when the odds are against you.” Arnold Palmer
19. “Success isn’t how far you got, but the distance you traveled from where you started.” Proverb
20. “Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great,” Mark Twain

Next a strategy is needed on how much time to spend on labs and theory. I will probably spend more time reading than working through actual labs as I can cover more ground this way to refresh all the grey matter. A few days before the lab I will work through some full-scale labs and focus on speed. If the SP seats continue to be available as they are at the moment, I think this is a good season to put this one to bed.

February 1, 2010

BGP fast-external-fallover – Common confusion

Filed under: CCIE, CCIE SP — 21500 @ 1:01 pm

Most will know the feature and what it does, but to recap the process level command:

R5(config-router)#bgp fast-external-fallover

R5(config-router)#no bgp fast-external-fallover

This feature will enable fast fallover in the event of a link failure for all neighbors peers. In layman terms shutdown the bgp neighbor as soon as the interface reset is detected and not wait for the holddown timer to expire.

Then the interface command:

R5(config-if)#ip bgp fast-external-fallover permit

R5(config-if)#ip bgp fast-external-fallover deny

This is used to overwrite the process level command. Therefore if the feature is enabled under the bgp process, which is on by default, and a specific client interface is flapping frequently, the interface level command can be used to keep the client peer from flapping due to the fast-fallover and prevent upstream peers from dampening the client routes. Fast-fallover is important in multihomed scenarios where it is useful to shut the neighbor as soon as possible in order to avoid packet drops.

But the real reason for this post is that I have seen this a couple of times configured in both (RS) INE and (SP) IPX workbooks with the incorrect interface level command:

R5(config-if)#no ip bgp fast-external-fallover

This will have no effect, except removing previous fast-fallover config. Beware of this common confusion between the two syntaxes. The correct interface level configuration is to use permit or deny.

January 30, 2010

Old habits: Soft-Reconfiguration

Filed under: CCIE, CCIE SP — 21500 @ 9:37 am

While on the subject of old habits, I had to mention this one. I remember back when studying for CCNA and maybe even CCNP that it was always recommended to configure soft-reconfiguration in order to propagate route policy updates/changes without hard resetting the bgp neighbor. This is one of those things that sometimes just becomes routine, a habit, something that is just pasted into new configs and forgotten about. Well it might be time to shake this one off as well.

In brief terms the soft-reconfiguration command will allow a ’soft’ reset. The tcp session between the two bgp peers will not be reset but new policy changes will take effect. E.g, a new route-map filter is applied. Therefore a way to cause minimal damage to overall stability of the network.

A decade or so ago RFC 2918 Route Refresh for BGP-4 September 2000 was published which made the soft-reconfiguration redundant. Two bgp peers that support the route refresh capability can implement a soft reset without any preconfiguration. In order to determine whether a peer support this capability:

show ip bgp nei 11.11.7.11
BGP neighbor is 11.11.7.11,  remote AS 11, external link
BGP version 4, remote router ID 150.140.130.120
BGP state = Established, up for 00:03:27
Last read 00:00:27, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)

Extract from: http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfbgp.html#wp1001128

To use soft reset without preconfiguration, both BGP peers must support the soft route refresh capability, which is advertised in the OPEN message sent when the peers establish a TCP session. Routers running Cisco IOS software releases prior to Release 12.1 do not support the route refresh capability and must clear the BGP session using the neighbor soft-reconfiguration router configuration command. Clearing the BGP session in this way will have a negative impact upon network operations and should only be used as a last resort.

Table 8 Advantages and Disadvantages of Hard and Soft Resets
Type of Reset Advantages Disadvantages
Hard reset No memory overhead. The prefixes in the BGP, IP, and Forwarding Information Base (FIB) tables provided by the neighbor are lost. Not recommended.
Outbound soft reset No configuration, no storing of routing table updates. Does not reset inbound routing table updates.
Dynamic inbound soft reset Does not clear the BGP session and cache.

Does not require storing of routing table updates, and has no memory overhead.

 Both BGP routers must support the route refresh capability (in Cisco IOS Release 12.1 and later releases).
Configured inbound soft reset (uses theneighbor soft-reconfiguration router configuration command) Can be used when both BGP routers do not support the automatic route refresh capability. Requires preconfiguration.

Stores all received (inbound) routing policy updates without modification; is memory-intensive.

Recommended only when absolutely necessary, such as when both BGP routers do not support the automatic route refresh capability.

Now what does this really mean to you and me? The memory consumption used by soft-reconfiguration since all routes from a neighbor with soft-reconfig configured will be stored in memory. For example a peer might send a full table but the router is filtering all neighbor AS and neighbor client AS’s. Although only a few thousand routes might be inserted into the bgp table from this neighbor, the router still has to keep the remaining 200k+ routes in memory. If the router has a couple on these peers, it will probably not scale well. By relying only on the route refresh feature, the router will be able to scale to far more peers.

In an enterprise environment with less routes, an old 3600 might still be active in the BGP routing domain and become unstable due to running out of memory. Removing the legacy “soft-reconfiguration” configuration might be the healing touch it needs.

January 15, 2010

Autonegotiate – The debate continues

Filed under: CCIE SP — 21500 @ 11:14 pm

The saying, old habbits die hard holds true to this one. Quite a while ago I read an article by Greg Ferro regarding the force speed and duplex myth. Today I stumbled on Terry Slattery’s blog regarding the same “autonegotiate duplex or not“ topic. For those that dont know Sir Slattery, he is practically CCIE#1. Yes, the first man on the moon. While I accept each person has his own opinion based on past experience, consider reading these two posts with an open mind.

The fundamental problem I have with the “Force All” practice is the administrative overhead with duplex mismatching. I found that problems caused due to this practice out weigh the problems solved by 100:1, in fact it might be more. Besides the network overhead there is also the system administrative overhead as forcing needs to happen on both sides or in a LAN scenario the helpdesk overhead when a techinician needs to force settings on all workstations.

Problems happen when ports are forced in order to make them shut up and stay up. I could compare this to a situation where my wife indirectly complains I am spending too much time preparing for the next CCIE, I could just put the head phones on and ignore the warning message. But this does not solve the problem and it might make it worse by making it harder to determine when I have pushed the issue beyond its limits. If ports are not agreeing on a speed and duplex, 99.9% of the time it can be solved by asking the following two questions?

1) Are both sides are auto/auto? Should be standard practice and you will have a happy network.

2) The Autonegotiation principle is based on electrical signal pulses with micro second (µs) tolerances.  Are the signals received within the required threshold? If not, why not? Quality layer 1 will determine the quality of the layers above.

This raise some thoughts:
How old are the cables? How old is the Datacenter? Something that I hardly ever hear of is the lifespan of UTP cables. While manufactures will today punt a 20+ year lifespan on CAT5e, I personally believe UTP cables from the 90’s should be phased out. Where possible, do not re-use patch leads as they are often the culprits. Patching and repatching puts additional wear and tear on the cable/connectors. All good quality UTP cable has the manufacturing date printed almost every meter. Check the manufacture dates of the patch leads, more than 5 years? Tie a knot in it. Check the cable standard, recently I discovered a 1000Mb link issue due to a Cat5 cable (rated 100mb) being used. Only use at a minimum Cat5e.

The negative effects of forcing speeds is that the shut up and stay up effect does exactly that. The autonegotiation process especially on 1000Mb links is fundamental to fast fail over detection and error signaling. When troubleshooting something as simple as packetloss on a Gb link with both sides forced is difficult to determine whether the problem is at the physical layer. This is since only a fraction of errors and CRC’s are logged. Removing the settings will most likely display a more realistic error count. This is not specific to GB ports, I have seen this on 100mb links as well.

The fundamental flaw with forcing speed and duplex, besides the technical aspects mentioned above, is that everyone has to follow this religion vigorously.

December 30, 2009

BGP Best Path Selection Process

Filed under: CCIE, CCIE SP — Tags: , , — 21500 @ 9:18 am

One of those topics that is really fundamental to passing Cisco exams and labs or more importantly, predicting the behavior of BGP, is knowing the BGP route selection process well.
Following is a summary for quick reference.

1. Next_Hop: The next hop of the BGP route has to be in the routing table else if it is unreachable, the route is ignored.
2. Pre-bestpath Cost: If the pre-bestpath cost attribute is present, choose the route with the lowest cost value, if they are the same, the lowest community.
3. Weight: Cisco proprietary, local significant attribute where the largest is prefered.
4. Loc_Pref: If the weights are the same, choose the path with the highest local preference.
5. Local Originated: Routes that were locally originated with network statement, aggregated or redistributed.
6. AS_PATH: Next compare the as-path length and prefer the route with the shortest AS_PATH length.
7. ORIGIN: Choose the route with the lowest origin type if the AS_PATH lengths are the same. IGP<EGP<INCOMPLETE
8. MED: If the origin types are the same, choose the route with the lowest MED value. This will only be compared for routes from the same AS or if bgp always-compare-med is enabled, for all routes.
9. EBGP/iBGP: Prefer EBGP routes over IBGP routes if the routes have the same MED value.
10. IGP: At this point if there are still multiple routes prefer the route with the shortest route to the NEXT_HOP. The IGP will have already determined the shortest path to the next-hop.
11. Cost: If the cost attribute is present not configured to be ignored, choose the lowest cost.
12. Multipath: If multipath is enabled, multiple paths that match up to this point will be installed.
13. Oldest: If multiple external routes remain, choose the oldest one, thus avoids propagating a flapping route. To overwrite this, this step can be ignored with bestpath compare router-id.
14. Router_ID: If multiple routes still exist, the BGP ROUTER_ID will be a tiebreaker. Choose the route advertised by the BGP peer with the lowest Router_ID. If RR present, the originator ID is used.
15. Cluster Length: Minimum RR cluster length is compared next.
16. Lowest Neighbor: Last, the path from the lowest neighbor address.

Richard Bannister made a great post on the topic that in detail illustrates the algorithm in a flow-chart:
http://rbcciequest.wordpress.com/2008/02/27/bgp-path-selection/

And then there is the well known Cisco documentation:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

Preview of Richard Bannister’s flow-chart:
Bgp best path flow-chart

BGP scan-time

Filed under: CCIE, CCIE SP — Tags: , , — 21500 @ 8:18 am

BGP scanner process monitors the next hop of installed routes to verify next-hop reachability. It is also responsible to select, install, and validate the BGP best path. By default, the BGP scanner is used to poll the RIB for this information every 60 seconds. During the 60 second time period between scan cycles, Interior Gateway Protocol (IGP) instability or other network failures can cause black holes and routing loops to temporarily form.

BGP scan process is also responsible for the checks to determine whether the conditional advertisement should or should not advertise the conditional route. It also checks whether route dampening information needs to be updated.

bgp scan-time

There is also a VPN4 equivalent that is configured under the VPN4 address family and the syntax is slightly different. By default it runs every 15 seconds.

bgp scan-time import

Also see:
http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_adv_features_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1056233
http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/VPN_EN.html#wp1045721

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 7, 2009

Dynamips to real switches with QinQ support

Filed under: CCIE, CCIE SP, dynagen, dynamips — Tags: , , — 21500 @ 3:41 pm

There is an unbelievable amount of junk on the net that can send one in all the wrong directions. When it comes to dynamips it is no different and it seems everyone has a different opinion on what works and what does not. It probably depends on the OS dynamips runs on and the alignment of the moon and the stars. For me the best solution thus far was to run Dynamips on Ubuntu Linux server edition. The reasons for this is due to the 100Mb memory Ubuntu server consumes to run the OS as well as the stability and responsiveness of Dynamips on linux. It has worked well.

To break out to real switches I started with the multiple USB adapter approach. Basically you map each USB to Ethernet adapter to a router ethernet port in the dynagen net file. Sounds simple, and while it is, the USB approach for me turned out to be unreliable. It would work, then it would not. This plus the hassle with using USB adapters from different vendors and drivers just becomes messy.

After more research I tried the “switch in the middle” method. This is by far the easiest, quickest, cleanest and most reliable route:

Overview:
So you are probably already using dynamips to run the routers. To break out the first thing is to create a trunk between your linux server and a breakout switch. Then create a bunch of vlans on the linux server. One for every port that will connect to real switches e.g. if R2 needs to connect to the real switches with Fa0/0 and Fa0/1, create two vlans for this router. In the dynagen net file map each ethernet port to the vlan ’sub interfaces’ which were created when the vlans were created. Create the same vlans on the breakout switch that were created on the server. Assign each access port that will link to the real switches into a different vlan. Each access port on the breakout switch now represents a router port e.g. fa0/6 in vlan 106 on the breakout switch represents router R6 fa0/0 interface which connects to Sw2 fa0/6.

Requirements:
1) A second network card
2) The vconfig utility.

apt-get install vlan

3) Kernel that will support Dot1q

modprobe 8021q

4) A breakout switch. Try to stick with a Cisco switch.
5) If you want to support QinQ / dot1q-tunnel, the breakout switch needs to support QinQ tunneling

Steps:
1) Create a trunk between your linux server and another switch that will become the switch in the middle or breakout switch.
2) Create the required vlans on the server. Or use the following script to do steps 1 and 2.

#!/bin/bash
#############
# vlansetup.sh
# http://21500.net
#############

#### Enable Dot1q support
modprobe 8021q

#### Set the ethernet MTU
ifconfig eth1 mtu 1536

#### Create the Vlans
vconfig add eth1 101
vconfig add eth1 102
vconfig add eth1 103
vconfig add eth1 104
vconfig add eth1 105
vconfig add eth1 106
vconfig add eth1 107
vconfig add eth1 108
vconfig add eth1 109
vconfig add eth1 110
vconfig add eth1 111
vconfig add eth1 112
vconfig add eth1 113
vconfig add eth1 114
vconfig add eth1 115
vconfig add eth1 116
vconfig add eth1 117
vconfig add eth1 118
vconfig add eth1 119
vconfig add eth1 120
vconfig add eth1 121
vconfig add eth1 122
vconfig add eth1 123

#### Bounce the interface
ifconfig eth1 down
ifconfig eth1 up

3) Configure the trunk on the breakout switch

interface fastethernet 0/24
switchport trunk encapsulation dot1q
switchport mode trunk

4) Assign the Access ports their vlans

!
interface fastethernet 0/1
switchport access vlan 101
switchport mode access
!
interface fastethernet 0/2
switchport access vlan 102
switchport mode access
!
interface fastethernet 0/3
switchport access vlan 103
switchport mode access
!
interface fastethernet 0/4
switchport access vlan 104
switchport mode access
! …
! …
! …
interface fastethernet 0/23
switchport access vlan 123
switchport mode access
!

5) If you want to support QinQ and CDP between the virtual routers and the real switchs, your breakout switch needs to support QinQ. Enable a dot1q tunnel on each interface.

interface range fastethernet 0/1 – 23
switchport mode dot1q-tunnel
l2protocol-tunnel cdp

6) Map the ports in the dynagen .net file

[[ROUTER R1]]
f0/0 = NIO_linux_eth:eth1.101
f0/1 = NIO_linux_eth:eth1.103
[[ROUTER R2]]
f1/0 = NIO_linux_eth:eth1.102

7) Connect the switches to the breakout switch with crossover cables. In this example Port fa0/1 on the breakout switch represents Fa0/0 on R1 and connects to Sw1 Fa0/1.

R1 Fa0/0 -> BSw Fa0/1 -> SW1 Fa0/1
R2 Fa1/0 -> BSw Fa0/2 -> SW1 Fa0/2
R1 Fa0/1 -> BSw Fa0/3 -> SW2 Fa0/1

Once I got this working I found that someone already did the hard work. Wish I saw this much earlier. The only difference between the two methods is that I used one breakout switch while MrPaul’s method uses the Dynamips switches and the breakout switch.

HOWTO Connect Real Switches Using One NIC & QinQ

This is the image MrPaul made:

Breakout Switch

Older Posts »

Powered by WordPress