If you’d like to share your labs you can do so by following the steps here. Now onto the lab!

RUNNING OSPF ON A NON-BROADCAST MODE
NBMA over FRAME RELAY

•    DEFAULT MODE FOR X.25, FRAME RELAY, AND ATM NETWORK
•    NEIGHBORS ARE STATICALLY CONFIGURED
•    ACTS LIKE A LAN ENVIROMENT NETWORK
•    A DR/BDR MUST BE ELECTED (MUST HAVE FULL CONNECTIVITY)
•    MUST BE ONE SUBNET

NBMA over Frame Relay – Drawbacks
1.    Slow forming neighbors

Routers Used: 7200

IOS: c7200-jk9s-mz.124-13b.bin

Feature of Topology: NBMA, Non-Broadcast Multiple Access, Frame Relay, OSPF

Image:

Download: GNS3-Labs:: NBMA over FRAME RELAY LAB-Angel

Thanks,

Angel Canario

It’s great that you can find an exercise on the internet, whip it up real quick, work on it and share it afterward. It’s amazing how Dynamips/GNS3 allow such capability to lab and work out real world scenarios with little to no effortt.

Thanks for the share Brahadesh! Hope to see more..

Now onto the lab!

-Lenny

Scenario

Here is a little scenario which i came across on this website. Please go through the site to get a better understanding of the Goal of the lab.

http://nil.com/ipcorner/SmallSiteMultiHoming/

However let me give a Brief about the goal of this lab

Remote site has two ISP’s that allow only static routes into them and no routing protocols. Remote site needs to be Connected to the Central site all the time, However Remote site prefers to connect to the central site Via ISP A ( in this case Via R0-R1-R3).But remote site should start using the second path i.e R0-R2-R3 if the main link fails.

Goals

We are using the IP SLA concept to create a tracking object, To Track the IP address 3.3.3.3 ( This can be a server at the central site). Remote site uses Two Public IP addresses provided to it by the Two ISPs. Routers R1 and R2 are the ISPs and R3 is the Central office router. Use natting to translate Private IP space within your network to the Public. For simplicity I use OSPF between R1, R2 and R3 to exchange routes.

1) Configure R0,R1,R2,R3 IP address and Loopbacks

2) Configure OSPF on R1,R2 and R3 make sure the routes are exchanged

3) Configure NATing on R0, You have make use of Route maps to create NAT pools on per interface basis.

4) Configure IP SLA to poll your Central Site( 3.3.3.3) at a set interval of every 3 seconds, and start the polling NOW.

5) Create a track object to track the IP SLA polls

6)Finally create  a delay of  10 seconds when the route goes down and 20 seconds when the link recovers.

7) Create 2 static routes pointing to each ISP, Force the  router to prefer ISP A by influencing the metric.

Attach the static default routes to the Track object to remove them from the routing table if the primary link goes down.

Above are just guidelines, detailed configuration steps can be found on the link given above, or in the attached configs.

Note: I turn off Keep-Alives on the ethernet interface of the Router R0, to fool the router to think it is actually Up. Helps you keep the topology simple.

Forgive me if the IP addressing scheme seems foolish. I created this lab on the fly did not think much about the Ip addressing.

Routers Used: 7200

IOS: c7200-adventerprisek9-mz.124-4.T1.bin (This lab needs IOS version 12.4 or later)

Feature of Topology: IP SLA, Object Tracking, NAT, Route Maps, OSPF

Image:

Download: GNS3-Labs-Small Site Multihoming-Brahadesh

Regards,
Brahadesh

Hi everyone,

GNS3 v0.6.1 is released! this is a minor release that brings some improvements and bug fixes. Nothing really new but now we have a solid base to start making new features. Also the GNS3 binary version for Windows has been repackaged to include python 2.6 and Qt 4.5.1 dlls. A binary version (.app) for MacOS X should be released soon.

Improvements:

