I know this has been hyped for v7 but I think adding this to 6.x should be key. I was looking at some ccr1072s for a new deployment but there are 3 upstream providers with full IPv4 and 6 feeds from each. I have some concerns about performance if I deploy with them. I have solutions for DDoS weaknesses already which was also a concern but there are solid workarounds for that one.
Does anyone have a few full BGP feeds still on the CCRs? Are there any day to day issues assuming no connection flapping? It just takes a long time to converge all routes and process updates but this in general doesn’t impact passing traffic right? Anyway, i could imagine the complexity of coding a multithreaded bgp/route daemon so it’s not like i don’t get that.. i’m hoping they hire someone if necessary.
I have, no flapping all is working ok but convergence times is horrible. I have only 3 Full Feeds on each (ie: one full peer and two reflectors with all other peers) one tilera core is constantly at 100percent it will do as much as it can, as fast as it can.
Forwarding and routing is good and fast as long as you keep all traffic in fastpath. It is a router not a firewall.
Multithreaded approach is much overdue and we all are eagerly waiting for its arrival. Some here on the forum says it is not needed but looking at ALL other bgp implementations in on the market all is multi threaded.
1 thread reads queue and updates kernel routing table.
1 thread for each peering session keeps track of all traffic to and from one peer and keeps all peer data in specific local full table.
1 thread for each peer local table applying filters and posting result to main central queue.
Thanks for the info. Might give it a try. I think I can do 2 full feeds and only partial for the other peer. It’d be great if I knew that within a year it would be multithreaded.. it’s been talked about for years now it looks like. Ok done whining. haha
True, but it is still good practice to do anti-spoofing filtering on a border router
I also feel happier blocking traffic to the control plane with filters on the ‘input’ chain - you never know when some new bug with SSH or SNMP might turn up.
To prevent spoof, IP > Settings > RP Filter. You won’t route any package which it’s source isn’t reachable by you.
We currently have a CCR1072 with 2 full peers, 100 BGPv4 sessions and 120 routing filters. 0 firewall rules
It works? Well, it’s routing about 8gbps at peak hours. Maximum CPU usage is 10% (one core ALWAYS at 100%).
The problem: any route (even a static one) takes 15-20 minutes to start working. For example, if you add 192.168.1.1/24 address in ether1, it takes some minutes until you can ping to 192.168.1.0/24 network.
Of course if one of full peers goes down, be ready to loose all connectivity for 10-15 minutes. There is no way to flight or mitigate a DDoS attack with this response time (when you propagate the route to blackhole server, the attacker finished attacking hours ago and will be having a beer on the beach)
Can CCR1072 do it? Yes, it can. Can CCR1072 do it with carrier class performance? Absolutely no. Will it work when RouterOS v7 is launched? Maybe we’ll never know. Possibly many of us will be retired by then. For now, we’re moving to Huawei.
Similar scenario here, although within a much smaller environment:
CCR1009-7G-1C-1S+
Two BGPv4 full-feeds for IPv4/v6
Cymru full-bogons feed IPv4/v6
15 BGPv4 peeers / 125 routing filters
50 IPv4 and 50 IPv6 simple firewall rules
CPU average at 12%, peaks at 30% when under heavy-load
One single core always at 100% utilization (routing)
Would switch to a CCR1016 or CCR1036 instantly, if we knew it would be more performant. Unfortunately the current routing software implementation is the limiting factor - not the hardware itself. One could achieve better results even on much older x86 hardware by using a solid BGPd/routing software suite.
In our case it takes around 5-10 minutes. Matching routes on dst-address or bgp-as-path is HORRIBLE too. Might give FRRouting on x86 a try soon before we eventually will end up with a Cisco ASR. Sad story because I always preferred MT over other vendors for various reasons, not solely price-related, I’d be willing to even pay higher prices if they had fixed their crooked routing and BGP implementation. MT, do you even still hear our prayers?
IP SETTINGS RPFilter is there for antispoof (URPF But not vrf compatible in currently in V6) this makes allt your traffic remain in fastpath with URPF enabled either as STRICT or LOOSE where strict is telling the router only to accept packet source on ingress if it is currently routed and that the route is ACTIVE. Setting LOOSE will accept packet source ingress as long as A route is found Active or not. @MT Where is the ipv6 setting for URPF?
@MT PLEASE FIX VRF issue in V6 IF POSSIBLE if not PLEASE PUSH OUT THE UNICORN NEXT Version so that Routeros once again can be a GOOD Router.
Fixing Control plane issues on a tilera device with plenty of cores just to sacrifice fastpath… NO… But if you use weaker routers. You know what’s best for your network.
Set the Boorder witch often is multi homed to loose and others downstream to customer to strict and your’re DONE Concerning antispoof (AKA URPF)
Any update on this topic?
Using CCR1072 equipment no-one likes to get stuck with a hanging routing table on one core and route insert or modification times of 15-20 minutes.
Would be nice, but looks like it requires at least a v4.9 Linux kernel to be useful. So not practical to try and back port it to an older kernel. Would probably need substantial modifications to make it work. Would like to have them put that effort into getting a alpha or beta version released to get the ball rolling on a newer kernel.
When you only want to have failover you can consider having your upstream providers only send a default route and maybe their locally-announced subnets over BGP instead of a full table.
Any update on this topic?
Using CCR1072 equipment no-one likes to get stuck with a hanging routing table on one core and route insert or modification times of 15-20 minutes.
With the new 7 beta that is out we know they have improved the process of importing bgp routes. Just a matter of time before this is released into the wild and on e.g Tile.
However I would not run it in production for quite a while yet.
