OSPF towards Cisco, LLS

[vinceneil666]

Hi,

Anyone have any experience with the LLS (L-bit) that most Cisco will have enabled default. As far as I can see in the logs my Cisco box will send with option 0x52, and the Fortigate will send with option 0x42 (that I figure is the LLS option)

I am having issues with ospf flapping massivly between loading/full on the Cisco end - and was wondering if anyone else have looked into this..and if it do have an impact ? 

[Antonio_Milanese · Accepted solution]

Hi Vince,

i dubt that having L-bit set in Hello/DBD packets it's the main issue and personally never had a interoperability problem (cisco,hpe,dell/force10,fortigate shop here) since as per RF2328/4813 if the router does not implement LLS extensions at minumum simply ignore L-bit and if support some standard or private extensions (NSF,Gracefull Restart,ecc) it can check/parse TLVs to see if it's supported....

but you can always turn off LLS per interface basis if you want a direct confirmation that's an interoperability bug/issue.

Anyway maybe knowing the cisco IOS/NX and FOS version can help and the output of

on cisco:

show ip ospf neighbor CISCO_INT detail

show ip ospf interface CISCO_INT detail

on FGT:

get router info ospf interface FGT_INT_NAME

get router info ospf nei detail all

since your the adjacency it's formed and not stucked before FULL state but it's flapping i'm expecting that you have exeeded retrasmissions or there is another trasmission problem

another good idea it's to turn on

debug ip ospf adj

Other questions:

- have you Gracefull restart enabled ? and if yes how it's configured on cisco and fortigate? LLS or Opaque LSA ?

- are you establish an adj via virtual link ?

- message digest auth ?

- bfd enabled ?

Well...enogh questions for now =)

Regards,

Antonio

[HA]

Hello,

Also, check if the MTU is same. If not change change the MTU on both devices or enable ospf mtu ignore...

Regards,

HA

[vinceneil666]

Hi, tnx :) 

I know - me either. But I am just stuck, and the only thing I can think of..or that I can find is the L bit.. but yeah. :) 

TROUBLE-cisco-NODE1#sh ip ospf neighbor vlan xxx detail

Neighbor x.x.x.x, interface address x.x.x.x In the area 0 via interface Vlanxxx Neighbor priority is 1, State is FULL, 1680 state changes DR is x.x.x.x BDR is x.x.x.x Options is 0x2 in Hello (E-bit) Options is 0x42 in DBD (E-bit, O-bit) Dead timer due in 00:00:35 Neighbor is up for 00:00:19 Index 3/3, retransmission queue length 0, number of retransmission 679 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 4 msec

It is up for, aprox 50 seconds, then restarts.

 my log fills up with this.:

Sep 5 10:20:39: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR1 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:20:53: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR2 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:21:19: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR1 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:21:41: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR2 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:22:08: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR1 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:22:31: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR2 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:22:57: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR1 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:23:20: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR2 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:23:39: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR1 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:24:01: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR2 on Vlanxxx from LOADING to FULL, Loading Done Sep 5 10:24:20: %OSPF-5-ADJCHG: Process 1, Nbr FORTIGATE-NR1 on Vlanxxx from LOADING to FULL, Loading Done

On both Cisco and FTG: cisco : Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

forti: Timer intervals configured, Hello 10.000, Dead 40, Wait 40, Retransmit 5

MTU is 1500 on the interfaces, but this is runnin over a REP ring with higher mtu. But for the OSPF interfaces they are on 1500.

Network Type BROADCAST on both..

The thing is, as I have looked into this. I see that I have a Cisco box working fine. So everything points in the direction of the problem cisco box.. but they are runnign same software - exactley same. C4500X's with 

ROM: 15.0(1r)SG10 , Version 03.07.01.E

All interfaces are fine..  hm :) .. 

[Antonio_Milanese]

Hi Vince,

vinceneil666 wrote:
Index 3/3, retransmission queue length 0, number of retransmission 679 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 4 msec

umm there are quite a lot of retransmission... since the adjacency reaches FULL state and they have agreed to all parameters (MTU included) i can only think about the problem may originate from: 1) when you they are starting to exchange non type 1/2 LSA and there is a "real" MTU difference on the path (more later) 2) the interface on one side (FGT?) it's flapping or have collisions/crc/phy problems 3) the interface or underline vlan it's blocked by REP even if it's a regular port f.e for xSTP bad interaction or if you have REP VLAN load-balance and misconfigured vlans someware inbetween  

