Archive

Archive for February, 2014

The future of GNS3 – with comments from Stephen at GNS3

February 26, 2014 8 comments

Intro

My last post asked for GNS3 to come clean. Some may have mistaken it for a bashing
of GNS3 which was definitely not the intention of the post. The post was intended
to get a discussion going and to see what GNS3 is planning for the future.
I’m happy to say that Stephen Guppy of GNS3 reached out to me to comment on the post.
They are listening to the community which is fantastic.

Switching

First off regarding the switching, yes it will be implemented through L2IOU.
If you expect GNS3 to develop new switches to be implemented in the new version,
this is not the case. For anyone with some knowledge of switches you must understand
how difficult this is. Switches do all the forwarding in ASICs which are very fast
and dumb chips designed to be lightning fast when forwarding traffic.

To emulate an ASIC would be very difficult if not impossible and the design of the
ASIC is not anything that Cisco would release to the public.

Of course you could implement other switches such as Arista or Huawei or anything
that has been released as a VM. GNS3 is working very hard to implement native support
for these images.

Is it legal?

GNS3 is providing a frontend to L2IOU. They can’t provide binaries or licenses. IOU
is a Cisco only application. It is up to the end users to choose if they want to use
this functionality or not. Looking from Cisco’s perspective it’s a double edged sword.
They don’t want to have something in the wild which could be looked upon as a Cisco
official image and not having the quality as expected from Cisco. On the other hand
Cisco will surely benefit from users having hands on experience on their operating
systems. In the end it’s all up to you if you choose to use such binaries.

The future of GNS3

In the beginning GNS3 was mainly used by students wanting to get certified on Cisco
equipment. Stephen pointed out that although Cisco still is an important player, GNS3
has grown a lot and many students now study Juniper and other vendors which make up
a big chunk of the users.

The aim of GNS3 in the future is to be the “CML/VIRL” of platforms. CML will be for
Cisco only although you could bridge adapters out to other networks. GNS3 wants
to integrate with all vendors to make it a multi vendor environment where you can
run all networking operating systems that are avaible as VMs. This could be XRv,
CSR1000v, N1kv, Vyatta, Arista, Juniper and so on.

End words

I hope this post has brought some clarity on how the switching in the new GNS3 will
be implemented. I wish Stephen and the rest of the GNS3 team good luck with their
new release.

Advertisements
Categories: GNS3 Tags: , , ,

Some pointers on OSPF as PE to CE protocol

February 23, 2014 5 comments

There was a discussion at the Cisco Learning Network (CLN) about OSPF as PE to CE
protocol.
I wanted to provide some pointers on using OSPF as PE to CE protocol.

RFC 4577 describes how to use OSPF as PE to CE protocol. When using BGP to carry the
OSPF routes the MPLS backbone is seen as a super backbone. This adds another level of
hierarchy making OSPF three levels compared to the usual two when using plain OSPF.

Superbackbone

Because the the MPLS backbone is seen as a super area 0, that means that OSPF routes
going across the MPLS backbone can never be better than type 3 summary LSA. Even if
the same area is used on both sides of the backbone and the input is a type 1 or type 2
LSA it will be advertised as a summary LSA on the other side.

LSA across superbackbone

The only way to keep the type 1 or type 2 LSAs as they are is to use a sham link.
Sham links sets up a control plane mechanism acting as a tunnel for the LSAs passing
over the MPLS backbone. Sham links are outside the scope of this article.

A LSA can never be “better” than it originally was input as. This means that if the input
to the PE isa type 3 LSA this can never be converted to a type 1 or type 2 LSA on the other
side. If the LSA was type 5 external to begin it will be sent as type 5 on the other side
as well.

To understand how the LSAs are sent over the backbone, look at this picture.

MPBGP

OSPF LSA is sent to PE which is running OSPF in a VRF with the CPE. The PE installs
the LSA as a route in the OSPF RIB. If the route is the best one known to the router
it can install it to the global RIB.

The PE redistributes from OSPF into BGP. Only routes that are installed as OSPF in
the RIB will be redistributed. To be able to carry OSPF specific information the PE
has to add extended communities. To make the IPv4 route a VPNv4 route the PE has
to add the RD and RT values. The OSPF specific communities consist of:

Domain-ID

The domain ID can either be hard coded or derived from the OSPF process running.
It is used to identify if LSAs are sent into the same domain as they originated
from. If the domain ID matches then type 3 summary LSAs can be sent for routes
that were internal or inter area. If the domain ID does not match then all routes
must be sent as external.

Domain ID match

Domain ID 1

Domain ID non match

Domain ID 2

OSPF Route Type

The route type consists of area number, route type and options.

Route Type

If we look at a MPBGP update we can see the route type encoded.

