Archive

Posts Tagged ‘RIP’

INE 10 day bootcamp – Review

September 4, 2012 10 comments

I’m back from London and it’s been a great experience. Many readers are interested in what
the bootcamp is like. It is a big investment to go for so it is understandable that you
want to know if it will be worth it. I’ll start by describing the teacher and his teaching
methods.

Brian Dennis is a well known and respected man in the network industry. He is CCIE #2210
and has 5x CCIEs. That is among the very best in the world. Brian is not one of those
academic guys that only knows what is written in a book. He as a solid background in the
industry which means he can explain WHY things are the way they are and not just stating
facts without any reasoning behind it. There will be NO powerpoints, it is CLI only and
although he has a topology he is using the configurations are not prebuilt. He will do
them live which means there will be issues, which is GOOD. You get to see a 5x CCIE
troubleshooting and since he hasn’t prepared the faults before you will see how he would
troubleshoot a live problem which is very good practice for the TS lab in the CCIE lab.
Brian is a strong believer in that there are no tips and tricks. If you have an
instructor teaching you all these tips and tricks then that instructor is a fake.
If you know the technology there are no tips and tricks. Sure he can teach you some
useful commands but there are no tips and tricks in routing protocols.

Jeremy Brown is the bootcamp coordinator. He’s a very nice guy and he will help you
with any queries you have about the bootcamp. If you are attending you will be
talking to him for sure.

When you start the class the first day you will be handed a folder with paper and
a pen and some contact information. Brian will introduce himself and give some
general guidelines and explain how the real lab works with TS section and
configuration section etc. Then everyone gets to introduce themselves. My class
had a lot of nationalities, Bolivia, France, Venezuela, Sweden, UK, Ireland,
Norway, Hungary were all represented.

The bootcamp runs from 9 AM in the morning to about 19-20 PM in the evening.
There will be some 15 minute breaks and a lunch break for 1.5h. It is long
days indeed so make sure to get enough sleep in the evening. This is a pure
learning experience, leave the partying for another time. If you want to
have some fun there will be time in the weekend for that.

The first day is about layer two. Since the configuration is built from
scratch it makes sense to start out with layer two. The topology used
is based on Cisco 360 with 5 routers and 4 switches. The routers are ISR
routers and the switches are 3560’s. It is good that this topology is
used since that is very similar to what is being used in the real lab.
When attending the bootcamp you are expected to have a good knowledge
of protocols and that you have watched the INE ATC videos. This is so
that you don’t get overwhelmed by the information in the bootcamp.
The layer two section focused on MST, PPP and frame relay and
spanning tree features like BPDU guard, BPDU filter etc. One advice
that Brian gave is to try to mix in things like PPP, PPPoE, PPPoFR
etc in your labs so that you get used to using these technologies.

Later in the week we moved on to IGPs. OSPF will be the main topic.
This is natural since OSPF will guaranteed be in your lab and you
REALLY need to know OSPF to pass the lab. Brian is an OSPF
machine, he knows the LSDB like the back of his hand. He is very
methodical and will confirm each step and show you in the LSDB
what we are seeing and why we are seeing it. He’s not one of
those guys that clears the routing table when he runs into a
glitch, he will explain how and why it is there. He had a very
good section about the forwarding address, this is an important
part of OSPF and Brian explained why it is used. He had a very
good analogy with BGP where basically if the FA is not set then
you are using next-hop-self and if it is set then the next-hop
is preserved. He also had a good explanation of the capability
transit feature and he did some great diagrams showing which
LSAs go where. This is basic knowledge but he put it so well in
that diagram. We also talked about virtual links and things like
that. One good command he showed was the show ip ospf rib
command. EIGRP and RIP will be shorter sections, he will only
show some more advanced configuration since these protocols are
a bit simpler to understand. For EIGRP he showed hot do do
unequal cost load balancing and how to calculate the metric
if you want to get a certain ratio. He showed how to do
offset-list, leak maps and authentication.