vinceneil666 wrote:
MTU is 1500 on the interfaces, but this is runnin over a REP ring with higher mtu. But for the OSPF interfaces they are on 1500.

I must admit that i'm not a big fan of REP since the first time I discovered it.. I think that's a medicine(hack) worse than the ill it's supposed to cure (xSTP) expecially on metro deployment but let's forget my opnions.. you say that there is an underline bigger MTU... what are the values of  system MTU / routed MTU and of course interface (IP) MTU..it's the FGT  directly connected to the REP segment members, and if yes the outgoing interface it's configured as switchport ? beware there is some subtle MTU interaction when you have SVI or virtual interfaces and the "real" physical MTU of outgoing switchport, moreever there is a important caveat for OSPF using SVI : https://www.cisco.com/c/e...hnote-ospf-mtu-00.html pay attention on CSCse01519: OSPF should honor interface ip MTU when sending packets !!!!! Anyway because here there are more moving parts than ospf  I think that a simple net diagram could help a lot ! Check show int of outgoing interface and debug ip ospf packets to see if there is a chance that you are sending ospf packets with a larger mtu.. Regards, Antonio

[emnoc]

I have to say one of the following.

The interface database  packet mtu or the link quality is poor. You can  capture  the OSPF packet and look at the DataBase Description from both  units to  inspect the "configured ospf mtu"

link quality is a direct relationship to plos  ( packet lost ) , crc or mis-match. Since I see two nor having problems for vlanXXX  hows the interface quality 

show int gi x/x counters

show int gi x/x counters errors

[vinceneil666]

Thanx for all replies, I will try to get a litte drawing in place when time allows :) 

Just real quick input.. I do get these flaps on a fixed interval of aprox 30 sec. I can not see, as of now, any links that have any issues (sh count int err)...

I have done lots of debug cisco side, and I get a lot of "cant see outselves in hello packet"

I have another switch, same cisco box as the one with issues, that have no problems towards fortigates. Same config and so on.. .. 

[Antonio_Milanese]

Hi Vince,

vinceneil666 wrote:
Just real quick input.. I do get these flaps on a fixed interval of aprox 30 sec. I can not see, as of now, any links that have any issues (sh count int err)...

you have 40sec dead timer so that's nothing strange  

vinceneil666 wrote:
I have done lots of debug cisco side, and I get a lot of "cant see outselves in hello packet"

"cannot see ourself in hello packet"......from.... ??? 

...router id and int info can be usefull =) now..that error message it's changing the landscape a little bit: - all previous packet drop causes may be still valids (plus some multicast snafu someware in the middle) but the most significant bit here it's occuring to hello and type 1 LSA too! - you should really  have to provide us a net diagram with your OSPF topology too since this behavior cloud be explained with other OSPF topology/conf issues... f.e.  have you checked if you have a duplicate router-ids (on loopbacks) or maybe they are NOT hardcoded ?

does FGTs have multiple int on same vlan or secondary addresses ?

Without the network and ospf topology knowledge or the actual ospf packets debugs/capture I cannot really helping further without shooting into the dark =) Regards, Antonio

[emnoc]

Thanx for all replies, I will try to get a litte drawing in place when time allows :)    Just real quick input.. I do get these flaps on a fixed interval of aprox 30 sec. I can not see, as of now, any links that have any issues (sh count int err)...   I have done lots of debug cisco side, and I get a lot of "cant see outselves in hello packet"   I have another switch, same cisco box as the one with issues, that have no problems towards fortigates. Same config and so on.. ..

Could be a bug on the cisco or fortigate, are ALL items running the same code?

As far as mtu issues regardless of  ospf-ignore-mtu you can see this in any OSPF  packet if md5 authentication is not enabled. ( md5 encrypts all excepts the HELLO packets btw )

Inspect all OSPF-speakers for the mtu value that's carried  by ALL speakers. Use tshark/wireshark for validation

Ensure the OSPF type ( Stubby , Normal, etc.... are the same )

Ensure the links has no major error-counters or CRC or input-errors,etc.....

Ken