Archive

Archive for March, 2011

Integrated Routing and Bridging

March 30, 2011 7 comments

Sorry for the lack of updates lately but I spent the whole last week skiing and recharging my
batteries and now I’m back fully motivated to continue my path to the lab.

This time we will be talking about Integrated Routing and Bridging (IRB). Before studying for
the lab I had never used this feature. I’m not sure why we would use this feature in a
production network, maybe because we need to bridge two networks instead of routing
them due to some badly written application. If you have used it in real networks please post
in the comments. It is fair game for the lab so we need to know about it.

IRB is a feature used on routers that lets us bridge between a bridged domain and a
routed domain. Remember that in order for a VLAN to span a router the router must
be able to forward frames from one interface to another while maintaining the VLAN
header. If a network protocol is configured on a router interface (IP) it will terminate
the VLAN. This means that the VLAN header will not be maintained. When configuring
IRB we will be using a Bridged Virtual Interface (BVI), this can be compared to a SVI
on a switch. A BVI gives the bridged interfaces a connection to the routed world.

When IRB is configured and traffic comes in on a routed interface (IP address configured)
that is destined for a host in the bridge group the traffic will first be routed to the BVI.
The packet will then be forwarded to the bridging engine which forwards it through a
bridged interface, the forwarding is based on the destination MAC address. If a packet
comes in on a bridged interface destined for a host in a routed network the traffic will
first go to the BVI and then be sent to the routing engine before it sends it out the
routed interface. If bridging between two interfaces with no routed protocols the traffic
will not pass the BVI interface. Think of the bridge-group as an external switch and
the BVI lets us connect this external switch to the router.

The image below describes the scenario. R1 and R3 are in different VLANs but in
the same subnet, we need communication between the two routers. Between the
routers we have a couple of switches.

The configuration on R1 and R3 is straightforward. They have physical interfaces
with an IP address.

R1:

interface FastEthernet0/0
ip address 136.1.136.1 255.255.255.0

R3:

interface FastEthernet0/1
ip address 136.1.136.3 255.255.255.0

R1 is connected to SW1 and R3 to SW3. The switch configuration is just a basic access port.

SW1:

interface FastEthernet0/1
switchport access vlan 16

SW3:

interface FastEthernet0/3
switchport access vlan 36

Router R6 is connected to SW2 and it needs a trunk port.

SW2:

interface FastEthernet0/6
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 16,36
switchport mode trunk

Now we need to configure R6 to bridge between the two different VLANs. We start by activating IRB.

bridge irb

Then we need to tie the interfaces to the bridge-group.

interface FastEthernet0/0.16
bridge-group 1
!
interface FastEthernet0/0.36
bridge-group 1

Now we create a BVI interface in the subnet.

interface BVI1
ip address 136.1.136.6 255.255.255.0

Lastly we need to activate spanning-tree and activate routing for the bridged interfaces.

bridge 1 protocol ieee
bridge 1 route ip

So using IRB we can both bridge and route between interfaces on a
router, something that is not possible otherwise.

Finally, these are some useful commands to show what is going on when using IRB.

show interfaces irb
show bridge
show spanning-tree

Advertisements
Categories: Routing, Switching Tags: , ,

Lost in transit

March 19, 2011 Leave a comment

I have registered a domain for my blog. It is still hosted at WordPress but I wanted an easier address to remember. From now on you can also reach my blog via http://lostintransit.se or http://www.lostintransit.se

Categories: Announcement Tags:

Filtering RIP routes with an offset-list

March 18, 2011 1 comment

As you all know RIP is a distance vector routing protocol and that gives us a lot of options
when doing filtering. This time we will look at a feature that is not widely known, the
offset list. Assume that we have two routers, R1 and R2 and this is the task at hand.

  • R1 should filter all RIP routes coming from R2 with an even second octet
  • The access-list used may only contain one line
  • Do not use the distribute-list or distance command to accomplish this