R4#sh bgp vpnv4 uni rd 1:1 1.1.1.1/32
BGP routing table entry for 1:1:1.1.1.1/32, version 5
Paths: (1 available, best #1, table cust)
Flag: 0x820
  Not advertised to any peer
  Local
    2.2.2.2 (metric 21) from 2.2.2.2 (2.2.2.2)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000020200 
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:22.22.22.22:0
      mpls labels in/out nolabel/18

Something that is a bit peculiar is that this update has a route type of 2 even though
it originated from a type 1 LSA. In the end it doesn’t make a difference because it will
be advertised as type 3 LSA to the CPE.

OSPF Router ID

The router ID of the router that originated the LSA (PE) is also carried as an extended
community.

R4#sh bgp vpnv4 uni rd 1:1 1.1.1.1/32
BGP routing table entry for 1:1:1.1.1.1/32, version 5
Paths: (1 available, best #1, table cust)
Flag: 0x820
  Not advertised to any peer
  Local
    2.2.2.2 (metric 21) from 2.2.2.2 (2.2.2.2)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000020200 
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:22.22.22.22:0
      mpls labels in/out nolabel/18

MED

The MED is set to the OSPF metric + 1 as defined by the RFC.


R4#sh bgp vpnv4 uni rd 1:1 1.1.1.1/32
BGP routing table entry for 1:1:1.1.1.1/32, version 5
Paths: (1 available, best #1, table cust)
Flag: 0x820
  Not advertised to any peer
  Local
    2.2.2.2 (metric 21) from 2.2.2.2 (2.2.2.2)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000020200 
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:22.22.22.22:0
      mpls labels in/out nolabel/18

The goal of these extended communities is to extend BGP so that OSPF LSAs can be
carried transparently as if BGP hadn’t been involved at all. LSAs are translated
to BGP updates and then translated back to LSAs.

If we look at a packet capture we can see the extended communities attached.
This BGP Update originated from a type 5 external LSA with metric-type 1.

Capture

When using OSPF as the PE to CE protocol it is important to remember the design
rules of OSPF. Because of that you should avoid designs like this:

OSPF1

In this design area 1 is used on both sides but the CPE is then connected to area 0
which makes it an ABR. The rules of OSPF dictate that summary LSAs must only be
received over area 0 if it is an ABR. This means this topology is broken and would
require changing area or using a virtual link.

OSPF as PE to CE protocol has some complexity but must of it is still plain OSPF
which is in itself a complicated protocol. Combine that with BGP and MPLS and
it is easy to get confused which protocol is responsible for what. That is also
one of the reasons that I recommend to use eBGP or static when customers connect
to their ISP.

Categories: BGP, MPLS, OSPF Tags: , , , , ,

GNS3 – It’s time to come clean

February 21, 2014 6 comments

Many network engineers, Cisco students and people just interested in networking
has used GNS3 in the past for studies and Proof of Concepts (PoC). Despite it
being a CPU hog, bugs in the Ethernet drivers and lack of stability it has
been a vital tool to not have to invest large sums of money into real hardware.

The legality of GNS3 has always been an issue, GNS3 claims to have good relations
with Cisco which might be true because Cisco knows the value of people being
able to practice on their products. GNS3 is just a GUI and they don’t provide
any images so they aren’t doing anything illegal.

Crowd funding

A while back GNS3 decided to crowd fund their new release called 1.0.
The main selling point was that they are adding switching. I was skeptical of
this right from the start. GNS3 has always claimed that they can’t support
switching outside of ESW cards due to not being able to emulate ASICs.
What has changed now? From the GNS3 official FAQ:

Q. Will you support Cisco switching?

A. Switching is going be supported in GNS3 using L2IOU images, which are special IOS images made to work on PC/Linux. These are more like generic Cisco switches with most of the same features as in real switches. So in the end you can have 90% of the same features, just a bit slower.

Switching will be supported through L2IOU images. For those of you not familiar
with L2IOU, it is a binary running on Linux which is used in the CCIE RS lab in
the troubleshooting section. This is an actual binary so it is not emulating the
hardware. Because the ASIC is not emulated some features are not supported such as
Q-in-Q, QoS and private VLANs.

What’s the problem?

The problem is that this is a Cisco internal software. To run it you must have the binary
and a license. This software is not allowed to run outside of Cisco. Doing so would be
an illegal act unless Cisco opens up for it. But why would they when they have CML coming
out?

GNS3 is just a GUI

Yes, GNS3 is just a GUI. In the past they have been able to avoid legal issues by users
downloading IOS images (which they have the right to). With L2IOU it’s a totally new
ball game. By adding support they are in fact encouraging users to use illegal
software, IOS images could be acquired legally but L2IOU images can not.

Come clean GNS3

I decided not to contribute to GNS3 because I don’t think they were fair in
the crowd funding part. Switching was the main selling point, lets be honest.
Most people donated because of that, I could have donated because I like the
software but I don’t like how GNS3 are playing their cards right now.
It’s time to come clean GNS3!

Categories: Announcement, GNS3 Tags: , , ,

Cisco XRv has been released

February 9, 2014 14 comments

Many of you have probably heard of Cisco VIRL or what is now called Cisco Modeling
Labs (CML). CML is due for release later this year and is supposed to include
support for IOS, IOS XE, NXOS and IOS XR.

Last year Cisco released the Cloud Services Router (CSR1000v) which is a virtual
router running IOS XE.

Now Cisco has released the XRv which is a virtual router running IOS XR. This is
great news for anyone that wants to learn IOS XR or to test changes and to try
different concepts on IOS XR.

The VM can be run on ESXi or KVM/QEMU which gives flexibility. The installation
guide is located here.

To find the download path on CCO, this is what it should look like.

Download path

Every VM needs 3GB of RAM to start but when it’s running it seems to only use 1GB
and has a very low CPU usage.

Resource_usage

At this moment the download is restricted but Cisco is working on moving the restriction.
Expect this to be solved this coming week. XRv will be available in three packages.

Packages

There is restriction on 2 Mbit BW which should not be an issue for labbing purposes.

The initial release has some nasty bugs. So make sure to not use more than one CPU.

Caveats

To be able to run the image the server must meet the following requirements.

Requirements

The complete list of release notes are here.

After you have deployed the VM, which can be done with OVF template or by creating
a VM and using VMDK, don’t forget to create a serial interface and tie this to the
network or you will not be able to see any output from the VM. This is described
in the release notes.

Cisco also provides a free workbook with some basic concepts for IOS XR which can be
found here.

I would also recommend this also free IOS XR workbook by Jeffrey Fry. It’s a great
contribution to the community and it can be found here.

Have fun learning IOS XR!