Archive

Posts Tagged ‘Redistribution’

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.

Route redistribution – Route-maps and tagging

August 16, 2012 2 comments

Earlier I have done some posts on route redistribution and on
route filtering in different protocols. I wanted to expand on this
by showing different ways we can tag and do filtering with route-maps
when doing route redistribution.

We start out with this topology where two different OSPF segments are
separated by an EIGRP segment.

R2 will redistribute between OSPF and EIGRP mutually. R1 is redistributing
its loopback so it will be an external OSPF route. R4 and R5 will mutually
redistribute between EIGRP and OSPF. One interesting aspect about EIGRP is
that in the EIGRP packet we can see which protocol that originated the
route from the beginning. Take a look at this output showing the R1 loopback
in the EIGRP domain.

R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560002816
  Routing Descriptor Blocks:
  10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.24.2
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that it came from OSPF 1 and that the ASBR is 10.10.24.2.
We also see that it had a metric of 20 and no tag applied to it. Where
is this information carried? Take a look at this packet capture.

We can see that a lot of information is carried for external routes.
This gives us options when doing tagging and filtering.

We configure distribution on R2 and then look at our options for doing
tagging and filtering.

R2#sh run | s router
router eigrp 100
 redistribute ospf 1 metric 1 1 1 1 1

If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.

R4#sh ip route eigrp | i EX
D EX    10.10.1.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0
D EX    10.10.12.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0

If we traceroute this traffic will go straight to R2.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 32 msec 40 msec 28 msec
  2 10.10.12.1 60 msec *  64 msec

What if we want external routes to go through R5 instead? We can
match on the route-type and incoming interface to block R2 routes.
This is a pretty blunt tool but can be good for some scenarios.

R4(config)#route-map RM_DENY_EXT_FA0/0 deny 10
R4(config-route-map)#match route-type external
R4(config-route-map)#route-map RM_DENY_EXT_FA0/0 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FA0/0 in fa0/0

So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?

R4#sh ip route eigrp | i EX
D EX    10.10.1.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1
D EX    10.10.12.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1
R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 40 msec 36 msec 16 msec
  2 10.10.35.3 56 msec 40 msec 40 msec
  3 10.10.23.2 48 msec 28 msec 44 msec
  4 10.10.12.1 68 msec *  68 msec

Now all external routes will go through R5 instead.

Currently we are not doing redistribution on R4 and R5. What will
happen with the EIGRP external routes when we do redistribution?
First we remove the previous configuration and then we configure
redistribution.

R4(config)#router eigrp 100
R4(config-router)#no distribute-list route-map RM_DENY_EXT_FA0/0 in FastEthernet0/0
R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 sub
R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 1 1 1 1 1
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 sub

From R4 we now look at how it reaches 10.10.1.0/24.

R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "eigrp 100", distance 170, metric 2560002816, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from 10.10.45.5 on FastEthernet0/1, 00:00:52 ago
  Routing Descriptor Blocks:
    10.10.45.5, from 10.10.45.5, 00:00:52 ago, via FastEthernet0/1
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1
  * 10.10.24.2, from 10.10.24.2, 00:00:52 ago, via FastEthernet0/0
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

Why does it have two entries for 10.10.1.0/24? Take a look in the
EIGRP topology table.

R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2560002816
  Routing Descriptor Blocks:
  10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.24.2
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)
  10.10.45.5 (FastEthernet0/1), from 10.10.45.5, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.56.5
        AS number of route is 10
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that one route is originating from OSPF 1, which is the true
source of the route and one is originating via OSPF 10. R5 is learning
this route via OSPF and then redistributing it into EIGRP and R4 is
learning that via EIGRP. Let us confirm that R5 sees this as an OSPF
route.

R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1 1 1 1 1
  Last update from 10.10.56.6 on FastEthernet1/0, 00:08:12 ago
  Routing Descriptor Blocks:
  * 10.10.56.6, from 10.10.46.4, 00:08:12 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

Which it does. What would happen if R5 was redistributing with a
better metric than R2 is doing? First we enable debugging of ip
routing on R4. Remember that in a stable topology where everything
is converged there should be no changes.

R4#debug ip routing
IP routing debugging is on

Then we change the metric on R5.

R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 100000 10 255 1 1500
RT: eigrp's 10.10.1.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to 

[170/30720]
RT: del 10.10.1.0/24 via 10.10.24.2, eigrp metric [170/2560002816]
RT: NET-RED 10.10.1.0/24
RT: NET-RED 10.10.1.0/24
RT: eigrp's 10.10.12.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to 

[170/30720]
RT: del 10.10.12.0/24 via 10.10.24.2, eigrp metric [170/2560002816]
RT: NET-RED 10.10.12.0/24
RT: NET-RED 10.10.12.0/24

We can see that the metric change but at least we have no flapping.

R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "eigrp 100", distance 170, metric 30720, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from 10.10.45.5 on FastEthernet0/1, 00:02:33 ago
  Routing Descriptor Blocks:
  * 10.10.45.5, from 10.10.45.5, 00:02:33 ago, via FastEthernet0/1
      Route metric is 30720, traffic share count is 1
      Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Do we still have reachability?

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 40 msec 16 msec 28 msec
  2 10.10.56.6 48 msec 32 msec 28 msec
  3 10.10.46.4 24 msec 44 msec 28 msec
  4 10.10.45.5 52 msec 48 msec 52 msec
  5 10.10.56.6 60 msec 60 msec 64 msec
  6 10.10.46.4 64 msec 60 msec 60 msec
  7 10.10.45.5 84 msec 108 msec 100 msec

