Community discussions

MikroTik App
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Feature request for 5.0 final.

Sun Jan 02, 2011 12:00 am

SNMPSET and SNMPGET : to manage switches ports from Router OS scripts.



TCPDUMP : To allow for faster IP debuging. Torch does not allow to see some important things like DSCP.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7056
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Feature request for 5.0 final.

Sun Jan 02, 2011 12:02 am

TCPDUMP : To allow for faster IP debuging. Torch does not allow to see some important things like DSCP.
Packet Sniffer
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Sun Jan 02, 2011 2:01 pm

The main problem with Packet Sniffer is that it is not realtime. You need to stop it to get the result. If you watch for a problem, most often you don't know when it will happen. So basically, non realtime sniffers are most of the time useless.


Sending a stream through TZSP encapsulation to Wireshark is an option but not always possible because it does take bandwith. Most of the time using TZSP is complicated.

Another better option would be to be able to connect Wireshark through remote connection to Router OS. But this would need to implement WinPcap deamon inside Router OS.
The advantage of this is that you can define what you want to dump directly from Wireshark. All interfaces are available.


But the simplest and more efficient is certainly TCPDUMP.
 
dolphinik1
newbie
Posts: 29
Joined: Tue Nov 20, 2007 9:24 pm

Re: Feature request for 5.0 final.

Sun Jan 02, 2011 11:38 pm

CoA/PoD for PPTP/PPPOE/L2TP/OVPN/SSTP/HotSpot
 
sw0rdf1sh
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Sun Nov 28, 2010 6:16 pm

Re: Feature request for 5.0 final.

Mon Jan 03, 2011 3:14 am

I would like to see the ability to get the value of total connections to a hotspot , total unique users to a hotspot (probably checking different mac addresses) and total tx/rx bytes in hotspot since the beggining without reset of this value if the router reboots.
Something like a stats menu in winbox that stores the values.Or maybe embed this feature in graphing.

Is this possible?
 
fewi
Forum Guru
Forum Guru
Posts: 7717
Joined: Tue Aug 11, 2009 3:19 am

Re: Feature request for 5.0 final.

Mon Jan 03, 2011 3:59 am

I don't know if it would help as a workaround, but I run a script on my Hotspot routers that every five minutes logs the number of users per Hotspot. The router is set up for remote syslog. On the syslog server I use syslog-ng, which finds those specific syslog messages and writes them to a named pipe. A Perl script runs as a daemon and listens on that named pipe, parses the incoming messages, and uses rrdtool to graph them. Finally, a web interface (PHP) allows users to query usage based on a date range and the target router.
I can't just post all of that because it's part of a larger system that contains stuff my employer wouldn't want shared, but I could post more details and some code if it would be useful to you. The whole thing wasn't particularly hard to do, a colleague and I put everything together in less than a day.

It could easily be adjusted to also log rx/tx, and probably connections per Hotspot, though I am not sure what you mean by that. Any value that can be derived via router scripts can be sent to the outside world and recorded and displayed somehow.
 
sw0rdf1sh
Frequent Visitor
Frequent Visitor
Posts: 50
Joined: Sun Nov 28, 2010 6:16 pm

Re: Feature request for 5.0 final.

Mon Jan 03, 2011 2:20 pm

