Re: Firewalls - Ease of Use and Maintenance?

[Seth Mos]

On 9-11-2011 0:06, Jones, Barry wrote:
> Hello all.
> I am potentially looking at firewall products and wanted suggestions as to 
> the easiest firewalls to install, configure and maintain? I have a few small 
> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. 
> I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and 
> each have strong and not as strong features for ease of use. Like everyone, 
> I'm resource challenged and need an easy solution to stand up and operate.

I am biased because I am a pfSense developer.

pfSense is a free open source FreeBSD based firewall with the pf packet
filter. http://www.pfsense.org

It supports various features and installable packages that might fill
your needs. Commercial support is also available.

One of the reasons I use it at work is because it is by far the cheapest
solution to gigabit redundant (Active/Passive) firewalls. It runs on x86
machines from the low end PCengines.ch Alix 2D3 to something like a dual
core Intel Atom for or the higher end on a "normal" server.

It is administered entirely via the webUI, saves the config in a XML
file you can backup and then restore on pretty much any other hardware
you have around should it need to be replaced.

The (readable) XML file was also really easy to provision things like
hundreds of VPN tunnels instead of clicking through the UI.

The PHP command interface allows you to perform scripting operations on
the XML as well which comes in handy on mass mutations.

Kind regards,

Seth

Re: Firewalls - Ease of Use and Maintenance?

[Tom Hill]

On Wed, 2011-11-09 at 09:13 +0100, Seth Mos wrote:
> I am biased because I am a pfSense developer.
> 
> pfSense is a free open source FreeBSD based firewall with the pf
> packet filter. http://www.pfsense.org

I'm a very happy user of m0n0wall and I know pfSense is often seen as
the more 'grown up' variant.

Still though, I hear bad things of the IPv6 support in pfSense. It's
"available" but not stock-standard & supported.

How does the pfSense developer attitude towards filtering the entire
Internet, IPv6 included, currently stand?

Tom

Re: Firewalls - Ease of Use and Maintenance?

[Seth Mos]

On 9-11-2011 11:07, Tom Hill wrote:
> On Wed, 2011-11-09 at 09:13 +0100, Seth Mos wrote:
>> I am biased because I am a pfSense developer.
>>
>> pfSense is a free open source FreeBSD based firewall with the pf
>> packet filter. http://www.pfsense.org
> 
> I'm a very happy user of m0n0wall and I know pfSense is often seen as
> the more 'grown up' variant.
> 
> Still though, I hear bad things of the IPv6 support in pfSense. It's
> "available" but not stock-standard & supported.

That is correct, it is in the 2.1 branch. Our code has diverged a lot
from m0n0wall where it came from so porting it was not easy. Instead I
wrote the code from scratch.

I wrote the IPv6 code in pfSense 2.1 for the last year and I've been
using it in production for quite a while now. Since February this year
to be precise.

It is true that until 2.1 is released somewhere next year the latest
official release is pfSense 2.0.

The people running Commercial support do support 2.1 with IPv6 if you
need it though. There are already a number of customers running it in
production because they needed IPv6 support.

The biggest holdup is lack of commercial VPN client support for
dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a
working Windows OpenVPN dual stack client solution in the Client
exporter on 2.1.

Working dual stack for your VPN solution is kind of important if you
expect to be able to reach your corporate servers. Much grief/fun to be
had here. If the corporate LAN advertises quad A records then it will
confuse your VPN clients if they have a v4 VPN address but only a v6
internet address.

> How does the pfSense developer attitude towards filtering the entire
> Internet, IPv6 included, currently stand?

I do not quite understand your question. If you are referring to a
default deny policy on incoming traffic, then yes.

The default rule is to deny incoming traffic over IPv6 as it did over
IPv4. You will need to create rules to allow it through. Default LAN
rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the
firewall rules as you see fit.

If I misunderstood your question then please verify.

Kind regards,

Seth

Re: where was my white knight....

[Nick Hilliard]

On 09/11/2011 03:14, Randy Bush wrote:
> once again, 
>   o when you have no connection to a cache or no covering roa for a
> a prefix, the result is specified as NotFound
>   o we recommend you route on NotFound
> 
> so the result is the same as today.

Well no, not really because when the cache becomes reachable again, you
need to revalidate everything which got a NotFound.  This will cause extra
bgp churn where revalidation caused a local policy change.

Even if you have a local cache, this will still cause problems due to the
problem you summarised in draft-ietf-sidr-origin-ops, section 6:

"Like the DNS, the global RPKI presents only a loosely consistent view,
depending on timing, updating, fetching, etc.  Thus, one cache or router
may have different data about a particular prefix than another cache or
router.  There is no 'fix' for this, it is the nature of distributed data
with distributed caches."

Local caches may miss updates due to interior unreachability.  Routers will
not revalidate after cache updates.  So this loosely consistent view will
propagate into your routers' bgp views.  Do I really want this?  Or, more
to the point, is a perpetually inconsistent bgp network view better or
worse than the occasional more serious reachability problem that rpki is
attempting to solve?  This isn't clear to me.

>> Until this happens, there will be no connectivity from the router to
>> the cache
> 
> false

Not false in the scenario I described.  Please read what I said, not what
your straw man whispers in your ear. :-)

Nick

Re: Firewalls - Ease of Use and Maintenance?

[Tom Hill]

On Wed, 2011-11-09 at 12:01 +0100, Seth Mos wrote:
> That is correct, it is in the 2.1 branch. Our code has diverged a lot
> from m0n0wall where it came from so porting it was not easy. Instead I
> wrote the code from scratch.
> 
> I wrote the IPv6 code in pfSense 2.1 for the last year and I've been
> using it in production for quite a while now. Since February this year
> to be precise.
> 
> It is true that until 2.1 is released somewhere next year the latest
> official release is pfSense 2.0.
> 
> The people running Commercial support do support 2.1 with IPv6 if you
> need it though. There are already a number of customers running it in
> production because they needed IPv6 support.

TH: This is good news. I look forward to the general availability of 2.1
in this case. An "official" release supporting v6 properly is long
over-due for pfSense; users have been complaining about the lack of
support for *years*.

> The biggest holdup is lack of commercial VPN client support for
> dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a
> working Windows OpenVPN dual stack client solution in the Client
> exporter on 2.1.
> 
> Working dual stack for your VPN solution is kind of important if you
> expect to be able to reach your corporate servers. Much grief/fun to be
> had here. If the corporate LAN advertises quad A records then it will
> confuse your VPN clients if they have a v4 VPN address but only a v6
> internet address.

TH: Indeed, but the more you push on it the better it will become
(hopefully). VPN clients/concentrators in the FOSS world is already a
minefield of incompatibilities and other such problems.

> > How does the pfSense developer attitude towards filtering the entire
> > Internet, IPv6 included, currently stand?
> 
> I do not quite understand your question. If you are referring to a
> default deny policy on incoming traffic, then yes.
> 
> The default rule is to deny incoming traffic over IPv6 as it did over
> IPv4. You will need to create rules to allow it through. Default LAN
> rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the
> firewall rules as you see fit.
> 
> If I misunderstood your question then please verify.

TH: In the past, the pfSense developer's attitude to IPv6 support has
been pretty poor. I have mentioned above that customers have been asking
for such support for years (i.e. since m0n0wall had it) and the response
has been 'it's not important yet', which really wasn't true.

But, despite that, it sounds like it's finally getting better. And that
can only be good news.

Tom

Re: Firewalls - Ease of Use and Maintenance?

[Richard Kulawiec]

You will find it very difficult to beat pf on OpenBSD for efficiency,
features, flexibility, robustness, and security.  Maintenance is very
easy: edit a configuration file, reload, done.

---rsk

Re: Firewalls - Ease of Use and Maintenance?

[Alex Nderitu]

On 11/09/2011 03:22 PM, Richard Kulawiec wrote:

You will find it very difficult to beat pf on OpenBSD for efficiency,
features, flexibility, robustness, and security.  Maintenance is very
easy: edit a configuration file, reload, done.

---rsk


An important feature lacking for now as far as I know is content/web 
filtering especially for corporates wishing to block inappropriate/time 
wasting content like facebook. Addition of this would place it a par 
with the best like Sonicwall and Fortinet.


Alex

Re: Firewalls - Ease of Use and Maintenance?

[Joe Greco]

> On 11/09/2011 03:22 PM, Richard Kulawiec wrote:
> > You will find it very difficult to beat pf on OpenBSD for efficiency,
> > features, flexibility, robustness, and security.  Maintenance is very
> > easy: edit a configuration file, reload, done.
>
> An important feature lacking for now as far as I know is content/web 
> filtering especially for corporates wishing to block inappropriate/time 
> wasting content like facebook. Addition of this would place it a par 
> with the best like Sonicwall and Fortinet.

I would probably disagree with Richard's statement; most organizations
are looking for something that's a little more of a product/appliance
and a little less of a one-off solution/generic UNIX box.