After we were done with IGPs we moved on to route redistribution.
This topic alone is enough to provide a good bootcamp experience.
Brian will in detail explain the difference between control plane
and data plane loops and why loops can occur. The important thing
to remember is that we are trying to protect the routes with a
high AD from being learned in a protocol with a lower AD. Usually
RIP is involved or EIGRP external routes since those have a high
AD. Brian will show you how to take any INE Vol2 lab topology
diagram and just look at it and identify potential issues.
This is a very good practice and when you can look at a diagram
and know what to do without even thinking about configuration
yet then you are in a good place. Brian will with his diagrams
show you where every command lives like the OSPF LSDB, OSPF RIB,
RIB, FIB etc. This is very good practice to make sure you have
a full understanding of what is going on.

BGP is of course an important topic and Brian is covering that
for sure. Brian starts by describing peering and goes through
some common misconceptions. BGP has no authentication,
wait for it…TCP has, this is a common misconception. It is
TCP providing the authentication of packets and not BGP.
He will explain concepts like hot potato vs cold potato routing.
He will show you the difference between disable-connected-check and
ebgp-multihop. He will teach you about route reflectors and
confederations and why you want to use the one or the other.
He will also explain MED in detail, something I found very useful,
explaining how deterministic MED works and always-compare-med.
He has such knowledge of everything and one thing I didn’t know
before is that networks in the BGP table are sorted by age where
the youngest network is listed first.

Building on BGP means MPLS comes naturally. These go hand in
hand and for the v4 CCIE lab you need to know MPLS. Brian
will of course explain the use of RD and RT. Remember that RD
only has a use in BGP. He shows where all the commands and
routes live and how to do troubleshooting for MPLS. The good
thing is that you will run into things that you didn’t maybe
think about and that will provide great troubleshooting. OSPF
is the most complicated PE-CE protocol and he will give you all
the details how to use Domain-ID, sham links and how the
external route tag and DN bit works.

First week is over. Time for some recovery. Have some fun and
go for some sightseeing or just do labs, the choice is yours.
Just make sure that you are well rested for when monday comes.

The second week started out with multicast. This was maybe my
favourite topic and I learned a lot from this section.
As I mentioned earlier Brian doesn’t believe in tips and tricks
and multicast is one of those topics where people have a lack
of understanding and that is why they go looking for tricks.
Multicast is 90% about PIM, you need to know PIM if you want
to be good with multicast. Brian shows common errors like having
a broken SPT or RPF failures and things like that. These usually
occur when hub and spoke frame relay is involved. With just a
few commands you can become very good with analyzing multicast.
Show ip pim interface, show ip pim neighbor,
show ip rpf x.x.x.x and show ip pim rp mapping will give you most
of the information you will need. The best thing about the
multicast section was that when we ran into errors Brian was very
methodical, instead of just pinging over and over he showed us
what was wrong and then cleared the mroute table, this will
make the mtree build again so that you always go back to a
well known state. It is probably common to have the correct
configuration but move away from it due to lack of patience
or lack of understanding of what is really going on.

Time for the killer topic, probably the most hated topic in
the entire blueprint for most candidates. You guessed it, it is
time for PfR. Where does this hate come from? Well it comes
from the fact that the 12.4 implementation of PfR is just so
incredibly bad. If I were to select one topic that is difficult
to study on your own and that you can really benefit from going
to a bootcamp then that would be PfR. Brian starts out with some
basic topologies and then moves on to some more advanced scenarios.
This topic runs for one day or even a bit more. You WILL run into
a lot of issues due to the implementation of PfR in 12.4. If you
have seen the PfR Vseminar then this will be a lot like that
with the added benefit that you can ask Brian questions of course.

The next big topic is QoS. Brian goes through frame relay
traffic shaping using both legacy syntax and MQC. He will go
through how to use policing and shaping. The coolest thing
about this part was how we configured values for policing
like Bc and then Brian showed by sending ICMP packets how the
token buckets are really working. You might be in for some
surprises here! No powerpoints here for sure! He will explain
the difference between single rate and dual rate policers and
why you would configure them for which scenarios. Then he will
go through the Catalyst QoS. This is a confusing section for
many since the Catalyst QoS is a bit convoluted. Brian shows
how the L2 QoS is very similar to MQC but the syntax is just
a bit strange. He shows how to use the priority queue and how
to use the share and shape queues for the SRR queues.

