It seems the time for a consistent OSPF costing checker/implementer is near. I am playing with the idea of doing a graph (in both the graphical and mathematical sense) of our OSPF backbone and pulling all costing inconsistencies.
These could include:
Inconsistencies in costing on the different sides of the same link
Inconsistencies in terms of costing ethernet and wireless.
I’m also thinking of then starting to suggest costs to admins where the actual costs deviates from some simple model.
Simple model as a start:
Ethernet 1
Wireless 10
Intermediate Model
Ethernet Gbit 1
Ethernet Mbit 2
Wifi 10 (maybe varying dual/single)
Complex Model
Ethernet varying by speed
Wifi varying by speed as well as “average” CCQ (different on each side of the link)
I’d like a friendly discussion on the topic with firmish suggestions on a simple initial model and speculative discussion on a future models for estimating costs.
I imagine this could start as suggestions perhaps via wms emails of costs, but could become automatic changes via script. Thoughts on this?
Spin I agree that we need to look into varying ospf costings. For example I have a AC link doing 702mbps/702mbps with 100%/100% ccq and a average ping of under 1ms. Costing on the wireless is set on 2 in both directions as the link can handle the traffic. Maybe look at a script that auto adjust the costings based on sync speed and ccq. Something like if the ccq is above 90% and sync is 120mbps make costing 8. If sync is 180mbps with ccq above 90% make costing 6. If sync is 300mbps with ccq above 90% make costing 4. If sync is over 300mbps with ccq above 90% make costing 2…
Set a reference bandwidth 1Gbps to a cost of 1 (call this A)
Calculate the reference bandwidth for the interface based on the speed be it 1Gbps, 100Mbps (or 10Mbps). For wireless use the sync speed but reduce for poor CCQ. (Call this B).
Cost then becomes A/B.
Examples:
Wireless link as per @jypels example would be 1000 / (702 * 100%) = 1.42 rounded up to 2.
Wireless link syncing at at 20Mbps with 90% CCQ would be 1000/(20*0.9) = 55 .55 rounded up to 56.
Ethernet link at 100Mbps would be 1000/100=10.
A script could check these and email admins who’s interfaces fall outside a range of these costs, or it could actually adjust to be within range of these estimates? We could make the range wide initially say +/- 50% of the estimated cost. I.e. the admin has discression to adjust the costs in the three examples as follows:
Graphire had worked out nice, friendly and balanced calculation last year. Wonder if he still has it.
It took signal, CCQ and one or 2 other bits. Found it to work well
Re-reading what you said I presume the wireless RB’s are in bridge mode for some reason? I don’t think that’s a great setup with this in mind. I’m assuming there is bridging involved?
I guess bridging wireless interfaces should not be allowed as it would mess with costing. You won’t be able to set the metric correctly for that. You’d need to set it at some weird average.
The wireless interface is bridged yes, but it runs its own OSPF on the core of each node. You assign a /29 that both Ubiquity devices use aswell as each core.
So for example you would have:
Node A core: 172.18.1.1
Node A Ubi: 172.18.1.2
Node B Ubi: 172.18.1.3
Node B core: 172.18.1.4
Each core has that assigned to a separate Ethernet port
Yes the cores are mikrotik, but with a couple of Ubiquity Edgepoints and edgerouters being deployed on the wug (as cores) currently. We might want to look into scripts for them, if possible. @Tinuva any input on this? @Diabolix would know if the Edgepoint supports scripts as he has setup the first edgepoint on the wug, with second one going live on sunday. .
Back in the day I also wanted to visit this but the formula was to include distance as I thought that the longer links should only do traffic when necessary. You can see OSPF Costing if you want to check the opinions at the time.
I like the complex method and the formula that you’re using. The bridged UBNT devices will pose a challenge but an admin can manually calculate those when they’re setting up the links.
It will have to based on reporting/automated emails and then manual applying of the changes. If it was automated the entire network would go down and who knows how the RBs will cope with the sudden rebuild of the routing table.
I’m thinking CCQ is measuring link quality. So if the link is bad due to distance or frequency issues or anything else then it should be OK. There might be an argument in sparing long distance links a little if they tend to be over-utilised but this would increase hop count for that traffic which would increase latency.
We’d need to stop bridging on some of these so that we can clearly set the cost on each link separately. Or calcualte some average cost for the bridge.
Yeah it probably can’t be done all at once. As I see it, it could be suggestions at first but it could be automated relatively easily. The script will just need to be set to update costings over time rather than in a short period of time to avoid this problem.
I’m currently putting together a OSPF monitoring script/thingy. Basically it pulls all information from the Link State Advertisement DB and puts together a model of our OSPF network. This is early stages at the moment.
Also found some older threads on the same topic in the mean time, which I’m linking here for reference:
Great minds think alike.
