Re: IPv6 End User Fee

[Dan Luedtke]

On Fri, 2012-08-03 at 14:22 -0500, Otis L. Surratt, Jr. wrote:
> 1. How are you making up loss of revenue on IPv4 assignments?
By using legacy IP only were it is necessary. This way I have to support
only one stack (IPv6), that saves me money.

Regards.

Dan
-- 
Dan Luedtke
http://www.danrl.de

Re: BGPttH. Neustar can do it, why can't we?

[William Herrin]

On Mon, Aug 6, 2012 at 2:49 AM, jamie rishaw  wrote:
> discuss.

Commodity service from a commodity provider. As much as I'd love for
Verizon to offer BGP directly over FIOS there are fewer than 40,000
customers worldwide for such a service. As long as they maintain
sufficient network neutrality to get high speed tunnel service with
someone and run BGP over the tunnel their behavior is not outrageous.

To facilitate this and all the folks with custom needs, a wireline
provider should have a choice between unbundling and open
settlement-free peering. Mandatory to do at least one. But that's a
whole other can of worms.

Regards,
Bill Herrin

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

Re: BGPttH. Neustar can do it, why can't we?

[Christopher Morrow]

On Mon, Aug 6, 2012 at 9:07 AM, William Herrin  wrote:
> As much as I'd love for
> Verizon to offer BGP directly over FIOS there are fewer than 40,000

I'm curious as to your number... where is that from?
Marhsall had noted a number of 'small businesses' in the US at ~1.4m
as of ~2006ish?

I'd think that there are many use-cases where BGP is useful for end
users of FIOS, turning out a 'business' class of service without BGP
seems like a less useful 'business' solution (especially where the sla
isn't really much better than the consumer solution).

-chris

IETF contacts? - Fwd: Reference to historic or obsolated RFCs

[Livio Zanol Puppim]

Hello guys,

I've sent the e-mail below to IETF, but I couldn't find a contact e-mail to
address this kind of subject in IETF site. Does anybody knows which e-mail
to send this?

The contact page from IETF website:
http://www.ietf.org/contact-the-ietf.html

-- Forwarded message --
From: Livio Zanol Puppim 
Date: 2012/8/6
Subject: Reference to historic or obsolated RFCs
To: ietf-i...@ietf.org, ietf-act...@ietf.org


Hello,

I don't know which contact to send this e-mail, so I'm copying the INFO and
ACTION e-mail... If these are the wrong contact, can you please point me
the correct e-mail?

Reading the *RFC 5375* I've found references to some RFCs that are
considered Historic, or have been updated. In some cases, this can lead to
a misunderstand of a a section in a RFC.

For example:
The* RFC 5375* in section *B.2.2* states that we should avoid using /127
IPv6 prefix, but* RFC 6164* clearly says that we can use /127 prefix for
Inter-Router links. In fact, the *RFC 6547*, moves the *RFC
3627*(referenced by the
* RFC 5375* in the above section) to Historic status.

If my point of view is indeed correct, I think that everytime a new RFC is
published that proposes an *Update* to another RFC, or *Obsoletes* another
RFC or moves a RFC to *Historic *status, the team responsible for it's
creation needs to read every reference to that RFC and request changes in
order to avoid this kind of misunderstanding. This is very important to
guys like me, that only reads the RFCs.

the section from RFC 5375
http://tools.ietf.org/html/rfc5375#appendix-B.2.2

"


B.2.2 .  /127 Addresses

   The usage of the /127 addresses, the equivalent of IPv4's RFC 3021

   [RFC3021 ], is not valid and
should be strongly discouraged as
   documented in RFC 3627 
[RFC3627 ].

"

-- 
[]'s

Lívio Zanol Puppim



-- 
[]'s

Lívio Zanol Puppim

Re: IETF contacts? - Fwd: Reference to historic or obsolated RFCs

[Joe Abley]

On 2012-08-06, at 10:10, Livio Zanol Puppim  
wrote:

> I've sent the e-mail below to IETF, but I couldn't find a contact e-mail to
> address this kind of subject in IETF site. Does anybody knows which e-mail
> to send this?

http://www.rfc-editor.org/rfcfaq.html
https://www.rfc-editor.org/mailman/listinfo/rfc-interest


Joe

Re: BGPttH. Neustar can do it, why can't we?

[Leo Bicknell]

In a message written on Mon, Aug 06, 2012 at 01:49:07AM -0500, jamie rishaw 
wrote:
> discuss.

It's a short sighted result created by the lack of competition.

IP access is a commodity service, with thin margins that will only
get thinner.  Right now those margins are being propped up in many
locations by monopoly or near-monopoly status, which creates a
situation where companies neither need to compete on features and
service quality nor do they need to turn to those areas to maintain
a profit.

If there was meaningful competition, the margin on raw IP access
would decline and companies would have to turn to value-add services
to maintain a profit margin.  From the simple up-sell of a static
IP address that some do today, to a fee for BGP, a fee for DDOS
mitigation, and so on.  These are all things it's not uncommon to
see when buying service in carrier netural colos where there is
competition.

There is no technological problem here.  BGP to the end user has a
cost.  The current business climate is causing people to cut all
possible costs and offering no incentive to innvovate and up-charge.

Which leads to an interesting question.  If on top of your $100/month
"business class Internet" the provider were to charge $50/month for
"BGP Access" to cover their costs of having a human configure the
session, larger access gear to handle the routes, and larger backbone
gear to deal with a larger routing table, would you still be as
gung ho about BGP to the business?

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


pgpEkPkYy56yO.pgp
Description: PGP signature

Re: BGPttH. Neustar can do it, why can't we?

[Måns Nilsson]

Subject: Re: BGPttH. Neustar can do it, why can't we? Date: Mon, Aug 06, 2012 
at 10:08:45AM -0400 Quoting Christopher Morrow (morrowc.li...@gmail.com):
> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin  wrote:
> > As much as I'd love for
> > Verizon to offer BGP directly over FIOS there are fewer than 40,000
> 
> I'm curious as to your number... where is that from?

AS numbers used to be 16-bit. 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I don't believe there really IS a GAS SHORTAGE.. I think it's all just
a BIG HOAX on the part of the plastic sign salesmen -- to sell more numbers!!


signature.asc
Description: Digital signature

Re: IETF contacts? - Fwd: Reference to historic or obsolated RFCs

[Livio Zanol Puppim]

Thanks! :)

2012/8/6 Joe Abley 

>
> On 2012-08-06, at 10:10, Livio Zanol Puppim 
> wrote:
>
> > I've sent the e-mail below to IETF, but I couldn't find a contact e-mail
> to
> > address this kind of subject in IETF site. Does anybody knows which
> e-mail
> > to send this?
>
> http://www.rfc-editor.org/rfcfaq.html
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
>
> Joe
>
>


-- 
[]'s

Lívio Zanol Puppim

Re: BGPttH. Neustar can do it, why can't we?

[William Herrin]

On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
 wrote:
> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin  wrote:
>> As much as I'd love for
>> Verizon to offer BGP directly over FIOS there are fewer than 40,000
>
> I'm curious as to your number... where is that from?
> Marhsall had noted a number of 'small businesses' in the US at ~1.4m
> as of ~2006ish?

Hi Chris,

Lacking any reason to believe otherwise, I estimate the number of BGP
users at reasonably close to the number of autonomous systems in the
Internet BGP table. Technically that doesn't have to be true... but
given the debugging nuissance associated with private AS numbers and
the trivial ease and cost with which an AS is registered it seems
likely to me.

Regards,
Bill Herrin


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

Re: BGPttH. Neustar can do it, why can't we?

[William Herrin]

On Mon, Aug 6, 2012 at 10:21 AM, Leo Bicknell  wrote:
> Which leads to an interesting question.  If on top of your $100/month
> "business class Internet" the provider were to charge $50/month for
> "BGP Access" to cover their costs of having a human configure the
> session, larger access gear to handle the routes, and larger backbone
> gear to deal with a larger routing table, would you still be as
> gung ho about BGP to the business?

Speaking for myself, yes, I'd pay the extra $50 and be glad. If it was
$500... well, I don't have that level of need for my basement. But I
have two clients who would gladly add $500 on top of a business fios
to get BGP.

Regards,
Bill Herrin

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

Re: BGPttH. Neustar can do it, why can't we?

[joel jaeggli]

On 8/6/12 7:08 AM, Christopher Morrow wrote:

On Mon, Aug 6, 2012 at 9:07 AM, William Herrin  wrote:

As much as I'd love for
Verizon to offer BGP directly over FIOS there are fewer than 40,000

I'm curious as to your number... where is that from?

sent to your mailbox every week


 AS Summary

   41838Number of ASes in routing system

http://www.cidr-report.org/as2.0/#General_Status

the majority of those are stub ASes and more than 1/3 of them are 
announcing only one prefix.


The addressable market of potential multihomers is probably larger than 
that.  but frankly there's a lot of friction that makes the proposition 
less than worthwhile for most businesses.


e.g. p.i. versus pa prefix assignment.

longish commitments to two or more providers

facilties

expertise

...

In ipv4 land, a nat box with two uplinks is probably a 90% solution for 
most non-services-offering high(er) availability needing small businesses.

Marhsall had noted a number of 'small businesses' in the US at ~1.4m
as of ~2006ish?