• Copy an inserted image in the project’s working directory and update its path in the .net file.
• Prevent auto-generated interface notes to be recorded in the .net file.
• Display an error msg box if a working directory can’t be used by an hypervisor.
• Check if a hostname has already been used when creating a new node.
• Warn to use manual links when a user select a NM-16ESW module.
• Check if GNS3 is running on a Windows 64 bits OS in order to choose the correct path to Putty.
• Check IOS and working directories paths when creating new nodes and throw a warning to the user if something is wrong.
• Button to edit project settings.

Fixes:

• Prevent notes to be deleted when typing the delete key while editing.
• Prevent NM-16ESW modules to be removed from routers when using Ethernet/FastEthernet links.
• Tooltips update when starting/stopping/suspending routers.
• Bug with Qt 4.5 on selected filter when openning a project (getOpenFileName)
• 99MB limit for pcmcia disks.
• Unicode errors with TMP env variable on Windows.
• AttributeError: value of `chassis’ must be of type string.
• Merge correct config paths when loading a .net create on a different platform.

Thanks for your support.
Jeremy

Download the new GNS3 Release! v0.6.1 via GNS3.net

Mirrors

Download the new GNS3 Release! v0.6.1 WINDOWS via UploadHookup

Download the new GNS3 Release! v0.6.1 LINUX via UploadHookup

Enjoy!

LBS

Scenario

We have a router connected to the ISP with two WAN connections:

- a Bronze link, with little bandwidth, on which we have a /30 subnet;
- a Gold link, with good performances, on which we have a /30 point-to-point subnet and an additional /24 routed subnet.

Note that ISP does not accept inbound traffic coming from a subnet that is not the one routed through the ingress interface: for example, we can’t send traffic from 1.1.1.0/24 out the Bronze link. One subnet, one link.

Objectives

Our goals are:

- users on the LAN need access to Internet;
- mission critical traffic has to go out through the Gold link;
- our servers have to be reachable from the outside on their public IP addresses.

For the sake of simplicity, in our example and lab mission critical traffic will be telnet traffic. In real life it can be RTP, database or other important traffic.

Routers Used: 3640

IOS: c3640-jk9s-mz.124-16

Feature of Topology: Policy-Based Routing(PBR)

Image:

Download: GNS3-Labs-Dual WAN connection on Cisco with PBR-Pierky

See Pierky’s lab at his site: Dual WAN connection on Cisco with Policy-based routing (PBR)

GNS3 is now available as a FreeBSD port.

FreeBSD users who have an up-to-date port database can install GNS3 with these following commands:
cd /usr/ports/emulators/gns3/
make install clean

Thanks to all the people who contributed to make GNS3 available on FreeBSD.

This lab picks up from:

• EvilRouters.net - Configuring Basic BGP
• GNS3-Topology: EvilRouters- BGP Over Multilink PPP Lab

Don’t get too confused - yes the topology has dramatically changed

In Jeremy’s next lab he will use the local preference attribute to influence INBOUND BGP Routing

Weight

Weight is assigned locally on a router to specify a preferred path if multiple paths exist out of a router for a destination. Weights can be applied to individual routes or to all routes received from a peer. Weight is specific to Cisco routers and is not propagated to other routers. The weight value ranges from 0 to 65,535. Routes with a higher weight are preferred when multiple routes exist to a destination. Routes that are originated by the local router have a default weight of 32,768.

You can use weight instead of local preference to influence the selected path to external BGP peers. The difference is that weight is configured locally and is not exchanged in BGP updates. On the other hand, the local preference attribute is exchanged between iBGP peers and is configured at the gateway router.

Routers Used: 3640

IOS: c3640-jk9s-mz.124-16a

Feature of Topology: BGP, Weight Attribute

The Goal of this lab?

We can see that we have two routes to each of: 192.168.2.0/24, 192.168.3.0/24, and 192.168.4.0/24. All things being equal, BGP will choose the shortest path to each network. We can see this evidenced by the fact that BGP has chosen to send traffic for 192.168.2.0/24 to AS 65002 (R2) and traffic for 192.168.4.0/24 to AS 65004 (R4). Notice, however, that while there are two routes to 192.168.3.0/24 (AS 65003), BGP has chosen to send traffic for that network through AS 65002 (R2). The path through R2 was chosen because it is the “more stable” route (R1’s adjacency with R2 was formed before R1’s adjacency with R4).

Let’s assume, however, that (for whatever reason) we want to route traffic for 192.168.3.0/24 through AS 65004 (R4). The easiest (but not always best) way to do this is by using BGP’s weight attribute.

Image:

Download: GNS3-Labs:: EvilRouters-Weighting To Influence BGP Routing

Enjoy .. LBS

We have all experienced a time when working in GNS3 and we _think_ we saved the the topology and router configurations. So you open GNS3 and load that config, start them routers, watch them boot all the way to the painful prompt

Would you like to enter the initial configuration dialog? [yes/no]:

And your hard work is GONE!

Have you wanted to contribute your labs, but don’t know how to package it all up?

Well my buddy Josh blogged about the 1st thing we should all do when starting a new lab.

Follow these steps to save your project. When the project is re-opened, router configurations will be in tact.

1. Open GNS3
2. Start a lab with objects (routers, pix, switches, etc)
3. Click ‘File > New Project’ instead of ‘File > Save’.
4. Make sure ‘Export Router Configuration Files’ and ‘Keep working directory files’ are checked.
5. Click ‘Yes’ to Apply project settings to the current topology.

GNS3 - How to save labs with router configs

After following Josh’s steps you will then ZIP up all the folders EXCEPT the Working Directory. Send everything else to me and I can take it from there posting your lab.

Be sure to take a screenshot of your lab with the proper credits to you before you ZIP your lab.

You can do this by going to

1. File
2. Export
3. Give the file a name
4. Save it to the same directory you created earlier for the lab/project

Using this method helps you keep your labs nice and organized and save you a lot of frustration!

- Lenny

We have a 2 distribution blocks network linked with the core layer; all elements are dual linked to the upstream layer for redundancy.

Block 1 has L3 access switches, running EIGRP as stub routers. Distribution routers send default route only to the access switches, and perform route aggregation toward core routers.

Block 2 has L2 access switches, with 2 local Vlans and 1 spanning Vlan. Local Vlans upstream traffic is load-balanced toward the distribution switches using GLBP, having STP blocking distrib-to-distrib link. The spanning vlan’s traffic is not load-balanced, but HSRP and STP grant redundancy in case of link failure.

Multicasting is implemented with anycast RP.

The included startup.vpc file contains the configuration for VPCS.
Remember to add Vlan to the switches!!

vlan database

vlan XX

Vlans to add:
A1 - Vlan 10
A2 - Vlan 20
D3, D4 - Vlan 3, 4 and 100
A3 - Vlan 3 and 100
A4 - Vlan 4 and 100

I strongly recommend you to read Cisco Solution Reference Design Guide at www.cisco.com/go/srnd.

Routers Used: 3640

IOS: c3640-jk9s-mz.124-16.bin

Feature of Topology: L2/L3 switching, VLan, HSRP, GLBP, spanning-tree, trunking, etherchannel, EIGRP, L2/L3 access switches, spanning vlan.

Image:

Download: GNS3-Labs::L2L3Access-Pierky

Routers P1, P2, P3 and P4 are in the core, just running OSPF in area 0. Each router has Loopback 0 with address 10.0.1.x (where x is the router number - P1 = 10.0.1.1).

Provider-edge routers PE1, PE2, PE3 and PE4 run OSPF in area 0 too; they have Loopback 0 with address 10.0.2.x.
Each PE routers has iBGP with P3, that is the route-reflector for AS 100.

All P and PE routers run LDP and are enabled for MPLS traffic-engineering.

Both Customer1 and Customer2 have 3 sites: 1 HQ and 2 branch offices. HQs have a /25 subnet, branch offices a /26.
Customer1 needs a full-mesh logical topology, with each site connecting directly to others sites.
Customer2 needs a hub-and-spoke topology, where each branch office sends traffic through the HQ to reach the other site.

Some clouds connected to Virtual PC Simulator are used to replace CE routers in order to lower system resources needed to run the topology. The VPCS config file is in the package (startup.vpc); you can find VPCS here: http://wiki.freecode.com.cn

A MPLS Traffic Engineering (TE) tunnel is configured (but administratively down) between PE1 and PE3; it has an explicit path through P1 and P2.

PE1#sh mpls traffic-eng tunnels tu1

Name: PE1_t1                              (Tunnel1) Destination: 10.0.2.3
Status:
Admin: admin-down Oper: down   Path: not valid   Signalling: Down
path option 1, type explicit 1

Config Parameters:
Bandwidth: 500      kbps (Global)  Priority: 7  7   Affinity: 0×0/0xFFFF
Metric Type: TE (default)
AutoRoute:  enabled   LockDown: disabled  Loadshare: 500      bw-based
auto-bw: disabled

Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.0.0.8 10.0.0.9 10.0.0.2 10.0.0.3
10.0.0.17 10.0.0.16 10.0.2.3
History:
Tunnel:
Time since created: 4 minutes, 6 seconds

As said, the tunnel is administratively down, so traffic from PE1 to PE3 is equal-cost routed via P1 and P4:

PE1#sh ip route 10.0.2.3
Routing entry for 10.0.2.3/32
Known via “ospf 1″, distance 110, metric 31, type intra area
Last update from 10.0.0.11 on Ethernet0/1, 00:03:42 ago
Routing Descriptor Blocks:
10.0.0.11, from 10.0.2.3, 00:03:42 ago, via Ethernet0/1
Route metric is 31, traffic share count is 1
* 10.0.0.9, from 10.0.2.3, 00:03:42 ago, via Ethernet0/0
Route metric is 31, traffic share count is 1

This is the path from VPCS1 to VPCS2 when the tunnel is down:

VPCS 1 >tracert 192.168.1.194
traceroute to 192.168.1.194, 12 hops max
1   192.168.1.129   204.000 ms  266.000 ms  93.000 ms
2   10.0.0.11   719.000 ms  609.000 ms  531.000 ms
3   10.0.0.6   437.000 ms  438.000 ms  500.000 ms
4   192.168.1.193   828.000 ms  828.000 ms  453.000 ms
5   192.168.1.194   500.000 ms  532.000 ms  469.000 ms

Lets open the tunnel:

PE1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
PE1(config)#int Tu
PE1(config)#int Tunnel 1
PE1(config-if)#no
PE1(config-if)#no shu
PE1(config-if)#no shutdown
PE1(config-if)#
PE1#
*Mar  1 00:05:07.335: %SYS-5-CONFIG_I: Configured from console by console
PE1#
*Mar  1 00:05:07.623: %LINK-3-UPDOWN: Interface Tunnel1, changed state to up
PE1#
*Mar  1 00:05:09.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
PE1#

Config Parameters:
Bandwidth: 500      kbps (Global)  Priority: 7  7   Affinity: 0×0/0xFFFF
Metric Type: TE (default)
AutoRoute:  enabled   LockDown: disabled  Loadshare: 500      bw-based
auto-bw: disabled

PE1#sh mpls traffic-eng tunnels tu1

InLabel  :  -
OutLabel : Ethernet0/0, 31
RSVP Signalling Info:
Src 10.0.2.1, Dst 10.0.2.3, Tun_Id 1, Tun_Instance 1
RSVP Path Info:
My Address: 10.0.0.8
Explicit Route: 10.0.0.9 10.0.0.2 10.0.0.3 10.0.0.17
10.0.0.16 10.0.2.3
Record Route:  NONE
Tspec: ave rate=500 kbits, burst=1000 bytes, peak rate=500 kbits
RSVP Resv Info:
Record Route:  NONE
Fspec: ave rate=500 kbits, burst=1000 bytes, peak rate=500 kbits
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.0.0.8 10.0.0.9 10.0.0.2 10.0.0.3
10.0.0.17 10.0.0.16 10.0.2.3
History:
Tunnel:
Time since created: 5 minutes, 18 seconds
Time since path change: 25 seconds
Current LSP:
Uptime: 25 seconds

Name: PE1_t1                              (Tunnel1) Destination: 10.0.2.3
Status:
Admin: up         Oper: up     Path: valid       Signalling: connected

path option 1, type explicit 1 (Basis for Setup, path weight 30)

That’s the new route to PE3:

PE1#sh ip route 10.0.2.3
Routing entry for 10.0.2.3/32
Known via “ospf 1″, distance 110, metric 31, type intra area
Routing Descriptor Blocks:
* directly connected, via Tunnel1
Route metric is 31, traffic share count is 1

The whole OSPF area 0 knows a tunnel is up with some allocated bandwidth; this is what PE2 knows:

PE2#show mpls traffic-eng topology
My_System_id: 10.0.2.2, Globl Link Generation 36
Signalling error holddown: 10 sec

IGP Id: 10.0.1.1, MPLS TE Id:10.0.1.1 Router Node
link[0 ]:DR Intf Address: 10.0.0.3, gen:36
frag_id 0, Intf Address:10.0.0.2
TE metric:10, IGP metric:10, attribute_flags:0×0
physical_bw: 10000 (kbps), max_reservable_bw_global: 5000 (kbps)
max_reservable_bw_sub: 0 (kbps)

Global Pool       Sub Pool
Total Allocated   Reservable        Reservable
BW (kbps)         BW (kbps)         BW (kbps)
—————   ———–       ———-
bw[0]:            0             5000                0
bw[1]:            0             5000                0
bw[2]:            0             5000                0
bw[3]:            0             5000                0
bw[4]:            0             5000                0
bw[5]:            0             5000                0
bw[6]:            0             5000                0
bw[7]:          500             4500                0

And this is the new VPCS1 to VPCS2 path:

VPCS 1 >tracert 192.168.1.194
traceroute to 192.168.1.194, 12 hops max
1   192.168.1.129   172.000 ms  171.000 ms  78.000 ms
2   10.0.0.9   609.000 ms  594.000 ms  641.000 ms
3   10.0.0.3   547.000 ms  641.000 ms  672.000 ms
4   192.168.1.193   594.000 ms  484.000 ms  485.000 ms
5   192.168.1.194   563.000 ms  500.000 ms  641.000 ms

Of course, the return traffic still flows through the usual path; you have to turn on the PE3 Tu1 tunnel interface to force the return traffic on the same path.

Routers Used: 3640

IOS: c3640-jk9s-mz.124-16

Feature of Topology: MPLS, Traffic Engineering, PE-CE routing, VRF, RSVP, LDP

Topology:

VPN:

VRF:

Download: GNS3-Labs:: MPLS VPN and Traffic Engineering

As a continuation from Jeremy’s Configuring Multilink PPP lab over at EvilRouters, and my GNS3 verison of it: EvilRouters-Multilnk PPP Lab - Here is part 2 of his series - This one is BGP Over Multilink PPP Lab

Routers Used: 3640

IOS: c3640-jk9s-mz.124-16a

Feature of Topology: BGP, Multilink PPP, MP, MPPP, MLP, or Multilink

What is Multilink PPP?

Multilink PPP (also referred to as MP, MPPP, MLP, or Multilink) provides a method for spreading traffic across multiple physical WAN links while providing packet fragmentation and reassembly, proper sequencing, multivendor interoperability, and load balancing on inbound and outbound traffic.

What is BGP?

The Border Gateway Protocol (BGP) is the core routing protocol of the Internet. It maintains a table of IP networks or ‘prefixes’ which designate network reachability among autonomous systems (AS). It is described as a path vector protocol. BGP does not use traditional IGP metrics, but makes routing decisions based on path, network policies and/or rulesets.

Image:

Download: GNS3-Labs:: EvilRouters-BGP Over Multilink PPP Lab

Enjoy .. LBS