Need best practice advice: carp and /30

Wed Oct 1 01:35:55 UTC 2008

-----Original Message-----
From: Tom Huppi [mailto:tomh at huppi.com] 
Sent: Tuesday, September 30, 2008 10:13 PM
To: Catalin Miclaus
Cc: freebsd-pf at freebsd.org
Subject: Re: Need best practice advice: carp and /30

On 10:44 Tue 30 Sep     , Catalin Miclaus wrote:

> tomh writes:

> > I am trying to build a pfsync implementation so that I can
> > work on various hardening and other experiments with minimal
> > downtime, and could use some advice.
> > 
> > I expect to be using the most current FreeBSD codebase with this
> > implementation.  Indeed, being able to do so is a driving force
> > behind my project.
> > 
> > My network layout looks like so:
> > 
> > 
> > 
> >                                -----------------
> >                           /--  | em0  PF-1  em1 | ---
> >         | ------------ | /     |      em2       |
> >  ISP -- | special vlan |       ----------------
> >         |  cisco 3560  |              |
> >         |------------- |\      ----------------          
> >                           \   |      em2       |
> >                             - | em0  PF-2  em1 | ----
> >                                ----------------
> > 
> > 
> > 
> > My ISP provides a single IP on a /30.  Say 70.187.255.246, and
> > that carries my class-C traffic which is on a different subnet
> > entirely.
> > 
> > A similar solution but with only one PF firewall (also acting as
> > a simple router) has been working well enough over the last 10
> > months, although I did have certain problems which I have yet to
> > get to the bottom of.  Possibly they have something to do with
> > the Cisco which I neglected to mention in my last query to this
> > list since I thought it unimportant at the time.
> > 
> > Anyway, my question relates to what are best-practices vis-a-vis
> > the network of the 'em0' interface.  Pretty clearly the carp0
> > interface is my ISP assigned one, but there is not room in the
> > /30 for other addresses.
> > 
> > My guess is that I should 'invent' a RFC1918 network for the two
> > em0 interfaces, but I certainly don't want this to cause wierd
> > problems in the VLAN (I don't anticipate doing any routing in
> > this VLAN, by the way.)
> > 
> > In my googleing I found some info about getting 'carpdev'
> > supported and the threads seem to have dried up over a year
> > ago, so I think that it is probably in and working these days(?)
> > Even if so, still remains unclear to me what is safe and
> > appropriate in my situation.
> > 
> > If anyone has experiance with a similar setup and hardware, I
> > would very much appreciate knowing of their experiances.  The
> > IOS revision on the Cisco is from about a year ago...don't have
> > it handy, but can get it if it is a factor.
> > 
> > (Also, thank you to all who had input on my last question to the
> > list.  I got some feedback from my ISP about it, but it only
> > adds to the mystery. I'll follow-up on that thread when I know
> > more.)
> > 
> > Thanks,
> > 
> >  - Tom
> 
> 
> On external interface you need to configure at least the default
route.
> Moreover your ISP will have to configure same private range on his
> equipments which I doubt he will agree.
> 
> The way I see it you have 2 solutions:
> 
> 1. request for a /29 from your ISP
> 2. use enhanced image for 3560 (that will make it a layer 3 device)
with
> private range to your firewalls and public range on the ISP link

Thank you for your suggestions.

The 3560 I have to work with has 'C3560-IPBASE-M' while the one
I have currently in production has 'C3560-ADVIPSERVICESK9-M'.

The one in production will support also IP routing.

I think that both of these IOS version would do simple VLAN
routing.  I am very much a novice at this and don't use any
VLAN routing at all currently since I was able to do the
simple stuff I needed host-side in on my current setup.  (I
have been planning to abandon that strategy with my new carp
implementation and try to do more with VLAN routing, but that is
on the 'other side' of the issue I am currently trying to deal
with.)

I wonder if it would/could work to have something like:

           ----------         ----------
 ISP -->  |  3560    |  -->  |  3560    | -- em0:pf-1
          | VLAN /30 |       | VLAN /29 | -- em0:pf-2
           ----------         ----------

Yes, however, on ISP interface you don't need any VLAN. Just use 'ip
routing' on global config mode and 'no switchport' on interface config
mode so that your switch port will become a router port.

where I arrange appropriate routing between the two VLANs?
Perhaps that is basically what you are suggesting?

See above suggestion. Don't forget to point default route towards your
ISP.

I am quite confused about what traffic one would expect to see
makeing it out of the em0 interfaces when carp is active and
working.  Relatedly, what exactly the default route does in such
a scenerio.  These details don't seem to be broadly described in
the documentation I have run across so far.

Default route is routing all traffic with for which does not exist a
specific route in the routing table.
Aka default gateway, gateway of last resort, etc.

Thanks again for any thoughts on the matter. 

 - Tom

Best Regards
Catalin Miclaus
ISP-Data Ops.
Starcomms Ltd.

> Best Regards
> Catalin Miclaus
> ISP-Data Ops.
> Starcomms Ltd.
> 
> 
> 
> -- 
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
> 
> 
> DISCLAIMER: The information contained in this message (including any
attachments) is confidential and may be privileged. If you have received
it by mistake please notify the sender by return e-mail and permanently
delete this message and any attachments from your system. Any form of
dissemination, use, review, distribution, printing or copying of this
message in whole or in part is strictly prohibited if you are not the
intended recipient of this e-mail. Please note that e-mails are
susceptible to change. STARCOMMS PLC shall not be liable for the
improper or incomplete transmission of the information contained in this
communication nor for any delay in its receipt or damage to your system.
STARCOMMS PLC does not guarantee that the integrity of this
communication has been maintained or that this communication is free of
viruses, interceptions or interferences. STARCOMMS PLC reserves the
right to monitor all e-mail communications, whether related to the
business of STARCOMMS or not, through its internal or external networks.

-- 

DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any form of dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited if you are not the intended recipient of this e-mail. Please note that e-mails are susceptible to change. STARCOMMS PLC shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. STARCOMMS PLC does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. STARCOMMS PLC reserves the right to monitor all e-mail communications, whether related to the business of STARCOMMS or not, through its internal or external networks.