I'd think that there are many use-cases where BGP is useful for end
users of FIOS, turning out a 'business' class of service without BGP
seems like a less useful 'business' solution (especially where the sla
isn't really much better than the consumer solution).

-chris

Re: BGPttH. Neustar can do it, why can't we?

[Christopher Morrow]

On Mon, Aug 6, 2012 at 10:27 AM, William Herrin  wrote:
> On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
>  wrote:
>> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin  wrote:
>>> As much as I'd love for
>>> Verizon to offer BGP directly over FIOS there are fewer than 40,000
>>
>> I'm curious as to your number... where is that from?
>> Marhsall had noted a number of 'small businesses' in the US at ~1.4m
>> as of ~2006ish?
>
> Hi Chris,
>
> Lacking any reason to believe otherwise, I estimate the number of BGP
> users at reasonably close to the number of autonomous systems in the
> Internet BGP table. Technically that doesn't have to be true... but
> given the debugging nuissance associated with private AS numbers and
> the trivial ease and cost with which an AS is registered it seems
> likely to me.

I know that 701 had many 'private' (AS7046) customer peerings than
public... it doesn't seem out of the realm of possibility that other
networks have the same situation. I think Marshall's numbers were
based on some small-business-SEC thing, it'd be nice if he piped up
with where he got the number though :(

Re: BGPttH. Neustar can do it, why can't we?

[Christopher Morrow]

On Mon, Aug 6, 2012 at 10:45 AM, Christopher Morrow
 wrote:
> On Mon, Aug 6, 2012 at 10:27 AM, William Herrin  wrote:
>> On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
>>  wrote:
>>> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin  wrote:
 As much as I'd love for
 Verizon to offer BGP directly over FIOS there are fewer than 40,000
>>>
>>> I'm curious as to your number... where is that from?
>>> Marhsall had noted a number of 'small businesses' in the US at ~1.4m
>>> as of ~2006ish?
>>
>> Hi Chris,
>>
>> Lacking any reason to believe otherwise, I estimate the number of BGP
>> users at reasonably close to the number of autonomous systems in the
>> Internet BGP table. Technically that doesn't have to be true... but
>> given the debugging nuissance associated with private AS numbers and
>> the trivial ease and cost with which an AS is registered it seems
>> likely to me.
>
> I know that 701 had many 'private' (AS7046) customer peerings than
> public... it doesn't seem out of the realm of possibility that other
> networks have the same situation. I think Marshall's numbers were
> based on some small-business-SEC thing, it'd be nice if he piped up
> with where he got the number though :(

I did some searching with webcrawler and found:
  


which on slide 2 credits marshall (from before the slide which is
dated 2005), the actual number is not (sadly) shown in the slides...

This message from Marshall alludes to sending the numbers to Vince
Fuller, Marshall goes on to say:
   
"Yes, I gave numbers to Vince Fuller about millions of multi-homers,
but that was to set an upper bound on the process. I do no believe
that every small business will rush out and multi-home, no matter how
automated BGP becomes."

So clearly he's betting as Joel has (and William as well) that the
number will be below his 1.4m total businesses, but above the current
40k asns, I would think.

-chris

Re: BGPttH. Neustar can do it, why can't we?

[Chris Boyd]

On Aug 6, 2012, at 9:08 AM, Christopher Morrow wrote:

> I'm curious as to your number... where is that from?
> Marhsall had noted a number of 'small businesses' in the US at ~1.4m
> as of ~2006ish?

Speaking as someone who does a lot of work supporting small business IT, I 
suspect the number is much lower.  As a group, these customers tend to be 
extremely cost averse.  Paying for a secondary access circuit may become 
important as cloud applications become more critical for the market segment, 
but existing smart NAT boxes that detect primary upstream failure and switch 
over to a secondary ISP will work for many cases.  Yes, it's ugly, but it gets 
them reconnected to the off-site email server and the payment card gateway.

--Chris

Re: BGPttH. Neustar can do it, why can't we?

[Leo Bicknell]

In a message written on Mon, Aug 06, 2012 at 10:05:30AM -0500, Chris Boyd wrote:
> Speaking as someone who does a lot of work supporting small business IT, I 
> suspect the number is much lower.  As a group, these customers tend to be 
> extremely cost averse.  Paying for a secondary access circuit may become 
> important as cloud applications become more critical for the market segment, 
> but existing smart NAT boxes that detect primary upstream failure and switch 
> over to a secondary ISP will work for many cases.  Yes, it's ugly, but it 
> gets them reconnected to the off-site email server and the payment card 
> gateway.

I don't even think the dual-uplink NAT box is that ugly of a solution.
Sure it's outbound only, but for a lot of applications that's fine.

However, it causes me to ask a differnet question, how will this
work in IPv6?  Does anyone make a dual-uplink IPv6 aware device?
Ideally it would use DHCP-PD to get prefixes from two upstream
providers and would make both available on the local LAN.  Conceptually
it would then be easy to policy route traffic to the correct provider.
But of course the problem comes down to the host, it now needs to
know how to switch between source addresses in some meaningful way,
and the router needs to be able to signal it.

As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might
be a relatively clean solution.  Are there other deployable, or nearly
deployable solutions?

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


pgplOaoI7mtWG.pgp
Description: PGP signature

Re: BGPttH. Neustar can do it, why can't we?

[Mikael Abrahamsson]

On Mon, 6 Aug 2012, Leo Bicknell wrote:

However, it causes me to ask a differnet question, how will this work in 
IPv6?  Does anyone make a dual-uplink IPv6 aware device? Ideally it 
would use DHCP-PD to get prefixes from two upstream providers and would 
make both available on the local LAN.  Conceptually it would then be 
easy to policy route traffic to the correct provider. But of course the 
problem comes down to the host, it now needs to know how to switch 
between source addresses in some meaningful way, and the router needs to 
be able to signal it.


There are working groups in the IETF looking into how to make this work, 
"homenet", "v6ops" and a few others. After a while one runs into protocol 
extensions or behavioural changes and things become non-trivial.


As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might be a 
relatively clean solution.  Are there other deployable, or nearly 
deployable solutions?


Yes, there are a lot of possible options. Feel free to participate in the 
process. There is nothing that is deployable right now though.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Cisco 7200 PCI Limitations

[david peahi]

The 7200 architecture dates from the late 1990s, and is basically modeled
on a PCI-bus UNIX workstation from that era. The 7200 is usable today as a
WAN aggregation router for T1 access, and nothing else. Using it as a GiGE
transit router will place a non-deterministic node in the network, unable
to scale to the 4 GiGE full-duplex throughput. Even worse is creating a
portchannel out of the 7200 GiGE interfaces and using dot1q sub-interfaces
to emulate an Ethernet switch in 7200 software, then connecting the 7200
dot1q trunk to a modern Ethernet switch with a wire speed backplane (for
example a Cisco 3560X Ethernet switch).
Long since considered an unacceptable best practice (due to the 7200
backplane limitation vs adjacent, directly connected modern Ethernet
switches), Cisco is still teaching portchannel in its router configuration
classes, so relatively new network engineers have actually been known to
use this ill-considered configuration.
If a 4 port GiGE Cisco router is needed, then the ASR1001 is the modern
version of the 7206, with wire speed throughput.

On Fri, Aug 3, 2012 at 12:36 AM, shthead  wrote:

> Hi all,
>
> I have a 7200 series router (7204) here and I am trying to figure out
> something with it. Currently the router has a NPE-G1 card in it, giving it
> 3 gig interfaces but I need an extra gig interface on it to make 4.
>
> Having a look around the available options are either get a PA-GE card
> that fits into one of the slots on the router or to get a C7200-I/O-GE+E
> (I/O controller with a gbit port on it).
>
> The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus
> will limit it to 300mbit full duplex (and it goes on further to say it will
> be limited to approx 200mbit in best case scenario due to the design of the
> card) [1].
>
> The other option left is the I/O controller. I found that you can get a
> port adaptor jacket card [2] for the 7200's that let you stick a normal
> interface card into the I/O controller slot (instead of the I/O controller
> itself).
>
> My main concern is if the jacket card uses its own PCI bus I am assuming
> the C7200-I/O-GE+E also connects via PCI which means it would be subject to
> the same limitations as the PA-GE.
>
> Does anyone have any idea if that would be correct and the only option for
> another gbit port would be to get another device?
>
> Thanks for the help
>
> [1] http://www.cisco.com/en/US/**products/hw/routers/ps341/**
> products_tech_**note09186a00800c814a.shtml#**backinfo
> [2] http://www.cisco.com/en/US/**prod/collateral/routers/ps341/**
> prod_qas0900aecd8045055e.html
>
>

Re: BGPttH. Neustar can do it, why can't we?

[Mike Jones]

On 6 August 2012 16:11, Leo Bicknell  wrote:
> In a message written on Mon, Aug 06, 2012 at 10:05:30AM -0500, Chris Boyd 
> wrote:
>> Speaking as someone who does a lot of work supporting small business IT, I 
>> suspect the number is much lower.  As a group, these customers tend to be 
>> extremely cost averse.  Paying for a secondary access circuit may become 
>> important as cloud applications become more critical for the market segment, 
>> but existing smart NAT boxes that detect primary upstream failure and switch 
>> over to a secondary ISP will work for many cases.  Yes, it's ugly, but it 
>> gets them reconnected to the off-site email server and the payment card 
>> gateway.
>
> I don't even think the dual-uplink NAT box is that ugly of a solution.
> Sure it's outbound only, but for a lot of applications that's fine.
>
> However, it causes me to ask a differnet question, how will this
> work in IPv6?  Does anyone make a dual-uplink IPv6 aware device?
> Ideally it would use DHCP-PD to get prefixes from two upstream
> providers and would make both available on the local LAN.  Conceptually
> it would then be easy to policy route traffic to the correct provider.
> But of course the problem comes down to the host, it now needs to
> know how to switch between source addresses in some meaningful way,
> and the router needs to be able to signal it.

Multiple prefixes is very simple to do without needing a dual uplink
router, just get 2 "normal" routers and have them both advertise their
own prefixes, the problem is the policy routing that you mentioned a
dual WAN router would do.

A client that sees prefix A from router A and prefix B from router B
should IMO prefer router A for traffic from prefix A and router B for
traffic from prefix B. Current implementations seem to abstract away
the addressing and the routing in to completely separate things
resulting in it picking a default router then using that for all
traffic, this isn't too much of a problem if neither of your upstreams
do any source address filtering but I would much rather OS vendors
change their implementations than tell ISPs to stop filtering their
customers.

> As messy as IPv4 NAT is, it seems like a case where IPv6 NAT might
> be a relatively clean solution.  Are there other deployable, or nearly
> deployable solutions?

If you have a router that sends out RAs with lifetime 0 when the
prefix goes away then this should be deployable for "poor mans
failover" (the same category I put IPv4 NAT in), however there are
some bugs with client implementations and some clients might refuse to
use that prefix/router again until they have rebooted which could be
an issue for infrequently rebooted clients if the other connection
later goes down. A lifetime of 1 instead of 0 should in theory work
around this behaviour but I haven't seen any implementations that do
this and haven't tested myself.

It's a shame that this IPv6 stuff doesn't work properly out of the
box, I fear that there will be a lot of hackery due to early
limitations that will stick around - for example if NAT becomes
readily available before clients can properly handle multiple prefixes
from multiple routers (and DHCP-PD chaining, and the various other
"we're working on it" things), then even once clients start being able
to do it properly I suspect people will still stick to their beloved
NAT because that's what they are used to.

- Mike

Re: Cisco 7200 PCI Limitations

[PC]

While I agree it may not be suitable for transit GigE purposes, it is
certainly acceptable for many WAN aggregation scenarios and CPE scenarios
well in excess of T1 speeds.

There are still many out there in DS3, Fast-E, subrate ethernet subscriber,
ATM, (DSL/L2TP/PPPOE), DMVPN, and other similar scenarios.  For this, while
often not ideal, they continue to work fine.

On Mon, Aug 6, 2012 at 10:47 AM, david peahi  wrote:

> The 7200 architecture dates from the late 1990s, and is basically modeled
> on a PCI-bus UNIX workstation from that era. The 7200 is usable today as a
> WAN aggregation router for T1 access, and nothing else. Using it as a GiGE
> transit router will place a non-deterministic node in the network, unable
> to scale to the 4 GiGE full-duplex throughput. Even worse is creating a
> portchannel out of the 7200 GiGE interfaces and using dot1q sub-interfaces
> to emulate an Ethernet switch in 7200 software, then connecting the 7200
> dot1q trunk to a modern Ethernet switch with a wire speed backplane (for
> example a Cisco 3560X Ethernet switch).
> Long since considered an unacceptable best practice (due to the 7200
> backplane limitation vs adjacent, directly connected modern Ethernet
> switches), Cisco is still teaching portchannel in its router configuration
> classes, so relatively new network engineers have actually been known to
> use this ill-considered configuration.
> If a 4 port GiGE Cisco router is needed, then the ASR1001 is the modern
> version of the 7206, with wire speed throughput.
>
> On Fri, Aug 3, 2012 at 12:36 AM, shthead  wrote:
>
> > Hi all,
> >
> > I have a 7200 series router (7204) here and I am trying to figure out
> > something with it. Currently the router has a NPE-G1 card in it, giving
> it
> > 3 gig interfaces but I need an extra gig interface on it to make 4.
> >
> > Having a look around the available options are either get a PA-GE card
> > that fits into one of the slots on the router or to get a C7200-I/O-GE+E
> > (I/O controller with a gbit port on it).
> >
> > The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus
> > will limit it to 300mbit full duplex (and it goes on further to say it
> will
> > be limited to approx 200mbit in best case scenario due to the design of
> the
> > card) [1].
> >
> > The other option left is the I/O controller. I found that you can get a
> > port adaptor jacket card [2] for the 7200's that let you stick a normal
> > interface card into the I/O controller slot (instead of the I/O
> controller
> > itself).
> >
> > My main concern is if the jacket card uses its own PCI bus I am assuming
> > the C7200-I/O-GE+E also connects via PCI which means it would be subject
> to
> > the same limitations as the PA-GE.
> >
> > Does anyone have any idea if that would be correct and the only option
> for
> > another gbit port would be to get another device?
> >
> > Thanks for the help
> >
> > [1] http://www.cisco.com/en/US/**products/hw/routers/ps341/**
> > products_tech_**note09186a00800c814a.shtml#**backinfo<
> http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800c814a.shtml#backinfo
> >
> > [2] http://www.cisco.com/en/US/**prod/collateral/routers/ps341/**
> > prod_qas0900aecd8045055e.html<
> http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd8045055e.html
> >
> >
> >
>

Re: BGPttH. Neustar can do it, why can't we?

[Leo Bicknell]

In a message written on Mon, Aug 06, 2012 at 05:51:02PM +0100, Mike Jones wrote:
> If you have a router that sends out RAs with lifetime 0 when the
> prefix goes away then this should be deployable for "poor mans
> failover" (the same category I put IPv4 NAT in), however there are

If your provider does Unicast RPF strict mode, which I hope _all_
end user and small business connections default to doing this won't
work.  The traffic has to be policy routed out based on the source
IP.

Having the host stack do that is an acceptable solution (your dual
router model) I think, but I don't know of a single one that does
that today.

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


pgp26jdIW5Fr2.pgp
Description: PGP signature

RE: Verizon FiOS - is BGP an option?

[Frank Bulk]

Even though we know it's technically possible, service providers aren't
going to overprovision power backup unless there is a business reason to do
so.  Some state PUCs have minimum battery run times -- I'm sure service
providers who provide telephone service are meeting that because their
certificate depends on that.  After that, it's just providing enough
services to remain comparatively competitive.

Frank

-Original Message-
From: Ralph E. Whitmore, III [mailto:ral...@interworld.net] 
Sent: Sunday, August 05, 2012 11:54 PM
To: nanog@nanog.org
Subject: RE: Verizon FiOS - is BGP an option?

What I think most people are objecting to is that most of the issue with
maintain service is not related to technical capabilities, but related to
the cost of providing these support services impacting the profit margins of
the large monopolistic carriers.  Verizon with their FIOS offerings, at
least in my area is CO based and all optical, so all I have to provide is
power to my own FIOS terminal which is easy to do, floated on batteries (not
the POS that VZ provided but a real battery bank) and I stay online. We have
been through 10 outages at least 10 hours in duration and one 3 day outage
all courtesy of SCE who can't figure out how to replace the 57 year old
wires that keep breaking from corrosion here in So. Calif.  As a subscriber,
I paid for the copper Wire that VZ installed, I paid for the Copper that
Edison installed, I pay to maintain  both of these services on a 7x24x365
basis. And each and every month, SCE and VZ take  a mandatory deduction out
of my bill specifically to replace the copper every  50 years (the design
life of the infrastructure).  Edison squanders that money and just patches
the infrastructure with no regard for the customers, and VZ replaces the
copper with FIOS so they don't have to allow any competition from anyone
else and demos the copper when they are done so no one else can use it.  All
of these companies fail to understand that they were granted a license  and
handed the keys to provide a public service and we expect them to perform
that job rain or shine 7x24x365.  Hurricanes (while not a problem where I
am) are a known problem in many parts of the company and it is their job to
maintain service despite the hurricanes.  These fiber huts/RSU's were
installed to minimize VZ's (insert your favorite carrier here) cost of
maintenance for their network . This way, they can increase their profits by
laying off more workers and hiring more subcontractors.  So be it, that is
their business model.  What people/PUC/ Regulatory bodies fail to follow up
on is that just because they are allowed to install Fiber Huts/RSU's the
customers should expect the same level of service and redundancy that is
provided by a brick and mortar CO built to the ATT/Bellcore standards for
stability and reliability.  I am all for the carriers pushing the edge
closer to the customers, but it should not be allowed to occur at a
substandard level.  They certainly aren't offering a discount for
substandard service received by some.  My customers get 99.999% reliability
from my infrastructure, I expect the carriers to do at least as well,
obviously that doesn't happen.

All my Roadside cabinets have a DC plant that is engineered to hold the
facility for  at least 18 hours based on the equipment in the box. All my
facilities have an external Transfer switch and a generator plug.  A single
5kw generator, with one cable and padlock,  with one tank of fuel (generally
propane or diesel)(about 5 gallons) will run the hut for 8-10 hours, fully
recharge the DC plant inside buying you another 18 hours on battery
(therefore 28 additional hours before fuel is needed) and to boot have
electronic monitoring to tell me if there is another AC failure of the
generator during that 8-10 hours.   One contractor, god forbid we wouldn't
do this with actual employees of the company, with a pickup truck and a
small trailer should be able to support between 12-20 Fiber Huts /RSU's in a
single shift. If your site is bigger than a 5KW site then you should have
generator backup onsite in the first place.  If I can do this
Verizon/ATT/Centurylink should have no trouble supporting their facilities
in a similar fashion.  I am a little dinky company with 12 employees, but
Verizon( your carrier name here) If you want to use Wisper Watt 25KW
generators, more power to you, they will just pass the costs on to us
anyways in the next rate hike.  The argument about lack of fuel availability
is total bunk as well as I can't believe that any carrier doesn't already
have  1000's of gallons onsite already to support their CO's, trucks, ect.
if you need more you can order a 5000gallon tank like everyone else in the
real world does, you can probably have it delivered tomorrow afternoon if
you place the order tomorrow morning before noon.  Lack of power at an Fiber
hut/RSU is negligence at best on a carriers part, not an unsolvable
technical problem

My un

Re: Verizon FiOS - is BGP an option?

[William Herrin]

On Mon, Aug 6, 2012 at 8:31 AM, Frank Bulk  wrote:
> Even though we know it's technically possible, service providers aren't
> going to overprovision power backup unless there is a business reason to do
> so.  Some state PUCs have minimum battery run times -- I'm sure service
> providers who provide telephone service are meeting that because their
> certificate depends on that.  After that, it's just providing enough
> services to remain comparatively competitive.

It's unfortunate that some of them intend to wait for the PUCs and
SCCs to compel them to maintain service availability at the level they
learned to do it at for POTS. And then complain nodoubt about how much
it costs since they didn't architect their network to be friendly to
power backup. Don't these guys ever want to get ahead of the curve? If
they want to keep making the case for being allowed to operate an
unregulated monopoly/duopoly "information service," it seems like it
would be unwise to provoke State Corporation Commission with service
outages.

Regards,
Bill Herrin


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

Re: BGPttH. Neustar can do it, why can't we?

[Owen DeLong]

On Aug 6, 2012, at 07:27 , William Herrin  wrote:

> On Mon, Aug 6, 2012 at 10:08 AM, Christopher Morrow
>  wrote:
>> On Mon, Aug 6, 2012 at 9:07 AM, William Herrin  wrote:
>>> As much as I'd love for
>>> Verizon to offer BGP directly over FIOS there are fewer than 40,000
>> 
>> I'm curious as to your number... where is that from?
>> Marhsall had noted a number of 'small businesses' in the US at ~1.4m
>> as of ~2006ish?
> 
> Hi Chris,
> 
> Lacking any reason to believe otherwise, I estimate the number of BGP
> users at reasonably close to the number of autonomous systems in the
> Internet BGP table. Technically that doesn't have to be true... but
> given the debugging nuissance associated with private AS numbers and
> the trivial ease and cost with which an AS is registered it seems
> likely to me.
> 

This ignores the probability that cost effective BGP service availability would
strongly drive demand for AS Numbers and adoption of the technology.

Owen

Re: BGPttH. Neustar can do it, why can't we?

[Owen DeLong]

On Aug 6, 2012, at 07:21 , Leo Bicknell  wrote:

> In a message written on Mon, Aug 06, 2012 at 01:49:07AM -0500, jamie rishaw 
> wrote:
>> discuss.
> 
> It's a short sighted result created by the lack of competition.
> 
> IP access is a commodity service, with thin margins that will only
> get thinner.  Right now those margins are being propped up in many
> locations by monopoly or near-monopoly status, which creates a
> situation where companies neither need to compete on features and
> service quality nor do they need to turn to those areas to maintain
> a profit.
> 
> If there was meaningful competition, the margin on raw IP access
> would decline and companies would have to turn to value-add services
> to maintain a profit margin.  From the simple up-sell of a static
> IP address that some do today, to a fee for BGP, a fee for DDOS
> mitigation, and so on.  These are all things it's not uncommon to
> see when buying service in carrier netural colos where there is
> competition.
> 
> There is no technological problem here.  BGP to the end user has a
> cost.  The current business climate is causing people to cut all
> possible costs and offering no incentive to innvovate and up-charge.
> 
> Which leads to an interesting question.  If on top of your $100/month
> "business class Internet" the provider were to charge $50/month for
> "BGP Access" to cover their costs of having a human configure the
> session, larger access gear to handle the routes, and larger backbone
> gear to deal with a larger routing table, would you still be as
> gung ho about BGP to the business?
> 

I'd pay it in a heartbeat.

Owen

Re: BGPttH. Neustar can do it, why can't we?

[Scott Helms]

Probability is much too strong IMO.  Most businesses don't even consider 
multi-homing and many that do use NAT devices with several connections 
rather than trying to run BGP.


#not associated nor do I recommend, just an example

http://www.fatpipeinc.com/warp/index.html



This ignores the probability that cost effective BGP service availability would
strongly drive demand for AS Numbers and adoption of the technology.

Owen






--
Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

Re: BGPttH. Neustar can do it, why can't we?

[Owen DeLong]

Respectfully, I disagree... I think this is a causal chain...

1.  Lack of cost-effective BGP-based service means that
2.  CPE vendors are not motivated to provide self-configuring bgp-speaking 
routers to behave in this manner means that
3.  SMBs seek other solutions using available CPE technology.

If cost-effective BGP-based service were available, providers would likely work 
with CPE vendors to get automation features added to products to support such 
services and multihomed organizations would definitely want to use those 
features.

Owen

On Aug 6, 2012, at 13:16 , Scott Helms  wrote:

> Probability is much too strong IMO.  Most businesses don't even consider 
> multi-homing and many that do use NAT devices with several connections rather 
> than trying to run BGP.
> 
> #not associated nor do I recommend, just an example
> 
> http://www.fatpipeinc.com/warp/index.html
> 
> 
>> This ignores the probability that cost effective BGP service availability 
>> would
>> strongly drive demand for AS Numbers and adoption of the technology.
>> 
>> Owen
>> 
>> 
>> 
> 
> 
> -- 
> Scott Helms
> Vice President of Technology
> ZCorum
> (678) 507-5000
> 
> http://twitter.com/kscotthelms
> 
> 

next hop packet loss

[Jim Ray]

Good afternoon. I am a newbie to this group, and this post is my first
post ever. A friend from another list recommended this group.

 

I have a Time Warner Business Class connection and am unable to reach 
http://www.checkpoint.com to research product line I wish to carry. I
did a trace route and confirmed packets are past my network, Time Warner
network and onto next hop where they execute jump to nowhere
instruction.

 

Time Warner says it is off their network, and they can't help. I
received no reply from above.net next hop.

 

What is the best way to solve this type of problem?

 

Here is the tracert just now (it has been failing for weeks):

 

C:\Documents and Settings\jim.ray>tracert checkpoint.com

 

Tracing route to checkpoint.com [216.200.241.66]

over a maximum of 30 hops:

 

  152 ms28 ms37 ms  10.129.96.1

  210 ms12 ms16 ms  ten13-0-0-238.rlghnca-rtr1.nc.rr.com
[66.26.32.2

42]

  316 ms12 ms12 ms  ae19.rlghncpop-rtr1.southeast.rr.com
[24.93.64.0

]

  419 ms23 ms24 ms  107.14.19.20

  516 ms19 ms19 ms  107.14.19.133

  628 ms20 ms19 ms  xe-0-1-1.er2.iad10.us.above.net
[64.125.12.61]

  723 ms19 ms19 ms  xe-2-0-0.cr2.dca2.us.above.net
[64.125.31.209]

  874 ms49 ms56 ms  xe-0-2-0.cr2.iah1.us.above.net
[64.125.28.50]

  977 ms79 ms79 ms  xe-0-3-0.cr2.lax112.us.above.net
[64.125.30.50]

 

1085 ms86 ms86 ms  xe-1-0-0.cr2.sjc2.us.above.net
[64.125.31.233]

1184 ms92 ms86 ms  xe-1-1-0.er2.sjc2.us.above.net
[64.125.26.202]

1286 ms86 ms   105 ms  64.124.201.230.b709.above.net
[64.124.201.230]

13 *** Request timed out.

14 *** Request timed out.

15 *** Request timed out.

16 *** Request timed out.

17 *** Request timed out.

18 *** Request timed out.

19 *** Request timed out.

20 *** Request timed out.

21 *** Request timed out.

22 *** Request timed out.

23 *** Request timed out.

24 *** Request timed out.

25 *** Request timed out.

26 *** Request timed out.

27 *** Request timed out.

28 *** Request timed out.

29 *** Request timed out.

30 *** Request timed out.

 

Trace complete.

 

Regards,

 

Jim Ray, President

Neuse River Networks

2 Davis Drive, PO Box 13169

Research Triangle Park, NC 27709

919-838-1672 x100

www.NeuseRiverNetworks.com  

   

 

<>

Wanted: Asia bandwidth test files

[Micah Anderson]

Hi,

I'm sitting on what is advertised as a 100mbit/sec connection in
Cambodia. I have been trying to verify that, because I do not believe it
is valid.

I did iperf tests from a number of network locations, and at one point I
did get 71mbit/sec (most of the results were around 20-25mbit/sec or
less). But I dont think 30 second iperf tests are particularly revealing
when the bandwith rate might change drastically over the day. I
considered doing a 3 day iperf test, but somehow this seems not how the
tool was designed.

Someone suggested I find test files from various Asian locations to
download via wget. I found a bunch of 100mb test files for various
providers in N. America and Europe on webhostingtalk, which were
interesting, but I never got more than around 5mbit/sec with them.

Does anyone have any machines in Japan, S. Korea, or other asian
locations with good bandwidth. where they can host a 100mbit file so I
can attempt to download it to test this?

Other suggestions for reliable tests would also be welcome! Please, dont
suggest some flash garbage :)

thanks!
micah

-- 

Re: IETF contacts? - Fwd: Reference to historic or obsolated RFCs

[Tom Taylor]

I'd suggest the ietf-discussion list, since it's a matter for general 
discussion.


On 06/08/2012 10:10 AM, Livio Zanol Puppim wrote:

Hello guys,

I've sent the e-mail below to IETF, but I couldn't find a contact e-mail to
address this kind of subject in IETF site. Does anybody knows which e-mail
to send this?

The contact page from IETF website:
http://www.ietf.org/contact-the-ietf.html

-- Forwarded message --
From: Livio Zanol Puppim 
Date: 2012/8/6
Subject: Reference to historic or obsolated RFCs
To: ietf-i...@ietf.org, ietf-act...@ietf.org


Hello,

I don't know which contact to send this e-mail, so I'm copying the INFO and
ACTION e-mail... If these are the wrong contact, can you please point me
the correct e-mail?

Reading the *RFC 5375* I've found references to some RFCs that are
considered Historic, or have been updated. In some cases, this can lead to
a misunderstand of a a section in a RFC.

For example:
The* RFC 5375* in section *B.2.2* states that we should avoid using /127
IPv6 prefix, but* RFC 6164* clearly says that we can use /127 prefix for
Inter-Router links. In fact, the *RFC 6547*, moves the *RFC
3627*(referenced by the
* RFC 5375* in the above section) to Historic status.

If my point of view is indeed correct, I think that everytime a new RFC is
published that proposes an *Update* to another RFC, or *Obsoletes* another
RFC or moves a RFC to *Historic *status, the team responsible for it's
creation needs to read every reference to that RFC and request changes in
order to avoid this kind of misunderstanding. This is very important to
guys like me, that only reads the RFCs.

the section from RFC 5375
http://tools.ietf.org/html/rfc5375#appendix-B.2.2

"


B.2.2 .  /127 Addresses

The usage of the /127 addresses, the equivalent of IPv4's RFC 3021

[RFC3021 ], is not valid and
should be strongly discouraged as
documented in RFC 3627 
[RFC3627 ].

"

Re: Wanted: Asia bandwidth test files

[Sadiq Saif]

Linode hosts one to test their Tokyo location -
http://speedtest.tokyo.linode.com/100MB-tokyo.bin

Source - http://www.linode.com/speedtest/

On Thu, Aug 2, 2012 at 1:59 PM, Micah Anderson  wrote:
>
> Hi,
>
> I'm sitting on what is advertised as a 100mbit/sec connection in
> Cambodia. I have been trying to verify that, because I do not believe it
> is valid.
>
> I did iperf tests from a number of network locations, and at one point I
> did get 71mbit/sec (most of the results were around 20-25mbit/sec or
> less). But I dont think 30 second iperf tests are particularly revealing
> when the bandwith rate might change drastically over the day. I
> considered doing a 3 day iperf test, but somehow this seems not how the
> tool was designed.
>
> Someone suggested I find test files from various Asian locations to
> download via wget. I found a bunch of 100mb test files for various
> providers in N. America and Europe on webhostingtalk, which were
> interesting, but I never got more than around 5mbit/sec with them.
>
> Does anyone have any machines in Japan, S. Korea, or other asian
> locations with good bandwidth. where they can host a 100mbit file so I
> can attempt to download it to test this?
>
> Other suggestions for reliable tests would also be welcome! Please, dont
> suggest some flash garbage :)
>
> thanks!
> micah
>
> --
>
>



-- 
Sadiq S
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Re: next hop packet loss

[Tom Hill]

Hi Jim,

On 06/08/12 22:27, Jim Ray wrote:

What is the best way to solve this type of problem?


It's not a problem, it's checkpoint purporting to be 'secure' when all 
they're doing is blocking ICMP outright, seemingly.


If I try 'tcptraceroute' (from Linux) it works just fine, bare the 
Above.net hop in the middle that doesn't respond - ignore.


$ sudo tcptraceroute -n checkpoint.com
traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets
 1  81.187.203.81  0.719 ms  1.050 ms  1.298 ms
 2  90.155.53.54  30.184 ms  31.604 ms  32.370 ms
 3  90.155.53.43  33.891 ms  35.072 ms  36.021 ms
 4  85.91.238.217  37.016 ms  38.236 ms  39.215 ms
 5  85.91.224.10  40.226 ms  41.358 ms  42.354 ms
 6  212.187.200.145  164.713 ms  164.102 ms  164.020 ms
 7  4.69.139.99  45.316 ms  194.042 ms  194.088 ms
 8  64.125.14.17  194.297 ms  193.943 ms  193.558 ms
 9  64.125.31.198  194.304 ms  194.462 ms  193.560 ms
10  * * *
11  64.125.26.37  288.267 ms  284.237 ms  166.340 ms
12  64.125.24.38  178.571 ms  179.467 ms  156.769 ms
13  64.125.28.238  148.002 ms  147.244 ms  147.501 ms
14  64.125.26.141  206.010 ms  205.574 ms  205.426 ms
15  64.125.28.57  201.753 ms  172.439 ms  174.169 ms
16  64.124.201.230  176.866 ms  172.412 ms  172.510 ms
17  208.185.174.208  173.668 ms  174.310 ms  173.999 ms
18  216.200.241.66   172.504 ms  172.386 ms  172.700 ms


Tom

Re: BGPttH. Neustar can do it, why can't we?

[Scott Helms]

Owen,

That's like saying if it were easy to fly we'd all be pilots, which 
isn't true either.  BGP would need to be completely redesigned/replaced 
before it could possibly be automated to that level much less 
implemented by the Lynksis/DLink/Netgear/$yourfavoritesohorouter 
vendor.  Business would need a reason to implement BGP and most simply 
don't AND BGP would have to be dramatically simpler and safer.  
Operators already have to be deeply involved (AKA filtering the 
announced networks) with edge network BGP implementations to prevent 
someone from announcing they're the preferred route for some other 
organization's netblock.  This happens already on occasion and all of 
the people who run routers speaking BGP are generally professionals.


On 8/6/2012 4:27 PM, Owen DeLong wrote:

Respectfully, I disagree... I think this is a causal chain...

1.  Lack of cost-effective BGP-based service means that
2.  CPE vendors are not motivated to provide self-configuring bgp-speaking 
routers to behave in this manner means that
3.  SMBs seek other solutions using available CPE technology.

If cost-effective BGP-based service were available, providers would likely work 
with CPE vendors to get automation features added to products to support such 
services and multihomed organizations would definitely want to use those 
features.

Owen

On Aug 6, 2012, at 13:16 , Scott Helms  wrote:


Probability is much too strong IMO.  Most businesses don't even consider 
multi-homing and many that do use NAT devices with several connections rather 
than trying to run BGP.

#not associated nor do I recommend, just an example

http://www.fatpipeinc.com/warp/index.html



This ignores the probability that cost effective BGP service availability would
strongly drive demand for AS Numbers and adoption of the technology.

Owen





--
Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms







--
Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000

http://twitter.com/kscotthelms

Re: Wanted: Asia bandwidth test files

[Shishio Tsuchiya]

Hi
I think RING project NLNOG has potential to help your effort.
https://ring.nlnog.net/
At least they have location in tokyo.

And I talked with Seichi Kawamura who is leader of JANOG about method of 
quality　verification among the world wide.
They are using host of Softlayer, amazon and OVH which could select the 
location.

Job and Mucho ccing.

Regards,
-Shishio


(2012/08/03 2:59), Micah Anderson wrote:
> 
> Hi,
> 
> I'm sitting on what is advertised as a 100mbit/sec connection in
> Cambodia. I have been trying to verify that, because I do not believe it
> is valid.
> 
> I did iperf tests from a number of network locations, and at one point I
> did get 71mbit/sec (most of the results were around 20-25mbit/sec or
> less). But I dont think 30 second iperf tests are particularly revealing
> when the bandwith rate might change drastically over the day. I
> considered doing a 3 day iperf test, but somehow this seems not how the
> tool was designed.
> 
> Someone suggested I find test files from various Asian locations to
> download via wget. I found a bunch of 100mb test files for various
> providers in N. America and Europe on webhostingtalk, which were
> interesting, but I never got more than around 5mbit/sec with them.
> 
> Does anyone have any machines in Japan, S. Korea, or other asian
> locations with good bandwidth. where they can host a 100mbit file so I
> can attempt to download it to test this?
> 
> Other suggestions for reliable tests would also be welcome! Please, dont
> suggest some flash garbage :)
> 
> thanks!
> micah
> 