That having been said, if you AREN'T put off by "edit a configuration
file", then maybe you won't be put off by "install Squid, add squidGuard
(IIRC), and configure transparent proxying" and you're pretty much all
the way there.  Oh, and you get caching acceleration for free.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Firewalls - Ease of Use and Maintenance?

[Richard Kulawiec]

On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> An important feature lacking for now as far as I know is content/web
> filtering especially for corporates wishing to block
> inappropriate/time wasting content like facebook. 

1. That's not a firewall function.  That's a censorship function.

2. You can of course easily do that via a variety of means, including
BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
allocations, running an HTTP proxy that blocks them, etc.  I presume
that any minimally-competent censor could easily devise a first-order
solution (using the software packages supplied with OpenBSD) in an afternoon.

---rsk

Re: Firewalls - Ease of Use and Maintenance?

[Nick Hilliard]

On 09/11/2011 12:22, Richard Kulawiec wrote:
> You will find it very difficult to beat pf on OpenBSD for efficiency,
> features, flexibility, robustness, and security.  Maintenance is very
> easy: edit a configuration file, reload, done.

There are several areas where pf falls down.  One is auto-synchronisation
from primary to backup firewall (not really a pf problem, but it's
important for production firewall systems).  Another is ipv6 fragments,
although this was mostly fixed in a commit on 20110329 (released in 5.0),
which unfortunately has not yet made its way to freebsd yet.  A third is
openbsd's poor ethernet hardware interrupt handling.  Again, this has
improved recently, but it's still lags seriously behind linux / freebsd.

Having said that, it's still my least disfavoured stateful packet filtering
system.

Nick

Re: Firewalls - Ease of Use and Maintenance?

[Joe Greco]

> On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> > An important feature lacking for now as far as I know is content/web
> > filtering especially for corporates wishing to block
> > inappropriate/time wasting content like facebook. 
> 
> 1. That's not a firewall function.  That's a censorship function.

A "firewall" is pretty much a censorship function, you're using it to
disallow certain types of traffic on your network.  It's simply a matter
of what layer you find most convenient to block things...  a firewall
is better closer to the bottom of the OSI layer model, a proxy is better
closer to the top of the OSI layer model.

Is it "censorship" not to want unwanted connection attempts to our
gear, and block unsolicited TCP connections inbound?

Is it "censorship" not to want unwanted exploit attempts to our
gear, and run everything through ClamAV, and use blocklists to
prevent users inadvertently pulling content from known malware sites?

There's no functional differentiation between blocking content for
one reason and blocking it for another.  There's certainly a huge
difference in the POLICY decisions that drive those blocking decisions,
but the technology to do them is essentially identical.  You can,
after all, block facebook on your firewall at the IP level and I think
we would both agree that that is "censorship" but also something a
firewall is completely capable of.  It's just neater and more practical
to do at a higher level, for when facebook changes IP addresses (etc),
so a higher level block is really more appropriate.

> 2. You can of course easily do that via a variety of means, including
> BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
> allocations, running an HTTP proxy that blocks them, etc.  I presume
> that any minimally-competent censor could easily devise a first-order
> solution (using the software packages supplied with OpenBSD) in an afternoon.

It's a little trickier to do in practice.  I kind of wish pfSense
included such functionality by default, it'd be so killer.  :-)
Last I checked, it was possible-but-a-fair-bit-of-messing-around.

Still, vote++ for pfSense.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Firewalls - Ease of Use and Maintenance?

[-Hammer-]

I think that firewall/censorship is all semantics. The real question is 
the scale of the environment and the culture of your shop and areas of 
ownership.


I work in a large enterprise. Combining "functions" such as L3 
firewalling with content filtering with url filtering with XXX can be 
difficult.


1. Can the platform actually handle all the traffic?
2. Does one group own ALL the separate functions? If not, RBAC becomes 
an important (and sometimes political) issue.

3. How easy is it to troubleshoot?

Although modern hardware is quickly catching up with all the glorious 
software features people want these days, in our environment we found it 
easier and saner to separate these functions. They were owned by 
different groups and the number of FWs we deploy vs the number of 
content filters didn't add up to make sense when aggregating functions 
was discussed.


In a smaller operation a Fortinet or other product that consolidates 
these efforts may make sense. In a larger operation in depends on many 
outside factors.


I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. 
I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over 
Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, 
Sonicwall (say Uncle!) and others. They all have their pros and cons and 
in the end it is specific to your shops needs.


More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD 
isn't UNIX. That's a different mailing list.
More of a Linux guy and need to make sure you have a vendor to yell at? 
CheckPoint. IPSO/SPLAT/GAEA is all Linux.
Not a UNIX/Linux guy and you need a more reliable vendor? And a 
traditionally safer bet? "No one ever got fired for buying Cisco."
Need to save money? Consolidate functions? Confident of the capabilities 
of the product? Fortinet.


And the list goes on and on and on


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/09/2011 08:00 AM, Joe Greco wrote:

On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
 

An important feature lacking for now as far as I know is content/web
filtering especially for corporates wishing to block
inappropriate/time wasting content like facebook.
   

1. That's not a firewall function.  That's a censorship function.
 

A "firewall" is pretty much a censorship function, you're using it to
disallow certain types of traffic on your network.  It's simply a matter
of what layer you find most convenient to block things...  a firewall
is better closer to the bottom of the OSI layer model, a proxy is better
closer to the top of the OSI layer model.

Is it "censorship" not to want unwanted connection attempts to our
gear, and block unsolicited TCP connections inbound?

Is it "censorship" not to want unwanted exploit attempts to our
gear, and run everything through ClamAV, and use blocklists to
prevent users inadvertently pulling content from known malware sites?

There's no functional differentiation between blocking content for
one reason and blocking it for another.  There's certainly a huge
difference in the POLICY decisions that drive those blocking decisions,
but the technology to do them is essentially identical.  You can,
after all, block facebook on your firewall at the IP level and I think
we would both agree that that is "censorship" but also something a
firewall is completely capable of.  It's just neater and more practical
to do at a higher level, for when facebook changes IP addresses (etc),
so a higher level block is really more appropriate.

   

2. You can of course easily do that via a variety of means, including
BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
allocations, running an HTTP proxy that blocks them, etc.  I presume
that any minimally-competent censor could easily devise a first-order
solution (using the software packages supplied with OpenBSD) in an afternoon.
 

It's a little trickier to do in practice.  I kind of wish pfSense
included such functionality by default, it'd be so killer.  :-)
Last I checked, it was possible-but-a-fair-bit-of-messing-around.

Still, vote++ for pfSense.

... JG
   

Re: Firewalls - Ease of Use and Maintenance?

[-Hammer-]

OH yeah!

MANAGEMENT: If you have a few FWs and you manage them independently life 
is grand. But what if you have 20? 50? 100? and if 30-40 percent of the 
policy is the same?


Cisco: NOTHING. Don't let them lie to you.
CheckPoint: Provider 1 and SmartManager.
Juniper: Not sure.
BSD/PFSense: Nothing I know of
Others: ???

Disclaimer: We are currently a CheckPoint/FWSM/PIX/ASA/Juniper shop. 
This is the byproduct of mergers/acquisitions/etc. We have standardized 
on CheckPoint and are phasing out the other vendors as they sunset. A 
major factor in the decision was management. In the end, if you separate 
the functions like we do, a FW is a FW is a FW. L3/4 isn't that 
complicated these days. It's L7 FWs that get the attention. So if the 
product is stable and has a good MTBF then it's not a huge difference to 
us as far as the capability of the FW to perform it's function. They all 
do it well.


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/09/2011 08:52 AM, -Hammer- wrote:
I think that firewall/censorship is all semantics. The real question 
is the scale of the environment and the culture of your shop and areas 
of ownership.


I work in a large enterprise. Combining "functions" such as L3 
firewalling with content filtering with url filtering with XXX can be 
difficult.


1. Can the platform actually handle all the traffic?
2. Does one group own ALL the separate functions? If not, RBAC becomes 
an important (and sometimes political) issue.

3. How easy is it to troubleshoot?

Although modern hardware is quickly catching up with all the glorious 
software features people want these days, in our environment we found 
it easier and saner to separate these functions. They were owned by 
different groups and the number of FWs we deploy vs the number of 
content filters didn't add up to make sense when aggregating functions 
was discussed.


In a smaller operation a Fortinet or other product that consolidates 
these efforts may make sense. In a larger operation in depends on many 
outside factors.


I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. 
I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over 
Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, 
Sonicwall (say Uncle!) and others. They all have their pros and cons 
and in the end it is specific to your shops needs.


