Community discussions

 
mikeeg02
just joined
Topic Author
Posts: 10
Joined: Fri Mar 30, 2018 2:28 am

Network Design suggestions......

Mon Apr 16, 2018 11:11 pm

Sorry for my paint skills, or lack there of. My physical network layout is below. What I need is the redundancy of being able to use ANY route available to get where it needs to go, while also still being smart about it, and using the the least amount of hops. (They are all wirelessly connected, some licensed and some license free links.) Fast convergence is ideal, because there is audio streaming across the links.

I took over this network and cleaned it up, made things work great and stable with 6.38.5 Each site is a router, with /30 subnets and ospf running on each interface to the next site. From there, there are vpls tunnels to sites that have equipment that require being on the same LAN (outputted to a switch and segregated by vlans. Since upgrading to the 6.41 series, the ospf costs seem to be giving me trouble. I have to manipulate interface costs to keep everything stable now. I have the dude running on .0, some things just dont add up. Something changed in how they handle ospf routes going to 6.41.3 and then things are also different going to 6.41.4. At this point Im starting to question proper deployment, maybe configuration, but again everything worked perfectly in 6.38.5. Which makes me start to wonder whether theres a better setup I had not considered. I dont want to keep "trying" new software versions. Perhaps going back to 6.38.5 is the ideal scenario, but I just wonder how others would deploy a similar network. I believe it is becoming a limitation of ospf having multiple routes to destinations. In 6.41.3, the mpls tunnels always worked, it was layer 3 issues that came up, in 6.41.4 they seem to of combined those to issues into one where if I cant get to it through my gateway, the vpls tunnel cannot be established. So I am interested in how others would design this network to do something similar to what I am?
network.png
You do not have the required permissions to view the files attached to this post.
 
User avatar
Anumrak
Forum Guru
Forum Guru
Posts: 1051
Joined: Fri Jul 28, 2017 2:53 pm

Re: Network Design suggestions......

Tue Apr 17, 2018 10:15 am

OSPF must work just fine if all of your interfaces in area 0, because ldp will work only in one area as a vpls. If you did the same in higher version, then it might be a bug.
 
Muqatil
Trainer
Trainer
Posts: 574
Joined: Mon Mar 03, 2008 1:03 pm
Location: London - UK
Contact:

Re: Network Design suggestions......

Tue Apr 17, 2018 5:17 pm

Be careful with asymmetric routing.
MPLS does not support ECMP whilst OSPF does. Some protocols (such as SNMP) are not responding correctly on asymmetric routing.
Try to set the OSPF weights to not have any asymmetric routing or ECMP (unless forced by Traffic engineering)
Renato Bernardi

skype: medtech5
 
User avatar
IPANetEngineer
Trainer
Trainer
Posts: 1053
Joined: Fri Aug 10, 2012 6:46 am
Location: Jackson, MS, USA
Contact:

Re: Network Design suggestions......

Tue Apr 17, 2018 8:46 pm

Since you're using VPLS already, I would probably use MPLS TE to define paths for traffic rather than OSPF cost. OSPF cost doesn't scale well and can create suboptimal traffic scenarios.

This is assuming that traffic engineering is your most important requirement. I normally recommend the bugfix version to my clients for production networks unless it's missing a specific feature you need.
Global - MikroTik Support & Consulting - English | Francais | Español | Portuguese +1 855-645-7684
https://iparchitechs.com/services/mikro ... l-support/ mikrotiksupport@iparchitechs.com
 
mikeeg02
just joined
Topic Author
Posts: 10
Joined: Fri Mar 30, 2018 2:28 am

Re: Network Design suggestions......

Tue Apr 17, 2018 9:14 pm

Ive done some path costing, and optimized routes to that extent, and considered how that will be affected in the event that a path is down. Recently I found that rp-filter was set to strict, which upon researching I have found to be more desireable to use loose. Changing so seems to of remedied the connectivity issues. I am interested in TE, but havent deployed anything utilizing it yet. It looks like you have to specify each route it can take? Does that mean you need to plan (or create rather) for each and every route failure?

I do agree on the bug fix versions, generally. Though I had built ~1/3 of the network on my bench with similar equipment, and didnt see issues, until it was fully scaled.

Who is online

Users browsing this forum: No registered users and 5 guests