So lets look at our tasks, how do we filter routes with an even second octet?
This might look a bit complicated but it’s easy when you’ve done it before. The routes we
are receiving from R2 are 30.0.0.0 to 30.3.0.0 and 31.0.0.0 to 31.3.0.0. Lets start
by focusing on the second octet. We will convert our even subnets to binary, we only care about the first and second octet.

30.0.0.0 – 00011110 00000000
30.2.0.0 – 00011110 00000010
31.0.0.0 – 00011111 00000000
31.2.0.0 – 00011111 00000010

See the pattern? If not look at the odd subnets below.

30.1.0.0 – 00011110 00000001
30.3.0.0 – 00011110 00000011
31.1.0.0 – 00011111 00000001
31.3.0.0 – 00011111 00000011

Do you see it now? Even subnets always end with a zero for the least significant bit.
Odd subnets always end with a one. This means that the final bit in the second octet is
interesting to us, the rest is don’t care. Now we need to convert this to a wildcard mask,
set all the bits we don’t care about to one and the one we do care about to zero.
Add them up, in binary it is 11111110 which equals to 254 in decimal.

Now we need to fill in the rest of the wildcard mask, remember that we were only allowed
to use one line in the access-list. How can we match both 30 and 31 in the first octet?
Look at the binary again, only the least significant bit in the first octet differs so we do
care about all the bits except for the least significant bit. Convert this to binary and we
have 00000001 which is 1 in decimal. So now we have the wildcard 1.254.255.255 since
we don’t care about the third and fourth octet.

As stated in the tasks we need to filter even routes, how can this be accomplished
in an access-list? Either we can deny odd routes, that would filter even routes
but since there is an implicit deny we would need a permit statement for the even
routes. That would break the one line requirement. So we need to permit the even
routes in the access-list and the implicit deny will solve the rest.

access-list 1 permit 30.0.0.0 1.254.255.255

Using a distribute-list would be the most common and easiest solution but
we are not allowed to do that. By using the distance command we could filter
routes by setting the administrative distance to something not believable like 255
but we are not allowed to do that either.

That only leaves us with the offset-list. The offset-list lets us manipulate routing
metrics, we are allowed to do this since it is distance vector and that is the reason
why distance vector is often called “routing by rumor”. In a link-state protocol we
would not be allowed to do this as we would need to send the original LSA.
So we can manipulate the metric, how can this help us? Remember that in RIP
we have the hop-count as metric and only metrics of up to 15 are valid, 16 and up
are regarded as invalid routes. So we then need to set our routes to have an offset of 16.

router rip
offset-list 1 in 16 Vlan783

So we have defined our offset-list, access-list 1 is used, the direction is
inbound, we want to filter routes we are receiving. We need to define the
offset, which is 16. We also need to define on what interface the RIP routes
are received. This is the layer three interface and may or may not be the
physical interface.

By now hopefully you have picked up a new way of filtering routes and can add it to your toolbelt.

Categories: CCIE, RIP, Routing Tags: , , , ,

Flash cards updated

March 17, 2011 3 comments

I have updated the flashcards with some questions on FHRP, Syslog, EEM, ZBF and NTP. There is over 200 questions in the bank now. As usual download the file from here.

Categories: Anki, CCIE Tags: , ,

OSPF lab notes

March 14, 2011 1 comment

This post is based on notes from my practicing OSPF vol1 labs. I want to have them saved
for later reference but I also think that this post can help others and clear some of the
confusions of OSPF.

Lets assume that we have some lab tasks that involve OSPF. The first thing we should do
is make a diagram with all the devices and the areas that the interfaces are connected
to. If this diagram is already provided for us and we find it usable, then don’t waste
time doing a new one! Otherwise if there isn’t one of if your not happy with it, make
a new one.

I like to make diagrams in Visio but when we diagram for the lab its about being
effective so don’t try to create some masterpiece. I just use circles for routers and
squares for switches and then I write the device name inside the circle or the square.
Then I write the interfaces on the devices and IP if needed and make circles for the
areas that include the interfaces.

So these are some of the things I have noted down when labbing.

  • The default mode of OSPF on frame-relay interfaces is non-broadcast