Whatever time is left will be spent on topics like EEM and
services that you would like to go through. If you feel that
you are weak in some service then this would be a good time to
ask Brian to go through it. I left the bootcamp at 3 PM on
friday and I probably missed a couple of hours in the end.
If you can find a later flight or go home on saturday that
could be a good option.

So now you have gone through a wall of text and you are
whondering what I think about it? Well if it wasn’t obvious
from my text then Yes! Go for it! Yes it costs to go and
with everything to account for like living expense and hotel,
yes it is costly. However if you look just at the price for the
bootcamp which is around 5990$. That is actually a good price,
if you consider that you can get 1500$ paid for your lab then
the cost is actually 4500$ Where I live one week of training
at Global Knowledge is usually around 3000$ for a week and
then often you get some Power Point guy reading slides or you
doing labs while the instructor is watching. The one thing I
found best about the bootcamp was that you learn how to think
at a higher level. Being a CCIE is not about knowing a lot of
commands, it is about thinking at a high level. You get to pick
the brain of a 5x CCIE with real world experience, you won’t
find many guys like that in the world and from what I’ve seen
I would rank Brian among the very best of them. The IGP, Multicast,
Redistribution, PfR sections were very good and you will learn a lot
for sure even if you were strong in these areas before.

Hopefully in class you will meet some new friends. I met some
people people in class I had only seen online before and also made
some new friends. I had a great time with David Rothera, Gian Paolo,
Jose Leitao, Susana and Harald. I also met Darren
for the first time, we have known each other online for a while now
but never met. I also had the chance to meet Patrick Barnes which is
another of my online friends 馃檪

I’ve tried to cover as much as I can remember but always feel free
to ask questions in the comments section if you have anything you are
still thinking about.

Advertisements

RIP – request and response packets

August 10, 2012 1 comment

I was discussing the other day with someone on IRC about a RIP issue he had.
Apparently he had RIP request packets coming in and then all routers were
responding with response packets with full routing table. It seemed like some
kind of amplification attack. That made me realize that I didn’t even know RIP
uses request and response packets. This is very overkill for the CCIE but you
want to know the protocols not just pass a test right? So I then went on to
read the RFC and realized this was the first time reading it.

So when a router boots up or has its RIP process started the following happens.
The router sends a RIP request packet to either 255.255.255.255 or 224.0.0.9
depending on which version is running (who runs v1?). The packet looks like
this.

We see that the command is request and it is basically a packet with no
address information and the metric set to 16 (infinity).

Now the routers hearing this request will respond with a response packet.
It looks like this.

So the other router responds with all RIP routes that it has in its routing
table. The updates that RIP sends every 30 seconds are basically unsolicited
response packets. So why do we have request packets in the first case? It’s
a way of speeding up the convergence process so when a router boots up it
gets the routes immediately instead of waiting for in worst case 30 seconds
before hearing a RIP update.

So that should give you some more insight into RIP. I might do a followup post
on flash updates and suppression of null updates as well.

Categories: CCIE, RIP Tags: , , , ,

RIP MD5 authentication – mismatch in key ID

August 7, 2012 Leave a comment

This is an interesting fact I just found out. When we configure MD5
authentication for RIP they key-ID and key-string must match, this is
well known. But what happens if we actually configure the wrong key-ID?
Take a look at the following config.

R1#sh run | s key chain
key chain RIP
 key 1
   key-string cisco
R2#sh run | s key chain
key chain RIP
 key 2
   key-string cisco

So R2 has a higher key-ID. No routes should be passing right? Wrong.
R2 will accept routes from R1 because it has the higher ID however
R1 will not accept routes from R2.

R1#show ip route rip

