From: Alexander Arsenyev (GU/ETL) (alexander.arsenyev@ericsson.com)
Date: Fri Oct 29 2004 - 07:53:34 GMT-3
Hello,
The idea is to "bundle" BRI and Serial into PPP Multilink therefore it will be
seen to OSPF as a single link. If there is a BW change downwards, with sufficiently high
"load-threshold" and sufficiently long "load-interval" the OSPF database could resynch
over Serial only leaving BRI idle. If there is a BW change upwards, then the OSPF database
could resynch over Serial+BRI putting some extra traffic to MLPPP (few old LSAs to be expired and few new
LSAs flooded).
SPF recalc indeed need to be done every time Serial load goes above certain mark or Serial goes down
in order to load-balance with BRI or reroute over b/bone but SPF on its own doesn't dial, it's new LSA
flooding which causes dialing.
Geert, have You been able to test the solution yet?
Cheers
Alex
-----Original Message-----
From: AdebolaA@mtnnigeria.net [mailto:AdebolaA@mtnnigeria.net]
Sent: 28 October 2004 14:54
To: Alexander Arsenyev (GU/ETL); geert.nijs@simac.be;
ccielab@groupstudy.com
Subject: RE: Backup and bandwidth-on-demand
Yes it does and you always have to nail the cost manually to guard against
your links flapping due to cost changes. If it is left like that, even when
you have the ISDN link setup as Dial-on-demand, it will see the change as a
change in the network an in order to synchronize will dial. Then you get an
enormous ISDN bill at the end of the month and a SPF recalculation that need
not be done.
See the link below
http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a0080
09481b.shtml#reason6
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Alexander Arsenyev (GU/ETL)
Sent: 28 October 2004 09:59
To: 'Geert Nijs'; ccielab@groupstudy.com
Subject: RE: Backup and bandwidth-on-demand
Hello Geert,
It seems that OSPF cost of MLPPP interface changes when number of links
change, see
http://www.cisco.com/warp/public/104/dcprob.html#reason6
The example shows MLPPP configured over Serials only, not sure about
Dialer+Serial.
HTH,
Cheers
Alex
-----Original Message-----
From: Geert Nijs [mailto:geert.nijs@simac.be]
Sent: 28 October 2004 09:53
To: Alexander Arsenyev (GU/ETL); ccielab@groupstudy.com
Subject: RE: Backup and bandwidth-on-demand
See Remarks below
________________________________
From: Alexander Arsenyev (GU/ETL) [mailto:alexander.arsenyev@ericsson.com]
Sent: Thu 10/28/2004 10:14
To: Geert Nijs; ccielab@groupstudy.com
Subject: RE: Backup and bandwidth-on-demand
Hello,
It looks like You have to differentiate between 2 scenarios:
1. Serial line fails -> BRI should stay down and traffic needs to be
rerouted via b/bone
2. Serial line reaches certain load -> BRI should connect and traffic split
between Serial and BRI.
>>>> This is exactly what i mean.
Also, if R1 and R2 are running OSPF and "connected to b/bone" it means to me
that Serial and BRI are NOT in area 0.
Is it correct? If yes then routes learned from b/bone will always be less
preferred (OSPF Inter-area) as opposed
>>> No. All links are in area 0. The serial (or BRI) just wins because it is
the shortest one.
to routes learned directly from OSPF neighbor connected via Serial/BRI (OSPF
Intra-area) and rerouting should happen automatically should Serial fail.
Is Serial link running PPP? If yes why not bundle BRI and Serial with PPP
Multilink and load-threshold?
>>> No.Serial is not running PPP.
>>>
>>> And even if the serial would be running multilink PPP, if the serial
failed, wouldn't the BRI (another channel) just take over ?
>>> Now that we mention this. Does the (ospf) metric cost of a mPPP bundle
change when a channel is added/removed ??
>>> If so, then we could manipulate the cost is such a way that, as long as
the serial is up, the serial + BRI is prefered. But when the serial is down,
the BRI cost would
>>> would be too high and rerouting would occur.
>>> Example:
>>> Cost via BB is 500. Put cost of 490 on serial and cost of 600 on bri
(dialer).
>>> If serial is up -> cost is 490
>>> If serial is up AND bri is up --> ?? cost would be less, because we have
more bandwidth. something like: 1 / ((1/490) + (1/600)) = 269.7 . Guys with
a background in
>>> electricity know what i mean, similar to two resistances in parrallel
:-)
>>> If serial is down, cost would be 600 for BRI, BB cost is less, so
rerouting would occur.
>>> mmmmmmm......great !!
>>> Is a Cisco router this smart ??
>>>
>>>
>>> Regards,
>>> Geert
HTH,
Cheers
Alex
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Geert Nijs
Sent: 27 October 2004 13:42
To: ccielab@groupstudy.com
Subject: Backup and bandwidth-on-demand
Hi group,
I have two routers R1 and R2 connected via a serial line and ISDN BRI, both
running OSPF
Both routers R1 and R2 are also connected to a backbone which runs OSPF.
The ISDN BRI is configured to provide bandwidth-on-demand with the backup
interface and backup load commands.
So when the load is high, the BRI kicks in to help the serial line. This
works fine.
The OSPF costs over the serial line and BRI line are equal, so that load
balancing occurs when both lines are active.
However, in a failure scenario of the leased line, i don't want to run
exclusively over the BRI lines (half of the bandwidth).
Actually, if the leased line fails, i don't want BRI backup, but rerouting
across the backbone.
The problem is, that due to the backup interface command on the serial line,
in case of failure, the BRIs get
activated immediatly and since i am running a routing protocol over the
BRIs, the BRIs become the preferred route.
I can't change the cost over BRI since i'll have to change the cost over the
serial lines also (to keep them equal for load-balancing).
I have been breaking my head on this issue, but i cannot think of a feature
that Cisco provides to overcome this issue.....
So if you have any information, links, hints.....
Regards,
Geert
############################################################################
#########
This e-mail and any attached files are confidential and may be legally
privileged.
If you are not the addressee, any disclosure, reproduction, copying,
distribution,
or other dissemination or use of this communication is strictly prohibited.
If you have received this transmission in error please notify Simac
immediately
and then delete this e-mail.
Simac has taken all reasonable precautions to avoid virusses in this email.
Simac does not accept liability for damage by virusses, for the correct and
complete
transmission of the information, nor for any delay or interruption of the
transmission,
nor for damages arising from the use of or reliance on the information.
All e-mail messages addressed to, received or sent by Simac or Simac
employees
are deemed to be professional in nature. Accordingly, the sender or
recipient of
these messages agrees that they may be read by other Simac employees than
the official
recipient or sender in order to ensure the continuity of work-related
activities
and allow supervision thereof.
############################################################################
#########
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:54 GMT-3