What does this mean? Non-broadcast means a few things. Non-broadcast means we cannot
send multicast or broadcast. Non-broadcast also means that a DR will be used.
Remember that if you see the prefix non in the OSPF type then we need to use neighbors.
If we have a hub and spoke topology we want to make sure that the hub always becomes
the DR since we won’t have l2 mappings to the other spokes in our frame-relay cloud.

How can we accomplish this? Remember that electing the DR is not preemptive, so we can
set the hub to have the highest priority and it is elected the DR and everything is fine
and dandy. When we have an outage at the hub and it comes back up but reachability is
not restored, why? While the hub was away another device could have been elected the DR
and just because the hub is back does not mean that it will assume its previous role.
So we need to make sure that the hub is elected the DR and that the other devices are
not eligible to be elected DR or BDR. The way of doing this is by entering ip ospf priority 0
under the frame-relay interface. Devices with a priority of 0 are not eligible for being
elected as DR/BDR.

  • Adjacencies and convergence can take a while in NBMA networks, dont panic!

What do I mean by this. While labbing I was noticing that forming adjacencies took quite
some time. I was typing show ip ospf nei and looking at the status and it would be EXSTART
or something else for quite some time before the adjacency was formed. So give it a few
minutes before you make the assumption that something is wrong with your config.
Remember that the timers on NBMA networks 30 seconds for hello and 120 for dead.

  • Neighbor command is only needed on DR

We won’t break anything by entering the neighbor command on the spokes but isn’t it better
to know how something works than just throw config at it? The spokes will only communicate
with the DR and the DR will be responsible for forming the adjacency. When we enter the
neighbor command under OSPF config mode on the hub it will start sending unicast packets
to the IP addresses that we have specified. Remember that multicast is the default in
most routing protocols. The hub sends unicast packets to the spokes which will notice that
unicast is being used and start replying with unicast themselves.

  • A router is not an ABR if no interfaces in area 0

This might sound a bit confusing. Lets say that we have a router with interfaces in area 1
and area 3. This must be an ABR right? Wrong! Unless it is connected to the backbone it
is not actually an ABR and it will not send type 3 summaries describing the other areas
networks. If you want some more background on this and a great article on OSPF I
recommend that you read Petr Laphukovs post at INE.

  • Using point-to-point mode

This mode is the default for interfaces that use point-to-point type of encapsulations
like HDLC or PPP. This mode can also be used to force a loopback to be advertised with its
configured mask instead of a /32 host route. This mode uses multicast and no DR is elected.
There is no need for a DR here since there can only be two devices communicating to each other.

  • Using point-to-multipoint mode

This mode is designed to work in partial mesh NBMA networks. When we use this mode
we will see that there is a /32 route for every spoke pointing to the hub. Also all routes
that are learned will have their next-hop changed to the IP of the hub. This means that
we do not need to have map statements for the other spokes. As this mode uses multicast
we need to have the keyword broadcast in our frame-relay statements.

  • Using point-to-multipoint non-broadcast

This works the same way as point-to-multipoint but the traffic is sent via unicast packets
instead of multicast. This means that we must have neighbor statements in our OSPF config.

  • Hints that we should use non-broadcast mode

If we have a broadcast segment like Ethernet and we are told that the OSPF
communication must be secured so noone can interfere with it then we should use
non-broadcast mode. Default on Ethernet segments multicast will be used but that
means that anyone can listen to the packets if they are connected to the segment.
If we enable non-broadcast the packets will be sent via unicast. Optionally we can
enable MD5 as well.

This post should give you an understanding of the different modes in OSPF,
remember that non-broacast always means neighbor statements.

Categories: CCIE, OSPF Tags: , ,

Saving time on lab tasks

March 11, 2011 1 comment

This post will show how you can save time on the lab tasks. Assume you need to complete this OSPF task.

  • Advertise the Loopback0 interfaces of R1, R2, R3 and R4 into OSPF area 0
  • Advertise the Loopback0 interface of R6 into OSPF area 1
  • Advertise the Loopback 0 interfaces of SW1 and SW3 into OSPF area 2
  • Advertise the Loopback 0 interfaces of R5, SW2 and SW4 into OSPF area 3