Now we have a routing loop. What is happening here is that R4
is learning the route first via EIGRP and redistributes it into
OSPF. R5 learns this route via OSPF and then redistributes it
back into EIGRP and then R4 learns this route. They are now
both pointing at each other which means we have a loop.

What are our options of solving this? One way of solving it is
to increase the OSPF external AD on R5. That way R5 should not
redistribute it back to R4.

R5(config-router)#distance ospf external 180

R4#sh ip route 10.10.1.1
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.46.6 on FastEthernet1/0, 00:00:38 ago
  Routing Descriptor Blocks:
  * 10.10.46.6, from 10.10.56.5, 00:00:38 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.46.6 56 msec 36 msec 16 msec
  2 10.10.56.5 48 msec 40 msec 40 msec
  3 10.10.35.3 52 msec 52 msec 52 msec
  4 10.10.23.2 112 msec 76 msec 72 msec
  5 10.10.12.1 96 msec *  120 msec

That solved the loop changing the distance is a bit of a hack unless
we incorporate the same policy on all devices. At least all devices
involved in redistribution should have the same policy.

R4(config)#router ospf 10
R4(config-router)#distance ospf external 180

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 28 msec 32 msec 12 msec
  2 10.10.12.1 44 msec *  60 msec

Yes, that solved it. A more elegant way is to use tagging and
filtering. We remove the previous distance commands.

What we can do now is to tag all external routes coming from OSPF 1
and then deny those routes from coming in if they have a tag set.
On R4 we tag routes with tag 444 and on R5 we will tag with 555.
First we confirm that the loop is back. You should note that with
redistribution you may see different results than I due to order of
operation. If that happens you could shutdown R5 link to R3 and
the loop should be back.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 16 msec 44 msec 24 msec
  2 10.10.56.6 36 msec 28 msec 36 msec
  3 10.10.46.4 32 msec 40 msec 32 msec
  4 10.10.45.5 48 msec 56 msec 48 msec
  5 10.10.56.6 64 msec 56 msec 68 msec
  6 10.10.46.4 48 msec 64 msec 60 msec

It is still there. Time for some route-maps.

R4(config)#route-map RM_DENY_EXT_FROM_R5 deny 10
R4(config-route-map)#match tag 444
R4(config-route-map)#route-map RM_DENY_EXT_FROM_R5 permit 100
R4(config-route-map)#route-map RM_SET_TAG_444 permit 10
R4(config-route-map)#match source-protocol ospf 1
R4(config-route-map)#match route-type external
R4(config-route-map)#set tag 444
R4(config-route-map)#route-map RM_SET_TAG_444 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R5 in
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_444 sub

First we will confirm on R5 that we now see a tag.

R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20
  Tag 444, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 100000 10 255 1 1500
  Last update from 10.10.56.6 on FastEthernet1/0, 00:00:48 ago
  Routing Descriptor Blocks:
  * 10.10.56.6, from 10.10.46.4, 00:00:48 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1
      Route tag 444

We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.

R6#sh ip route 10.10.24.0
Routing entry for 10.10.24.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 10.10.56.5 on FastEthernet0/1, 08:28:39 ago
  Routing Descriptor Blocks:
    10.10.56.5, from 10.10.56.5, 08:28:39 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1
  * 10.10.46.4, from 10.10.46.4, 08:30:34 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

There should be no loop on R4 now. We will test with a traceroute.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 28 msec 44 msec 12 msec
  2 10.10.12.1 36 msec *  48 msec

The loop is gone. We should implement the same policy on R5 so if
R4 sends routes back to R5 it should stop it from learning them.

R5(config)#route-map RM_DENY_EXT_FROM_R4 deny 10
R5(config-route-map)#match tag 555
R5(config-route-map)#route-map RM_DENY_EXT_FROM_R4 permit 100
R5(config-route-map)#route-map RM_SET_TAG_555 permit 10
R5(config-route-map)#match source-protocol ospf 1
R5(config-route-map)#match route-type external
R5(config-route-map)#set tag 555
R5(config-route-map)#router eigrp 100
R5(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R4 in
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_555 sub

And that concludes this lesson. Route redistribution is always fun 🙂
You can look at some of my older posts for more ideas about filtering
routes.

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.

Redistribution lab in GNS3/Dynamips

July 29, 2011 8 comments

At first I had some trouble understanding route redistribution. I’ve tried getting better at it and now I have a solid understanding of it. Darren did some labs on his blog and I decided to give it a go as well. It is really good practice to create a lab of your own. Surprisingly it is more difficult than one would expect to create tricky scenarios, this is my go at it.

This is the topology.

The goal of the lab is to achieve full reachability and provide optimum routing. Since all links have the same bandwidth the fewer number of hops the better the route (try staying inside the routing domain if possible).

Follow these steps in order:

  • Configure mutual redistribution between RIP and EIGRP on R5
  • Configure mutual redistribution between OSPF and EIGRP on R3
  • Configure mutual redistribution between OSPF and EIGRP on R2
  • Configure mutual redistribution between RIP and OSPF on R7
  • Configure mutual redistribution between RIP and OSPF on R8

All interfaces have been preconfigured with IP-adresses.

Download the topology and initial config here. Post your findings in the comments section.

 

Categories: CCIE, Routing Tags: , ,