I don't know if it would help as a workaround, but I run a script on my Hotspot routers that every five minutes logs the number of users per Hotspot. The router is set up for remote syslog. On the syslog server I use syslog-ng, which finds those specific syslog messages and writes them to a named pipe. A Perl script runs as a daemon and listens on that named pipe, parses the incoming messages, and uses rrdtool to graph them. Finally, a web interface (PHP) allows users to query usage based on a date range and the target router.
I use similar workaround for now.The problem is that I have a website in shared hosting and can't use cacti or rrdtool.They instructed me to use perl for using rrdtool but I have no idea how to do that.If you can find a guide and send me a link on how to use rrdtool in a shared hosting environment (I have cpanel/whm access) I'd appriciate that.
Right now I am using fetch tool as described in the link below sending in a mysql database the active users in the hotspot.
I can't just post all of that because it's part of a larger system that contains stuff my employer wouldn't want shared, but I could post more details and some code if it would be useful to you. The whole thing wasn't particularly hard to do, a colleague and I put everything together in less than a day.
Thank you for everything.I might start a new topic about that (as this topic refers to other things) or see the link at the end of my post.
It could easily be adjusted to also log rx/tx, and probably connections per Hotspot, though I am not sure what you mean by that.
I just want to display in my webpage something like: xxxx number of users transfered xxxxx mb of data from the beggining.
If I could get these values I could use the script below and use fetch tool calling for a php file every 5min,storing the values to a database and use php to display to website like fosben did.
Any value that can be derived via router scripts can be sent to the outside world and recorded and displayed somehow.
True.I would like to retrieve with scripting the values Tx/Rx Bytes in the last tab called "traffic" in winbox for the interface wlan1.Can you tell me how to get these values? (winbox 4.13 gets these values as a table in console so I can't send them with fetch tool-Stats command for an interface)

I have posted the workaround I am using here (Originaly fosben's script):
http://forum.mikrotik.com/viewtopic.php?f=9&t=28002

Anyway I thought it would be easier for us all (you and me) asking for this feature rather than asking for php,rrdtool,perl and other programming help.After all many people use mikrotik for free hotspots and the only thing that matters is if the router is online, statistics and health of the system.I think.(Please correct me if I'm wrong)

Also see this post I did:
http://forum.mikrotik.com/viewtopic.php?f=9&t=47647
 
User avatar
gustkiller
Member
Member
Posts: 419
Joined: Sat Jan 07, 2006 5:15 am
Location: Brazil
Contact:

Re: Feature request for 5.0 final.

Mon Jan 03, 2011 3:22 pm

Support ECMP routes with MPLS/LDP:
In current state, a network with a lot of ecmp routes via ospf ( with multiple links) when LDP is enabled, only one of the multiple routes gets a label, so all traffic goes only to one path and doing bonding and another work arrounds like create vpls and bonding then is not an option because of over head as router OS doesnt support l2mtu in X86 routers so only 1500mpls mtu works on our isp. Wit ldp distributing and using multiple labels for the same route, we can overcame that problem.

Support BGP as route source for LDP.

The current ISP BCP ( best common pratices) is that ospf should be used only for infrastructure routes ( loopbacks and /30) and bgp for all other routes ( customer routes) because bgp works better with large routes. the current RouterOs LDP implementation doesnt support bgp as route source to assign mpls labels to the routes. So enable bgp as route source to bind labels , will be a very good option for large networks with more than thousands of customer routes.
 
TKITFrank
Member Candidate
Member Candidate
Posts: 236
Joined: Tue Jul 07, 2009 2:55 pm
Location: Sweden

Re: Feature request for 5.0 final.

Mon Jan 03, 2011 7:11 pm

Support ECMP routes with MPLS/LDP:
In current state, a network with a lot of ecmp routes via ospf ( with multiple links) when LDP is enabled, only one of the multiple routes gets a label, so all traffic goes only to one path and doing bonding and another work arrounds like create vpls and bonding then is not an option because of over head as router OS doesnt support l2mtu in X86 routers so only 1500mpls mtu works on our isp. Wit ldp distributing and using multiple labels for the same route, we can overcame that problem.

Support BGP as route source for LDP.

The current ISP BCP ( best common pratices) is that ospf should be used only for infrastructure routes ( loopbacks and /30) and bgp for all other routes ( customer routes) because bgp works better with large routes. the current RouterOs LDP implementation doesnt support bgp as route source to assign mpls labels to the routes. So enable bgp as route source to bind labels , will be a very good option for large networks with more than thousands of customer routes.
+1,
It's sad to see the development of the MPLS implementation stop like it has done. Come on MT let's finish it for v5 !! =)
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Mon Jan 03, 2011 8:56 pm

Most Router OS functions comes from the opensource world, so they need to wait for updates from other groups like OpenWRT to put them inside Router OS.
You're so funny :lol:


THE LATEST REMARK IS NOT POSTED BY ME. I WOULD BE INTERESTED TO KNOW HOW IT IS POSSIBLE TO EDIT MESSAGES FROM SOMEONE ELSE ON THIS FORUM
Last edited by FIPTech on Fri Jan 07, 2011 2:56 pm, edited 1 time in total.
 
karlikus
just joined
Posts: 1
Joined: Fri Jun 01, 2007 11:24 am

Re: Feature request for 5.0 final.

Tue Jan 04, 2011 1:43 am

UDP for OpenVPN
 
erkel
Frequent Visitor
Frequent Visitor
Posts: 58
Joined: Sun May 27, 2007 12:04 pm

Re: Feature request for 5.0 final.

Fri Jan 07, 2011 2:46 pm

+1 for UDP for OpenVPN.

Please we need this.
 
User avatar
mjoksimovic
newbie
Posts: 46
Joined: Thu Jun 19, 2008 1:19 pm
Location: Serbia
Contact:

Re: Feature request for 5.0 final.

Sat Jan 08, 2011 4:30 am

"ARP watch" or "Dynamic ARP Inspection" function for RoS strictly needed. ARP spoofing/poisoning is much more frequent phenomenon. ArpON solution is not possible on WAN's connected directly to fiber optic links through media convertor.

We have about 5000 ARP addresses on the list every moment, clearing ARP list doesn't help.
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Sat Jan 08, 2011 12:49 pm

ARP / DHCP spoofing control is more a switch function, like 802.1x.

All well known manufacturers have this function in their managed level 2 entry level switches. (just after managed smartswitches).

If you need it on a wan link, then put a fiber module in the switch, and define a VLAN for it so that you can send it to the router. You will avoid to buy an external media converter.


More you put inside the software router, more you will get lost packets. Except if you have high end XXXXXX $ routers, with hardware ASIC / FPGA acceleration for everything.
 
User avatar
mjoksimovic
newbie
Posts: 46
Joined: Thu Jun 19, 2008 1:19 pm
Location: Serbia
Contact:

Re: Feature request for 5.0 final.

Mon Jan 10, 2011 1:04 am

ARP / DHCP spoofing control is more a switch function, like 802.1x.

All well known manufacturers have this function in their managed level 2 entry level switches. (just after managed smartswitches).

If you need it on a wan link, then put a fiber module in the switch, and define a VLAN for it so that you can send it to the router. You will avoid to buy an external media converter.


More you put inside the software router, more you will get lost packets. Except if you have high end XXXXXX $ routers, with hardware ASIC / FPGA acceleration for everything.
Tried with this configuration but with no success, ARP list are going to be filled out to the maximum of 8192 entries so I decided to configure complete firewall-ing under Open BSD and to run ArpON on it also just between media convertor and MikroTik.

P.S. Let's not to go to off-topic. Thanks for giving advice. :?
 
User avatar
Okivash
just joined
Posts: 2
Joined: Sun Jan 23, 2011 8:48 am
Location: Okinawa, JAPAN
Contact:

Re: Feature request for 5.0 final.

Sun Jan 23, 2011 9:34 am

UDP support for OpenVPN !!! desperately need this to work for a new project we'd like to build.
 
User avatar
omidkosari
Trainer
Trainer
Posts: 640
Joined: Fri Sep 01, 2006 4:18 pm
Location: Canada, Toronto

Re: Feature request for 5.0 final.

Tue Feb 01, 2011 10:45 am

 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Tue Feb 01, 2011 11:59 am

UDP support for OpenVPN !!! desperately need this to work for a new project we'd like to build.
Perhaps Mikrotik do not want to implemented this because they think that UDP is not reliable and they could have problems like with MAC Winbox access.


But OpenVPN is reliable with UDP even if there are lost packets, because each packet is validated before passing in the engine.


If there are corrupted packets, they are simply dropped.


In the end, OpenVPN is almost transparent for tuneled data, it just add checks, dropping corrupted packets.


So i don't see any reason why it would not be implemented, except perhaps if Mikrotik needs to work on assembler code (there is assembler code inside OpenVPN needing porting for each different processor).
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26387
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature request for 5.0 final.

Tue Feb 01, 2011 12:12 pm

No, it's certainly not the reason. I have previously already explained that there were many unfixed problems in the OpenVPN itself, so we have stopped development, and concentrated on more reliable projects like SSTP. We don't plan to make UDP support in OpenVPN in near future.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2104
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 10:33 am

Why use OpenVPN when there are much better options like PPTP, SSTP, L2TP ?

I would suggest IPSEC too but Mikrotik are still missing VTI support...
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 10:50 am

No, it's certainly not the reason. I have previously already explained that there were many unfixed problems in the OpenVPN itself, so we have stopped development, and concentrated on more reliable projects like SSTP. We don't plan to make UDP support in OpenVPN in near future.

Wich problems ?


Is there hardware acceleration available on MT products with SSTP ?


PPTP is the only one who is able to bridge (with BCP). L2TP should be extended to L2TPv3.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26387
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 10:51 am

 
Beccara
Long time Member
Long time Member
Posts: 606
Joined: Fri Apr 08, 2005 3:13 am

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 11:12 am

Digging around all your post's on it are it's buggy (in which case why is it perfectly stable in a plain linux setup and used by multinational corp) and you're "developers almost all committed suicide trying to make it work" along with the complaint that "client and server end must match configuration 100%" which is a very WTF comment to make, I dont expect things to work unless both ends are 100% config matched!

SSTP is a Microsoft spec that claims to be open but in reality nonone outside of Microsoft is going to touch it with a 10ft barge pole for fear of a submarine patent and is unlikely to gain widespread adaption, It has no UDP option which run's into issues, OpenVPN is better since it's standards based and has backing from both Cisco and Juniper, It's used by VMware and Nokia.

So far you haven't given a single valid reason why you wont be furthering development on OpenVPN in ROS, If companies much bigger than MT can use it internally and integrate it their products then why are you're dev's "almost comming suicide"??
 
User avatar
THG
Member
Member
Posts: 472
Joined: Thu Oct 15, 2009 1:05 am

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 11:18 am

Why use OpenVPN when there are much better options like PPTP, SSTP, L2TP ?
SSTP is only for remote client access, it does not support site-to-site VPN tunnels.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26387
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 11:30 am

client and server end must match configuration 100%" which is a very WTF comment to make
by this I meant that if you have lots of clients, and decide to change the encryption settings on the server, all clients will stop working unless you change the setting in the clients, one by one, by hand.

why is L2TP not good for you? It's UDP
 
Beccara
Long time Member
Long time Member
Posts: 606
Joined: Fri Apr 08, 2005 3:13 am

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 11:55 am

Personally I call that a feature :P but it's nothing a login script wouldn't fix for mass deployment. L2TP has it's place but OpenVPN is flexible in the ways it can be used. I haven't touched it in a good 9 months now but It's got alot of backing behind it from a number of big players, It seems silly for MT to stop work on it for reasons that basically boil down to "It's too hard for us"
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 1:35 pm

SSTP seems only used by Microsoft and is a very young technology. Not supported by Windows XP.

In the real world, Windows XP is still very present and this will not change soon.


L2TP neither SSTP do allow bridging ??

L2TPv3 do allow bridging but not supported by router OS.


Neither PPTP, L2TP or other PPP based tunnels do have very strong encryption. Only MPPE128. This is not recommanded to use them for secret informations like card paiements.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7056
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 2:06 pm

SSTP, L2TP and PPtP can be bridged see BCP
http://wiki.mikrotik.com/wiki/Manual:BC ... _bridging)
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26387
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 3:06 pm

L2TP neither SSTP do allow bridging ??
Not true. We support BCP on PPP for a very long time. There is an EoIP option
as well.
L2TPv3 do allow bridging but not supported by router OS.
This will be implemented, but known when.
Neither PPTP, L2TP or other PPP based tunnels do have very strong encryption. Only MPPE128. This is not recommanded to use them for secret informations like card paiements.
That's why people use L2TP with IPsec.
 
Sob
Forum Guru
Forum Guru
Posts: 9121
Joined: Mon Apr 20, 2009 9:11 pm

Re: Feature request for 5.0 final.

Wed Feb 02, 2011 7:40 pm

That's why people use L2TP with IPsec.
And they fail miserably when they try to use ROS as server for clients behind NAT. But to be fair, it's probably fixed in ROS >= 5.0rc2 (I didn't do full testing yet).
 
mikroguf
just joined
Posts: 11
Joined: Mon Dec 06, 2010 5:40 am

Re: Feature request for 5.0 final.

Thu Feb 03, 2011 1:40 am

Unfortunately, 5.0rc2 didn't completely solve all IPSec-behind-NAT issues. See http://forum.mikrotik.com/viewtopic.php?f=1&t=47207
 
User avatar
THG
Member
Member
Posts: 472
Joined: Thu Oct 15, 2009 1:05 am

Re: Feature request for 5.0 final.

Fri Feb 04, 2011 7:14 pm

SSTP, L2TP and PPtP can be bridged see BCP
http://wiki.mikrotik.com/wiki/Manual:BC ... _bridging)
This page looks empty. :shock:
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7056
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Feature request for 5.0 final.

Fri Feb 04, 2011 7:38 pm

 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2104
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: Feature request for 5.0 final.

Fri Feb 04, 2011 10:43 pm

Mikrotik needs to add Virtual Tunnel Interfaces (VTI) and Next Hop Tunnel Binding(NHTB) to their IPSEC implementation:

"IP security (IPsec) virtual tunnel interfaces (VTIs) provide a routable interface type for terminating IPsec tunnels and an easy way to define protection between sites to form an overlay network. IPsec VTIs simplify configuration of IPsec for protection of remote links, support multicast, and simplify network management and load balancing."


"JUNOS supports multipoint secure tunnel interfaces with the Next-hop Tunnel Binding (NHTB) feature. This allows a device to bind multiple IPSec SAs to a single secure tunnel interface. you can bind multiple IPSec VPN tunnels to a single st0 interface unit.
To link a specific destination to a specific IPSec tunnel bound to the same st0 interface, the J Series or SRX Series device uses two tables: the inet.0 route table and the next-hop tunnel binding (NHTB) table."

If these existed, we could sell significantly more Mikrotik hardware as it would allow us to run dynamic routing protocols across IPSEC easily, scale our IPSEC WAN's easily, and allow better vendor inter-op with Cisco, Juniper and Fortinet.
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Sat Feb 05, 2011 1:33 am

Why not use GRE instead ?

VTI seems only to give 4 bytes less than GRE headers, but it is proprietary ?
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2104
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: Feature request for 5.0 final.

Sat Feb 05, 2011 4:56 am

Hi FIPTech,

Configuring GRE to run over the top of IPSEC is a PITA, and from my experience is never as reliable as VTI's

VTI is not proprietary, it is just the most common name for it. Juniper call it "Secure Tunnel Interface", Fortinet call it "Interface mode IPSEC". They are all the same thing, and are all compatible with each other.

It's best thought of as an IPSEC Virtual Interface, you can assign an IP to it, and static route. Or you can assign an IP and dynamically route.

It is very flexible, and you can even use it if only one end supports it, this is done by not assigning an IP to the VTI, and adding a destination route to the interface. The remote end just needs the relevant proxy-id's in the policy and it will work (although using this hack configuration you obviously cannot use OSPF or other dynamic protocols)

An example of using VTI/NHTB is the following:

Site 1, IPSEC peer to site 2,3, VTI on peers set to be tunnel.1, tunnel.1 configured a 10.99.1.1/24, OSPF configured on tunnel.1

Site 2, IPSEC peer to site 1,3, VTI on peers set to be tunnel.1, tunnel.1 configured as 10.99.1.2/24 , OSPF configured on tunnel.1

Site 3, IPSEC peer to site 1,2, VTI on peers set to be tunnel.1, tunnel.1 configured at 10.99.1.3/24, OSPF configured on tunnel.1

So, basically you only have to create 1 tunnel interface on each router, and then bind the IPSEC peers to this, NHTB sends broadcast traffic to all peers, and unicast traffic to the correct peer. This allows OSPF to work in broadcast mode, but traffic to pass via the most efficient path.

Using these technologies, it is easy to create fully meshed IPSEC configurations, which is very useful for VoIP traffic as it then does not have to pass up to the IPSEC hub then back down to the spoke.

You could also obviously have a different tunnel interface bound to each ipsec peer, but you would have to configure an IP on each tunnel interface and this could become tedious if you had a whole bunch of sites.
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Sat Feb 05, 2011 1:23 pm

VTI seems unsupported in the Linux world. I don't remember i've seen this in the OpenSwan documentation.

Something that is supported inside Openswan is opportunistic encryption, with it you can share keys on a DNS server, so that each peer can connect to another one looking for the public keys on the DNS server.

It seems that since a couple years, Linux does not get the new functions it should have for Ethernet / IP / IPv6 access networks.

This limit the use of Linux routers for SMB market and very small providers use.

Instead of seing Linux developping network functions, we see Ubuntu and similar GUI distributions rising the kernel size for Desktop computing use. Something that Linux is not good at all : 90 % of the market is Windows.


This is a terrible situation, for example all the 802.1ah and 802.1Qay stuff (Provider Backbone Bridge and Provider Backbone transport) is not implemented yet inside Linux. This stuff would be very beneficial for small providers.

This situation should change, but unfortunately it is certainly very profitable to big names companies in the routing world, so almost every major actor in the industry will continue to support the developement of Ubuntu like distributions to keep Linux far from the high $ professional routing markets.

Perhaps Mikrotik and similar router distributions like Pfsense and Vyatta could start together a new Linux project, with specific routing kernel extensions.

The main goal would be to keep compatibility with the normal Linux kernel, for drivers and applications support, but adding routing and protocols extensions for example as kernel modules.

One thing is sure : Linux is more and more missing important network functions supported by usual big names companies in the routing world.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2104
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: Feature request for 5.0 final.

Sun Feb 06, 2011 10:04 am

FIPTech, a lot of commercial vendors base their Network Operating Systems on Linux, they just develop closed source modules and user-space applications to add the required functionality and make them unique.

Extreme Networks XOS, Allied Telesis's AlliedWare Plus, Cisco's NX-OS, Fortinet's FortiOS, Palo Alto Networks PAN-OS, are all Linux based, and to get the required performance all use hardware based acceleration.

You are right that there is no open-source VTI implementation, but there is plenty of documentation on how VTI/STI works, Juniper even have a detailed whitepaper. Mikrotik could if they had time develop this feature. Or they could do what they have with their dynamic routing, proxy and MPLS implementations and write their own.. IPSEC is the industry standard for site-to-site VPN's, and with it's inclusion as part of the IPv6 specification is not going to disappear any time in the near future, in fact I would bet it will be around long after SSTP and OpenVPN are forgotten.

If it is a question of profitability for Mikrotik, I would be happy to pay a premium for a L7 "Enterprise feature set" licence that included features like IPSEC with VTI/NHTB and stateful High Availability.
 
bda
Member Candidate
Member Candidate
Posts: 189
Joined: Fri Sep 03, 2010 11:07 am

Re: Feature request for 5.0 final.

Sun Feb 06, 2011 12:07 pm

CoA/PoD for PPTP/PPPOE/L2TP/OVPN/SSTP/HotSpot
Yes! But mostly for PPPoE/PPTP.
 
FIPTech
Long time Member
Long time Member
Topic Author
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: Feature request for 5.0 final.

Sun Feb 06, 2011 7:47 pm

FIPTech, a lot of commercial vendors base their Network Operating Systems on Linux, they just develop closed source modules and user-space applications to add the required functionality and make them unique.

...........

If it is a question of profitability for Mikrotik, I would be happy to pay a premium for a L7 "Enterprise feature set" licence that included features like IPSEC with VTI/NHTB and stateful High Availability.
Even if you could pay for this (like me and others) i doubt Mikrotik can find the developpment time to do advanced things like this in a raisonnable amount of time.

That's why i say that those smaller companies and some opensource groups should collapse to design new kernel routing extensions to Linux, instead of reinventing the wheel each one in front of their own desks.

For example Provider Backbone Bridge, PPB-TE and GMPLS compatibility is a big work. Can't be done by a single entity.

Smaller clients do needs those functions in a raisonnable delay after they have been implemented by big companies, so that they can stay in the competition.

If you need to wait 5 or 10 years to get those functions and you can't pay for $$$$$ or €€€€€ routers, then you can't catch opening markets.

I think there is a market for harware accelerated routers, 1 to 10 times the power of a RB1100 (and 1 to 10 times the price), with support for PBB, PBB-TE and other missing functions often discussed in this forum.

X86 multi core is not the solution. This is power hungry, expensive, often unreliable because of untested hardware and drivers.

The solution is mixed MIPS (or other risc arhitecture processors) combined with FPGA based logic processing hardware, so that L3 packet processing is done by accelerated circuits at wire speed.

RB2000 to RB10000 products with a level 7 licence could be very interesting products, for small to small-medium Internet and networks providers.

Extracting C++ Linux kernel code to recode it inside VHDL logic code for FPGA use is not a simple task.This kind of mixed programming is often done inside products of very big companies like HP, Sony, Cisco, EXFO to give only a few of them... But the amount of knowledge and developement time is certainly difficult to support for smaller sized companies, but not impossible...

The advantages of hardware logic acceleration is :

- lower production cost
- lower power consumption
- garanteed wire speed capabilities with lower clock speeds than serial processing

The main disadvantage is the cost of development, spliting Linux code and proprietary extensions to mixed VHDL programming.

Mikrotik know how to program FPGA circuits. I've seen they are using small ones in their RB products. It would be fine if they could use them for routing acceleration so that their high end products could be considered carrier class.

Yes i said carrier class. Because even if you are a small or very small provider, or even selling routers to final clients, you can't loose packets or add excessive amount of jitter or gaps in the streams.
This is because today VoIP and Video is more and more transported on IP or MPLS networks where latency and packet delivery is not garanteed - because of the asynchronous nature of Ethernet, and because of the large used packet size.

So the only way to have good quality on non SDH / ATM based networks is to use carrier class Ethernet routers, as soon as you are pushing more than a few 10 Mbps or 100 Mbps of trafic.

Perhaps i'm wrong, but i feel that Mikrotik has the required smartness to manufacture very nice small carier class products if they can find the necessary help from other groups / manufacturers, or perhaps from their bank :=)

The new RouterBoard SXT with NV2 support seems to prouve this. Very smart product.
 
nhickman
just joined
Posts: 11
Joined: Thu Dec 16, 2010 6:18 pm
Location: Sterling, VA
Contact:

Re: Feature request for 5.0 final.

Mon Feb 21, 2011 8:58 pm

Please update the Sierra Wireless kernel drivers to support the AT&T Shockwave USB modem. These are the only modems that AT&T is currently handing out so being able to support them ASAP would be nice.
link to drivers

Without the updated sierra.c, the Shockwave (AT&T's 308 model) will not enumerate ttyUSB devices with the serial driver. The sierra_net.c additionally allows the wwan0 direct IP interface, but to connect you still need access to ttyUSB2. Throughput is the same using pppd or the direct IP interface.

Once the drivers are updated you can connect through pppd with these scripts. Modify gsm_chat to use ttyUSB2 instead of ttyUSB0 then dial using 'pppd call gsm'.

Or connect with wwan0 ip interface like so:

Tell modem to connect:
ubuntu@ubuntu:/home/ubuntu# sudo screen /dev/ttyUSB2 115200
AT+CGDCONT=1,"IP","ISP.CINGULAR"
OK
AT!SCACT=1,1
OK
AT!SCACT=0,1 closes the connection.

Then bring up interface
ubuntu@ubuntu:/home/ubuntu# sudo ipconfig wwan0 up
ubuntu@ubuntu:/home/ubuntu# sudo dhclient wwan0
Listening on LPF/wwan0/46:40:97:23:03:07
Sending on   LPF/wwan0/46:40:97:23:03:07
Sending on   Socket/fallback
DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 166.217.196.242 from 255.255.255.255
DHCPREQUEST of 166.217.196.242 on wwan0 to 255.255.255.255 port 67
DHCPACK of 166.217.196.242 from 255.255.255.255
bound to 166.217.196.242 -- renewal in 849179012 seconds.
Either way you want to handle the connection would be fine. Just exclude the sierra_net driver to not use wwan0 and we could just stick to using the current ppp way of doing things.

Who is online

Users browsing this forum: Amazon [Bot] and 14 guests