More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD 
isn't UNIX. That's a different mailing list.
More of a Linux guy and need to make sure you have a vendor to yell 
at? CheckPoint. IPSO/SPLAT/GAEA is all Linux.
Not a UNIX/Linux guy and you need a more reliable vendor? And a 
traditionally safer bet? "No one ever got fired for buying Cisco."
Need to save money? Consolidate functions? Confident of the 
capabilities of the product? Fortinet.


And the list goes on and on and on
-Hammer-

"I was a normal American nerd"
-Jack Herer

   


On 11/09/2011 08:00 AM, Joe Greco wrote:

On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
 

An important feature lacking for now as far as I know is content/web
filtering especially for corporates wishing to block
inappropriate/time wasting content like facebook.
   

1. That's not a firewall function.  That's a censorship function.
 

A "firewall" is pretty much a censorship function, you're using it to
disallow certain types of traffic on your network.  It's simply a matter
of what layer you find most convenient to block things...  a firewall
is better closer to the bottom of the OSI layer model, a proxy is better
closer to the top of the OSI layer model.

Is it "censorship" not to want unwanted connection attempts to our
gear, and block unsolicited TCP connections inbound?

Is it "censorship" not to want unwanted exploit attempts to our
gear, and run everything through ClamAV, and use blocklists to
prevent users inadvertently pulling content from known malware sites?

There's no functional differentiation between blocking content for
one reason and blocking it for another.  There's certainly a huge
difference in the POLICY decisions that drive those blocking decisions,
but the technology to do them is essentially identical.  You can,
after all, block facebook on your firewall at the IP level and I think
we would both agree that that is "censorship" but also something a
firewall is completely capable of.  It's just neater and more practical
to do at a higher level, for when facebook changes IP addresses (etc),
so a higher level block is really more appropriate.

   

2. You can of course easily do that via a variety of means, including
BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
allocations, running an HTTP proxy that blocks them, etc.  I presume
that any minimally-competent censor could easily devise a first-order
solution (using the software packages supplied with OpenBSD) in an afternoon.
 

It's a little trickier to do in practice.  I kind of wish pfSen

Re: Firewalls - Ease of Use and Maintenance?

[Gregory Croft]

Hi, I'm at a smaller company that wanted not only firewall capabilities but
application level filtering.

We went with the Palo Alto Networks.
Story is the Palo Alto founder was formerly of Netscreen/Juniper.

Anyhow. We've not had any issues with the PA500's that we use in our
environment. They also just released a smaller unit (PA200) for small
offices. 

Very easy to use/operate. My only complaint is the time it takes to commit
changes. 

If you have any specific questions, shoot me an email.

Hope that helps.
Greg






On 11/8/11 6:06 PM, "Jones, Barry"  wrote:

> Hello all.
> I am potentially looking at firewall products and wanted suggestions as to the
> easiest firewalls to install, configure and maintain? I have a few small
> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I
> have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each
> have strong and not as strong features for ease of use. Like everyone, I'm
> resource challenged and need an easy solution to stand up and operate.
> 
> Feel free to ping me offline - and thank you for the assistance.
> 
> 
> Barry Jones - CISSP GSNA
> Project Manager II
> Sempra Energy Utilities
> (760) 271-6822
> 
> P please don't print this e-mail unless you really need to.
> 
> 

Re: Firewalls - Ease of Use and Maintenance?

[Jonathan Lassoff]

On Wed, Nov 9, 2011 at 5:24 AM, Nick Hilliard  wrote:
> On 09/11/2011 12:22, Richard Kulawiec wrote:
>> You will find it very difficult to beat pf on OpenBSD for efficiency,
>> features, flexibility, robustness, and security.  Maintenance is very
>> easy: edit a configuration file, reload, done.
>
> There are several areas where pf falls down.  One is auto-synchronisation
> from primary to backup firewall (not really a pf problem, but it's
> important for production firewall systems).

I've found that this works decently well, via pfsync. It sends out
multicast IP packets with multi-valued elements describing the state
of the flows it has in its table.

If you're having pf inspect TCP sequence numbers, there's a bit of a
race condition in failover with frequently or fast-moving TCP streams.
As the window of acceptable sequence numbers moves on the active
firewall, they're slightly delayed in getting replicated to the
backup(s) and installed in their state tables.
Consequently, on failover, it's possible for some flows to get blocked
and which have to be re-created.

I've hit this and dug into it recently, so if you're having a problem,
I'd be happy to chat offlist.

Cheers,
jof

ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week)

[John Curran]

NANOG Community -

There is an Draft Policy for Inter-RIR Transfers presently in extended
"Last Call" in the ARIN Policy Development Process.   The Last Call
will run for one more week, and allows an opportunity for anyone in the
Internet community to provide feedback regarding this proposed
number resource policy.  Feedback, including statements in support
or opposition, may be sent to the ARIN Public Policy Mailing List
"arin-p...@arin.net"  
(http://lists.arin.net/mailman/listinfo/arin-ppml
to join or view archives)   A copy of the Last Call announcement,
including the most recent changes and draft policy text, is attached
to this email.  Feel free to forward this email to anyone in the Internet
community that you feel may wish to comment in support or opposition
to this draft policy.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
Date: October 19, 2011 3:11:59 PM EDT
To: arin-p...@arin.net

The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
send an amended version of the following draft policy to an extended last call:

 ARIN-2011-1: ARIN Inter-RIR Transfers

The AC provided the following statement:


The Advisory Council reviewed the results of feedback from the ARIN
XXVIII Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR
Transfers.  While there were concerns regarding the presented wording,
there was significant continued support for a policy enabling
Inter-Regional transfers of IPv4 number resources from organizations able to 
make them available to any organization with valid requirements.

In addition to cumbersome wording, the presented text could not be
cleanly inserted into the NRPM.  The following is new language that
directly modifies section 8.3 "Transfers to Specified Recipients" to
allow such transfers to or from organizations in other regions.

The first paragraph is a modified version of the current 8.3 policy
language, envisioning resources being released to ARIN by the authorized
resources holder or additionally by another RIR to be transferred to a
specified recipient.  The second sentence was reorganized to emphasize
that it applies to an organization within the ARIN region that will
receive such a specified transfer, and to eliminate the single aggregate
language per 2011-10 which is also being sent to last call.

The new second paragraph adds language enabling transfers to a specified
recipient in another RIR's service region.  This language specifies that
such recipients justify their need to their RIR, following that RIR's
policies.  ARIN will verify that there is a compatible needs based
policy that the other RIR will use to evaluate the need of the recipient
and that both RIR's agree to the transfer. Implicit in the intent of
the language presented and in conformance with statements made, the size
of the block to be transferred is identified as /24 or larger, for
obvious practical reasons.

In accordance with concern for immediate adoption, the AC chose to
forward this version to last call.  Concerns expressed by some
stakeholders for further controls were noted by the AC, and are being
considered for future policy modification, assuaged in part by ARIN
staff assurances that if any significant abuse of this policy were to
occur, then the policy could easily be suspended.

The AC thanks everyone in the community for their help in crafting this
important policy and for your statements of support or other comments
during Last Call.


Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-1 will
expire on 16 November 2011. After last call the AC will conduct their last call 
review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2011-1
ARIN Inter-RIR Transfers

Date/version: 14 October 2011

Policy statement:

8.3 Transfers to Specified Recipients

In addition to transfers under section 8.2, IPv4 number resources may be
released to ARIN by the authorized resource holder or another RIR, in
whole or in part, for transfer to another specified organizational
recipient.  Organizations in the ARIN region may receive transferred
number resources under RSA if they can demonstrate the need for such
resources in the amount which they can justify under current ARIN policies.

IPv4 address resources may be transferred to organizations in another
RIR's service region if they demonstrate need to their region's RIR,
according to that RIR's policies. Inter-regional transfers may take
p

Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week)

[Leo Bicknell]

In a message written on Wed, Nov 09, 2011 at 03:33:04PM +, John Curran 
wrote:
> 
> There is an Draft Policy for Inter-RIR Transfers presently in extended
> "Last Call" in the ARIN Policy Development Process.   The Last Call
> will run for one more week, and allows an opportunity for anyone in the
> Internet community to provide feedback regarding this proposed
> number resource policy.  Feedback, including statements in support

I went and read a fair number of PPML messages via the web interface
as I no longer subscribe.  I also read the policy proposal.

I think the AC, and ARIN's policy process in general has come off
the rails.  There's a reason why I unsubscribed from PPML, and have
not participated for 2+ years.  I don't know exactly where things
went wrong, but somewhere they went very, very wrong.

But I don't have to summarize, Bill Sandiford (an AC Member) already
did that for me:
http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html

Which leads me to my thoughts on the process, from two areas:

1) The concept of Inter-RIR transfers is a bad idea.  Insuring
   "compatible" rules between RIR's will always be difficult at
   best.  There are technical difficulties for the RIR's, such
   as how reverse DNS is handled.  Most importantly, after going
   through all the pain of figuring out these details it's unlikely
   to help very many people at all.