Re: next hop packet loss

[Jim Ray]

It is a problem with http protocol regardless of ICMP. 

Sent from my iPhone

On Aug 6, 2012, at 5:51 PM, "Tom Hill"  wrote:

> Hi Jim,
> 
> On 06/08/12 22:27, Jim Ray wrote:
>> What is the best way to solve this type of problem?
> 
> It's not a problem, it's checkpoint purporting to be 'secure' when all 
> they're doing is blocking ICMP outright, seemingly.
> 
> If I try 'tcptraceroute' (from Linux) it works just fine, bare the Above.net 
> hop in the middle that doesn't respond - ignore.
> 
> $ sudo tcptraceroute -n checkpoint.com
> traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets
> 1  81.187.203.81  0.719 ms  1.050 ms  1.298 ms
> 2  90.155.53.54  30.184 ms  31.604 ms  32.370 ms
> 3  90.155.53.43  33.891 ms  35.072 ms  36.021 ms
> 4  85.91.238.217  37.016 ms  38.236 ms  39.215 ms
> 5  85.91.224.10  40.226 ms  41.358 ms  42.354 ms
> 6  212.187.200.145  164.713 ms  164.102 ms  164.020 ms
> 7  4.69.139.99  45.316 ms  194.042 ms  194.088 ms
> 8  64.125.14.17  194.297 ms  193.943 ms  193.558 ms
> 9  64.125.31.198  194.304 ms  194.462 ms  193.560 ms
> 10  * * *
> 11  64.125.26.37  288.267 ms  284.237 ms  166.340 ms
> 12  64.125.24.38  178.571 ms  179.467 ms  156.769 ms
> 13  64.125.28.238  148.002 ms  147.244 ms  147.501 ms
> 14  64.125.26.141  206.010 ms  205.574 ms  205.426 ms
> 15  64.125.28.57  201.753 ms  172.439 ms  174.169 ms
> 16  64.124.201.230  176.866 ms  172.412 ms  172.510 ms
> 17  208.185.174.208  173.668 ms  174.310 ms  173.999 ms
> 18  216.200.241.66   172.504 ms  172.386 ms  172.700 ms
> 
> 
> Tom
> 