Our task is to advertise the loopbacks of all routers and switches in the topology into OSPF in
different areas. The topology is the regular INE topology but it doesn’t really matter here.
The major network is 155.21.0.0/16 where R1 has the loopback 155.21.1.1, R2 has
155.21.2.2 and up to SW4 that has 155.21.10.10.

We will be using the notepad technique, this can save you a lot of time when the lab comes.
What we do is write everything into notepad instead of typing in the CLI and we try to
reuse as much config as we can and only change a few parameters and then we copy
and paste to all the devices. This will save you from typing, save time and be more
accurate than typing to the CLI.

We have two options here, either we advertise the loopbacks the regular way by
entering router ospf 1 and then using the network statement or we can use the
new method of configuring OSPF under the interface instead.

Lets look at the first approach. Every loopback is in it’s own class C subnet. Assume
that we have entered OSPF config mode and we now need to put the network
statement, what should we use? We only want to advertise the loopback and not
other interfaces. So we start typing in notepad.

end
conf t
router ospf 1
network 155.21.1.1 0.0.0.0 area 0

This is as specific as we can get, this will only advertise the loopback. Now we need to copy
this and lets look at R2. The reason why I put an end at the start is to make sure that we
will end up in config mode and not some other submode. Router ospf command should work
from most modes like interface config but its better to make sure.

end
conf t
router ospf 1
network 155.21.2.2 0.0.0.0 area 0

So we need to change two digits for every device. Can we be more effective? If we change
the network statement to 155.21.1.0 0.0.0.255 we would only need to change one digit in
notepad for every device, that is actually better!

There is an even more effective way of doing this, which will mean that we won’t have to
change a single digit for the first four devices! Every minute saved will give us more time
to troubleshoot and verify config. This is how we do it, type into notepad.

end
conf t
int lo0
ip ospf 1 area 0

This config will be exactly the same for the first four devices and for the others
we only need to change the area, that is one digit at most! So now we have done
this in the most effecient manner possible. Now we want to test the reachability
of all the loopbacks. We could ping manually from the CLI and type ping 155.21.1.1
and so on but that would take a lot of time for 9 loopbacks in every device.
We could enter all IP’s in notepad with ping statements and then paste this into all
the routers which would be way more effective but the most effective way of doing
this is by using the TCL shell in IOS. If we don’t have support for TCL (switches)
we can also use a macro. This is how we do it in TCL.

tclsh
foreach ip{
155.21.1.1
155.21.2.2
155.21.3.3
155.21.4.4
155.21.5.5
155.21.6.6
155.21.7.7
155.21.8.8
155.21.9.9
155.21.10.10
}{ping $ip re 1}

We could leave out the loopback from the device that we are currently on
but then we would have to edit more in notepad. We should get a reply from
ourselves and if not we know why the ping failed. So this code in TCL will ping
every loopback repeated only one time and show us the output. We have now
configured the loopbacks and verified reachability in a matter of minutes.
I hope this post will help you in saving time and as I progress in my studies I will
post more of these tips.

Categories: CCIE, Lab preparation Tags: , ,

CCIE command memorizer review

March 9, 2011 Leave a comment

This is a review of the CCIE command memorizer. Firstly, I did not pay anything for the product, David let me try it out so I could write a blogpost about it and he has a chance to respond to my remarks. That doesn’t mean that I am afraid of critizing issues that I find with it, this review will be as objective as possible. The CCIE command memorizer is developed by David Bombal, CCIE # 11023. He runs the website ConfigureTerminal.com and a lot of different applications are available there like the CCIE command memorizer and config generators.

When purchasing the CCIE command memorizer you will get some additional products as a bonus. Lets start by going through these.

Cool IOS Commands