2) The process followed to get here is totally broken.  Bill hit
   the nail on the head, and it's archived on ARIN's web site:
   Text in Sep: 
http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html
   Text in Oct: 
http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html

   Near as I can tell the feedback in the October meeting made the
   AC want to do a _total rewrite of the entire policy_, which they
   turned around in under a week and shoved directly into the last
   call process.

It's disgusting, and I'm glad I'm no longer involved.  It's a mockery of
the policy process ARIN has set up, and I'm baffled to this day why more
folks aren't upset about it.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpYtcCDli1H0.pgp
Description: PGP signature

Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week)

[William Herrin]

On Wed, Nov 9, 2011 at 10:33 AM, John Curran  wrote:
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send an amended version of the following draft policy to an extended last 
> call:
>
>  ARIN-2011-1: ARIN Inter-RIR Transfers

Hi folks,

There has been some contentious debate about this draft policy. In
particular, it may provide a path for bleeding IPv4 addresses from
North America to other world regions without requiring reciprocal
access to other regions' IPv4 addresses for North American companies.

If this concerns you, and I hope it does, I urge you to educate
yourself on the matter and then voice your opinion on the ARIN public
policy mailing list.

Reference materials:

The policy as presently drafted:
http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html

The proposed policy's draft history:
https://www.arin.net/policy/proposals/2011_1.html

How to subscribe to the ARIN public policy mailing list:
http://lists.arin.net/mailman/listinfo/arin-ppml

A brief selection of issues raised in the debate:

http://lists.arin.net/pipermail/arin-ppml/2011-October/023441.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023464.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023467.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023500.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023511.html
http://lists.arin.net/pipermail/arin-ppml/2011-October/023527.html
http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html
http://lists.arin.net/pipermail/arin-ppml/2011-November/023667.html

Regards,
Bill Herrin




-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week)

[John Curran]

On Nov 9, 2011, at 10:56 AM, Leo Bicknell wrote:

> 2) The process followed to get here is totally broken.  Bill hit
>   the nail on the head, and it's archived on ARIN's web site:
>   Text in Sep: 
> http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html
>   Text in Oct: 
> http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html
> 
>   Near as I can tell the feedback in the October meeting made the
>   AC want to do a _total rewrite of the entire policy_, which they
>   turned around in under a week and shoved directly into the last
>   call process.

Leo - 

  To be clear, the ARIN Advisory Council (ARIN AC) is definitely following 
  the current ARIN policy development process.  If they weren't, I would be 
  obligated to directly intervene.
 
  It is true that the present Policy Development process allows the AC ample 
  latitude in changing the policy proposals, with the requirement that if the 
  Advisory Council sends a draft policy to last call that is different from 
  the one presented at the public policy meeting, then the Advisory Council 
  will provide an explanation for all changes made to the text.

  My message to NANOG was to encourage folks to speak out on the PPML mailing
  list regarding their thoughts on the draft policy, as that is the forum 
  where the input will have the most impact.  I will note that ARIN also just
  completed an open consultation on a revised Policy Development Process, and
  while it has closed, I will take directly any suggestions that you have for
  changes to that process that you feel are necessary.

Thanks!
/John

John Curran
President and CEO
ARIN

Comcast IPv6 Update

[Brzozowski, John]

Update from http://www.comcast6.net
IPv6 Pilot Market Deployment Begins
Wednesday, November 9, 2011

Comcast has started our first pilot market deployment of IPv6 in limited areas 
of California and Colorado. This first phase supports directly connected CPE, 
where a single computer is directly connected to a cable device. A subsequent 
phase will support home gateway devices. To learn more, check out FAQs on the 
pilot market deployment and the 
announcement and 
technical 
details on our 
blog.

John
=
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozow...@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=

Re: Comcast IPv6 Update

[Jeroen Massar]

On 2011-11-09 17:32 , Brzozowski, John wrote:
> Update from http://www.comcast6.net
> IPv6 Pilot Market Deployment Begins
> Wednesday, November 9, 2011
> 
> Comcast has started our first pilot market deployment of IPv6...

Congrats! One step closer to full deployment!

Greets,
 Jeroen

Re: Comcast IPv6 Update

[Steve Clark]

On 11/09/2011 11:40 AM, Jeroen Massar wrote:

On 2011-11-09 17:32 , Brzozowski, John wrote:

Update from http://www.comcast6.net
IPv6 Pilot Market Deployment Begins
Wednesday, November 9, 2011

Comcast has started our first pilot market deployment of IPv6...

Congrats! One step closer to full deployment!

Greets,
  Jeroen


Sort of interesting that you are only handing out a single address and not a 
prefix  - which seems contradictory
to all recommended practices.

Will this be a continued effort for ISP's to charge for extra routable 
addresses?

My $.02




--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com

Re: Comcast IPv6 Update

[Cameron Byrne]

On Wed, Nov 9, 2011 at 8:40 AM, Jeroen Massar  wrote:
> On 2011-11-09 17:32 , Brzozowski, John wrote:
>> Update from http://www.comcast6.net
>> IPv6 Pilot Market Deployment Begins
>> Wednesday, November 9, 2011
>>
>> Comcast has started our first pilot market deployment of IPv6...
>
> Congrats! One step closer to full deployment!
>

+1

Glad to hear some good news about IPv6 deployment.  Now, lets talk
about deployment in Seattle :)

RE: Comcast IPv6 Update

[Blake T. Pfankuch]

This appears directed at the Home market.  Any word on the Business Class 
market even as a /128?

-Original Message-
From: Brzozowski, John [mailto:john_brzozow...@cable.comcast.com] 
Sent: Wednesday, November 09, 2011 9:33 AM
To: NANOG
Subject: Comcast IPv6 Update

Update from http://www.comcast6.net
IPv6 Pilot Market Deployment Begins
Wednesday, November 9, 2011

Comcast has started our first pilot market deployment of IPv6 in limited areas 
of California and Colorado. This first phase supports directly connected CPE, 
where a single computer is directly connected to a cable device. A subsequent 
phase will support home gateway devices. To learn more, check out FAQs on the 
pilot market deployment and the 
announcement and 
technical 
details on our 
blog.

John
=
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozow...@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=

Re: Comcast IPv6 Update

[Brzozowski, John]

This is not all we are pursuing, it is part of our incremental enablement
and deployment.  We have a non-trivial population of users that are
directly connected versus using a home router.  If you notice we also
mention that we will soon be sharing information about customer home
gateway plans.

Stay tuned.

John
=
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozow...@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=




On 11/9/11 11:47 AM, "Steve Clark"  wrote:

>
>  
>  
>On 11/09/2011 11:40 AM, Jeroen Massar wrote:
>
>  On 2011-11-09 17:32 , Brzozowski, John wrote:
>
>  
>Update from http://www.comcast6.net
>IPv6 Pilot Market Deployment Begins
>Wednesday, November 9, 2011
>
>Comcast has started our first pilot market deployment of IPv6...
>
>  
>
>  Congrats! One step closer to full deployment!
>
>Greets,
> Jeroen
>
>
>
>
>Sort of interesting that you are only
>  handing out a single address and not a prefix  - which seems
>  contradictory
>  to all recommended practices.
>  
>  Will this be a continued effort for ISP's to charge for extra
>  routable addresses?
>  
>  My $.02
>  
>  
>  
>
>-- 
>  Stephen Clark
>  NetWolves
>  Sr. Software Engineer III
>  Phone: 813-579-3200
>  Fax: 813-882-0209
>  Email: steve.cl...@netwolves.com
>  http://www.netwolves.com
>
>  
>

Re: Comcast IPv6 Update

[Brzozowski, John]

:)

=
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozow...@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=




On 11/9/11 11:49 AM, "Cameron Byrne"  wrote:

>On Wed, Nov 9, 2011 at 8:40 AM, Jeroen Massar  wrote:
>> On 2011-11-09 17:32 , Brzozowski, John wrote:
>>> Update from http://www.comcast6.net
>>> IPv6 Pilot Market Deployment Begins
>>> Wednesday, November 9, 2011
>>>
>>> Comcast has started our first pilot market deployment of IPv6...
>>
>> Congrats! One step closer to full deployment!
>>
>
>+1
>
>Glad to hear some good news about IPv6 deployment.  Now, lets talk
>about deployment in Seattle :)

Re: Comcast IPv6 Update

[Livingood, Jason]

On 11/9/11 11:54 AM, "Blake T. Pfankuch"  wrote:


>This appears directed at the Home market.  Any word on the Business Class
>market even as a /128?

Business Class is coming later. It won't hurt to contact the Business
Class sales number and ask about IPv6 (and tell them to escalate it) - it
all helps get us internal support and buy in. It is definitely on our
radar though. 

- Jason

Re: Logs Bank

[Matthew Walster]

On 8 November 2011 19:59,  wrote:
>
> If I may ask, is there any OSS that can serve as a log bank or log server,