Re: BGPttH. Neustar can do it, why can't we?

[Owen DeLong]

That's simply not true at all...

Let's look at what it takes to configure BGP as I suggested...

1. The ASN number of the two providers
2. The ASN to be used for the local side
3. The IP Address to use on the local end of each connection
4. The IP Address to peer with on each connection
5. The prefix(es) to be advertised.

Of these 5, only items 2 and 5 have to come from the customer and the customer 
needs to provide both of these to both ISPs anyway for them to configure their 
side.

It would be trivial for providers and CPE vendors to develop a standardized API 
by which a router could retrieve all 5 pieces of information for a given 
connection once that connection is plugged in to the router. It could literally 
be as simple as:

1.  Port gets address via SLAAC or DHCP
2.  Port retrieves XML configuration document from 
http://bgpconfig.local (or user-specified URL provided by ISP, or whatever)

6939
65512
192.0.2.21/30

2001:db8:1fea:93a9::1/64
192.0.2.22/30
2001:db8:1fea:93a9::2/64


203.0.113.0/24

198.51.100.0/24

0.0.0.0/0



(Yes, I realize that is a bit of an oversimplification of the XML syntax, but 
you get the idea)

3.  Router configures port and BGP session according to received 
XML document, including
appropriate prefix filters.

4.  Router runs with that XML based configuration as long as 
link-state and power remain.

