IGRP UPDATE PROBLEM
Lennart Blomstr|m
We have had a very serios problem since May this year. It started with
one of the customers to our netprovider, changed his uppdete time in
IGRP from 90s to 10s. That caused some of the most adjacent routers in
the netproviders backbone to change form 90 to 10 sec, witch caused a
lot of access-routers ,all Cisco, to start getting strange losts of
routes. Great part of the netproviders and cutomers networks was
infeted with update times at 10 sec. The rote losts was easy
explained. Routers interface running 10s update will lose
routers running 90s update after the 30s holddown and will see them
again , for 40s, after 60s when a new update comes. This causes routes
to be up 40s and gone 60s if you are an adjacent routers. An other
problem noticed is that the same IGRP process can have 90s on some
interfaces and 10s on others. If you look in "sh ip pro" it says that
the IGRP process runs with 90s update even thou it does not. If you
turn the router off if will change its update time, to what ever
adjacent routers run, when you porwer it up again.
This follows no specific pattern as far as I have seen yet.
I have also seen a router changing its updatetime on one interface
when an adjacent router on the same ethernet lost its connection with
it's neibour over a serial line.
It does not depend on revision, size or modell of the router. The common thing
is Cisco and IGRP.
This is a very serios problem, that Cisco has been working on since May
and have not solved yet. The worst is that you can not rely on the
network when you dont have control over wath is happening.
Is IGRP a protocol that can not be used by netproviders if you dont
have control of all routers running it ?
Has anyone else experienced this major problem ????
Any hints of what to do other than to skip IGRP???
Be ware this can happen to you!!!!
Blomman
--------------------------------------------------------------------
Lennart Blomstrom Telefon: +49 8 7071226
TELIA DATA AB Fax: +49 8 70712
Z53:07
Box 164 Email: blo...@tvt.se
S136 23 HANINGE
SWEDEN
--------------------------------------------------------------------
Tony Li
Wow. Well, this is interesting...
We have had a very serios problem since May this year. It started with
one of the customers to our netprovider, changed his uppdete time in
IGRP from 90s to 10s. That caused some of the most adjacent routers in
the netproviders backbone to change form 90 to 10 sec, witch caused a
lot of access-routers ,all Cisco, to start getting strange losts of
routes. Great part of the netproviders and cutomers networks was
infeted with update times at 10 sec. The rote losts was easy
explained. Routers interface running 10s update will lose
routers running 90s update after the 30s holddown and will see them
again , for 40s, after 60s when a new update comes.
This sounds like not all routers in the autonomous system have
consistent timers. This is a configuration problem.
This causes routes
to be up 40s and gone 60s if you are an adjacent routers. An other
problem noticed is that the same IGRP process can have 90s on some
interfaces and 10s on others. If you look in "sh ip pro" it says that
the IGRP process runs with 90s update even thou it does not. If you
turn the router off if will change its update time, to what ever
adjacent routers run, when you porwer it up again.
Interesting. There is no code to do this. I've never seen this behavior.
This follows no specific pattern as far as I have seen yet.
I have also seen a router changing its updatetime on one interface
when an adjacent router on the same ethernet lost its connection with
it's neibour over a serial line.
There is not update time per interface. There is one single update
timer. When it expires, all interfaces get updated.
This is a very serios problem, that Cisco has been working on since May
and have not solved yet. The worst is that you can not rely on the
network when you dont have control over wath is happening.
Interesting. Got a ticket number from the TAC for me? It certainly
hasn't made it to my attention...
Is IGRP a protocol that can not be used by netproviders if you dont
have control of all routers running it ?
IGRP assumes consistent settings of several parameters within the
autonomous system. If you cannot guarantee that, then you should
consider another alternative. Note that most (all?) IGPs currently
assume consistent configuration within the autonomous system, so just
changing protocols will not solve anything. You have a basic design
problem here.
You can solve this in many ways. You can use separate IGRP processes
for talking to other organizations, you can use an EGP protocol (EGP
or BGP), etc....
Tony
Vadim Antonov
: If you are going to be doing
: exterior routing, then you need to use an exterior routing protocol -
: like EGP or (better) BGP.
Of course, there is a catch -- you can't do load balancing with
existing EGP or BGP. Fortunately it's rarely needed. In any case
it's a good idea to filter out *all* incoming IGP information. We
have had troubles with customers feeding bogus routes into backbone IGRP.
--vadim
Thomas P. Brisco
We've got a configuration that (I believe) is similar to yours -
we have direct "back door" connections to other local Universities.
The trick is to keep your IGRPs seperate when crossing administrative
domains - which is a good idea anyway.
The setup is (in all cases) like:
1) We run IGRP with 15 second update periods
2) they don't - typically theirs is 90 seconds (default)
Set up two IGRP processes, one is just a "gateway" process -
below you'll see references to three IGRP processes, one is what
we share with the other site, a transitional one, and our internal
one. They have a Class B and C, we have a class B, we want to
share a class C.
router igrp 46 ! our information
network xxx.yyy.0.0 ! a class B that we have
network xxx.yyy.zzz.0 ! a class C that we *share*
timers basic 15 45 0 60 ! our timers
redistribute igrp 2 ! redistribute the learned information
no metric holddown ! what we prefer ...
router igrp 2 ! imported routes - router internal only
network xxx.yyy.zzz.0 ! the shared network
passive-interface 3 ! don't propigate our router internal
! routes to them
distribute-list 4 ! strangle propigation of their backdoors
no default-info in ! don't do the obvious
router igrp 7 ! share into their IGRP
network xxx.yyy.zzz.0 ! the shared network
distance 200 ! make them look ugly
distribute-list 3 in ! handle only administrative acceptable routes
no default-info in ! don't do the obvious
access-list 4 permit ttt.yyy.0.0 ! their class B
access-list 4 permit ttt.yyy.zzz.0 ! one of their class C's
access-list 3 permit eee.yyy.zzz.0 ! external provider's class B
! this allows us to propigate
! a default external route
Here IGRP 46 is our internal IGRP, IGRP 7 is their internal
IGRP, IGRP 2 is a buffering and filtering process that runs on
this particular router only - it permits only their own networks.
IGRP 46 updates our side for the "shared" network because
the router has an interface on it. IGRP 7 picks up their routes
and hands it to IGRP 2, which filters it of any bogons or backdoors
they may have. IGRP 7 talks to their IGRP 7. IGRP 7 picks up
our class B network. Both 7 and 2 suppress propigatio of exterior
routes.
This could probably be done with 2 IGRPs if I were more brave ...
Tp.
In <7495385...@news.Colorado.EDU>, blo...@palantir.p.tvt.se (Lennart Blomstr|m) says
...!rutgers!brisco (UUCP) bri...@pilot.njin.net (Internet)
brisco@ZODIAC (BITNET) 908-932-2351 (VOICE)
T.P. Brisco, Associate Director for Network Operations,
Computing Services, Telecommunications Division
Rutgers University, Piscataway, NJ 08855-0879
Just say "Moo"
Hakan Hansson
>I think that your real problem is that you are trying to use an
>interior routing protocol for exterior routing. This does not work &
>you run into problems (as you have found out).
>
>Interior routing protocols should only be run on routers with a common
>administration (and thus, presumably, with the same (or compatible)
>configurations on all of the routers involved).
>
>Once you start violating this, then you have to be real careful, or you
>run into problems (like you have discovered).
>
>This happens with any interior routing protocol - like RIP, IGRP or
>OSPF and with any router from any vendor. If you are going to be doing
>exterior routing, then you need to use an exterior routing protocol -
>like EGP or (better) BGP.
>
Andrew & others,
Now I have more and more realized that EGP (BGP) should not only be used by
service providers, but also by their customers, for implementing routing
policies. This was also advised by Cisco at their Networkers Europe
conference in Paris recently (to be able to connect to more than one
provider). (As you might understand, we are using IGP protocols to talk to
our customers in TIPnet).
But, what happens if all service providers starts exchange routing info with
their customers networks by using BGP/EGP? According to applicalble RFC:s
the maximum numbers of AS's that can be assigned is 65,535 (or a 16 bits
number). I believe that we have to re-design the BGP protocol to be able to
assign sufficient amount of AS numbers, or? (Suddenly the IP number space is
not the current problem....)
Does anyone else have an opinion in this matter?
/Hakan Hansson
== Unisource Business Networks Sweden
== Unidata IP Services * TIPnet NMC * Gothenburg
== phone +46-31-7708072 * fax +46-31-114664
*** Aktiv medlem i '8:e bit:ens vdnner' ***
Daniel Karrenberg
> h...@tip.net (Hakan Hansson) writes:
> ...
> But, what happens if all service providers starts exchange routing info
> with
> their customers networks by using BGP/EGP? According to applicalble RFC:s
> the maximum numbers of AS's that can be assigned is 65,535 (or a 16 bits
> number). I believe that we have to re-design the BGP protocol to be able
> to assign sufficient amount of AS numbers, or?
> (Suddenly the IP number space is not the current problem....)
>
> Does anyone else have an opinion in this matter?
1) 64K is a lot if you consider that we are currently routing less than 10k
nets, we could easily give each *net* its own AS today.
2) BGP-4 is not the ultimate routing protocol. IDRP has a pretty big space
for this (don;t remember exactly).
But still prudent use of the AS numbers is certainly a good thing:
3) only multi-homed customers need their own AS number. Single homed can
go in the AS of the SP.
4) also it is not necessary to have a unique AS number for isolated nets just
because the routers want one configured
Daniel
Hakan Hansson
>
> > h...@tip.net (Hakan Hansson) writes:
> > ...
> > But, what happens if all service providers starts exchange routing info
> > with
> > their customers networks by using BGP/EGP? According to applicalble RFC:s
> > the maximum numbers of AS's that can be assigned is 65,535 (or a 16 bits
> > number). I believe that we have to re-design the BGP protocol to be able
> > to assign sufficient amount of AS numbers, or?
> > (Suddenly the IP number space is not the current problem....)
> >
> > Does anyone else have an opinion in this matter?
>
>
>1) 64K is a lot if you consider that we are currently routing less than 10k
> nets, we could easily give each *net* its own AS today.
>
>2) BGP-4 is not the ultimate routing protocol. IDRP has a pretty big space
> for this (don;t remember exactly).
>
>But still prudent use of the AS numbers is certainly a good thing:
>
>3) only multi-homed customers need their own AS number. Single homed can
> go in the AS of the SP.
And then run internal-BGP/EGB. OK.
>
>4) also it is not necessary to have a unique AS number for isolated nets just
> because the routers want one configured
>
>Daniel
Daniel,
This use of EGP protocols is then a very good reason for our customers to
prefer class-C networks instead of class-B, since it is impossible(?) to
route between subnets using EGP. Thanks!
Then we have a small problem, though:
Our network is designed to carry several customers class-B networks, which
are spread geographically. The network continuity is done through our
network, which require us to run IGP.....
The only solution seems to be: Re-design our network (and several of our
customers also!)!
Are there any volunteers out there? :-)
/Hakan
Willi.Por...@gmd.de
>
> Now I have more and more realized that EGP (BGP) should not only be used by
> service providers, but also by their customers, for implementing routing
> policies. This was also advised by Cisco at their Networkers Europe
> conference in Paris recently (to be able to connect to more than one
> provider). (As you might understand, we are using IGP protocols to talk to
> our customers in TIPnet).
>
> their customers networks by using BGP/EGP? According to applicalble RFC:s
> the maximum numbers of AS's that can be assigned is 65,535 (or a 16 bits
> number). I believe that we have to re-design the BGP protocol to be able to
> assign sufficient amount of AS numbers, or? (Suddenly the IP number space is
> not the current problem....)
>
> Does anyone else have an opinion in this matter?
>
Yes, it really would be a problem if evey customer would get it's own
AS number. This is really not what we want.
Using as AS number means that you are following the routing policy
defined for this AS (see ripe-81).
Customers should NOT apply for their own AS number.
Instead the normal way should be that a customer gets its AS assigned from its
service provider who groups sets of customers that have the same routing policy
into a single AS.
Normaly this makes no big problem as the major set of customers is single homed.
-- Willi
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Willi Porten-Herzig GGGGG M M DDDDDD Email: porten...@gmd.de
GeNeRIC.DFNNOC G G MM MM D D Tel. + 49 2241/ 14 3190
GMD (German National G M M M M D D FAX + 49 2241/ 14 3002
Research Center for G GGGG M M M D D
Computer Science) G G M M D D Anything regarding DFN-IP
Rathausallee 10 G G M M D D email to 'dfn...@gmd.de'
D-53757 Sankt Augustin GGGGG M M DDDDDD and never personally to me!
Hakan Hansson
>So you just run the IGP to them and export it as part of your AS?
No, because the original problem was:
We should *not* run IGP to networks we have no control of (read: our
customers ones), because of inconsistent update timers in Cisco's IGRP. This
is the current advise from Cisco.
/Hakan
Daniel Karrenberg
> h...@tip.net (Hakan Hansson) writes:
> Then we have a small problem, though:
> Our network is designed to carry several customers class-B networks, which
> are spread geographically. The network continuity is done through our
> network, which require us to run IGP.....
Yep. But then these cannot be engineered easily to be multi-homed, can they.
So you just run the IGP to them and export it as part of your AS?
> The only solution seems to be: Re-design our network (and several of our
> customers also!)!
> Are there any volunteers out there? :-)
No, see above.
Daniel
Peter Lothberg
If you have more than one gateway talkig to an external peer, you need
to have IBGP between atleast those. (And inject full routing into your
IGP, or run a full mesh of IBGP and only carry internal information
(non-syncronize.))
> This use of EGP protocols is then a very good reason for our customers to
> prefer class-C networks instead of class-B, since it is impossible(?) to
> route between subnets using EGP. Thanks!
As we are rapidly moving towards a CIDR/BGP-4 speaking global
Internet, EGP (the protocol) is useless as soon as you have more than
one path to the outside world.
(CIDR, Default or DIE!)
BGP-4 is classless, so it might be usefull to solve some of your
problems with subnets.
> Then we have a small problem, though:
> Our network is designed to carry several customers class-B networks, which
> are spread geographically. The network continuity is done through our
> network, which require us to run IGP.....
This is a baad idea, as you then has to become part of the customers
IGP. A way of migrating from the current scenario to a 'clean'
solution maybe to to IP-over-IP tunnels between your customer routes.
> The only solution seems to be: Re-design our network (and several of our
> customers also!)!
This is no news, good reading might be Ripe-81 (the tutorial section),
and this problem shows up as soon you start to talk about multiple
interconnects between networks (AS;es).
> Are there any volunteers out there? :-)
And please, when you redo things, think about BGP-4/CIDR.
-Peter
Vadim Antonov
providers and regional networks (and in some cases multi-homed customers).
The regular customers are served with the aid of static routes, therefore
when they connect a new network they have to inform us. Actually it
is good because it's the only way to prevent injecting duplicating or
bogus network announcements into the global Internet.
--vadim
hen...@oar.net
>customers ones), because of inconsistent update timers in Cisco's IGRP. This
>is the current advise from Cisco.
No, this isn't stated correctly. This should be:
You shall not extend your IGP to networks you have no control of due to
the implicit model of trust inherent in IGPs. You will always filter
incoming routing announcements so as not to corrupt your IGP (and,
generally, make your life easier).
henry
Daniel Karrenberg
> Peter Lothberg <ro...@Slaptoy.Stupi.SE> writes:
>
> ...
>
> BGP-4 is classless, so it might be usefull to solve some of your
> problems with subnets.
>
> > Then we have a small problem, though:
> > Our network is designed to carry several customers class-B networks, whic
> h
> > are spread geographically. The network continuity is done through our
> > network, which require us to run IGP.....
>
> This is a baad idea, as you then has to become part of the customers
> IGP. A way of migrating from the current scenario to a 'clean'
> solution maybe to to IP-over-IP tunnels between your customer routes.
Of course Pter is right here!
My brain just had a very bad day yesterday :-(
> > The only solution seems to be: Re-design our network (and several of our
> > customers also!)!
>
> This is no news, good reading might be Ripe-81 (the tutorial section),
> and this problem shows up as soon you start to talk about multiple
> interconnects between networks (AS;es).
>
> > Are there any volunteers out there? :-)
>
> And please, when you redo things, think about BGP-4/CIDR.
Seconded!