This is an e-book with useful commands in the IOS. As a quite experienced engineer I know almost all of these already but they can be very useful if you haven’t seen them before. Some things you will find in this e-book.

  • How to use the do command
  • Searching for text in show run with / and + and –
  • How to write aliases
  • Setting the terminal length to zero
  • Using regular expressions
  • Ping and traceroute syntax

Overall a good product since it is included anyway but if you are well versed in IOS you will recognize most of these.

MPLS command memorizer

The MPLS command memorizer is developed for the MPLS exam included in the CCIP
certification but can also be used to prepare for the CCIE. When using the MPLS
command memorizer you will see a network diagram in Visio style and then
the tasks required to finish the section. The configuration is done in a virtual PuTTY
terminal. A task could be setting up BGP peering sessions and activating the peer
under the right address-family. If you need a hint you can enter an Y on the
righthand side and the correct command to be used will be shown. The program is
divided into different areas like “MPLS basic infrastructure”, “VPN configuration”,
“PE/CE static routing” and so on. This is good because it gives you the chance
to practice in the areas that you are weak. It is a good product and it has its
use but don’t expect it to replace Dynamips, they fill different roles.

BSCI command memorizer

This exam is now named ROUTE but most of the content is the same. I’ve been a
CCNP for a couple of years and I’m doing the CCIE now so I don’t have that much
use for this program but it works in the same way as the other two. If you are
doing the CCNP this is a good product. It will show you a network diagram and
the tasks that you need to complete. It contains labs for all the different routing
protocols.

CCIE command memorizer

This is the reason I got interested in the product since I am studying for the
CCIE. Every day I have a 40 minute commute one way to work and I spend that
time studying. I wanted a way to keep labbing fresh and running the full
CCIE topology in Dynamips on my laptop is not an option.

The program is divided into different sections. Except for the labs there is a
“CCIE quick fire” and a “DocCD shortcuts section”. The CCIE quick fire is a
question bank with short answers. A question could be what timer is used
for a routing protocol or what the AD is for a protocol and the questions are
divided into different sections. Most of the questions are good but some feel
a little overkill and out of context, like answering fibre lengths for different
standards. Could be useful for the written but even that is questionable,
still it’s not a bad thing to know “too much”.

The DocCD section shows where to find the different technologies used for
the CCIE. Some of the links seem broken but you can also see how you can
find the links by navigation to switches -> LAN Switches and so on. A very
good idea but an update of this section would be nice.

Then we have the main section that is labs. Some of the lab sections also
have questions, an example would be “Assigned Multicast addresses” for IPv6
and the answer is FF00::/8. This is a quite nice feature I think because even
though we are practicing for the lab we still need to know the theory behind.

There is a lot of labs available, probably hundreds. When you type into the
virtual PuTTY terminal there is no option to use the questionmark to find
out available commands. If this is a good thing or not is up to you, this will
force you to learn the commands which might be a good thing.

If you want to see what the program looks like and the structure of it please
check out Davids website. Overall I feel it is a useful product if you have the
right expectations for it. This does not replace Dynamips in any way, this
is the first thing you need to understand but it can be a good sidekick.
Lastly here are some pros and cons with the product.

Pros

  • Fast to setup, no need to develop topologies
  • Doesn’t require a fast computer to run
  • No need for a Internet connection
  • A LOT of labs available
  • You get extra products when you buy the CCIE command memorizer
  • Helps with retention of commands
  • Good for short sessions when just setting up Dynamips would take more time than you have

Cons

  • Not full support for abbreviated commands
  • No context sensitive help, might not be a con, depends on personal opinion
  • Commands must be entered in exact order
  • Some tasks might be a bit repititive and maybe the IP-addressing should change to not memorize addresses
  • Would be nice with messages in console when peerings come up and maybe some basic show commands
  • Product updates? How often is the product updated? Some pages have a copyright from 2008

Overall it is a useful product and the prize is 150$ and then you also get the other
3 products. If you have the right expectations before buying it I don’t think you will
be disappointed. Regarding updates I was told that the product will be updated in
a couple of months.

Categories: CCIE Tags: ,