Do you mean OSS, or do you mean free?



M

RE: Firewalls - Ease of Use and Maintenance?

[Nathan Eisenberg]

> An important feature lacking for now as far as I know is content/web
> filtering especially for corporates wishing to block inappropriate/time
> wasting content like facebook. Addition of this would place it a par
> with the best like Sonicwall and Fortinet.
 
At a previous employer, we utilized a Fortigate 200B to replace multiple boxen 
(two firewalls, barracuda, etc).  I found it utterly underpowered for the 
featureset (even with much of it disabled), and its ability to utilize multiple 
WAN connections was extremely limited.  I realize this is only a low-to-midline 
example of their lineup, but I was consistently surprised by how easy it was to 
overwhelm the device, especially given the price-point.  The only thing I 
remember liking was the SSL-VPN functionality, but we couldn't use it because 
there was no Vista support at the time, so that was disabled too.

Now, perhaps they've made progress, or their higher end devices perform better 
- just sharing my experience with the 200B.

Nathan

RE: Firewalls - Ease of Use and Maintenance?

[Dennis Burgess]

Another alternative is RouterOS/MikroTik.  Plenty of high end solutions
and low end.   

---
Dennis Burgess, Mikrotik Certified Trainer 
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 Website: http://www.linktechs.net
LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"

> -Original Message-
> From: -Hammer- [mailto:bhmc...@gmail.com]
> Sent: Tuesday, November 08, 2011 5:32 PM
> To: nanog@nanog.org
> Subject: Re: Firewalls - Ease of Use and Maintenance?
> 
> You've worked with all the big dogs. What are you looking for?
> Alternative options?
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 
> 
> On 11/08/2011 05:06 PM, Jones, Barry wrote:
> > Hello all.
> > I am potentially looking at firewall products and wanted suggestions
as to
> the easiest firewalls to install, configure and maintain? I have a few
small
> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at
another.
> I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia),
and
> each have strong and not as strong features for ease of use. Like
everyone,
> I'm resource challenged and need an easy solution to stand up and
operate.
> >
> > Feel free to ping me offline - and thank you for the assistance.
> >
> > 
> > Barry Jones - CISSP GSNA
> > Project Manager II
> > Sempra Energy Utilities
> > (760) 271-6822
> >
> > P please don't print this e-mail unless you really need to.
> > 
> >
> >

Re: Firewalls - Ease of Use and Maintenance?

[Valdis . Kletnieks]

On Wed, 09 Nov 2011 08:00:01 CST, Joe Greco said:
> > On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> > > An important feature lacking for now as far as I know is content/web
> > > filtering especially for corporates wishing to block
> > > inappropriate/time wasting content like facebook. 

> > 1. That's not a firewall function.  That's a censorship function.

> Is it "censorship" not to want unwanted connection attempts to our
> gear, and block unsolicited TCP connections inbound?

> Is it "censorship" not to want unwanted exploit attempts to our
> gear, and run everything through ClamAV, and use blocklists to
> prevent users inadvertently pulling content from known malware sites?

I do believe that Alex was saying "blocking outbound access to time wasters
like Facebook" is a censorship function, not a firewall function.



pgpHncLDOXakk.pgp
Description: PGP signature

Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Jay Nakamura]

We ran into a strange situation yesterday that I am still trying to
figure out.  We have many VoIP customers but yesterday suddenly select
few of them couldn't reach the SIP provider's network from our
network.

I could traceroute to the SIP providers server from the affected
clients' IP just fine.  I confirmed that the SIP traffic was leaving
our network out the interface to the upstream provider and the SIP
provider says they couldn't see the SIP traffic come into their border
router.

SIP traffic coming from SIP provider to the affected customer came
through fine.  It's just Us -> SIP server was a problem.

I thought there may be some strange BGP issue going on but we had
other customers within the same /24 as the affected customers and they
were connecting fine.

The traffic at the time traversed

Our network -> Qwest/century link -> Level 3 -> SIP provider

I changed the routing around so it would go through our other
upstream, AT&T, and it started working.  With AT&T, the route was

Our network -> AT&T -> Level 3 -> SIP provider

So my questions is, is it possible there is some kind of filter at
Qwest or Level 3 that is dropping traffic only for udp 5060 for select
few IPs?  That's the only explanation I can come up with other than
the whole Juniper BGP issue 2 days ago left something in between in a
strange state?  I read the post about XO doing filtering on transit
traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.

Re: Firewalls - Ease of Use and Maintenance?

[Nick Hilliard]

On 09/11/2011 15:18, Jonathan Lassoff wrote:

I've found that this works decently well, via pfsync.


I meant config sync, not state sync.

Nick

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Sean Harlow]

I can't say I have a specific answer to your question, but yesterday I was 
seeing major packet loss on outbound audio from all my VoIP customers using 
Qwest and going in to servers on L3.  It's entirely possible that SIP was also 
being lost, just the audio was the more notable and pressing issue.  It seems 
to be resolved at this point, but we have not yet heard from Qwest what the 
actual problem was.

This was with sites in Northeast Ohio and the Chicago area connecting to 
servers in New York and LA for what it's worth.
--
Sean Harlow
s...@seanharlow.info

On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:

> We ran into a strange situation yesterday that I am still trying to
> figure out.  We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
> 
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine.  I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had
> other customers within the same /24 as the affected customers and they
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs?  That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state?  I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 

RE: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Preston Parcell]

What was the timeframe for your issues? Just curious since we saw some 
strangeness last night.


Preston 



-Original Message-
From: Sean Harlow [mailto:s...@seanharlow.info] 
Sent: Wednesday, November 09, 2011 12:00 PM
To: Jay Nakamura
Cc: NANOG
Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to 
destination but traceroute does

I can't say I have a specific answer to your question, but yesterday I was 
seeing major packet loss on outbound audio from all my VoIP customers using 
Qwest and going in to servers on L3.  It's entirely possible that SIP was also 
being lost, just the audio was the more notable and pressing issue.  It seems 
to be resolved at this point, but we have not yet heard from Qwest what the 
actual problem was.

This was with sites in Northeast Ohio and the Chicago area connecting to 
servers in New York and LA for what it's worth.
--
Sean Harlow
s...@seanharlow.info

On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:

> We ran into a strange situation yesterday that I am still trying to 
> figure out.  We have many VoIP customers but yesterday suddenly select 
> few of them couldn't reach the SIP provider's network from our 
> network.
> 
> I could traceroute to the SIP providers server from the affected 
> clients' IP just fine.  I confirmed that the SIP traffic was leaving 
> our network out the interface to the upstream provider and the SIP 
> provider says they couldn't see the SIP traffic come into their border 
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came 
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had 
> other customers within the same /24 as the affected customers and they 
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other 
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at 
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select 
> few IPs?  That's the only explanation I can come up with other than 
> the whole Juniper BGP issue 2 days ago left something in between in a 
> strange state?  I read the post about XO doing filtering on transit 
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 

RE: Firewalls - Ease of Use and Maintenance?

[Nathan Eisenberg]

> I meant config sync, not state sync.
 
I have multiple deployments of the config synchronization working just fine.  :)

Re: Firewalls - Ease of Use and Maintenance?

[C. Jon Larsen]

On Wed, 9 Nov 2011, Nick Hilliard wrote:


On 09/11/2011 15:18, Jonathan Lassoff wrote:

I've found that this works decently well, via pfsync.


I meant config sync, not state sync.


put the main portion of the conf in subversion as an include file and 
factor out local differences in the configs with macros that are defined 
in pf.conf


Easy.

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Jay Nakamura]

It started sometime Tuesday morning.  I have yet to set the route back
to Qwest.  I am going to do that tonight and test it.

On Wed, Nov 9, 2011 at 2:04 PM, Preston Parcell
 wrote:
> What was the timeframe for your issues? Just curious since we saw some 
> strangeness last night.
>
>
> Preston
>
>
>
> -Original Message-
> From: Sean Harlow [mailto:s...@seanharlow.info]
> Sent: Wednesday, November 09, 2011 12:00 PM
> To: Jay Nakamura
> Cc: NANOG
> Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to 
> destination but traceroute does
>
> I can't say I have a specific answer to your question, but yesterday I was 
> seeing major packet loss on outbound audio from all my VoIP customers using 
> Qwest and going in to servers on L3.  It's entirely possible that SIP was 
> also being lost, just the audio was the more notable and pressing issue.  It 
> seems to be resolved at this point, but we have not yet heard from Qwest what 
> the actual problem was.
>
> This was with sites in Northeast Ohio and the Chicago area connecting to 
> servers in New York and LA for what it's worth.
> --
> Sean Harlow
> s...@seanharlow.info
>
> On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:
>
>> We ran into a strange situation yesterday that I am still trying to
>> figure out.  We have many VoIP customers but yesterday suddenly select
>> few of them couldn't reach the SIP provider's network from our
>> network.
>>
>> I could traceroute to the SIP providers server from the affected
>> clients' IP just fine.  I confirmed that the SIP traffic was leaving
>> our network out the interface to the upstream provider and the SIP
>> provider says they couldn't see the SIP traffic come into their border
>> router.
>>
>> SIP traffic coming from SIP provider to the affected customer came
>> through fine.  It's just Us -> SIP server was a problem.
>>
>> I thought there may be some strange BGP issue going on but we had
>> other customers within the same /24 as the affected customers and they
>> were connecting fine.
>>
>> The traffic at the time traversed
>>
>> Our network -> Qwest/century link -> Level 3 -> SIP provider
>>
>> I changed the routing around so it would go through our other
>> upstream, AT&T, and it started working.  With AT&T, the route was
>>
>> Our network -> AT&T -> Level 3 -> SIP provider
>>
>> So my questions is, is it possible there is some kind of filter at
>> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
>> few IPs?  That's the only explanation I can come up with other than
>> the whole Juniper BGP issue 2 days ago left something in between in a
>> strange state?  I read the post about XO doing filtering on transit
>> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>>
>
>
>

RE: Performance Issues - PTR Records

[Leo Vegoda]

Mark Andrew wrote:

[...]

> > That said though the PTR->forward->PTR check is a proper check and a
> > really great way to figure out if the source SMTP host was actually set
> > up with at least some admin doing it the right way. If they can't be
> > bothered to set that up, why should you bother to accept that mail, or a
> > better choice, just score it a bit negatively at least.
> 
> Which only works as a filter because ISP's decided to prevent home
> users from putting valid PTR records in the DNS for their own
> machines.  It has nothing to do with clue or knowlege.  

Some do but some don't. I seem to remember a very nice little web interface for 
setting reverse DNS when I used xs4all's service in the Netherlands. 

Regards,

Leo

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Sean Harlow]

I saw the problems starting around 09:30 Eastern and continuing past 17:00.  
Looking through ticket notes I had missed when writing my previous reply it 
seems that a fix was confirmed around 22:30 which involved a faulty piece of 
equipment being replaced.  I do not have specifics on what went wrong and when 
it was actually fixed though.
--
Sean Harlow
s...@seanharlow.info

On Nov 9, 2011, at 2:04 PM, Preston Parcell wrote:

> What was the timeframe for your issues? Just curious since we saw some 
> strangeness last night.
> 
> 
> Preston 
> 
> 
> 
> -Original Message-
> From: Sean Harlow [mailto:s...@seanharlow.info] 
> Sent: Wednesday, November 09, 2011 12:00 PM
> To: Jay Nakamura
> Cc: NANOG
> Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to 
> destination but traceroute does
> 
> I can't say I have a specific answer to your question, but yesterday I was 
> seeing major packet loss on outbound audio from all my VoIP customers using 
> Qwest and going in to servers on L3.  It's entirely possible that SIP was 
> also being lost, just the audio was the more notable and pressing issue.  It 
> seems to be resolved at this point, but we have not yet heard from Qwest what 
> the actual problem was.
> 
> This was with sites in Northeast Ohio and the Chicago area connecting to 
> servers in New York and LA for what it's worth.
> --
> Sean Harlow
> s...@seanharlow.info
> 
> On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:
> 
>> We ran into a strange situation yesterday that I am still trying to 
>> figure out.  We have many VoIP customers but yesterday suddenly select 
>> few of them couldn't reach the SIP provider's network from our 
>> network.
>> 
>> I could traceroute to the SIP providers server from the affected 
>> clients' IP just fine.  I confirmed that the SIP traffic was leaving 
>> our network out the interface to the upstream provider and the SIP 
>> provider says they couldn't see the SIP traffic come into their border 
>> router.
>> 
>> SIP traffic coming from SIP provider to the affected customer came 
>> through fine.  It's just Us -> SIP server was a problem.
>> 
>> I thought there may be some strange BGP issue going on but we had 
>> other customers within the same /24 as the affected customers and they 
>> were connecting fine.
>> 
>> The traffic at the time traversed
>> 
>> Our network -> Qwest/century link -> Level 3 -> SIP provider
>> 
>> I changed the routing around so it would go through our other 
>> upstream, AT&T, and it started working.  With AT&T, the route was
>> 
>> Our network -> AT&T -> Level 3 -> SIP provider
>> 
>> So my questions is, is it possible there is some kind of filter at 
>> Qwest or Level 3 that is dropping traffic only for udp 5060 for select 
>> few IPs?  That's the only explanation I can come up with other than 
>> the whole Juniper BGP issue 2 days ago left something in between in a 
>> strange state?  I read the post about XO doing filtering on transit 
>> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>> 
> 
> 

Re: Firewalls - Ease of Use and Maintenance?

[Eduardo Schoedler]

How about Endian Firewalls ?

--
Eduardo Schoedler
Sent via iPhone


Em 09/11/2011, às 16:16, "Dennis Burgess"  escreveu:

> Another alternative is RouterOS/MikroTik.  Plenty of high end solutions
> and low end.   
> 
> ---
> Dennis Burgess, Mikrotik Certified Trainer 
> Link Technologies, Inc -- Mikrotik & WISP Support Services
> Office: 314-735-0270 Website: http://www.linktechs.net
> LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"
> 
>> -Original Message-
>> From: -Hammer- [mailto:bhmc...@gmail.com]
>> Sent: Tuesday, November 08, 2011 5:32 PM
>> To: nanog@nanog.org
>> Subject: Re: Firewalls - Ease of Use and Maintenance?
>> 
>> You've worked with all the big dogs. What are you looking for?
>> Alternative options?
>> 
>> -Hammer-
>> 
>> "I was a normal American nerd"
>> -Jack Herer
>> 
>> 
>> 
>> On 11/08/2011 05:06 PM, Jones, Barry wrote:
>>> Hello all.
>>> I am potentially looking at firewall products and wanted suggestions
> as to
>> the easiest firewalls to install, configure and maintain? I have a few
> small
>> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at
> another.
>> I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia),
> and
>> each have strong and not as strong features for ease of use. Like
> everyone,
>> I'm resource challenged and need an easy solution to stand up and
> operate.
>>> 
>>> Feel free to ping me offline - and thank you for the assistance.
>>> 
>>> 
>>> Barry Jones - CISSP GSNA
>>> Project Manager II
>>> Sempra Energy Utilities
>>> (760) 271-6822
>>> 
>>> P please don't print this e-mail unless you really need to.
>>> 
>>> 
>>> 
> 

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Owen Roth]

Yes!

Yesterday, from 9AM-10AM PST, I had a Qwest client transiting Level3 where 
traceroutes were working, but sip registrations were not. They were leaving 
fine, but not being received on the destination side. 

Then at 10AM-2PM PST, same client, registrations and invites were now working, 
but "180 RINGING" was being eaten. Things worked fully at 2PM. We only 
contacted Level3, and they didn't see any issues at around 1:45PM PST.

Regards,
Owen

- Original Message -
From: "Preston Parcell" 
To: "Sean Harlow" , "Jay Nakamura" 
Cc: "NANOG" 
Sent: Wednesday, November 9, 2011 11:04:01 AM
Subject: RE: Anyone seen this kind of problem? SIP traffic not getting to 
destination but traceroute does

What was the timeframe for your issues? Just curious since we saw some 
strangeness last night.


Preston 



-Original Message-
From: Sean Harlow [mailto:s...@seanharlow.info] 
Sent: Wednesday, November 09, 2011 12:00 PM
To: Jay Nakamura
Cc: NANOG
Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to 
destination but traceroute does

I can't say I have a specific answer to your question, but yesterday I was 
seeing major packet loss on outbound audio from all my VoIP customers using 
Qwest and going in to servers on L3.  It's entirely possible that SIP was also 
being lost, just the audio was the more notable and pressing issue.  It seems 
to be resolved at this point, but we have not yet heard from Qwest what the 
actual problem was.

This was with sites in Northeast Ohio and the Chicago area connecting to 
servers in New York and LA for what it's worth.
--
Sean Harlow
s...@seanharlow.info

On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote:

> We ran into a strange situation yesterday that I am still trying to 
> figure out.  We have many VoIP customers but yesterday suddenly select 
> few of them couldn't reach the SIP provider's network from our 
> network.
> 
> I could traceroute to the SIP providers server from the affected 
> clients' IP just fine.  I confirmed that the SIP traffic was leaving 
> our network out the interface to the upstream provider and the SIP 
> provider says they couldn't see the SIP traffic come into their border 
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came 
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had 
> other customers within the same /24 as the affected customers and they 
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other 
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at 
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select 
> few IPs?  That's the only explanation I can come up with other than 
> the whole Juniper BGP issue 2 days ago left something in between in a 
> strange state?  I read the post about XO doing filtering on transit 
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 