That would allow a zeroconf BGP-enabled router in relatively small hardware 
accepting a default route that would work at least as well as today's dual-NAT 
based boxes. Note that BGP is not redesigned or even altered to achieve this. 
Since Linksys/DLink/Netgear/$EVERYONE already has web servers and clients 
embedded in their gear, the XML parser (or JSON or whatever they choose to use 
for standard encoding) would be pretty straight forward.

Yes, the operator/provider has to do some additional configuration, but 
speaking as a network operator, I know that this can be automated because the 
management of BGP configurations, including the filters _IS_ that automated 
where I work. If the provider is telling the router which prefixes to permit 
announcement of through the configuration URL, then it's even more reliable, 
right?

Owen

On Aug 6, 2012, at 15:05 , Scott Helms  wrote:

> Owen,
> 
>That's like saying if it were easy to fly we'd all be pilots, which isn't 
> true either.  BGP would need to be completely redesigned/replaced before it 
> could possibly be automated to that level much less implemented by the 
> Lynksis/DLink/Netgear/$yourfavoritesohorouter vendor.  Business would need a 
> reason to implement BGP and most simply don't AND BGP would have to be 
> dramatically simpler and safer.  Operators already have to be deeply involved 
> (AKA filtering the announced networks) with edge network BGP implementations 
> to prevent someone from announcing they're the preferred route for some other 
> organization's netblock.  This happens already on occasion and all of the 
> people who run routers speaking BGP are generally professionals.
> 
> On 8/6/2012 4:27 PM, Owen DeLong wrote:
>> Respectfully, I disagree... I think this is a causal chain...
>> 
>> 1.   Lack of cost-effective BGP-based service means that
>> 2.   CPE vendors are not motivated to provide self-configuring bgp-speaking 
>> routers to behave in this manner means that
>> 3.   SMBs seek other solutions using available CPE technology.
>> 
>> If cost-effective BGP-based service were available, providers would likely 
>> work with CPE vendors to get automation features added to products to 
>> support such services and multihomed organizations would definitely want to 
>> use those features.
>> 
>> Owen
>> 
>> On Aug 6, 2012, at 13:16 , Scott Helms  wrote:
>> 
>>> Probability is much too strong IMO.  Most businesses don't even consider 
>>> multi-homing and many that do use NAT devices with several connections 
>>> rather than trying to run BGP.
>>> 
>>> #not associated nor do I recommend, just an example
>>> 
>>> http://www.fatpipeinc.com/warp/index.html
>>> 
>>> 
 This ignores the probability that cost effective BGP service availability 
 would
 strongly drive demand for AS Numbers and adoption of the technology.
 
 Owen
 
 
 
