OSPF over PPP Multilink problem

[rvr_76bg]

Hello folks,

I am opening new topic because the old one for my issue was unclearly explained.

OK, I have 2xT1 bundled in a PPP Multilink interface. Normally if one of this serial lines goes down the second has to keep the Multilink interface up but this is not the case in our network. When one of the lines goes down the OSPF between the Multilink interfaces on both sides is going down and I lose connection to the remote office for several seconds, then the adjacency comes back up. When the OSPF goes down all IP Phones reset which is unacceptable. These are the messages that I got in the router log:

Jan 20 16:39:49.170 EEST: %CONTROLLER-5-UPDOWN: Controller E1 0/1/1, changed state to down (LOF detected)

Jan 20 16:39:51.170 EEST: %CONTROLLER-5-UPDOWN: Controller E1 0/1/1, changed state to up

Jan 20 16:57:48.173 EEST: %OSPF-5-ADJCHG: Process 40, Nbr 192.168.x.x on Multilink1 from LOADING to FULL, Loading Done

A folk from the forum suggested “ppp multilink minimum-links 1” command to be inserted under both multilink interfaces.

I worry about this LOF detected. What does it mean? What is the problem with this link?

Regards,

rvr

[pauloroque]

From the log you sent, the ospf adjacency had gone down before the E1 went down. Also, the int Multilink1 didn't went down. Weird, isn''t it? Try to send the log for a longer period before and after the problem.

What the state of the multilink interface was in this very moment? Could you provide us with 'sh ppp multilink' command and the relevant config?

PRoque

[jglobermudez]

Hello,

I have a lot of PPP links that I can run with one link down all day long with no flapping. the diffrence is I am static routing to them. implement a static route if you can.

or tie the ospf to a loopback interface (be careful with that!!!! know what you are doing)

hope this helps

jb

[rvr_76bg]

Here is the output from sh ppp multilink:

Multilink1, bundle name is xxxxx

Endpoint discriminator is xxxxx

Bundle up for 4w0d, total bandwidth 3072, load 12/255

Receive buffer limit 24000 bytes, frag timeout 1000 ms

0/0 fragments/bytes in reassembly list

14018 lost fragments, 139597267 reordered

1163/876016 discarded fragments/bytes, 0 lost received

0xBD0973 received sequence, 0x9F2CE3 sent sequence

Member links: 2 active, 0 inactive (max not set, min not set)

Se0/1/0:0, since 5d09h

Se0/1/1:0, since 16:50:58

No inactive multilink interfaces

What do you guys think about the command ppp multilink minimum-links 1. I think it won't help because this is actually the default. Cannot provide you with the log, it was deleted.

rvr

[Giuseppe Larosa]

Hello Rumen,

the OSPF hello packets are IP packets that need to go through the PPP multilink bundle.

PPP multilink usually performs per packet load sharing and also fragmentation when needed.

My guess is that in your case OSPF hellos follow the same physical path (in one direction) so when one link fails and until that link is declared unusable some time is needed: for example at least 30 seconds if it has to wait for 3 PPP keepalive missing and the OSPF dead interval can fail too.

I would try to use a PPP keepalive lower then default 10 seconds in the hope to be able to keep OSPF adjacency up.

try

keepalive 3

Usually this kind of problems happens for example in etherchannel where a fixed load balancing rule is used.

Hope to help

Giuseppe

[royalblues]

Rvr

I have seen this issue with multilink..

There are 2 ways u can use to reduce the convergence time..

1) Remove the multilink and run ospf individually on both the links. The adjacency would be built over both the links in this case.. When one of the link fails, you will still some ping timeouts but the convergence is much faster than in multilink

2) enable OSPF fast hellos if the latency between the two routers is not much

HTH

Narayan

[francisco_1]

OSPF uses the metric aCost, which is related to the bandwidth. If there are equal cost paths (the same bandwidth on both multilinks), OSPF installs both routes in the routing table. The routing table tries to use both links equally, regardless of the interface utilization. If one of the links in the first multilink fails, OSPF does not send all the traffic down the second multilink. If the first multilink peaks 100%, OSPF does not send any traffic down the second multilink because OSPF tries to use both links equally, regardless of the interface utilization. The second is used fully only when the first multilink goes down.

Francisco

[rvr_76bg]

Thanks folks,

There are no 2 multilink bundles, it's only one that has 2xT1 combined in it.

rvr