RIP: ignored v2 packet from 10.10.1.2 (invalid authentication)
R2#show ip route rip
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/1] via 10.10.1.1, 00:00:26, FastEthernet0/0

RIP: received packet with MD5 authentication

The only thing I can think of why this works is that it is some form
of rollover process where they older key-ID is accepted until routers
have been migrated to the new ID. It is strange that it works though
since key-ID 1 does not exist on R2.

If we change the password on R1 then the authentication will fail on R2
also.

RIP: ignored v2 packet from 10.10.1.1 (invalid authentication)

So the password is surely checked but they key-ID is ignored if a higher
key-ID is locally configured.

If anyone has some background on this I would be very interested. All I
could find was a RFC for MD5 for RIP. It mentioned something about key rollover
but nothing definite.

Categories: CCIE, RIP Tags: , , , ,

OSPF – Use of forwarding address

August 6, 2012 29 comments

In OSPF and other routing protocols we have something called forwarding address.
This can be used to route traffic in another direction than to the router that
originated the LSA. We start with the following topology.

It’s a basic OSPF setup where area 1 is a NSSA area. As you can see we have
two ABRs. Remember that in NSSA area, redistributed routes will be seen as N
internally but as E outside the area. To make this happen the ABR must translate
the type 7 LSA to type 5 LSA. If we have multiple ABRs, which one is responsible
for this task? The ABR with the highest RID will do the translation.

If we look at the LSA at R1, this is what it looks like.

R1#sh ip ospf data ex 10.10.4.0

            OSPF Router with ID (10.10.13.1) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1373
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x7306
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.10.234.4
        External Route Tag: 0

So R3 is the ABR doing the translation but the forward address is set to
10.10.234.4 which is the address of R4. This means that traffic doesn’t need
to pass through R3 to reach the R4 network. The router will lookup the
10.10.234.0/24 prefix and use the routing information to reach the
10.10.4.0 network. This is proven by a traceroute.

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 44 msec 44 msec 20 msec
  2 10.10.234.4 60 msec *  72 msec

What happens if the forwarding address network is not advertised? We will
do some filtering on R2.

