Re: Creating a Circuit ID Format
Excerpts from Colton Conor's message of August 21, 2017 10:26 pm: We are building a new fiber network, and need help creating a circuit ID format to for new fiber circuits. Is there a guide or standard for fiber circuit formats? Does the circuit ID change when say a customer upgrades for 100Mbps to 1Gbps port? What do the larger carriers do? Any advice on creating a circuit ID format for a brand new fiber network? Originally we ran a CLEC using a LECs copper, and our circuit ID was historically a telephone number for DSL circuits. The ILEC had a complex method for assigning circuit IDs. I am sure anything will work as long as you keep track of it, but any advice would be great! Hi, I see you have already received some very good suggestions. The key for me with circuit IDs are that they have to integrate well in your backend systems as well as your products. There is little point in creating a telcordia-like system if you will have trouble filling in all the fields in an automated way, just like it can be troublesome to keep an incrementing number accurate, if you don't have a good central database to track it in. Avoid creating a number system where the A-end and B-end is part of the ID if you have (or ever will have) logical multi-point circuits. Also avoid having circuit numbers that take assumptions of your country of operation if you ever have to deliver something cross-border. I happen to like the format of PREFIX-NUMBERS, where the prefix indicates some sort of broad type, and with such a form it is important not to have too restrictive prefix types. For example consider only having Fiber, Copper, and logical as types, or whatever makes sense in your operation. With too many similar types comes the risk of having disparity between what your circuit ID suggests, and what is actually out there. I would suggest that you keep separate IDs for the actual fiber in the ground, and the service the customer buys. That way you can track the customer subscription, modify the parameters of it, if the customer upgrades his speed, but separately track your fiber deployment. At a previous employer we had to implement Service IDs on an already existing network where everything previously had been using only the actual fiber IDs, and that was a painful process, so it's better to get these things right as early as possible. -- Best Regards Allan Eising IP Network Engineer NORDUnet A/S m: eis...@nordu.net w: http://www.nordu.net
Re: Mikrotik BGP Question
On Sun, 23 May 2010 08:21:47 +0200, Graham Beneke wrote: > On 2010/05/21 11:56 PM, Martin List-Petersen wrote: >> - Mikrotik still has some memory leaks in the BGP stack somewhere, >> causing funny issues at times. >> >> - Filters aren't adequate for my use, and lacking a lot on IPv4, but >> even more on IPv4. > > I haven't seen either of those issues running the v4.x stream of > RouterOS. The memory leak was solved a while ago and Mikrotik has fairly > short release cycles. > > We have extensive inbound and outbound filters on our eBGP doing most of > the normal things that you would do on a cisco. The IPv6 filters must be > built via the terminal to avoid limitations with the current GUI but > they also work very well In some ways, I find the MikroTik RouterOS routing filter syntax a little more powerful than Cisco's route-maps. As routing filters work the same way as firewall filters, you can group rules in "chains" and reuse parts of your filters in other filters by jumping to another chain. This could be used, for instance, on a peering setup, where you have a number of rules per peer but also some common filtering for all peers, or to handle specific and generic filtering for your customers. I haven't yet found anything that I missed being able to with filters, at least with BGP. With other routing protocols, it's another story. Regards, Allan Eising
Re: Mikrotik RouterOS
On Mon, 12 Apr 2010 14:54:59 -0400, James Jones wrote: > I am currently looking at using RouterOS as a way to build a Metro > Ethernet solution. Does anyone have experience with the device and the > OS? How is the performance? Are there any "Gotchas"? > > > -James I've been working with RouterOS for a while, especially with it's more service provider oriented features such as MPLS and BGP. Here are some points that might help you: 1) Consider what device you want to run it on, especially regarding expected throughput. If you want to run it on x86 hardware, consider either buying one of the available x86 solutions, such as PoweRouter or OGMA connect, or spend some time evaluating that your hardware configuration is indeed supported. RouterOS is based on a 32-bit linux kernel, and it's not the newest one... The upcoming version 5 will feature a recent kernel, but is still 32bit, so don't expect things like multiqueue to work on your intel NICs. 2) Understand that bugs happen, and new software is released frequently. Acknowledge that there might be issues with quality assurance for new software versions. Expect to test new versions rigorously before rolling out. That said, MikroTik support is very friendly and will help you with most issues. 3) Their RouterBoard products are cheap, and are often made from the cheapest components. I have seen issues with faulty components. Recently, they EOL'd their only rack-mount router, the RB1000U, while the replacement - a cheaper router with more ports, and little less power - has not yet gone into sale. And now for all the good things: 4) Their MPLS support, as well as their implementations of routing protocols are quite good. They support both MPLS and VPLS and can even work with Cisco's BGP-signalled VPLS, as well as the rfc version of it. 5) The CLI is easy to work with, and has an excellent API that allows you to easily integrate provisioning into your existing systems. There is also a graphic tool called WinBox. This tool gives you a very easy overview of your router's configuration, so put away any CLI-only bias you might have inherited from working with other vendors. I consider their routers great for Metro Ethernet solutions on a lower scale. Their low cost makes it very easy to roll out an MPLS network, as the price for a PoP will be low, however keep an eye on the performance of the routers. You are welcome to contact me if you have any additional questions. Regards, Allan Eising
