On one of my dmz machines I need to define a separate provider, which holds a set of routes to/from the (public) internet, as well as 3 of my internal networks (all arriving or originating on the same interface). As I have TC_EXPERT=No, as well as TRACK_PROVIDERS=No and USE_DEFAULT_RT=No, what would be the appropriate option to use for this provider: "track", "notrack", or neither? The man page doesn''t tell me much (either that, or I am getting a bit goofy today), so I need to canvass an opinion. Thanks. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On 04/27/2013 01:26 PM, Dash Four wrote:> On one of my dmz machines I need to define a separate provider, which > holds a set of routes to/from the (public) internet, as well as 3 of my > internal networks (all arriving or originating on the same interface). > > As I have TC_EXPERT=No, as well as TRACK_PROVIDERS=No and > USE_DEFAULT_RT=No, what would be the appropriate option to use for this > provider: "track", "notrack", or neither? The man page doesn''t tell me > much (either that, or I am getting a bit goofy today), so I need to > canvass an opinion. Thanks.The ''track'' option affects connection marking when incoming packets are received. When a packet is received on a ''track'' provider and the packet either creates a new connection or is part of a connection with no connection mark, then the connection is marked with the provider''s mark value. This causes all subsequent packets for that connection (in and out) to bypass the PREROUTING mangle rules (since you have TC_EXPERT=No) and simply use the connection mark''s value for routing (in the absence of a relevant routing rule). In general, ''track'' is the safe and efficient choice for a provider that has a configured mark value. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Tom Eastep wrote:> On 04/27/2013 01:26 PM, Dash Four wrote: > >> On one of my dmz machines I need to define a separate provider, which >> holds a set of routes to/from the (public) internet, as well as 3 of my >> internal networks (all arriving or originating on the same interface). >> >> As I have TC_EXPERT=No, as well as TRACK_PROVIDERS=No and >> USE_DEFAULT_RT=No, what would be the appropriate option to use for this >> provider: "track", "notrack", or neither? The man page doesn''t tell me >> much (either that, or I am getting a bit goofy today), so I need to >> canvass an opinion. Thanks. >> > > The ''track'' option affects connection marking when incoming packets are > received. When a packet is received on a ''track'' provider and the packet > either creates a new connection or is part of a connection with no > connection mark, then the connection is marked with the provider''s mark > value. This causes all subsequent packets for that connection (in and > out) to bypass the PREROUTING mangle rules (since you have TC_EXPERT=No) > and simply use the connection mark''s value for routing (in the absence > of a relevant routing rule). In general, ''track'' is the safe and > efficient choice for a provider that has a configured mark value. >Right, thanks Tom. If I use this provider for connections which do have a nat (from the top of my head, I do have at least 3 types of connections which get MASQUERADEd), should I then use the ''track'' or not, given that all these connections have statements in rtrules to direct to my provider table, based on their final destinations. To give you a brief example of this: in eth1->masquerade->eth0 out (the "provider" interface). My rtrules are with priorities 26000+ and are based on the destinations (subnet addresses) of these masqueraded connections. In addition, the dmz host (which has both eth0 and eth1 interfaces on it) also initiates such connections, but they start directly on the eth0 interface. ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Dash Four wrote:> > Tom Eastep wrote: >> On 04/27/2013 01:26 PM, Dash Four wrote: >> >>> On one of my dmz machines I need to define a separate provider, >>> which holds a set of routes to/from the (public) internet, as well >>> as 3 of my internal networks (all arriving or originating on the >>> same interface). >>> >>> As I have TC_EXPERT=No, as well as TRACK_PROVIDERS=No and >>> USE_DEFAULT_RT=No, what would be the appropriate option to use for >>> this provider: "track", "notrack", or neither? The man page doesn''t >>> tell me much (either that, or I am getting a bit goofy today), so I >>> need to canvass an opinion. Thanks. >>> >> >> The ''track'' option affects connection marking when incoming packets are >> received. When a packet is received on a ''track'' provider and the packet >> either creates a new connection or is part of a connection with no >> connection mark, then the connection is marked with the provider''s mark >> value. This causes all subsequent packets for that connection (in and >> out) to bypass the PREROUTING mangle rules (since you have TC_EXPERT=No) >> and simply use the connection mark''s value for routing (in the absence >> of a relevant routing rule). In general, ''track'' is the safe and >> efficient choice for a provider that has a configured mark value. >> > Right, thanks Tom. If I use this provider for connections which do > have a nat (from the top of my head, I do have at least 3 types of > connections which get MASQUERADEd), should I then use the ''track'' or > not, given that all these connections have statements in rtrules to > direct to my provider table, based on their final destinations. To > give you a brief example of this: > > in eth1->masquerade->eth0 out (the "provider" interface). My rtrules > are with priorities 26000+ and are based on the destinations (subnet > addresses) of these masqueraded connections. In addition, the dmz host > (which has both eth0 and eth1 interfaces on it) also initiates such > connections, but they start directly on the eth0 interface.Any help with this? ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On 04/29/2013 07:25 PM, Dash Four wrote:> > > Dash Four wrote: >> >> Tom Eastep wrote: >>> On 04/27/2013 01:26 PM, Dash Four wrote: >>> >>>> On one of my dmz machines I need to define a separate provider, >>>> which holds a set of routes to/from the (public) internet, as well >>>> as 3 of my internal networks (all arriving or originating on the >>>> same interface). >>>> >>>> As I have TC_EXPERT=No, as well as TRACK_PROVIDERS=No and >>>> USE_DEFAULT_RT=No, what would be the appropriate option to use for >>>> this provider: "track", "notrack", or neither? The man page doesn''t >>>> tell me much (either that, or I am getting a bit goofy today), so I >>>> need to canvass an opinion. Thanks. >>>> >>> >>> The ''track'' option affects connection marking when incoming packets are >>> received. When a packet is received on a ''track'' provider and the packet >>> either creates a new connection or is part of a connection with no >>> connection mark, then the connection is marked with the provider''s mark >>> value. This causes all subsequent packets for that connection (in and >>> out) to bypass the PREROUTING mangle rules (since you have TC_EXPERT=No) >>> and simply use the connection mark''s value for routing (in the absence >>> of a relevant routing rule). In general, ''track'' is the safe and >>> efficient choice for a provider that has a configured mark value. >>> >> Right, thanks Tom. If I use this provider for connections which do >> have a nat (from the top of my head, I do have at least 3 types of >> connections which get MASQUERADEd), should I then use the ''track'' or >> not, given that all these connections have statements in rtrules to >> direct to my provider table, based on their final destinations. To >> give you a brief example of this: >> >> in eth1->masquerade->eth0 out (the "provider" interface). My rtrules >> are with priorities 26000+ and are based on the destinations (subnet >> addresses) of these masqueraded connections. In addition, the dmz host >> (which has both eth0 and eth1 interfaces on it) also initiates such >> connections, but they start directly on the eth0 interface. > Any help with this?Just set ''track''. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1