>>> 
>>> -- 
>>> Scott Helms
>>> Vice President of Technology
>>> ZCorum
>>> (678) 507-5000
>>> 
>>> http://twitter.com/kscotthelms
>>> 
>>> 
>> 
> 
> 
> -- 
> Scott Helms
> Vice President of Techn

Re: Wanted: Asia bandwidth test files

[PC]

If you can, I suggest finding other well connected hosts and using IPERF in
UDP mode for your testing.  Separating TCP long-fat pipe and slow start
issues from true packet delivery/loss rates at a given bitrate are
beneficial.  Use Linux as most iperf windows builds are based on cygwin and
have issues at higher bitrates.


On Mon, Aug 6, 2012 at 4:10 PM, Shishio Tsuchiya  wrote:

> Hi
> I think RING project NLNOG has potential to help your effort.
> https://ring.nlnog.net/
> At least they have location in tokyo.
>
> And I talked with Seichi Kawamura who is leader of JANOG about method of
> quality verification among the world wide.
> They are using host of Softlayer, amazon and OVH which could select the
> location.
>
> Job and Mucho ccing.
>
> Regards,
> -Shishio
>
>
> (2012/08/03 2:59), Micah Anderson wrote:
> >
> > Hi,
> >
> > I'm sitting on what is advertised as a 100mbit/sec connection in
> > Cambodia. I have been trying to verify that, because I do not believe it
> > is valid.
> >
> > I did iperf tests from a number of network locations, and at one point I
> > did get 71mbit/sec (most of the results were around 20-25mbit/sec or
> > less). But I dont think 30 second iperf tests are particularly revealing
> > when the bandwith rate might change drastically over the day. I
> > considered doing a 3 day iperf test, but somehow this seems not how the
> > tool was designed.
> >
> > Someone suggested I find test files from various Asian locations to
> > download via wget. I found a bunch of 100mb test files for various
> > providers in N. America and Europe on webhostingtalk, which were
> > interesting, but I never got more than around 5mbit/sec with them.
> >
> > Does anyone have any machines in Japan, S. Korea, or other asian
> > locations with good bandwidth. where they can host a 100mbit file so I
> > can attempt to download it to test this?
> >
> > Other suggestions for reliable tests would also be welcome! Please, dont
> > suggest some flash garbage :)
> >
> > thanks!
> > micah
> >
>
>
>
>

RE: Wanted: Asia bandwidth test files

[David Wilde]

Hi Micah,

You could try mirror.aarnet.edu.au, if Australia is sufficiently Asian for 
you...

David


-Original Message-
From: Micah Anderson [mailto:mi...@riseup.net] 
Sent: Friday, 3 August 2012 4:00
To: nanog@nanog.org
Subject: Wanted: Asia bandwidth test files


Hi,

I'm sitting on what is advertised as a 100mbit/sec connection in Cambodia. I 
have been trying to verify that, because I do not believe it is valid.

I did iperf tests from a number of network locations, and at one point I did 
get 71mbit/sec (most of the results were around 20-25mbit/sec or less). But I 
dont think 30 second iperf tests are particularly revealing when the bandwith 
rate might change drastically over the day. I considered doing a 3 day iperf 
test, but somehow this seems not how the tool was designed.

Someone suggested I find test files from various Asian locations to download 
via wget. I found a bunch of 100mb test files for various providers in N. 
America and Europe on webhostingtalk, which were interesting, but I never got 
more than around 5mbit/sec with them.

Does anyone have any machines in Japan, S. Korea, or other asian locations with 
good bandwidth. where they can host a 100mbit file so I can attempt to download 
it to test this?

Other suggestions for reliable tests would also be welcome! Please, dont 
suggest some flash garbage :)

thanks!
micah

-- 

Re: BGPttH. Neustar can do it, why can't we?

[William Herrin]

On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong  wrote:
> That's simply not true at all...
>
> Let's look at what it takes to configure BGP as I suggested...
>
> 1. The ASN number of the two providers
> 2. The ASN to be used for the local side
> 3. The IP Address to use on the local end of each connection
> 4. The IP Address to peer with on each connection
> 5. The prefix(es) to be advertised.

Add to that:

6. Primary A, Primary B, Balanced (routing priority via AS path prepends)
7. Optional password for each session (some ISPs require one)

Or take another tack: have the SOHO router accept a URL for each BGP
connection and have the provider build the config. Then all you enter
is your provider-assigned interface address, a DNS server address and
a URL.

Your point is well taken. A leaf node BGP configuration could be
simplified to the point where it fits on a SOHO router config page and
does not require an expert to configure.

Regards,
Bill Herrin




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

Re: BGPttH. Neustar can do it, why can't we?

[Seth Mattinen]

On 8/6/12 4:15 PM, William Herrin wrote:
> On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong  wrote:
>> That's simply not true at all...
>>
>> Let's look at what it takes to configure BGP as I suggested...
>>
>> 1. The ASN number of the two providers
>> 2. The ASN to be used for the local side
>> 3. The IP Address to use on the local end of each connection
>> 4. The IP Address to peer with on each connection
>> 5. The prefix(es) to be advertised.
> 
> Add to that:
> 
> 6. Primary A, Primary B, Balanced (routing priority via AS path prepends)
> 7. Optional password for each session (some ISPs require one)
> 
> Or take another tack: have the SOHO router accept a URL for each BGP
> connection and have the provider build the config. Then all you enter
> is your provider-assigned interface address, a DNS server address and
> a URL.
> 
> Your point is well taken. A leaf node BGP configuration could be
> simplified to the point where it fits on a SOHO router config page and
> does not require an expert to configure.
> 


