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 ?
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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
Hello,
Also, check if the MTU is same. If not change change the MTU on both devices or enable ospf mtu ignore...
Regards,
HA
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 :) ..
Hi Vince,
vinceneil666 wrote: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
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
vinceneil666 wrote: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
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 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
PCNSE
NSE
StrongSwan
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.. ..
Hi Vince,
vinceneil666 wrote:you have 40sec dead timer so that's nothing strange
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)...
vinceneil666 wrote:"cannot see ourself in hello packet"......from.... ???
I have done lots of debug cisco side, and I get a lot of "cant see outselves in hello packet"
...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
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
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1561 | |
1034 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.