R2(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise
R3(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise

R1#sh ip route 10.10.4.0
% Subnet not in table

There is no reachability for the network any longer? How can we resolve
this without removing the filtering?

We can tell R3 to suppress the FA in the LSA.

R3(config-router)#area 1 nssa translate type7 suppress-fa

The network is back and we have reachability but now traffic must pass
through R3 since the FA is not set.

R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.12.2 on FastEthernet0/0, 00:00:07 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 3.3.3.3, 00:00:07 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 52 msec 76 msec 48 msec
  2 10.10.23.3 36 msec 48 msec 40 msec
  3 10.10.234.4 72 msec *  72 msec

So by setting the FA we achieve more effecient routing. The reason to have
a forwarding address is to reduce the number of LSAs needed. If all ABRs were
doing type 7 to type 5 translation then there would be more LSAs than what is
optimal.

Lets take a look at the LSA now. Note that the FA will be set to 0.0.0.0.

R1#sh ip ospf data ex 10.10.4.0

            OSPF Router with ID (10.10.13.1) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 212
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x6218
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

By default the FA is always set when using NSSA areas. Now we take a look
at another use case where we have another routing protocol involved and
redistribution is done between the routing domains.

This is our example topology. Very similar to before. We just changed from
OSPF to RIP on the lefthand side.

R3 will be the router doing mutual redistribution between RIP and OSPF.
We will see that the FA will be set to 0.0.0.0. We check the route on R1.

R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.12.2 on FastEthernet0/0, 00:01:07 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 3.3.3.3, 00:01:07 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

R1#sh ip ospf data ex 10.10.4.0

            OSPF Router with ID (10.10.13.1) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 79
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x6616
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

As expected the FA is set to 0.0.0.0. This means that traffic must traverse
R3. We confirm with a traceroute.

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 64 msec 28 msec 24 msec
  2 10.10.23.3 68 msec 40 msec 40 msec
  3 10.10.234.4 96 msec *  76 msec

Now what happens if we enable OSPF on R3 interface towards R4?

R3(config-if)#ip ospf 1 area 0

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 56 msec 32 msec 24 msec
  2 10.10.234.4 60 msec *  72 msec

Traceroute is now takinig the shorter path. How did this happen? Take a
look at the LSA on R1.

R1#sh ip ospf data ex 10.10.4.0

            OSPF Router with ID (10.10.13.1) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 59
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0x7107
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.10.234.4
        External Route Tag: 0

The FA has now been set. How did this happen? The FA will be set for
external routes if we meet the following conditions.

  • OSPF is enabled on the ASBR’s next hop interface AND
  • ASBR’s next hop interface is non-passive under OSPF AND
  • ASBR’s next hop interface is not point-to-point AND
  • ASBR’s next hop interface is not point-to-multipoint AND
  • ASBR’s next hop interface address falls under the network range specified in the router ospf command.

 

So we have met all the conditions needed to set the FA. I hope that
you know have a better understanding of the forwarding address and
as usual always poste questions/feedback in the comments field.

Route redistribution – filtering and mitigating loops

January 30, 2012 6 comments

This post is about route redistribution and the different filtering techniques
we have available in our toolbelt. This post requires that you have a basic
understanding of route redistribution. For some good posts look at Petr
Lapukhovs posts at INE.

First lets define what is route redistribution? Generally we will use route
redistribution when multiple routing protocols are running in the network or
multiple instances of the same routing protocol is running. This can be due
to mergers, acquisitions or a fork lift upgrade. Maybe network is running
OSPF but is migrating to EIGRP or vice versa. We can also have redistribution
of connected and static routes.

What are some of the issues we can run into with route redistribution? We can
have routing loops in the network. These may not always be visible right away.
We can see them when doing a traceroute or when using debug ip routing.

We can also have issues with route feedback. Route feedback is when a redistributed
route gets redistributed back into the same protocol from which it originated. This
can lead to suboptimal routing or routing loops.

How do we define how “believable” a prefix is? First we must know that only the
same prefixes will be compared. 162.14.1.0/24 and 162.14.1.0/25 are not the same
prefixes. Longer match always wins! If we are comparing the two same prefixes
from different routing protocols then the AD will determine which one is the
best. Lower AD wins. If the AD for some reason is the same then the default AD
is the tie breaker.

Routes that are external should be less trusted than internal routes. EIGRP does
this by default by setting AD to 170 for external routes but 90 for internal. If
the other protocols did the same then we would not have issues with routing loops
at all. OSPF uses the same AD for internal and external prefixes (110) but we
can modify the AD for external routes if we want to. RIP does not have this
possibility.

Routing loops generally occur when we have redistribution between a protocol with
higher AD to a protocol with lower AD. This means that RIP is most often involved
in loops since it has the highest AD and we can’t define an external AD.

Lets look at a topology where loops can occur. This image is hand drawn and something
I do when doing labs to try to spot potential issues. I use a different color for
different protocols and draw arrows where redistribution occurs.

We are doing mutual redistribution on R1 and R2. The issue here is that we will
have suboptimal routing. You can download topology and configs here.

Look at the show ip route and traceroute from R1 to R2’s loopback.

R1 is going the whole way round even though it has a direct route via RIP to
R2. This is of course due to RIP having a higher AD than OSPF. Lets look at
a few different ways of fixing this. If this was the CCIE lab you would do nothing
unless it was asked of you to provide optimal routing. We don’t have a loop so it’s
not really a big issue at the moment. The issue here is that OSPF is not setting
a higher AD on it’s external prefixes. So we will have to do this manually.

So we set the AD to something higher than RIP, 121 in this case. Now we take
the direct path. Remember that AD is a local setting so this would have to be done
on all routers choosing suboptimal path.

We could also lower the AD of RIP. Either we do it for all routes or for a selection
of routes. Here we will select the routes with an ACL. We can set the distance for
all route sources or for a specific one based on the IP. Here we only have one so
we don’t really care, we will match on 0.0.0.0 255.255.255.255.

So now the AD is 109 for the RIP route which beats OSPF of 110. This would of course
also be have to be done on all routers with suboptimal path.

This is another way of doing it. We are setting a distance of 255 for the RIP routes
when they are entering as OSPF routes. 255 is not a valid distance for installing to
RIB so RIP routes will be preferred.

We can also use a distribute-list to control what routes get installed via OSPF.
Since OSPF is a link state protocl the LSA will of course propagate to other
routers.

As you can see the route is still present in the OSPF database but it does not
get installed into the RIB.

There is also a more fancy way of using distribute-lists. We can tie them to
a routing-protocol and define what is allowed to go out from that protocol
into the routing protocol that we are currently configuring. We will configure
R2 so that RIP routes are not allowed to be redistributed into OSPF. This will
kill any redundancy in the network.

So we go to the config mode of the routing protocol we are redistributing into.
Then we define with the distribute-list what is allowed to go out from other
protocols into the one we are now configuring. This is an effective way of
filtering when we have a lot of redistribution going on. In a small scenario
like this it does not make much sense but it’s very handy in large scenarios.

There is still one tool left and that is the route-map. The route-map is the
most flexible and scalable solution of all. We can choose what prefixes get
redistributed with an access-list or prefix-list. Lets try that first.

Here we matched prefixes with a prefix-list. The prefix-list has a deny for the
loopback of R2 and permits anything else. The route-map only has a permit statement,
deny in prefix-list and permit in route-map means that the prefix does not match
and moves to the next statement which is an implicit deny. The permit matches the
permit of the route-map and allows anything else.

This is an example of route feedback.

R5 is the only redistribution point. The issue here is that the routes that R3
learns from R1 and R2 via RIP will arrive at R5. R5 then redistributes into
OSPF. R3 will receive these LSA’s and find that this path is better due to a
lower AD. R3 will then install this route. R3 stops announcing that route via
RIP. R5 looses its route via RIP and can’t redistribute it into OSPF, so it
stops announcing it via OSPF. R3 installs the RIP route again and the fun
has just begun. Debug ip routing will show this procedure repeat over and over.

For our final tool we need a more complicated scenario to make full use of it.
First lets take a look at the topology. Download configs and topology here.

We have mutual redistribution on R3 and R5. The issue here is that we are
redistributing into RIP with a seed metric of 1. R3 sees R1’s loopback via
RIP with a metric of 2. R3 redistributes this information into OSPF. R5 learns
this information via OSPF and then redistributes into RIP with a metric of 1.
R3 now has two possible paths to R1 loopback. One with a metric of 1 and one
with a metric of two. Of course the lower metric wins. This means that R5
points towards R3 via R4 and R3 points to R5. Ladies and gentlemen, we have
a routing loop. There is definately a risk of loops when doing mutual redistribution.
When I redistribute something into RIP I usually set a quite high seed metric like 7.
This lowers the risk of loops because the RIP metric internally should be lower unless
it’s a very large network.

The probably best way to filter redistribution is to use route tagging. We set
a tag in a route-map and then base our filters on this. Sometimes it can be difficult
knowing where a route originated and from which protocol it came. If we set good tags
we can see both just by looking at the tag. I usually set a tag like 390, that means
that router 3 originated the route and it came from EIGRP. A tag of 4120 would mean
that it was a RIP route from R4 to begin with. Now lets try this technique as well.

We will set a tag of 3120 on R3 and also deny routes with a tag of 5110 on R3. This
is used to prevent R3 from taking OSPF routes from R5 received over RIP and then
redistributing them back into OSPF.

This is what the filtering looks like on R5.

Here we deny routes with a tag of 3120 and set our own tag of 5110.

Note that there is a risk that the loop still remains. R3 is announcing
routes via RIP natively to R5. We have a chicken and egg problem here.
This is the scenario before tagging. R3 redistributes RIP into OSPF. R5 receives
the routes and install them via OSPF since AD is lower than RIP. R5 then redistributes
these back into RIP. R3 sees the lower metric via R5 and installs this route in the
RIB. We now have a loop.

We start implementing tagging. R3 tags RIP routes going into OSPF
and denies any prefixes that R5 has already redistributed from OSPF to RIP.
R5 denies routes from R3 with a tag of 3120 from going back into RIP and sets
its own tag of 5110. There is a risk that R5 sees the best path via RIP to R3
and then announces an OSPF route which R3 installs. We need to make sure that
R5 sees the best path via OSPF to have a stable network. This can be done by
clearing routing table and shutting down links. To make sure this does not
happen we should also tag RIP routes going into OSPF on R5.

So you see that redistribution can be very complicated and there are a lot of
tools available. Try to check what routes are native to which routing protocol
and make sure that these are preferred in that domain. You can use distance
or other tools to make sure this happens.

In the real lab there could be hidden bombs that you need to detect to have a stable
topology. Probably you won’t be that restricted what you could do but there could
be some restrictions. So it’s good to have as many tools as possible. If all else
fails, do what it takes to get connectivity. Use distribute-lists or whatever
to have a stable topology. Yes, you will loose points but you can definately
not finish the lab if you don’t have a stable topology.

I hope this post has been informative and if you want to give med feedback
post in the comments section.

Multicast helper map and how to verify multicast

December 8, 2011 7 comments

The multicast helper map is an interesting feature. It can be used in scenarios where we want to transport broadcast. Routers don’t forward broadcast by default but we can convert this to multicast and transport it across our network and then convert it back to broadcast. Might not be that common in real life if you don’t work at a stock exchange but is fair game for the lab and a topic that we should not be surprised to see at the lab.

So the basic idea is to convert broadcast packets, transport them as multicast and then convert it back to broadcast. First lets look at our topology.

Multicast helper map topology

The idea here is to take broadcast coming from R1 in on R2 Fa0/0, convert it to multicast. Transport it to R3 which then converts it back to broadcast and sends it out to R4. Using this technology we can actually exchange routes between non adjacent routers, pretty cool?

You can download a .net file and initial configs for the routers here.

This is our assigned task:

Create a Loopback99 interface on R1 and assign it an IP address of 1.1.1.1/24; advertise this network on R1 using RIP v1 via FastEthernet0/0.

Configure R4 to receive the RIP advertisements from R1. You must use a multicast solution for this. In other words you may not configure solutions involving tunnel interfaces, enable RIP elsewhere than R1 and R4, use bridging, IPsec, magic, etc.

路 Use PIM dense mode only.

路 You may use a secondary IP address of 155.12.1.4/24 as part of your solution.

路 Use access list 120 for any lists you need.

路 You do not need to be able to ping 1.1.1.1 from R4

路 Use the multicast group 224.9.9.9

So we start by configuring R1. RIP version 1 is broadcast only and it does not include the subnet mask. All we need to do on R1 is configure RIP. We simply announce the network and leave the default settings which is to announce with version 1 and receive version 1 or 2. All the magic will happen on R2 and R3.

Then we proceed to configure R2. This is where most of the magic happens. We need to enable PIM dense mode on both Fa0/0 and S0/0. To be able to process switch the UDP RIP packets coming in we need to configure ip forward-protocol udp rip. Then we will configure the multicast helper map. Lets have a look.

So broadcast coming in on Fa0/0 matching access-list 120 is converted to multicast with a destination of 224.9.9.9. We are running PIM dense mode so later we should be able to see (S,G) entries in the mroute table.

We proceed to configure R3. The config will be very similar to R2.

On R3 we convert back 224.9.9.9 to the broadcast address of the segment between R3 and R4. We need to turn on directed broadcast otherwise we will not be allowed to send this packet out.

On R4 we simply turn on RIP. We were allowed to create a second subnet but lets wait with that.

So now everything should be running. However, we will have some issues. I am not running any IGP between R2 and R3. R3 will not know how to reach the source 155.1.12.1 so we will have a RPF failure which you can see below.

We can also see this if we check the mroute counters.

So how can we fix the RPF failure? We have a few different options. Either we need to run an IGP between R2 and R3 or we could add a static route or we could add a static mroute. This time I chose to use a static mroute because it is easy. Lets add that.

Now the traffic should be reaching R4. However the RIP rout will not be installed. This is because RIP validates the update source. If we receive an update from a non locally connected source the update will not be accepted. We can configure RIP to not validate the update source or we can configure a secondary IP address in same subnet as the source (we were allowed to do this according to the task).

Now we have the route installed. What will the multicast routing table look like? Lets look at R2 and R3. Since we are running dense mode we should only have (S,G) entries.

R2 has the (S,G) entry as expected. It has a flag of T since it is a SPT tree. We don’t have an incoming RPF neighbor since R1 is not running PIM.

Now we will look at R3.

We have R2 as the incoming RPF neighbor. RPF is done via static mroute. We have no outgoing interface. This is usually bad but since we are converting back to broadcast this is OK. If we do a debug of mpacket we will see an error message that OIL is null.

We have completed our task and if this was the lab we would stop here. To take it to the next step lets think what we would need to be able to have reachability from R4 to R1 loopback.

As we can see route recursion fails since we don’t know how to reach 155.1.12.1. Earlier we used a hack to not validate the update source. Lets remove this and add the secondary subnet to R4 instead.

Now the route recursion is working. R4 is using outgoing interface Fa0/0. This is Ethernet so we need to encapsulate the packet and send it to R1 MAC address. Usually we would send ARP request but the devices are not locally connected. Lets try adding a static ARP entry.

Traffic should be able to reach R3. R3 will not know how to reach 1.1.1.1 though. I’ll add static routes on R3 and R2.

Finally I’ll also add a static ARP entry on R1.

Now lets try a ping. It didn’t work. No matter how I try by adding static ARP entries and the correct routes I could not get the ping to succeed. I even tried on R4 to source traffic from 155.1.12.4 but that did not work either. I could see the traffic leaving R4 but not entering on R3. Very strange. If you have any suggestions post them in the comments section.

Categories: CCIE, Multicast Tags: , , ,

RIP timers

October 15, 2011 4 comments

RIP timers are the most basic thing in the world right? Even the command to set them is named timers basic… However in some documentation it is not really clear what the difference is between the invalid and holddown timer. The default timers are 30 for updates, 180 for invalid, 180 for holddown and 240 for flush. I have heard and seen described in official documentation that when a route is in holddown it will not accept routes with a worse metric but routes with a better metric. This is however not true. First lets describe the different timers.

Updates – Updates are sent every 30 seconds by default to the address 224.0.0.9.

Invalid – If there has not been any updates for 180 seconds about the prefix it is consider invalid and the route will be poisoned (route advertised with a metric of 16).

Holddown – The timer for holddown will be activated when the route goes into an invalid state. This is set to 180 by default.

Flush – This timer is set to 240 seconds, when a routes is 240 seconds old it is flushed from the routing table.

So the holddown timer is used to stabilize the topology, even better routes will be suppressed which is not what some documentation says. Here is how I tested it.

I created a topology with 3 routers connecting to each other and both the routers announced 1.1.1.1/32 to the middle router. I created an ACL on the middle router to filter all traffic so that the best route will become invalid. On the third router I used an offset-list to make the route worse. After the route became invalid I stopped sending the route with a worse metric and sent it with a better metric. However the route is still not installed until the holddown timer has expired. If you manipulate the timers it is easier to see. I used 5 seconds for updates, 30 for invalid, 30 for holddown and flush of 240. You will see that it takes 60s before the route gets installed.

If you use the standard timers the holddown timer will not expire before the route is flushed since the 180 seconds start counting after 180s by default and then there is only 60s left until the route is flushed. Try this out for yourself and see if you get the same results as I.

Here is a good link describing the timers.

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