This is all being approached from the wrong angle; there's too much
technical talk. "BGP to the Home" needs to be sales/marketing driven.
(You're allowed to use buzzwords with no actual meaning though.)

~Seth

Re: BGPttH. Neustar can do it, why can't we?

[Owen DeLong]

On Aug 6, 2012, at 16:15 , William Herrin  wrote:

> On Mon, Aug 6, 2012 at 12:55 PM, Owen DeLong  wrote:
>> That's simply not true at all...
>> 
>> Let's look at what it takes to configure BGP as I suggested...
>> 
>> 1. The ASN number of the two providers
>> 2. The ASN to be used for the local side
>> 3. The IP Address to use on the local end of each connection
>> 4. The IP Address to peer with on each connection
>> 5. The prefix(es) to be advertised.
> 
> Add to that:
> 
> 6. Primary A, Primary B, Balanced (routing priority via AS path prepends)

Not absolutely required and certainly going beyond what is required to provide 
slightly better than the functionality provided with the dual-NAT scenario.

> 7. Optional password for each session (some ISPs require one)

Fair enough, but pretty trivial.

> 
> Or take another tack: have the SOHO router accept a URL for each BGP
> connection and have the provider build the config. Then all you enter
> is your provider-assigned interface address, a DNS server address and
> a URL.

Well, I was going for zeroconf, but yes, that was basically allowed for in what 
I described.

> 
> Your point is well taken. A leaf node BGP configuration could be
> simplified to the point where it fits on a SOHO router config page and
> does not require an expert to configure.
> 

Yep... And it could even be made 100% automated zeroconf with a little more 
effort.

It could even use provider-assigned private-ASNs and a shared PA prefix with a 
little additional ingenuity.

Owen

Re: BGPttH. Neustar can do it, why can't we?

[james machado]

On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong  wrote:
> That's simply not true at all...
>
> Let's look at what it takes to configure BGP as I suggested...
>
> 1. The ASN number of the two providers
> 2. The ASN to be used for the local side
> 3. The IP Address to use on the local end of each connection
> 4. The IP Address to peer with on each connection
> 5. Te prefix(es) to be advertised.
>
> Of these 5, only items 2 and 5 have to come from the customer and the 
> customer needs to provide both of these to both ISPs anyway for them to 
> configure their side.
>
> It would be trivial for providers and CPE vendors to develop a standardized 
> API by which a router could retrieve all 5 pieces of information for a given 
> connection once that connection is plugged in to the router. It could 
> literally be as simple as:
>
> 1.  Port gets address via SLAAC or DHCP
> 2.  Port retrieves XML configuration document from 
> http://bgpconfig.local (or user-specified URL provided by ISP, or whatever)
> 
> 6939
> 65512
> 192.0.2.21/30
> 
> 2001:db8:1fea:93a9::1/64
> 192.0.2.22/30
> 
> 2001:db8:1fea:93a9::2/64
> 
> 
> 203.0.113.0/24
> 
> 198.51.100.0/24
> 
> 0.0.0.0/0
> 
> 
>
> (Yes, I realize that is a bit of an oversimplification of the XML syntax, but 
> you get the idea)
>
> 3.  Router configures port and BGP session according to received 
> XML document, including
> appropriate prefix filters.
>
> 4.  Router runs with that XML based configuration as long as 
> link-state and power remain.
>
> That would allow a zeroconf BGP-enabled router in relatively small hardware 
> accepting a default route that would work at least as well as today's 
> dual-NAT based boxes. Note that BGP is not redesigned or even altered to 
> achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers 
> and clients embedded in their gear, the XML parser (or JSON or whatever they 
> choose to use for standard encoding) would be pretty straight forward.
>

>From a SMB perspective this is part of the problem.  Why pay for:

 1. An ASN
 2. 2 BGP connections
 3. PI space
 4. More expensive hardware (potentially and probably)

when I'm only going to get a Default Route?  I've added complexity to
my life, administrative and OPEX overhead when I'm getting no benefits
of BGP other than a default route.  I can get a default route from a
provider without adding complexity and overhead.

An SMB who does not have a staff on hand wants it cheap and to work.
Everything else is a potential expense they don't want to spend.  They
don't want to have to call either their support company or vendor
because the "Internet is down", at most they want to pull the power on
the router and plug it back in and have it all work.  At best they
want to only know what that "little black box with the blinky lights"
is when someone packs it into a box because it's wasting power and now
the "Internet is broken".

>From an SMB who has a staff on hand it still may not be worth it if
they don't have someone who is BGP smart.  And truth to tell *you*
don't want more BGP idiots polluting the routing table either
intentionally or unintentionally.

Conversely if you do make BGP that available to SMB's and home users
(not necessarily a bad thing) the issues with routing table size has
to be dealt with.  Right now there are roughly 42K ASes with routes in
the routing table.  Add SMB's and home users and your looking at
potentially millions of ASes with routes in the routing table.  Heck
if you *only* double the ASes and associated routes many many routers
are going to crash and need replacement.


> Yes, the operator/provider has to do some additional configuration, but 
> speaking as a network operator, I know that this can be automated because the 
> management of BGP configurations, including the filters _IS_ that automated 
> where I work. If the provider is telling the router which prefixes to permit 
> announcement of through the configuration URL, then it's even more reliable, 
> right?
>
> Owen
>
> On Aug 6, 2012, at 15:05 , Scott Helms  wrote:
>
>> Owen,
>>
>>That's like saying if it were easy to fly we'd all be pilots, which isn't 
>> true either.  BGP would need to be completely redesigned/replaced before it 
>> could possibly be automated to that level much less implemented by the 
>> Lynksis/DLink/Netgear/$yourfavoritesohorouter vendor.  Business would need a 
>> reason to implement BGP and most simply don't AND BGP would have to be 
>> dram

Re: Wanted: Asia bandwidth test files

[Aftab Siddiqui]

Hi Micah

> Does anyone have any machines in Japan, S. Korea, or other asian
locations with good bandwidth. where they can host a 100mbit file so I can
attempt to download it to test this?
>

you may try downloading from stingray.cyber.net.pk
It's in Karachi (Pakistan) with GigE limits. Use rsync.

Regards,

Aftab A. Siddiqui.

-- 
Regards,

Aftab A. Siddiqui

Re: Wanted: Asia bandwidth test files

[Jason Leschnik]

I find the mirrors here are generally beefy

https://launchpad.net/ubuntu/+archivemirrors

Thanks.

On Tuesday, August 7, 2012, Aftab Siddiqui wrote:

> Hi Micah
>
> > Does anyone have any machines in Japan, S. Korea, or other asian
> locations with good bandwidth. where they can host a 100mbit file so I can
> attempt to download it to test this?
> >
>
> you may try downloading from stingray.cyber.net.pk
> It's in Karachi (Pakistan) with GigE limits. Use rsync.
>
> Regards,
>
> Aftab A. Siddiqui.
>
> --
> Regards,
>
> Aftab A. Siddiqui
>


-- 
Regards,
Jason Leschnik.

[m] 0432 35 4224
[w@] jason dot leschnik  ansto dot gov dot au
[U@] jml...@uow.edu.au

RE: Cisco 7200 PCI Limitations

[Holmes,David A]

For users with private DS3-based network links between sites, for the case 
where 2 or more of these DS3's are to be bundled together in a multi-link PPP 
connection, Cisco will not support this configuration due to insufficient 7200 
cpu resources, so packet-by-packet load sharing must be used which could result 
in packets arriving out of sequence. Cisco will not support VoIP over 
packet-by-packet load sharing. Additionally, PIM multicast uses only a single 
DS3 under the packet-by-packet load sharing scenario, so all available 
bandwidth with 2 or more DS3s is not available.
The 7200 will support 8 T1s in a logical multilink bundle, though, so for low 
speed circuits, the 7200 still provides complete IOS feature functionality.
The 7200s have some very limited uses, but in my view they have no place in 
today's wire speed backbone networks, particularly when 3 or more 7200 GiGE 
interfaces can be used as a logical bundle. The biggest problem is the tendency 
of some to treat the 7200 as an Ethernet switch, define a portchannel with 2 or 
more GiGE interfaces, connect the 7200 portchannel to a modern Ethernet switch, 
and by this action define a network bottleneck where packets can be dropped due 
to a serious backplane/wire speed mismatch.

-Original Message-
From: PC [mailto:paul4...@gmail.com]
Sent: Monday, August 06, 2012 10:05 AM
To: david peahi
Cc: nanog@nanog.org
Subject: Re: Cisco 7200 PCI Limitations

While I agree it may not be suitable for transit GigE purposes, it is
certainly acceptable for many WAN aggregation scenarios and CPE scenarios
well in excess of T1 speeds.

There are still many out there in DS3, Fast-E, subrate ethernet subscriber,
ATM, (DSL/L2TP/PPPOE), DMVPN, and other similar scenarios.  For this, while
often not ideal, they continue to work fine.

On Mon, Aug 6, 2012 at 10:47 AM, david peahi  wrote:

> The 7200 architecture dates from the late 1990s, and is basically modeled
> on a PCI-bus UNIX workstation from that era. The 7200 is usable today as a
> WAN aggregation router for T1 access, and nothing else. Using it as a GiGE
> transit router will place a non-deterministic node in the network, unable
> to scale to the 4 GiGE full-duplex throughput. Even worse is creating a
> portchannel out of the 7200 GiGE interfaces and using dot1q sub-interfaces
> to emulate an Ethernet switch in 7200 software, then connecting the 7200
> dot1q trunk to a modern Ethernet switch with a wire speed backplane (for
> example a Cisco 3560X Ethernet switch).
> Long since considered an unacceptable best practice (due to the 7200
> backplane limitation vs adjacent, directly connected modern Ethernet
> switches), Cisco is still teaching portchannel in its router configuration
> classes, so relatively new network engineers have actually been known to
> use this ill-considered configuration.
> If a 4 port GiGE Cisco router is needed, then the ASR1001 is the modern
> version of the 7206, with wire speed throughput.
>
> On Fri, Aug 3, 2012 at 12:36 AM, shthead  wrote:
>
> > Hi all,
> >
> > I have a 7200 series router (7204) here and I am trying to figure out
> > something with it. Currently the router has a NPE-G1 card in it, giving
> it
> > 3 gig interfaces but I need an extra gig interface on it to make 4.
> >
> > Having a look around the available options are either get a PA-GE card
> > that fits into one of the slots on the router or to get a C7200-I/O-GE+E
> > (I/O controller with a gbit port on it).
> >
> > The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus
> > will limit it to 300mbit full duplex (and it goes on further to say it
> will
> > be limited to approx 200mbit in best case scenario due to the design of
> the
> > card) [1].
> >
> > The other option left is the I/O controller. I found that you can get a
> > port adaptor jacket card [2] for the 7200's that let you stick a normal
> > interface card into the I/O controller slot (instead of the I/O
> controller
> > itself).
> >
> > My main concern is if the jacket card uses its own PCI bus I am assuming
> > the C7200-I/O-GE+E also connects via PCI which means it would be subject
> to
> > the same limitations as the PA-GE.
> >
> > Does anyone have any idea if that would be correct and the only option
> for
> > another gbit port would be to get another device?
> >
> > Thanks for the help
> >
> > [1] http://www.cisco.com/en/US/**products/hw/routers/ps341/**
> > products_tech_**note09186a00800c814a.shtml#**backinfo<
> http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note09186a00800c814a.shtml#backinfo
> >
> > [2] http://www.cisco.com/en/US/**prod/collateral/routers/ps341/**
> > prod_qas0900aecd8045055e.html<
> http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd8045055e.html
> >
> >
> >
>

This communication, together with any attachments or embedded links, is for the 
sole use of the intended recipient(s) and may contain information that is 
confidential or legally protected. If yo

Re: BGPttH. Neustar can do it, why can't we?

[Owen DeLong]

On Aug 6, 2012, at 16:42 , james machado  wrote:

> On Mon, Aug 6, 2012 at 3:55 PM, Owen DeLong  wrote:
>> That's simply not true at all...
>> 
>> Let's look at what it takes to configure BGP as I suggested...
>> 
>> 1. The ASN number of the two providers
>> 2. The ASN to be used for the local side
>> 3. The IP Address to use on the local end of each connection
>> 4. The IP Address to peer with on each connection
>> 5. Te prefix(es) to be advertised.
>> 
>> Of these 5, only items 2 and 5 have to come from the customer and the 
>> customer needs to provide both of these to both ISPs anyway for them to 
>> configure their side.
>> 
>> It would be trivial for providers and CPE vendors to develop a standardized 
>> API by which a router could retrieve all 5 pieces of information for a given 
>> connection once that connection is plugged in to the router. It could 
>> literally be as simple as:
>> 
>>1.  Port gets address via SLAAC or DHCP
>>2.  Port retrieves XML configuration document from 
>> http://bgpconfig.local (or user-specified URL provided by ISP, or whatever)
>>
>>6939
>>65512
>>192.0.2.21/30
>>
>> 2001:db8:1fea:93a9::1/64
>>192.0.2.22/30
>>
>> 2001:db8:1fea:93a9::2/64
>>
>>
>> 203.0.113.0/24
>>
>> 198.51.100.0/24
>>
>> 0.0.0.0/0
>>
>>
>> 
>> (Yes, I realize that is a bit of an oversimplification of the XML syntax, 
>> but you get the idea)
>> 
>>3.  Router configures port and BGP session according to received 
>> XML document, including
>>appropriate prefix filters.
>> 
>>4.  Router runs with that XML based configuration as long as 
>> link-state and power remain.
>> 
>> That would allow a zeroconf BGP-enabled router in relatively small hardware 
>> accepting a default route that would work at least as well as today's 
>> dual-NAT based boxes. Note that BGP is not redesigned or even altered to 
>> achieve this. Since Linksys/DLink/Netgear/$EVERYONE already has web servers 
>> and clients embedded in their gear, the XML parser (or JSON or whatever they 
>> choose to use for standard encoding) would be pretty straight forward.
>> 
> 
>> From a SMB perspective this is part of the problem.  Why pay for:
> 
> 1. An ASN
> 2. 2 BGP connections
> 3. PI space
> 4. More expensive hardware (potentially and probably)
> 

1-3 are optional and not required for what I proposed. You could do it with a 
private ASN, PA space and an LOA if you don't care about provider mobility.

I would argue that 4 assumes facts not in evidence.

> when I'm only going to get a Default Route?  I've added complexity to
> my life, administrative and OPEX overhead when I'm getting no benefits
> of BGP other than a default route.  I can get a default route from a
> provider without adding complexity and overhead.
> 

The goal here was to make this as simple and cost-effective as the NAT-based
IPv4 solution currently in common use. There's no reason it can't be exactly 
that.

It does provide advantages over the NAT-based solution (sessions can survive
failover).

You certainly have the option of a more complex BGP configuration, but that
does require a more expensive router and probably 1-3 as well.

> An SMB who does not have a staff on hand wants it cheap and to work.

Which is why I proposed a mechanism by which it could be zero-configuration,
zero additional cost, and provide only marginal benefits over the current IPv4
configuration while also supporting IPv6.

> Everything else is a potential expense they don't want to spend.  They
> don't want to have to call either their support company or vendor
> because the "Internet is down", at most they want to pull the power on
> the router and plug it back in and have it all work.  At best they
> want to only know what that "little black box with the blinky lights"
> is when someone packs it into a box because it's wasting power and now
> the "Internet is broken".

Right... I believe what I proposed comes as close to that as current SOHO
routers that are in common use in the SMB world.

> 
>> From an SMB who has a staff on hand it still may not be worth it if
> they don't have someone who is BGP smart.  And truth to tell *you*
> don't want more BGP idiots polluting the routing table either
> intentionally or unintentionally.
> 

No BGP expertise required... Look again at what I proposed... All configuration
of the BGP is done automatically and dictated by the ISP.

> Conversely if you do make BGP that available to SMB's and home users
> (not necessarily a bad thing) the issues

IPv6 Toolkit v1.2.2 released

[Fernando Gont]

Folks,

We've released IPv6 toolkit version 1.2.2. It is available at:
 (tarball and git repository).

This version is meant to be fully-portable to Mac OS (the list of
supported systems now including, at the very least, FreeBSD, NetBSD,
OpenBSD, Linux, and Mac OS), and also incorporates a number of patches
send by the community.

Any feedback on the tools will be welcome (either unicast to me, or on
the ipv6hackers mailing-list
).

P.S.: If you've sent patches and your patches have not yet been
applied, most likely it just means that I'm catching-up with them
(feel free to resend!).

Thanks!

Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: NFSen plugin - ddd

[Andrew Jones]

I did manage to get my hands on it this morning (thanks Brandon!).
I've put it up for anyone who's interested [1], I had a couple of people
ask for a copy if I found it.
I haven't had a chance to look through the plugin yet, so take no
responsibility for it.
Cheers,
Jonesy

[1] http://www.haqthegibson.com/files/ddd.zip


On Sun, 5 Aug 2012 19:08:56 -0400, Jason Hellenthal
 wrote:
> Don't know if you ever recieved a reply for this but this is the best I
> have come up with to get more eyes on it.
> 
> http://sourceforge.net/apps/trac/nfsen-plugins/wiki/RequestPlugin
> 
> I have not submitted a request for it but if you happen to come accross
> this plugin, I would be interested.
> 
> On Fri, Aug 03, 2012 at 01:55:21PM +1000, Andrew Jones wrote:
>> Hi All,
>> Does anyone have a copy of the DDoS detection plugin for NFSen called
ddd
>> that they could send to me?
>> According to a blog article [1] I read, it used to be available at [2].
>> It's not there, and I haven't had any luck trying to track it down the
>> usual ways. If anyone is able to provide a copy, I'd appreciate it.
>> Thanks,
>> Jonesy
>> 
>> 
>> [1] http://www.ccieflyer.com/2010-01-JasonRowley.php
>> [2] http://www.synacknetworks.com/ddd/ddd.zip

Trouble with IPv6 setup on Quagga

[Anurag Bhatia]

Hello everyone



I am having trouble with Quagga in setting up IPv6 BGP. So far it was
failing with external providers. Just now I gave it a try to setup BGP
session (IPv6 only) within our ASN between two routers.

>From our other end router I see there is no acconcement, while I see blocks
being announced via Quagga. Also strange enough is that the number of
blocks I account - they all come as "withdrawl routes" on other router as
soon as Quagga is turned on.



E.g this is what I see on Quagga:


node4# show bgp ipv6 summary
BGP router identifier 199.116.78.28, local AS number 54456
RIB entries 18741, using 1757 KiB of memory
Peers 1, using 4560 bytes of memory

NeighborVAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
 State/PfxRcd
2607:1b00:10:a::1
4 544566865   5000 00:00:05 9798

Total number of neighbors 1
node4#




So BGP session is up. Next if I check advertised routes, it goes like:




node4# show bgp ipv6 neighbors  2607:1b00:10:a::1 advertised-routes
BGP table version is 0, local router ID is 199.116.78.28
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
  r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network  Next HopMetric LocPrf Weight Path
*> 2607:1b00:d1::/48
::   0100  32768 i
*> 2607:1b00:d2::/48
::   0100  32768 i

Total number of prefixes 2
node4#



I don't see these routes in other router at all.




Here's what my Quagga bgpd.conf looks like:


 hostname node4
 timers bgp 4 16


router bgp 54456
 bgp router-id 199.116.78.28
 redistribute connected metric 1
 redistribute static metric 1
 neighbor 2607:1b00:10:a::1 remote-as 54456
 neighbor 2607:1b00:10:a::1 next-hop-self

 address-family ipv6
 network 2607:1b00:d1::/48
 network 2607:1b00:d2::/48
 neighbor 2607:1b00:10:a::1 activate
 exit-address-family






Was wondering if someone can point in me right direction since both of
these prefixes are (annnounced and ?) withdrawn as soon as I restart Quagga.





Thanks.

-- 

Anurag Bhatia
Web: anuragbhatia.com
Skype: anuragbhatia.com

Linkedin  |
Twitter|
Google+