Re: Firewalls - Ease of Use and Maintenance?

[Joe Greco]

> On Wed, 09 Nov 2011 08:00:01 CST, Joe Greco said:
> > > On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
> > > > An important feature lacking for now as far as I know is content/web
> > > > filtering especially for corporates wishing to block
> > > > inappropriate/time wasting content like facebook. 
> 
> > > 1. That's not a firewall function.  That's a censorship function.
> 
> > Is it "censorship" not to want unwanted connection attempts to our
> > gear, and block unsolicited TCP connections inbound?
> 
> > Is it "censorship" not to want unwanted exploit attempts to our
> > gear, and run everything through ClamAV, and use blocklists to
> > prevent users inadvertently pulling content from known malware sites?
> 
> I do believe that Alex was saying "blocking outbound access to time wasters
> like Facebook" is a censorship function, not a firewall function.

Of course he was.

My point is that that's irrelevant. 

There are plenty of good policy reasons for wanting to block application 
layer stuff.  The statement Alex made appeared to characterize blocking 
facebook as a "bad policy".  As a result, one might infer that Alex's 
conclusion is that "firewalls shouldn't do this type of blocking."

The merits of policies such as "blocking facebook" are largely beyond
the scope of NANOG; I don't propose to debate that point.  There are
other forums to debate such censorship.

However, the point I made should be easily understood:  a firewall that
offers tools to prevent users from visiting a certain website (via URL,
let's say) is really not any different than a firewall that offers tools
to prevent users from visiting a certain website (via packet firewall
rules, let's say).  Do you really want your users connecting to websites
known to be operated by RBN, or virus infected stuff, or spyware?  The
difference between "we want to protect our gear against known harmful
sites" and "we want to block our employees from visiting dating sites"
is probably indistinguishable at a technical implementation level.

So, in clearer response to Alex: who cares?  That's not a NANOG issue.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Jeff Wheeler]

On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura  wrote:
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs?  That's the only explanation I can come up with other than

I ran into exactly this problem last week with Rogers.  All traffic
from the client except udp/5060 could be received by us, and udp/5060
was blocked.  We tested other IP addresses on our (provider) side and
did not find any blocking there, so we assigned a new IP to the SIP
gateway.  I hardly think this can be an ordinary malfunction, but good
luck getting a phone company to troubleshoot a problem with their
subscribers using mobile data to connect to a third-party voice
gateway...

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Firewalls - Ease of Use and Maintenance?

[Nick Hilliard]

On 09/11/2011 19:07, C. Jon Larsen wrote:

put the main portion of the conf in subversion as an include file and
factor out local differences in the configs with macros that are defined in
pf.conf

Easy.


As I said, it's not a pf problem.  Commercial firewalls will do all this 
sort of thing off the shelf.  It's a pain to have to write scripts to do 
this manually.


Nick

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Jay Ashworth]

- Original Message -
> From: "Jeff Wheeler" 

> On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura 
> wrote:
> > So my questions is, is it possible there is some kind of filter at
> > Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> > few IPs? That's the only explanation I can come up with other than
> 
> I ran into exactly this problem last week with Rogers. All traffic
> from the client except udp/5060 could be received by us, and udp/5060
> was blocked. We tested other IP addresses on our (provider) side and
> did not find any blocking there, so we assigned a new IP to the SIP
> gateway. I hardly think this can be an ordinary malfunction, but good
> luck getting a phone company to troubleshoot a problem with their
> subscribers using mobile data to connect to a third-party voice
> gateway...

Well, just a couple of days ago, we discussed that XO does this kind of 
rifle-bullet filtering in certain circumstances; is any party getting their
connectivity from them?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Jared Mauch]

On Nov 9, 2011, at 2:45 PM, Jeff Wheeler wrote:

> On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura  wrote:
>> So my questions is, is it possible there is some kind of filter at
>> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
>> few IPs?  That's the only explanation I can come up with other than
> 
> I ran into exactly this problem last week with Rogers.  All traffic
> from the client except udp/5060 could be received by us, and udp/5060
> was blocked.  We tested other IP addresses on our (provider) side and
> did not find any blocking there, so we assigned a new IP to the SIP
> gateway.  I hardly think this can be an ordinary malfunction, but good
> luck getting a phone company to troubleshoot a problem with their
> subscribers using mobile data to connect to a third-party voice
> gateway…

I've seen UDP/5060 be intercepted or blocked by various providers.  This
is common in international markets.  If you are doing VoIP over the public
internet, it may be worthwhile to invest in software or hardware that
can VPN either 'back' or 'out' to the internet.  I have a PPTP VPN
solution I use to escape various hotel networks.  You can even do an
install on a Linux box with the poptop/pptpd solution.  (Having a
ssh server on tcp/80 and tcp/443 also can help, and is part of 'being
prepared').

- Jared

Re: Comcast IPv6 Update

[Owen DeLong]

This is excellent news, John and I encourage you and the folks at Comcast
to keep up the good work.

I wait with baited breath for the day I can move my business class connection
to IPv6.

Owen

On Nov 9, 2011, at 8:54 AM, Brzozowski, John wrote:

> This is not all we are pursuing, it is part of our incremental enablement
> and deployment.  We have a non-trivial population of users that are
> directly connected versus using a home router.  If you notice we also
> mention that we will soon be sharing information about customer home
> gateway plans.
> 
> Stay tuned.
> 
> John
> =
> John Jason Brzozowski
> Comcast Cable
> e) mailto:john_brzozow...@cable.comcast.com
> o) 609-377-6594
> m) 484-962-0060
> w) http://www.comcast6.net
> =
> 
> 
> 
> 
> On 11/9/11 11:47 AM, "Steve Clark"  wrote:
> 
>> 
>> 
>> 
>>   On 11/09/2011 11:40 AM, Jeroen Massar wrote:
>> 
>> On 2011-11-09 17:32 , Brzozowski, John wrote:
>> 
>> 
>>   Update from http://www.comcast6.net
>> IPv6 Pilot Market Deployment Begins
>> Wednesday, November 9, 2011
>> 
>> Comcast has started our first pilot market deployment of IPv6...
>> 
>> 
>> 
>> Congrats! One step closer to full deployment!
>> 
>> Greets,
>> Jeroen
>> 
>> 
>> 
>> 
>>   Sort of interesting that you are only
>> handing out a single address and not a prefix  - which seems
>> contradictory
>> to all recommended practices.
>> 
>> Will this be a continued effort for ISP's to charge for extra
>> routable addresses?
>> 
>> My $.02
>> 
>> 
>> 
>> 
>>   -- 
>> Stephen Clark
>> NetWolves
>> Sr. Software Engineer III
>> Phone: 813-579-3200
>> Fax: 813-882-0209
>> Email: steve.cl...@netwolves.com
>> http://www.netwolves.com
>> 
>> 
>> 
> 

Re: Performance Issues - PTR Records

[Mark Andrews]

In message <41f6c547ea49ec46b4ee1eb2bc2f341849f82d4...@exvpmbx100-1.exc.icann.o
rg>, Leo Vegoda writes:
> Mark Andrew wrote:
> 
> [...]
> 
> > > That said though the PTR->forward->PTR check is a proper check and a
> > > really great way to figure out if the source SMTP host was actually set
> > > up with at least some admin doing it the right way. If they can't be
> > > bothered to set that up, why should you bother to accept that mail, or =
> a
> > > better choice, just score it a bit negatively at least.
> >=20
> > Which only works as a filter because ISP's decided to prevent home
> > users from putting valid PTR records in the DNS for their own
> > machines.  It has nothing to do with clue or knowlege. =20
> 
> Some do but some don't. I seem to remember a very nice little web interface=
> for setting reverse DNS when I used xs4all's service in the Netherlands.=20
> 
> Regards,
> 
> Leo

But many do.  As I said the ability to set up PTR records has
*nothing* to do with the clue level of the administrator.  It has
everything to do with what the ISP will let you do.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Comcast IPv6 Update

[Jared Mauch]

On Nov 9, 2011, at 11:58 AM, Livingood, Jason wrote:

> On 11/9/11 11:54 AM, "Blake T. Pfankuch"  wrote:
> 
> 
>> This appears directed at the Home market.  Any word on the Business Class
>> market even as a /128?
> 
> Business Class is coming later. It won't hurt to contact the Business
> Class sales number and ask about IPv6 (and tell them to escalate it) - it
> all helps get us internal support and buy in. It is definitely on our
> radar though. 


Thanks!

I have been telling everyone to ask each time they phone in.  I suspect
there's a non-trivial number of people in this community alone that could
call in for IPv6 on the business service, even if it is just a /64 for
starters :)

(That is all I would want myself).

I'm grateful you are communicating with the community on your efforts.

- Jared

Re: Performance Issues - PTR Records

[Blake Hudson]

Larry Blunk wrote the following on 11/3/2011 12:47 PM:

