Core Routers and Connection Tracking
Hi All We have a few CCR1072's as our border routers, core routers and PE routers. They are pure routers (OSPF, BGP, Routing) with no NAT, Mangle, etc. They just route packets around on public IPs. We're providing internet services to our customers and our IaaS environment. In this scenario it makes sense to me that we would disable connection tracking. Extra over head with no real value? However, once you turn this of you lose the ability to use Established/Related rules in your firewall input chain, making DNS/upgrading/NTP etc a bit of a pain since return packets are dropped. So, I'm curious, are others using CCR's in these scenarios? Do you have connection tracking on or off? Why? Shane
Hi Shane! If you have multiple border routers, with possibility that connections are established with outbound packets via one border and reply packets via another border, then connection tracking is no use anyway - since the reply packets will be not part of any established connection on that 'other' router. So the point may be moot :-} But if that is not possible, then perhaps consider using fasttrack which essentially bypasses firewall (and qos ;) while still having advantage of connection tracking (it is a kind of connection tracking anyway I guess ;) In the end, though, 1072 is pretty slick, and you need a lot of traffic to bog it down - have you monitored CPU profiles with connection tracking enabled? It is rare that traffic handling will peg a CPU - usually only large routing table manipulation is the primary culprit for CPU pegging (i.e. BGP with multiple global route tables) Cheers! Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 10:59 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] Core Routers and Connection Tracking
Hi All
We have a few CCR1072's as our border routers, core routers and PE routers. They are pure routers (OSPF, BGP, Routing) with no NAT, Mangle, etc. They just route packets around on public IPs. We're providing internet services to our customers and our IaaS environment.
In this scenario it makes sense to me that we would disable connection tracking. Extra over head with no real value? However, once you turn this of you lose the ability to use Established/Related rules in your firewall input chain, making DNS/upgrading/NTP etc a bit of a pain since return packets are dropped.
So, I'm curious, are others using CCR's in these scenarios? Do you have connection tracking on or off? Why?
Shane
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hey Mike We're certainly not actually seeing any performance issues which has prompted me to start looking at this - It's just a theoretical discussion at this point as a part of nailing down our config template and I was curious what others are doing. It certainly is possible on our network that packets may exit/return to the network through different routers, so as you say in that case it's not offering much, just opening a connection which may not close until it expires. Has anyone actually seen a performance drop caused by having it on? That would be pretty hard to simulate on a 1072 but I imagine some of the smaller kit might see some performance impact with enough connections/sec (although they are likely a CPE and need NAT so it needs to be on anyway). Shane -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Monday, 24 June 2019 10:37 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking Hi Shane! If you have multiple border routers, with possibility that connections are established with outbound packets via one border and reply packets via another border, then connection tracking is no use anyway - since the reply packets will be not part of any established connection on that 'other' router. So the point may be moot :-} But if that is not possible, then perhaps consider using fasttrack which essentially bypasses firewall (and qos ;) while still having advantage of connection tracking (it is a kind of connection tracking anyway I guess ;) In the end, though, 1072 is pretty slick, and you need a lot of traffic to bog it down - have you monitored CPU profiles with connection tracking enabled? It is rare that traffic handling will peg a CPU - usually only large routing table manipulation is the primary culprit for CPU pegging (i.e. BGP with multiple global route tables) Cheers! Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 10:59 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] Core Routers and Connection Tracking
Hi All
We have a few CCR1072's as our border routers, core routers and PE routers. They are pure routers (OSPF, BGP, Routing) with no NAT, Mangle, etc. They just route packets around on public IPs. We're providing internet services to our customers and our IaaS environment.
In this scenario it makes sense to me that we would disable connection tracking. Extra over head with no real value? However, once you turn this of you lose the ability to use Established/Related rules in your firewall input chain, making DNS/upgrading/NTP etc a bit of a pain since return packets are dropped.
So, I'm curious, are others using CCR's in these scenarios? Do you have connection tracking on or off? Why?
Shane
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 11:23 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking
Hey Mike
We're certainly not actually seeing any performance issues which has prompted me to start looking at this - It's just a theoretical discussion at this point as a part of nailing down our config template and I was curious what others are doing.
It certainly is possible on our network that packets may exit/return to
Hi Shane, If you do not need or use any connection tracking features, then you certainly won't see any /decrease/ in performance by tuning it off :-} If you use connection-state features in firewall, then you will see some performance benefit in turning it on, but if you have asynchronous packet connections, then flows will break if you try to drop packets that are untracked or invalid, so a moot point whether it does anything good for you at all :-} Cheers! Mike. the
network through different routers, so as you say in that case it's not offering much, just opening a connection which may not close until it expires.
Has anyone actually seen a performance drop caused by having it on? That would be pretty hard to simulate on a 1072 but I imagine some of the smaller kit might see some performance impact with enough connections/sec (although they are likely a CPE and need NAT so it needs to be on anyway).
Shane
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Monday, 24 June 2019 10:37 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking
Hi Shane!
If you have multiple border routers, with possibility that connections are established with outbound packets via one border and reply packets via another border, then connection tracking is no use anyway - since the reply packets will be not part of any established connection on that 'other' router. So the point may be moot :-}
But if that is not possible, then perhaps consider using fasttrack which essentially bypasses firewall (and qos ;) while still having advantage of connection tracking (it is a kind of connection tracking anyway I guess ;)
In the end, though, 1072 is pretty slick, and you need a lot of traffic to bog it down - have you monitored CPU profiles with connection tracking enabled? It is rare that traffic handling will peg a CPU - usually only large routing table manipulation is the primary culprit for CPU pegging (i.e. BGP with multiple global route tables)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 10:59 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] Core Routers and Connection Tracking
Hi All
We have a few CCR1072's as our border routers, core routers and PE routers. They are pure routers (OSPF, BGP, Routing) with no NAT, Mangle, etc. They just route packets around on public IPs. We're providing internet services to our customers and our IaaS environment.
In this scenario it makes sense to me that we would disable connection tracking. Extra over head with no real value? However, once you turn this of you lose the ability to use Established/Related rules in your firewall input chain, making DNS/upgrading/NTP etc a bit of a pain since return packets are dropped.
So, I'm curious, are others using CCR's in these scenarios? Do you have connection tracking on or off? Why?
Shane
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 11:23 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking
Hey Mike
We're certainly not actually seeing any performance issues which has prompted me to start looking at this - It's just a theoretical discussion at this point as a part of nailing down our config template and I was curious what others are doing.
It certainly is possible on our network that packets may exit/return to
Hi Shane, In devices where we have Connection Tracking turned off, firewall rules have been modified to check for Syn packets instead of connection state. It is not as secure as using Connection State in rules, in particular it only works for TCP packets, however if CPU load is a concern it may be an acceptable risk. -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Monday, 24 June 2019 11:37 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking Hi Shane, If you do not need or use any connection tracking features, then you certainly won't see any /decrease/ in performance by tuning it off :-} If you use connection-state features in firewall, then you will see some performance benefit in turning it on, but if you have asynchronous packet connections, then flows will break if you try to drop packets that are untracked or invalid, so a moot point whether it does anything good for you at all :-} Cheers! Mike. the
network through different routers, so as you say in that case it's not offering much, just opening a connection which may not close until it expires.
Has anyone actually seen a performance drop caused by having it on? That would be pretty hard to simulate on a 1072 but I imagine some of the smaller kit might see some performance impact with enough connections/sec (although they are likely a CPE and need NAT so it needs to be on anyway).
Shane
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Monday, 24 June 2019 10:37 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking
Hi Shane!
If you have multiple border routers, with possibility that connections are established with outbound packets via one border and reply packets via another border, then connection tracking is no use anyway - since the reply packets will be not part of any established connection on that 'other' router. So the point may be moot :-}
But if that is not possible, then perhaps consider using fasttrack which essentially bypasses firewall (and qos ;) while still having advantage of connection tracking (it is a kind of connection tracking anyway I guess ;)
In the end, though, 1072 is pretty slick, and you need a lot of traffic to bog it down - have you monitored CPU profiles with connection tracking enabled? It is rare that traffic handling will peg a CPU - usually only large routing table manipulation is the primary culprit for CPU pegging (i.e. BGP with multiple global route tables)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 10:59 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] Core Routers and Connection Tracking
Hi All
We have a few CCR1072's as our border routers, core routers and PE routers. They are pure routers (OSPF, BGP, Routing) with no NAT, Mangle, etc. They just route packets around on public IPs. We're providing internet services to our customers and our IaaS environment.
In this scenario it makes sense to me that we would disable connection tracking. Extra over head with no real value? However, once you turn this of you lose the ability to use Established/Related rules in your firewall input chain, making DNS/upgrading/NTP etc a bit of a pain since return packets are dropped.
So, I'm curious, are others using CCR's in these scenarios? Do you have connection tracking on or off? Why?
Shane
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi I have 72 & 36 as border routers - similar setup BGP is about it some firewalling. I use conntrack and i also have a rule to allow non syn packets in to create connections, asym routing. I leave contrack on so my first line allow connected or related to be hit first plus it gives me stats on connections - bit weird on asym routes - but if you know the pathing can be helpful I actually put in a request a few years ago - there is a deamon in linux to syn the contrack state between linux machines - this could be ported over to ROS and would allow for asym routing with out special tcp rules A On Tue, 25 Jun 2019 at 08:27, Philip Loenneker < Philip.Loenneker@tasmanet.com.au> wrote:
Hi Shane,
In devices where we have Connection Tracking turned off, firewall rules have been modified to check for Syn packets instead of connection state. It is not as secure as using Connection State in rules, in particular it only works for TCP packets, however if CPU load is a concern it may be an acceptable risk.
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Monday, 24 June 2019 11:37 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking
Hi Shane,
If you do not need or use any connection tracking features, then you certainly won't see any /decrease/ in performance by tuning it off :-}
If you use connection-state features in firewall, then you will see some performance benefit in turning it on, but if you have asynchronous packet connections, then flows will break if you try to drop packets that are untracked or invalid, so a moot point whether it does anything good for you at all :-}
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 11:23 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking
Hey Mike
We're certainly not actually seeing any performance issues which has prompted me to start looking at this - It's just a theoretical discussion at this point as a part of nailing down our config template and I was curious what others are doing.
It certainly is possible on our network that packets may exit/return to the network through different routers, so as you say in that case it's not offering much, just opening a connection which may not close until it expires.
Has anyone actually seen a performance drop caused by having it on? That would be pretty hard to simulate on a 1072 but I imagine some of the smaller kit might see some performance impact with enough connections/sec (although they are likely a CPE and need NAT so it needs to be on anyway).
Shane
-----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Mike Everest Sent: Monday, 24 June 2019 10:37 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Core Routers and Connection Tracking
Hi Shane!
If you have multiple border routers, with possibility that connections are established with outbound packets via one border and reply packets via another border, then connection tracking is no use anyway - since the reply packets will be not part of any established connection on that 'other' router. So the point may be moot :-}
But if that is not possible, then perhaps consider using fasttrack which essentially bypasses firewall (and qos ;) while still having advantage of connection tracking (it is a kind of connection tracking anyway I guess ;)
In the end, though, 1072 is pretty slick, and you need a lot of traffic to bog it down - have you monitored CPU profiles with connection tracking enabled? It is rare that traffic handling will peg a CPU - usually only large routing table manipulation is the primary culprit for CPU pegging (i.e. BGP with multiple global route tables)
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Shane Clay Sent: Monday, 24 June 2019 10:59 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: [MT-AU Public] Core Routers and Connection Tracking
Hi All
We have a few CCR1072's as our border routers, core routers and PE routers. They are pure routers (OSPF, BGP, Routing) with no NAT, Mangle, etc. They just route packets around on public IPs. We're providing internet services to our customers and our IaaS environment.
In this scenario it makes sense to me that we would disable connection tracking. Extra over head with no real value? However, once you turn this of you lose the ability to use Established/Related rules in your firewall input chain, making DNS/upgrading/NTP etc a bit of a pain since return packets are dropped.
So, I'm curious, are others using CCR's in these scenarios? Do you have connection tracking on or off? Why?
Shane
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
participants (4)
-
Alex Samad -
Mike Everest -
Philip Loenneker -
Shane Clay