On 11/02/2011 05:57 PM, Matt Chung wrote:

I work for a regional ISP and very recently there has been an influx of
calls reporting "slowness" when accessing certain websites (i.e
google.com/voice/b) via HTTP.  After performing a tcpdump and 
analyzing the

session, I have been able to pinpoint the latency at the application
layer.  After the tcp session has been established, it takes up to 15-20
seconds before the application begins sending data.   The root of the
problem was that the PTR record for our customer(s) address does not
exist.  As soon as the record is created, latency from the 
application is
eliminated.  This is analogous to latency when accessing a server 
over SSH

when no PTR is available.

A seperate packet capture from another customer exhibiting similar
performance behavior showed many TCP retransmissions.  At first 
glance, I

assumed this was network related however this correlates with the
application not responding and inducing retransmissions at the TCP layer
(different symptoms, same problem).

Historically, there was no compelling reason to create PTR records 
for our

CPE however more and more applications seem to be dependent on it.
Although we will be assigning a record for each address, my question 
is why

is the application (specifically HTTP) dependent on a reverse record ?
What is the purpose?

Hope this is helpful as well



  We recently encountered a similar issue with a customer.
The sites that had slowness issues were configured to
use the traditional Google Analytics javascript instead
of the newer asynchronous code.
  The problem was not the lack of a PTR record, but rather
the in-addr delegation was pointing to lame servers that were
no longer responding (hence the long timeouts as the
Google servers attempted to perform reverse lookups
on the client IP's).  As others have pointed out, as long
as there's a valid nameserver responding, a lack of PTR
record would not cause issues as an NXDOMAIN record would
be sent back immediately and the Google Analytics server
will move on.


 -Larry Blunk
  Merit


Larry, you're absolutely correct. One has to wonder what the continued 
debate is about. The Op likely had a DNS loop, misconfiguration, or lame 
servers. Correcting that issue should resolve any "slowness". The issue 
then is whether the application requires a valid PTR (or subsequent 
matching forward record) such as SMTP.


BTW, ARIN requires valid IN-ADDR.ARPA domain records. The specific 
record may be NXDOMAIN (non-existant), but the server cannot be lame - 
https://www.arin.net/policy/nrpm.html#seven1
I believe just about all of us on this list have agreed to this policy. 
However, my experience tells me that many people choose to ignore it. 
This thread is evidence of such.


--Blake

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Blake Hudson]

Jay Nakamura wrote the following on 11/9/2011 12:47 PM:

We ran into a strange situation yesterday that I am still trying to
figure out.  We have many VoIP customers but yesterday suddenly select
few of them couldn't reach the SIP provider's network from our
network.

I could traceroute to the SIP providers server from the affected
clients' IP just fine.  I confirmed that the SIP traffic was leaving
our network out the interface to the upstream provider and the SIP
provider says they couldn't see the SIP traffic come into their border
router.

...
So my questions is, is it possible there is some kind of filter at
Qwest or Level 3 that is dropping traffic only for udp 5060 for select
few IPs?  That's the only explanation I can come up with other than
the whole Juniper BGP issue 2 days ago left something in between in a
strange state?  I read the post about XO doing filtering on transit
traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.



I've found tools like tcptraceroute (the name is deceiving, UDP is the 
default) and hping to be invaluable in tracking down issues like these 
that are obviously above the routing and into the transport layer.


I'm not sure how an IP transit provider (who should be providing 
routing/switching) screws up transport layer connections - looks like 
they are arbitrarily "managing" client data. Just my $0.02.


--Blake

Re: Comcast IPv6 Update

[Paul Graydon]

On 11/09/2011 06:32 AM, Brzozowski, John wrote:

Update from http://www.comcast6.net
IPv6 Pilot Market Deployment Begins
Wednesday, November 9, 2011

Comcast has started our first pilot market deployment of IPv6 in limited areas of California and 
Colorado. This first phase supports directly connected CPE, where a single computer is directly 
connected to a cable device. A subsequent phase will support home gateway devices. To learn more, 
check out FAQs on the pilot market deployment  and 
the announcement  and technical 
details  on our blog.

John

Good to hear, thanks John.  Hopefully Comcast's marketing/sales team can 
run productively with this.  It might start to encourage some of the 
other major and minor ISPs to jump on board.


Paul

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Michael Ulitskiy]

It may also be related to QoS policy inside the carriers.
Some time ago I've seen exactly the same symptoms with Verizon when sip 
signaling
was sent marked as EF. Remarking it down to CS1 or CS3 (don't remember exactly) 
solved the problem.

Michael

On Wednesday 09 November 2011 13:47:37 Jay Nakamura wrote:
> We ran into a strange situation yesterday that I am still trying to
> figure out.  We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
> 
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine.  I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
> 
> SIP traffic coming from SIP provider to the affected customer came
> through fine.  It's just Us -> SIP server was a problem.
> 
> I thought there may be some strange BGP issue going on but we had
> other customers within the same /24 as the affected customers and they
> were connecting fine.
> 
> The traffic at the time traversed
> 
> Our network -> Qwest/century link -> Level 3 -> SIP provider
> 
> I changed the routing around so it would go through our other
> upstream, AT&T, and it started working.  With AT&T, the route was
> 
> Our network -> AT&T -> Level 3 -> SIP provider
> 
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs?  That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state?  I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
> 
> 

Re: Comcast IPv6 Update

[Jim Burwell]

On 11/9/2011 08:58, Livingood, Jason wrote:

On 11/9/11 11:54 AM, "Blake T. Pfankuch"  wrote:



This appears directed at the Home market.  Any word on the Business Class
market even as a /128?

Business Class is coming later. It won't hurt to contact the Business
Class sales number and ask about IPv6 (and tell them to escalate it) - it
all helps get us internal support and buy in. It is definitely on our
radar though.

- Jason


Yeh.  I've been waiting since before the trial started for biz class 
IPv6.  I even read some article on one of the Comcast sites (IIRC) that 
one of their business class customers was doing NDS.  I guess it was a 
one-off.  :)

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Jay Nakamura]

I just removed the route to our other provider and traffic is going
out Qwest again. The problem seems to be gone now.  As others had
similar problems during the same period using Qwest, it must have been
some strange issue with Qwest.

On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura  wrote:
> We ran into a strange situation yesterday that I am still trying to
> figure out.  We have many VoIP customers but yesterday suddenly select
> few of them couldn't reach the SIP provider's network from our
> network.
>
> I could traceroute to the SIP providers server from the affected
> clients' IP just fine.  I confirmed that the SIP traffic was leaving
> our network out the interface to the upstream provider and the SIP
> provider says they couldn't see the SIP traffic come into their border
> router.
>
> SIP traffic coming from SIP provider to the affected customer came
> through fine.  It's just Us -> SIP server was a problem.
>
> I thought there may be some strange BGP issue going on but we had
> other customers within the same /24 as the affected customers and they
> were connecting fine.
>
> The traffic at the time traversed
>
> Our network -> Qwest/century link -> Level 3 -> SIP provider
>
> I changed the routing around so it would go through our other
> upstream, AT&T, and it started working.  With AT&T, the route was
>
> Our network -> AT&T -> Level 3 -> SIP provider
>
> So my questions is, is it possible there is some kind of filter at
> Qwest or Level 3 that is dropping traffic only for udp 5060 for select
> few IPs?  That's the only explanation I can come up with other than
> the whole Juniper BGP issue 2 days ago left something in between in a
> strange state?  I read the post about XO doing filtering on transit
> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.
>

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

[Jack Bates]

On 11/9/2011 4:45 PM, Blake Hudson wrote:
I'm not sure how an IP transit provider (who should be providing 
routing/switching) screws up transport layer connections - looks like 
they are arbitrarily "managing" client data. Just my $0.02. 


With today's routers, all sorts of weird things can go wrong, especially 
if it's a hardware failure.


I had an IO/FE go out on a 7200 (which is as software as you get) which 
attributed to a lot of weirdness. It started when the IGP updated state 
information on the IO card's FE, which shut down mpls switching on the 
router, but the LSP itself was still considered up. It then showed by 
freaking out the neighbor 7206 when we reboot the failing one (could no 
longer ping the loopback of the neighbor router with and without using 
the LSP, but all IGP was up and you could ping/telnet/ssh to any other 
IP ). Finally the  reboot itself showed the true issue (required 
multiple power cycles and a reset of the ata card to even load IOS in an 
unstable state).


I don't even want to think what happens when a high end router's 
linecard starts to fail.



Jack

Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week)

[Randy Bush]

> 1) The concept of Inter-RIR transfers is a bad idea.  Insuring
>"compatible" rules between RIR's will always be difficult at
>best.

no need to coordinate rules/policies at all.  what we suggested in a/p
three years back was simple.  seller must abide by seller's local
selling policy and buyer must abide by buyer's local receiving policy.

randy