Re: local_preference for transit traffic?

[Jeff Wheeler]

On Thu, Dec 15, 2011 at 2:24 AM, Keegan Holley
 wrote:
> I always assumed that taking in more traffic was a bad thing.  I've heard
> about one sided peering agreements where one side is sending more traffic
> than the other needs them to transport. Am I missing something?  Would this
> cause a shift in their favor allowing them to offload more customer traffic
> to their peers without complaint?

Well, if Level3 wanted less ingress traffic, they would probably stop
this practice.  I would imagine they thought about it carefully.

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

Re: De-bogon not possible via arin policy.

[Jared Mauch]

I'm also aware of at least one network that has consumed all private address 
space, perhaps even including the testing /15 as well. 

If you are using a /8 /12 and /16 in total, ones future life could be very 
interesting. Almost makes the case for v6 easier at their site. I'm hoping we 
see 2012 as the date of broadband v6 becoming commonly available in the states 
at least. 

Jared Mauch

On Dec 15, 2011, at 8:14, Jimmy Hess  wrote:

> 
> That would essentially provide a backdoor around normal RIR justified
> need policy, if it were allowed..

Re: local_preference for transit traffic?

[Keegan Holley]

 I always assumed that taking in more traffic was a bad thing.  I've heard
about one sided peering agreements where one side is sending more traffic
than the other needs them to transport. Am I missing something?  Would this
cause a shift in their favor allowing them to offload more customer traffic
to their peers without complaint?

2011/12/15 Jeff Wheeler 

> On Thu, Dec 15, 2011 at 1:07 AM, Keegan Holley
>  wrote:
> > Had in interesting conversation with a transit AS on behalf of a customer
> > where I found out they are using communities to raise the local
> preference
>
> That sounds like a disreputable practice.
>
> While not quite as obvious, some large transit ASes, like Level3,
> reset the origin to I (best) sometime between when they learn it and
> when they announce it to their customers and peers.  This similarly
> causes them to suck in a bit more traffic than they might otherwise.
>
> --
> Jeff S Wheeler 
> Sr Network Operator  /  Innovative Network Concepts
>
>
>

Re: De-bogon not possible via arin policy.

[Jimmy Hess]

On Wed, Dec 14, 2011 at 10:47 PM, David Conrad  wrote:
[snip]
> I'm confused. When justifying 'need' in an address allocation request, what 
> difference does it make >whether an address in use was allocated by an RIR or 
> was squatted upon?  Last I heard, renumbering >out of (say) RFC 1918 space 
> into public space was still a justification for address space.  Has this 
> >changed?

It is a potential network change that could require additional address
space, if an operator plans a complete and immediate renumbering,  but
the choice to renumber is not an automatic justification for the same
number of  non-RFC1918 IPs   as the count of IPs available in their
RFC1918 space networks.
I'm sure the RIRs are not allowing that.

A RFC1918 network is not a "normal" network; and this is not a
renumbering in the same manner as a renumbering from public IP space
to new public IP space.




The operator might have to show why they shouldn't renumber their 1918
network partially, over time,  in a manner compatible with the RIR
policy for initial service provider allocations, instead of all at
once.

In other words:   What is the technical justification that all those
rfc1918  addressed hosts suddenly need to be moved  immediately,   and
 not over a normal allocation time frame for new public networks?


When building the rfc1918 network originally, the architect did not
need to follow RFC 2050,  RFC3194, etc,  so it is quite possible that
the 1918 network does not efficiently utilize IP addresses.

That means the RIR has to establish that the criterion is good enough.
"I have a rfc1918 /16 that I use,  so give me a public /16, please"
is not good enough.


That would essentially provide a backdoor around normal RIR justified
need policy, if it were allowed..

--
-JH

Re: local_preference for transit traffic?

[Jeff Wheeler]

On Thu, Dec 15, 2011 at 1:07 AM, Keegan Holley
 wrote:
> Had in interesting conversation with a transit AS on behalf of a customer
> where I found out they are using communities to raise the local preference

That sounds like a disreputable practice.

While not quite as obvious, some large transit ASes, like Level3,
reset the origin to I (best) sometime between when they learn it and
when they announce it to their customers and peers.  This similarly
causes them to suck in a bit more traffic than they might otherwise.

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

Re: local_preference for transit traffic?

[Keegan Holley]

I suppose so because prepend is so easily defeated, but sometimes you don't
own a prefix shorter than the one you need to advertise.  Assuming I
understand your suggestion correctly.

2011/12/15 Holmes,David A 

> For this very reason I have advocated using longest prefix BGP routing for
> some years now, and checking periodically for the expected path, as it
> became obvious from investigating traceroutes that traffic was not being
> routed as intended using AS prepends.
>
> -Original Message-
> From: Keegan Holley [mailto:keegan.hol...@sungard.com]
> Sent: Wednesday, December 14, 2011 10:08 PM
> To: NANOG
> Subject: local_preference for transit traffic?
>
> Had in interesting conversation with a transit AS on behalf of a customer
> where I found out they are using communities to raise the local preference
> of routes that do not originate locally by default before sending to a
> other larger transit AS's.  Obviously this isn't something that was asked
> of them and it took a few days to find since the customer is not a large
> company and neither them nor my company has a link or business relationship
> with the AS in question.  This seemed strange to me for obvious reasons,
> but I was curious if anyone else was doing this and why.  You obviously
> cannot use prepend to affect transit traffic again for obvious reasons.
> MED is a weak metric but it at least only affects traffic that was already
> going to transit your AS.  The larger transit AS was favoring a lower
> bandwidth link for the customer and causing them to drop packets
> mysteriously.  Just wondering if this practice seemed as strange to others
> as it does to me.
>
> 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 you are not the intended
> recipient, you are hereby notified that any review, disclosure, copying,
> dissemination, distribution or use of this communication is strictly
> prohibited. If you have received this communication in error, please notify
> the sender immediately by return e-mail message and delete the original and
> all copies of the communication, along with any attachments or embedded
> links, from your system.
>
>

RE: local_preference for transit traffic?

[Holmes,David A]

For this very reason I have advocated using longest prefix BGP routing for some 
years now, and checking periodically for the expected path, as it became 
obvious from investigating traceroutes that traffic was not being routed as 
intended using AS prepends.

-Original Message-
From: Keegan Holley [mailto:keegan.hol...@sungard.com]
Sent: Wednesday, December 14, 2011 10:08 PM
To: NANOG
Subject: local_preference for transit traffic?

Had in interesting conversation with a transit AS on behalf of a customer
where I found out they are using communities to raise the local preference
of routes that do not originate locally by default before sending to a
other larger transit AS's.  Obviously this isn't something that was asked
of them and it took a few days to find since the customer is not a large
company and neither them nor my company has a link or business relationship
with the AS in question.  This seemed strange to me for obvious reasons,
but I was curious if anyone else was doing this and why.  You obviously
cannot use prepend to affect transit traffic again for obvious reasons.
MED is a weak metric but it at least only affects traffic that was already
going to transit your AS.  The larger transit AS was favoring a lower
bandwidth link for the customer and causing them to drop packets
mysteriously.  Just wondering if this practice seemed as strange to others
as it does to me.

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 you are not the intended recipient, you 
are hereby notified that any review, disclosure, copying, dissemination, 
distribution or use of this communication is strictly prohibited. If you have 
received this communication in error, please notify the sender immediately by 
return e-mail message and delete the original and all copies of the 
communication, along with any attachments or embedded links, from your system.

Re: /128 IPv6 prefixs in the wild?

[Mark Tinka]

On Thursday, December 15, 2011 01:54:56 PM Glen Kent wrote:

> In an IP/MPLS world, core routers in the service provider
> network learn the /32 loopback IPv4 addresses so that
> they can establish BGP/Targetted LDP sessions with
> those.

That's right - not sure how things would have been if 
'draft-swallow-mpls-aggregate-fec-01' had gained some 
traction.

> They then establish LSPs and VPN tunnels.

Indeed.

> Since
> we dont have RSVP for IPv6 and LDP for IPv6 (not yet
> RFC) we cannot form MPLS tunnels in a pure IPv6 only
> network. GIven this, would v6 routers have large number
> of /128 prefixes?
> 
> What are the scenarios when IPv6 routers would learn a
> large number of /128 prefixes?

I suspect ISP's that choose to assign broadband customers 
/128 addresses because "they only ever need one address" may 
be a situation where you see rise given to this.

> I would presume that most IPv6 prefixes that the routers
> have to install are less than /64, since the latter 64
> is the host part. Is this correct?

This is certainly going to re-open some "wounds", but no, 
not all providers are assigning /64 to interfaces. Some 
(like us) are using longer prefix lengths such as /112 and 
/126.

But as for /128 prefix lengths, aside from the fact that 
Loopbacks will be floating around the network, whether 
you're using them to signal MPLS LSP's or setup iBGP 
sessions, you will see them with ISP's that assign them to 
customers and choose not to aggregate them at specific edge 
routers.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.

local_preference for transit traffic?

[Keegan Holley]

Had in interesting conversation with a transit AS on behalf of a customer
where I found out they are using communities to raise the local preference
of routes that do not originate locally by default before sending to a
other larger transit AS's.  Obviously this isn't something that was asked
of them and it took a few days to find since the customer is not a large
company and neither them nor my company has a link or business relationship
with the AS in question.  This seemed strange to me for obvious reasons,
but I was curious if anyone else was doing this and why.  You obviously
cannot use prepend to affect transit traffic again for obvious reasons.
MED is a weak metric but it at least only affects traffic that was already
going to transit your AS.  The larger transit AS was favoring a lower
bandwidth link for the customer and causing them to drop packets
mysteriously.  Just wondering if this practice seemed as strange to others
as it does to me.

/128 IPv6 prefixs in the wild?

[Glen Kent]

Hi,

In the service provider networks, would we usually see a large number
of /128 prefixs in the v6 FIB tables?

In an IP/MPLS world, core routers in the service provider network
learn the /32 loopback IPv4 addresses so that they can establish
BGP/Targetted LDP sessions with those. They then establish LSPs and
VPN tunnels. Since we dont have RSVP for IPv6 and LDP for IPv6 (not
yet RFC) we cannot form MPLS tunnels in a pure IPv6 only network.
GIven this, would v6 routers have large number of /128 prefixes?

What are the scenarios when IPv6 routers would learn a large number of
/128 prefixes?

I would presume that most IPv6 prefixes that the routers have to
install are less than /64, since the latter 64 is the host part. Is
this correct?

Glen

Re: De-bogon not possible via arin policy.

[David Conrad]

On Dec 14, 2011, at 6:46 PM, Jimmy Hess wrote
> Wait...  you had started using bogon addresses /  "squatted" space not
> allocated  and claimed the number of IP addresses your network is using that 
> were not
> allocated by a RIR settles the need justification question?

I'm confused. When justifying 'need' in an address allocation request, what 
difference does it make whether an address in use was allocated by an RIR or 
was squatted upon?  Last I heard, renumbering out of (say) RFC 1918 space into 
public space was still a justification for address space.  Has this changed?

> You need to have all the documentation to show the actual justified
> technical need for the IPs you request,  such as what each specific
> address is used for.

Perhaps I'm naive, but I tend to give folks like Cameron the benefit of the 
doubt when it comes to dealing with IP address allocation requests and assume 
he provided a bit more information than what you're suggesting.  I find the 
suggestions by other posters that he look at IPv6 particularly amusing.

Unfortunately, regardless of the specifics of Cameron's case, the reality is 
that the traditional model of address allocation (i.e., "to each according to 
need" to quote a 19th century philosopher) is rapidly coming to a close.  I 
expect there will be many more situations like Cameron's in the future.

Regards,
-drc

Re: De-bogon not possible via arin policy.

[Joel jaeggli]

On 12/14/11 18:46 , Jimmy Hess wrote:
> On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne  wrote:
>> Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I
>> own ~100k ipv4 addresses today.
>> My customers use over 10 million bogon / squat space ip addresses today,
>> and I have good attested data on that.
> 
> Wait...  you had started using bogon addresses /  "squatted" space not
> allocated  and claimed
> the number of IP addresses your network is using that were not
> allocated by a RIR
> settles the need justification question?

Anyone who has used their network  in the last decade that actually
bother to look at their assigned ip address knows this.

>> Any suggestions on how to navigate this policy ?
> 
> Work with ARIN to provide a satisfactory need justification for the
> entire allocation you are requesting.
> A mere count of the number of IP addresses you are currently using is
> not a need justification.

The wikipedia page shows something on the order of 34 million customers.
I don't expect they all need an ip at the same time.

> There has to be a technical reason that each IP address is required.
> 
> "I'm making IANA-unsanctioned use of 10^9 bogon IP addresses,  please
> allocate me 10^9 proper IP addresses, so I can  have matching
> allocated IP space with global recognition instead";  just doesn't cut
> it.
> 
> You need to have all the documentation to show the actual justified
> technical need for the IPs you request,  such as what each specific
> address is used for.
> 
> 
> Regards,
> --
> -JH
> 

Re: Range using single-mode SFPs across multi-mode fiber

[Keegan Holley]

I stand corrected, but I haven't dealt much with 100BASE-FX.  I was just
talking in terms of 1G/10G.


2011/12/14 Mark Foster 

>  On 15/12/11 16:38, Keegan Holley wrote:
>
> 2011/12/14 oliver rothschild  
>
>  Thanks to all who responded to my clumsy first question (both on
> matters of etiquette and technology). The group I work with (we are a
> small project acting as a last mile provider) was in the midst of
> deploying this solution when I posed the question. We put the single
> mode Juniper SFPs (LX) on to a run of approximately 1670 meters.
>
>
>  How did you end up with a MM run this long?  SX optics are only rated at
> 500 meters at best.  Even with mode conditioning jumpers more the 1km is a
> risk.  I'm glad it held up during testing though.  Just out of curiosity
> did you purchase dark from a provider?  Is it inside of a building?
>
>
> Um.. check that.
>
> https://en.wikipedia.org/wiki/Multi-mode_optical_fiber
>
> "Typical transmission speed and distance limits are 100 Mbit/s for
> distances up to 2 km (100BASE-FX),
> 1 Gbit/s to 220–550 m 
> (1000BASE-SX),
> and 10 Gbit/s to 300 m 
> (10GBASE-SR
> )."
>
> The old OM1 installations I used to work on started out as 10Mbit hubbed
> ethernet links and on the odd occasion would run out to close to 2km within
> a campus.  They were progressively upgraded with the flow of:
>
> 10FX on 3Com Linkbuilder Kit
> 100FX on 3Com Corebuilder Kit and Allied Telesyn 100FX Media converters
> 1000SX on a variety of 3Com, Nortel and Cisco kit out to ~220m
> 1000LX via Mode-Conditioning out to ~900-1000m.
>
> The OM1 only got retired when the distance was >900m or there was budget
> to put new fibre on the run, in which case we ran SMF and rigged LX drivers.
>
> Mark.
>
>
>
>
>

Re: Range using single-mode SFPs across multi-mode fiber

[Chuck Anderson]

On Wed, Dec 14, 2011 at 10:38:47PM -0500, Keegan Holley wrote:
> 2011/12/14 oliver rothschild 
> 
> > Thanks to all who responded to my clumsy first question (both on
> > matters of etiquette and technology). The group I work with (we are a
> > small project acting as a last mile provider) was in the midst of
> > deploying this solution when I posed the question. We put the single
> > mode Juniper SFPs (LX) on to a run of approximately 1670 meters.
> >
> 
> How did you end up with a MM run this long?  SX optics are only rated at
> 500 meters at best.  Even with mode conditioning jumpers more the 1km is a
> risk.  I'm glad it held up during testing though.  Just out of curiosity
> did you purchase dark from a provider?  Is it inside of a building?

In my case, it was installed for compatibility with FDDI, and used
mostly for 10BASE-FL and 100BASE-FX, which work up to 1 or 2km, until
we started using it for 1000BASE-LX.

Re: Range using single-mode SFPs across multi-mode fiber

[Mark Foster]

On 15/12/11 16:38, Keegan Holley wrote:
> 2011/12/14 oliver rothschild 
>
>> Thanks to all who responded to my clumsy first question (both on
>> matters of etiquette and technology). The group I work with (we are a
>> small project acting as a last mile provider) was in the midst of
>> deploying this solution when I posed the question. We put the single
>> mode Juniper SFPs (LX) on to a run of approximately 1670 meters.
>>
> How did you end up with a MM run this long?  SX optics are only rated at
> 500 meters at best.  Even with mode conditioning jumpers more the 1km is a
> risk.  I'm glad it held up during testing though.  Just out of curiosity
> did you purchase dark from a provider?  Is it inside of a building?

Um.. check that.

https://en.wikipedia.org/wiki/Multi-mode_optical_fiber

"Typical transmission speed and distance limits are 100 Mbit/s for
distances up to 2 km (100BASE-FX
), 1 Gbit/s to 220--550 m
(1000BASE-SX ), and 10 Gbit/s
to 300 m (10GBASE-SR
)."

The old OM1 installations I used to work on started out as 10Mbit hubbed
ethernet links and on the odd occasion would run out to close to 2km
within a campus.  They were progressively upgraded with the flow of:

10FX on 3Com Linkbuilder Kit
100FX on 3Com Corebuilder Kit and Allied Telesyn 100FX Media converters
1000SX on a variety of 3Com, Nortel and Cisco kit out to ~220m
1000LX via Mode-Conditioning out to ~900-1000m.

The OM1 only got retired when the distance was >900m or there was budget
to put new fibre on the run, in which case we ran SMF and rigged LX drivers.

Mark.

Re: Range using single-mode SFPs across multi-mode fiber

[Keegan Holley]

2011/12/14 oliver rothschild 

> Thanks to all who responded to my clumsy first question (both on
> matters of etiquette and technology). The group I work with (we are a
> small project acting as a last mile provider) was in the midst of
> deploying this solution when I posed the question. We put the single
> mode Juniper SFPs (LX) on to a run of approximately 1670 meters.
>

How did you end up with a MM run this long?  SX optics are only rated at
500 meters at best.  Even with mode conditioning jumpers more the 1km is a
risk.  I'm glad it held up during testing though.  Just out of curiosity
did you purchase dark from a provider?  Is it inside of a building?

Re: Range using single-mode SFPs across multi-mode fiber

[Chuck Anderson]

On Wed, Dec 14, 2011 at 10:02:58PM -0500, oliver rothschild wrote:
> Thanks to all who responded to my clumsy first question (both on
> matters of etiquette and technology). The group I work with (we are a
> small project acting as a last mile provider) was in the midst of
> deploying this solution when I posed the question. We put the single
> mode Juniper SFPs (LX) on to a run of approximately 1670 meters. We
> successfully established a 1G ethernet connection. Testing to date has
> been meager, but shows that the link is viable. Under significant load
> there is some minor packet loss. Since the link far exceeds the amount
> of data it required, we have decided to continue using it.
> Interestingly neither interface showed any physical errors.

Technically you should be using offset-launch "mode conditioning"
patch cords at each end when running LX over multimode fiber.  I had
been lucky with not using them for many years on 62.5/125 (OM1)
multimode (and just started doing so again, albiet only for
OOB/non-production traffic use).  I believe my longest link was/is
around 1 km.

http://www.cisco.com/en/US/prod/collateral/modules/ps5455/white_paper_c11-463677.html

Range using single-mode SFPs across multi-mode fiber

[oliver rothschild]

Thanks to all who responded to my clumsy first question (both on
matters of etiquette and technology). The group I work with (we are a
small project acting as a last mile provider) was in the midst of
deploying this solution when I posed the question. We put the single
mode Juniper SFPs (LX) on to a run of approximately 1670 meters. We
successfully established a 1G ethernet connection. Testing to date has
been meager, but shows that the link is viable. Under significant load
there is some minor packet loss. Since the link far exceeds the amount
of data it required, we have decided to continue using it.
Interestingly neither interface showed any physical errors.

v/r,
Oliver Rothschild
Network Engineer III

Re: De-bogon not possible via arin policy.

[Jimmy Hess]

On Wed, Dec 14, 2011 at 3:15 PM, Cameron Byrne  wrote:
> Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I
> own ~100k ipv4 addresses today.
> My customers use over 10 million bogon / squat space ip addresses today,
> and I have good attested data on that.

Wait...  you had started using bogon addresses /  "squatted" space not
allocated  and claimed
the number of IP addresses your network is using that were not
allocated by a RIR
settles the need justification question?

> Any suggestions on how to navigate this policy ?

Work with ARIN to provide a satisfactory need justification for the
entire allocation you are requesting.
A mere count of the number of IP addresses you are currently using is
not a need justification.

There has to be a technical reason that each IP address is required.

"I'm making IANA-unsanctioned use of 10^9 bogon IP addresses,  please
allocate me 10^9 proper IP addresses, so I can  have matching
allocated IP space with global recognition instead";  just doesn't cut
it.

You need to have all the documentation to show the actual justified
technical need for the IPs you request,  such as what each specific
address is used for.


Regards,
--
-JH

Re: De-bogon not possible via arin policy.

[Jeff Wheeler]

On Wed, Dec 14, 2011 at 4:15 PM, Cameron Byrne  wrote:
> Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I
> own ~100k ipv4 addresses today.
>
> My customers use over 10 million bogon / squat space ip addresses today,
> and I have good attested data on that.

Cameron,

I have a client who went through the same problem in early-2011.  They
had several thousand residential and small business end-users behind
NAT and wished to provision public IP addresses for them.  They
assumed ARIN would be pleased to issue an appropriate block for their
project.  David Huberman rejected their request outright and told them
to request provider space, renumber the customers to provider IPs, and
then apply to ARIN again and renumber their network a second time.
The client did not bother to involve me until after they had already
been told to FOAD.

This is clearly a counter-productive waste of time, but if the client
had applied using the immediate need process, and provided the
additional supporting documentation required by that, I think they
would not have had this problem.  The analyst you worked with should
have suggested a different application procedure or otherwise worked
with you to facilitate your request.  Sometimes the ARIN staff are
nice and helpful, sometimes they are not.  It depends on who you get
assigned to, price of tea in china, phase of the moon, etc.

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

Re: Time Warner Routing Issue

[Courtney Smith]

On Dec 14, 2011, at 4:09 PM, nanog-requ...@nanog.org wrote:

> 
> Message: 3
> Date: Wed, 14 Dec 2011 15:46:52 -0500
> From: Brian Christopher Raaen 
> To: nanog@nanog.org
> Subject: Time Warner Routing Issue
> Message-ID:
>   
> Content-Type: text/plain; charset=ISO-8859-1
> 
>  They said the reason was they didn't
> have an LOA (which they had gotten back in October) and the ip blocks were
> not in the Level3 Radb list.  I could still see announcement to some peers
> (Shaw Cable in Canada) in a few looking glasses and BGP routers.  However
> my network blocks were not showing for the larger US carriers like Qwest
> and AT&T.  One of their techs just called me back and said that Level3
> should be advertising it, but I still do not see the routes on the AT&T
> route server.  After noting that the tech said that it may take another day
> for BGP to "propagate" to other peers as they update their radb tables.  In
> my experience I've never seen anything where I had to wait for a route to
> propagate other than standard routing table updates which usually take less
> then an hour, and I'd really not expect this many problems between Tier1
> and Tier2 providers.  I need to know if this matches other's experience and
> wanting to know what other people were seeing with traceroutes and "show ip
> bgp".  The networks in question at the following 4 /24's
> 
> 68.68.176.0/24
> 68.68.177.0/24
> 68.68.178.0/24
> 68.68.179.0/24
> 
> the serial ip address is 72.43.84.254
> 
> Thanks for your assistance.
> 
> ---
> Brian Raaen
> Zcorum
> Network Architect
> 

I believe the TWC tech is referring to prefix filter updates and not routing 
table updates.  Some of TWC's peers most likely use IRR based filters on their 
BGP sessions.  Most networks only check once a day for IRR changes and apply 
those changes to filters.  It looks TWC put in proxy route objects today for 
your blocks so I am guessing someone at TWC forgot to make the updates in 
advance.   Work around is for them to reach out to the peers with IRR based 
filters and request a manual update.   Sounds like that is what they are doing.

route:  68.68.176.0/24
descr:  RR-RC-Princetown Cable Company, Inc.-Albany
origin: AS11351
notify: ipadd...@rr.com
mnt-by: MAINT-RR
changed:ipadd...@rr.com 20111214
source: RADB
route:  68.68.177.0/24
descr:  RR-RC-Princetown Cable Company, Inc.-Albany
origin: AS11351
notify: ipadd...@rr.com
mnt-by: MAINT-RR
changed:ipadd...@rr.com 20111214
source: RADB

Run the below on 12/15 and it should return your blocks.
$ whois -h filtergen.level3.net radb::as11351 | grep 68.6
$ 




Courtney Smith
courtneysm...@comcast.net

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Re: Time Warner Routing Issue

[Brian Christopher Raaen]

Thank you everyone for your assistance.  Either having a tech spot my
post and make the change or me calling their bluff got them to fix it.
Thanks

---
Brian Raaen
Zcorum
Network Architect


On Wed, Dec 14, 2011 at 3:46 PM, Brian Christopher Raaen
 wrote:
> I have a Time Warner circuit that has been giving me issues and what their
> tech support has been telling me has not matched my previous experience
> with other backbones.  I have been trying to move the backbone on one site
> from a tier-3 provider to Time Warner.  Yesterday TW started advertising
> BGP for the ip blocks I have (68.68.176.0/22 in /24's) before they had the
> circuit completed, so I had to make an emergency mid-day switch to move to
> Time Warner.  Then yesterday night they stopped announcing my blocks so my
> site went down again and would still be completely down if we had not added
> NAT to the /30 point-to-point link.  They said the reason was they didn't
> have an LOA (which they had gotten back in October) and the ip blocks were
> not in the Level3 Radb list.  I could still see announcement to some peers
> (Shaw Cable in Canada) in a few looking glasses and BGP routers.  However
> my network blocks were not showing for the larger US carriers like Qwest
> and AT&T.  One of their techs just called me back and said that Level3
> should be advertising it, but I still do not see the routes on the AT&T
> route server.  After noting that the tech said that it may take another day
> for BGP to "propagate" to other peers as they update their radb tables.  In
> my experience I've never seen anything where I had to wait for a route to
> propagate other than standard routing table updates which usually take less
> then an hour, and I'd really not expect this many problems between Tier1
> and Tier2 providers.  I need to know if this matches other's experience and
> wanting to know what other people were seeing with traceroutes and "show ip
> bgp".  The networks in question at the following 4 /24's
>
> 68.68.176.0/24
> 68.68.177.0/24
> 68.68.178.0/24
> 68.68.179.0/24
>
> the serial ip address is 72.43.84.254
>
> Thanks for your assistance.
>
> ---
> Brian Raaen
> Zcorum
> Network Architect

Re: De-bogon not possible via arin policy.

[David Conrad]

On Dec 14, 2011, at 1:15 PM, Cameron Byrne wrote:
> Just fyi, de-bogoning , or private rfc 1918 is not really an option even
> with strong and consistent demonstrate load.
> 
> Any suggestions on how to navigate this policy ?


Given unmet demand, I'd think the solution would be fairly obvious (albeit 
likely quite expensive with the going rate being around $12/address). I'd guess 
some of the folks who would be more than happy to help you (in exchange for a 
transaction fee of course) will contact you in the near future (if they haven't 
already). 

Regards,
-drc

Re: Time Warner Routing Issue

[Grant Ridder]

Hi Brian,

My school has 2x TW circuits.  Tracing to 68.68.176.1 shows that it doesn't
leave TW's network.  In Chris's previous email, the origion is AS 11351 which
is Road Runner (now owned by TW).  It gets to Albany, NY then dies.


C:\Users\ridderg>tracert 68.68.176.1

Tracing route to gw.princetowncable.com [68.68.176.1]
over a maximum of 30 hops:

  1<1 ms 1 ms<1 ms  155.92.105.254
  2 1 ms 1 ms 1 ms  155.92.10.17
  3 2 ms 1 ms 1 ms  155.92.10.1
  4 3 ms 1 ms 8 ms  155.92.10.130
  5 2 ms 1 ms 2 ms
207-250-86-49.static.twtelecom.net[207.250.86.49]
  6 4 ms 4 ms 4 ms
chi2-pr1-xe-2-3-0-0.us.twtelecom.net[66.192.250.154]
  749 ms 5 ms 4 ms  ae-1-0.cr0.chi10.tbone.rr.com [66.109.6.152]
  818 ms19 ms18 ms  66.109.6.73
  932 ms31 ms31 ms  ae1-0.glflnyaq-rtr000.nyroc.rr.com[24.24.21.213]
 1031 ms31 ms33 ms
rdc-74-76-241-191.alb.northeast.rr.com[74.76.241.191]
 11 *** Request timed out.
 12 *** Request timed out.
 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.

-Grant


On Wed, Dec 14, 2011 at 3:23 PM, Chris Stone  wrote:

> Brian,
>
> > wanting to know what other people were seeing with traceroutes and "show
> ip
> > bgp".  The networks in question at the following 4 /24's
> >
> > 68.68.176.0/24
> > 68.68.177.0/24
> > 68.68.178.0/24
> > 68.68.179.0/24
>
> Here's what I'm seeing on our L3 connection here in Denver, CO::
>
> route1:~$ show ip bgp | egrep '68.68.17[6-9]'
> *> 68.68.176.0/24   4.79.81.221  0 0 3356 7843
> 11351 i
> *> 68.68.177.0/24   4.79.81.221  0 0 3356 7843
> 11351 i
> *> 68.68.178.0/24   4.79.81.221  0 0 3356 7843
> 11351 i
> *> 68.68.179.0/24   4.79.81.221  0 0 3356 7843
> 11351 i
>
> traceroute to 68.68.176.1 (68.68.176.1), 30 hops max, 60 byte packets
>  1  4.79.81.221  0.348 ms  0.343 ms  0.339 ms
>  2  4.69.147.94  0.310 ms  0.316 ms  0.337 ms
>  3  4.69.132.106  16.486 ms  21.091 ms  16.440 ms
>  4  4.69.151.165  14.695 ms  14.709 ms 4.69.151.129  22.556 ms
>  5  4.69.145.144  14.874 ms  14.890 ms 4.69.145.80  14.951 ms
>  6  4.28.152.110  14.697 ms  14.806 ms 4.59.32.18  16.736 ms
>  7  66.109.9.104  14.579 ms 66.109.6.208  14.686 ms  14.478 ms
>  8  66.109.9.40  30.662 ms 66.109.6.23  30.592 ms  30.638 ms
>  9  66.109.6.20  30.420 ms  30.595 ms  30.582 ms
> 10  66.109.6.73  44.523 ms  44.460 ms  44.498 ms
> 11  24.24.21.213  57.437 ms  57.642 ms  57.626 ms
> 12  74.76.241.191  57.340 ms  57.495 ms  57.388 ms
> 13  74.76.241.181  57.478 ms  57.450 ms  57.766 ms
> 14  * * *
> 15  * * *
> 16  * * *
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 30  * * *
>
> traceroute to 68.68.179.1 (68.68.179.1), 30 hops max, 60 byte packets
>  1  4.79.81.221  0.421 ms  0.429 ms  0.430 ms
>  2  4.69.147.94  0.384 ms  0.402 ms  0.404 ms
>  3  4.69.132.106  14.763 ms  14.725 ms  14.750 ms
>  4  4.69.151.141  14.817 ms  14.787 ms 4.69.151.165  14.687 ms
>  5  4.69.145.80  62.893 ms 4.69.145.208  14.992 ms 4.69.145.144  14.975 ms
>  6  4.28.152.110  14.994 ms  14.808 ms  14.805 ms
>  7  66.109.6.208  14.659 ms  14.658 ms  14.589 ms
>  8  66.109.6.23  30.599 ms  30.774 ms  30.725 ms
>  9  66.109.6.20  30.509 ms  30.713 ms  30.718 ms
> 10  66.109.6.73  44.476 ms 107.14.19.29  44.468 ms *
> 11  24.24.21.213  57.657 ms  57.583 ms  57.567 ms
> 12  74.76.241.191  57.356 ms  57.227 ms  57.183 ms
> 13  74.76.241.181  58.266 ms  57.402 ms  57.452 ms
> 14  * * *
> 15  * * *
> 16  * * *
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
> 28  * * *
> 29  * * *
> 30  * * *
>
>
> Chris
>
>

Re: De-bogon not possible via arin policy.

[Robert E. Seastrom]

What do you mean by "de-bogon"?  Do you mean that your customers'
addresses are listed in various RBLs for previous misbehavior?  That
they are using addresses that were never properly allocated to them?
Something different?

You don't "own" IPv4 addresses; they are assigned or allocated to you
in response to demonstrated need.

ARIN takes into account your history of needing IP address space when
evaluating your request for more address space to be assigned or
allocated to you.  If you have not been back to ARIN for address space
recently (or ever, if these are legacy addresses), you may find
yourself subject to slow start just like a newly established entity.

It does not sound as if ARIN rejected you for an IPv4 allocation.
>From your statement below, it sounds as if ARIN approved you for a
/18, which is reasonable and in accordance with current policies.  If
you walked in to ARIN and asked them for 10 million IPv4 addresses
(which is on the order of 1/8 of the total that ARIN has on hand, for
everyone), it is unsurprising that they declined.

If you can clarify the problem, it's possible the community may be
able to offer assistance.

-r

PS: I'm on the ARIN Advisory Council, which means that I help with
policy creation.  Neither I nor my 14 colleagues on the AC are
employees; staff won't discuss particular cases, etc.  So if you want
us to know something, you'll have to state it here or in private email
or something.

Cameron Byrne  writes:

> Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I
> own ~100k ipv4 addresses today.
>
> My customers use over 10 million bogon / squat space ip addresses today,
> and I have good attested data on that.
>
> But all I can qualify for is a /18, and then in 3 months maybe a /17. This
> is called slow start ? For an established business?
>
> Just fyi, de-bogoning , or private rfc 1918 is not really an option even
> with strong and consistent demonstrate load.
>
> Any suggestions on how to navigate this policy ?

Re: De-bogon not possible via arin policy.

[Andrew D Kirch]

On 12/14/2011 4:20 PM, Rubens Kuhl wrote:

You should easily qualify for a /32 or larger IPv6 block.
And it's curious that errors that are likely to be there for decades
are just now trying to be fixed as IPv4 pool is depleted, isn't it ?


His users can also switch to DECNET and reach about as many internet 
sites as they would with IPv6.  Ooh well, internet's dieing, lets pack 
up our routers and go home.  Randy Bush will turn out the lights for us.


Andrew

Re: Time Warner Routing Issue

[Chris Stone]

Brian,

> wanting to know what other people were seeing with traceroutes and "show ip
> bgp".  The networks in question at the following 4 /24's
>
> 68.68.176.0/24
> 68.68.177.0/24
> 68.68.178.0/24
> 68.68.179.0/24

Here's what I'm seeing on our L3 connection here in Denver, CO::

route1:~$ show ip bgp | egrep '68.68.17[6-9]'
*> 68.68.176.0/24   4.79.81.221  0 0 3356 7843 11351 i
*> 68.68.177.0/24   4.79.81.221  0 0 3356 7843 11351 i
*> 68.68.178.0/24   4.79.81.221  0 0 3356 7843 11351 i
*> 68.68.179.0/24   4.79.81.221  0 0 3356 7843 11351 i

traceroute to 68.68.176.1 (68.68.176.1), 30 hops max, 60 byte packets
 1  4.79.81.221  0.348 ms  0.343 ms  0.339 ms
 2  4.69.147.94  0.310 ms  0.316 ms  0.337 ms
 3  4.69.132.106  16.486 ms  21.091 ms  16.440 ms
 4  4.69.151.165  14.695 ms  14.709 ms 4.69.151.129  22.556 ms
 5  4.69.145.144  14.874 ms  14.890 ms 4.69.145.80  14.951 ms
 6  4.28.152.110  14.697 ms  14.806 ms 4.59.32.18  16.736 ms
 7  66.109.9.104  14.579 ms 66.109.6.208  14.686 ms  14.478 ms
 8  66.109.9.40  30.662 ms 66.109.6.23  30.592 ms  30.638 ms
 9  66.109.6.20  30.420 ms  30.595 ms  30.582 ms
10  66.109.6.73  44.523 ms  44.460 ms  44.498 ms
11  24.24.21.213  57.437 ms  57.642 ms  57.626 ms
12  74.76.241.191  57.340 ms  57.495 ms  57.388 ms
13  74.76.241.181  57.478 ms  57.450 ms  57.766 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

traceroute to 68.68.179.1 (68.68.179.1), 30 hops max, 60 byte packets
 1  4.79.81.221  0.421 ms  0.429 ms  0.430 ms
 2  4.69.147.94  0.384 ms  0.402 ms  0.404 ms
 3  4.69.132.106  14.763 ms  14.725 ms  14.750 ms
 4  4.69.151.141  14.817 ms  14.787 ms 4.69.151.165  14.687 ms
 5  4.69.145.80  62.893 ms 4.69.145.208  14.992 ms 4.69.145.144  14.975 ms
 6  4.28.152.110  14.994 ms  14.808 ms  14.805 ms
 7  66.109.6.208  14.659 ms  14.658 ms  14.589 ms
 8  66.109.6.23  30.599 ms  30.774 ms  30.725 ms
 9  66.109.6.20  30.509 ms  30.713 ms  30.718 ms
10  66.109.6.73  44.476 ms 107.14.19.29  44.468 ms *
11  24.24.21.213  57.657 ms  57.583 ms  57.567 ms
12  74.76.241.191  57.356 ms  57.227 ms  57.183 ms
13  74.76.241.181  58.266 ms  57.402 ms  57.452 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


Chris

Re: De-bogon not possible via arin policy.

[Rubens Kuhl]

> Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I
> own ~100k ipv4 addresses today.>
> My customers use over 10 million bogon / squat space ip addresses today,
> and I have good attested data on that.
> But all I can qualify for is a /18, and then in 3 months maybe a /17. This
> is called slow start ? For an established business?
> Just fyi, de-bogoning , or private rfc 1918 is not really an option even
> with strong and consistent demonstrate load.
>
> Any suggestions on how to navigate this policy ?

You should easily qualify for a /32 or larger IPv6 block.
And it's curious that errors that are likely to be there for decades
are just now trying to be fixed as IPv4 pool is depleted, isn't it ?


Rubens

De-bogon not possible via arin policy.

[Cameron Byrne]

Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I
own ~100k ipv4 addresses today.

My customers use over 10 million bogon / squat space ip addresses today,
and I have good attested data on that.

But all I can qualify for is a /18, and then in 3 months maybe a /17. This
is called slow start ? For an established business?

Just fyi, de-bogoning , or private rfc 1918 is not really an option even
with strong and consistent demonstrate load.

Any suggestions on how to navigate this policy ?

Re: Time Warner Routing Issue

[Scott Weeks]

: Yesterday TW started advertising BGP for the ip blocks I have 
: (68.68.176.0/22 in /24's) before they had the circuit completed

How did they get the routes into their table if the ckt was not up and 
you were not advertising the routes to them?  Did they also announce 
the covering prefix?


scott




--- mailing-li...@brianraaen.com wrote:

From: Brian Christopher Raaen 
To: nanog@nanog.org
Subject: Time Warner Routing Issue
Date: Wed, 14 Dec 2011 15:46:52 -0500

I have a Time Warner circuit that has been giving me issues and what their
tech support has been telling me has not matched my previous experience
with other backbones.  I have been trying to move the backbone on one site
from a tier-3 provider to Time Warner.  Yesterday TW started advertising
BGP for the ip blocks I have (68.68.176.0/22 in /24's) before they had the
circuit completed, so I had to make an emergency mid-day switch to move to
Time Warner.  Then yesterday night they stopped announcing my blocks so my
site went down again and would still be completely down if we had not added
NAT to the /30 point-to-point link.  They said the reason was they didn't
have an LOA (which they had gotten back in October) and the ip blocks were
not in the Level3 Radb list.  I could still see announcement to some peers
(Shaw Cable in Canada) in a few looking glasses and BGP routers.  However
my network blocks were not showing for the larger US carriers like Qwest
and AT&T.  One of their techs just called me back and said that Level3
should be advertising it, but I still do not see the routes on the AT&T
route server.  After noting that the tech said that it may take another day
for BGP to "propagate" to other peers as they update their radb tables.  In
my experience I've never seen anything where I had to wait for a route to
propagate other than standard routing table updates which usually take less
then an hour, and I'd really not expect this many problems between Tier1
and Tier2 providers.  I need to know if this matches other's experience and
wanting to know what other people were seeing with traceroutes and "show ip
bgp".  The networks in question at the following 4 /24's

68.68.176.0/24
68.68.177.0/24
68.68.178.0/24
68.68.179.0/24

the serial ip address is 72.43.84.254

Thanks for your assistance.

---
Brian Raaen
Zcorum
Network Architect

Re: Range using single-mode SFPs across multi-mode fiber

[Keegan Holley]

2011/12/14 Jeff Kell 

> On 12/14/2011 3:37 PM, Keegan Holley wrote:
>
> > Single mode just has a smaller core size for the smaller "beam" emitted
> by
> > laser vs. LED.  it works although I've never done it outside of a lab (MM
> > is cheaper). As for the distance it theory that should come down to the
> > optics and your transmit power.  Hopefully this is just a cable
> connecting
> > the router to a long line.  I've never heard of a 10K MM fiber run since
> SX
> > optics can't shoot that far.  You should be able to get through the 500m
> or
> > so that MM optics are rated for, but YMMV (errors, light levels, bounces,
> > etc etc)
>
> Cisco gives specs for SFP LX over MM (they aren't that great at gig, and
> really suck at
> 10G; if you have 50u OM3/OM4 you can do much better at 10G).
>
> See SFP/fiber/distance table at
>
> http://www.cisco.com/en/US/prod/collateral/modules/ps5455/ps6577/product_data_sheet0900aecd8033f885.html
>
> They specify that line conditioning cables were used.  I would say if
you're going to bother purchasing why not purchase SM?


> We have run LX-over-MM (62.5) on short building runs as a band-aid until
> SM is
> available, and trying to do all new building MM with 50u OM3/OM4.  We do
> have some
> dependence on 62.5u MM - used by our aging Simplex alarm system - which
> does
> point-to-point looped token ring <*cough*> on the alarm side.


What distances?


>  I'm trying to get them to confirm 50u will work point-to-point, but at
> some non-alarm-points there would be a
> necessary 50-to-62.5 exchange taking place and I'm not certain how to
> accomplish that
> (50->62.5 would likely have tolerable loss, but not 62.5->50).
>
> I don't think changing core sizes in the middle would work even with SM
optics.

Re: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56

[Mark Foster]

On 15/12/11 09:54, Justin M. Streiner wrote:
> On Wed, 14 Dec 2011, Keegan Holley wrote:
>
 inappropriate. We are attempting to use Juniper single-mode SFPs (LX
 variety) across multi-mode fiber. Standard listed distance is always
 for SFPs using the appropriate type of fiber. Does anyone out there
 know how much distance we are likely to get? Thanks for your help in
 advance.
>> Single mode just has a smaller core size for the smaller "beam"
>> emitted by
>> laser vs. LED.  it works although I've never done it outside of a lab
>> (MM
>> is cheaper). As for the distance it theory that should come down to the
>> optics and your transmit power.  Hopefully this is just a cable
>> connecting
>> the router to a long line.  I've never heard of a 10K MM fiber run
>> since SX
>> optics can't shoot that far.  You should be able to get through the
>> 500m or
>> so that MM optics are rated for, but YMMV (errors, light levels,
>> bounces,
>> etc etc)
>
> In a nutshell, don't do it if at all possible.  This issue gets
> significantly
> worse at 10G.  If there's any way to get SMF in place for this link,
> do it.
>
> In practice, you will likely get something less than the rated
> distance, particularly if the MM fiber in question is an older type,
> such as OM1. If you're using OM1, mode-conditioning jumpers at both
> ends are pretty much a must.

I sense confusion in the above.

- LX drivers on MM fibre can work with Mode-Conditioning patch leads and
can give you significant distance wins, particularly if you're using
legacy OM1 Fibre. 
- SX drivers on SM fibre is not something i've ever seen done, I can't
imagine why you'd do it - even if SX drivers are cheaper.

>
> The problems with shooting an LX/LH beam over MMF are threefold:
> 1. Attenuation on some flavors of MMF can be significantly higher than
> an equivalent run of SMF.
> 2. Modal dispersion on MMF will scatter and distort the LX beam,
> likely resulting in link errors because the receiver can't recover the
> data correctly.
> 3. Shooting a 9 micron beam into a 50 (or worse, 62.5) micron core,
> and getting enough of the beam to reach the 9 micron target at the
> other end to result in a recoverable signal is problematic.

If you're not pushing your distance too far it'll probably be fine, to
be honest.
Back in the day when I was working on large legacy campus fibre runs,
220 metres was the max distance we considered OK for SX drivers and OM1
fibre (for gig ethernet).  Mode conditioning leads would push this out
to say, 900m trustworthy.  If your distance is >900m I would suggest a
fibre upgrade is on the cards.

Again, the above all assumes mode-conditioning in use.  If you're not
mode-conditioning your effective range is going to be very short - to
the point of unusability - and I'd be concerned about the affects of
'overdriving' fibre that is not set up for the use of low powered lasers
and was instead optimised for LEDs, which obviously put out a lot less
power.

Mark.

Re: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56

[Keegan Holley]

2011/12/14 Justin M. Streiner 

> On Wed, 14 Dec 2011, Keegan Holley wrote:
>
>  inappropriate. We are attempting to use Juniper single-mode SFPs (LX
 variety) across multi-mode fiber. Standard listed distance is always
 for SFPs using the appropriate type of fiber. Does anyone out there
 know how much distance we are likely to get? Thanks for your help in
 advance.

>>> Single mode just has a smaller core size for the smaller "beam" emitted
>> by
>> laser vs. LED.  it works although I've never done it outside of a lab (MM
>> is cheaper). As for the distance it theory that should come down to the
>> optics and your transmit power.  Hopefully this is just a cable connecting
>> the router to a long line.  I've never heard of a 10K MM fiber run since
>> SX
>> optics can't shoot that far.  You should be able to get through the 500m
>> or
>> so that MM optics are rated for, but YMMV (errors, light levels, bounces,
>> etc etc)
>>
>
> In a nutshell, don't do it if at all possible.  This issue gets
> significantly
> worse at 10G.  If there's any way to get SMF in place for this link, do it.
>
> +1 probably should have added that.  I guess I just assumed.


> In practice, you will likely get something less than the rated distance,
> particularly if the MM fiber in question is an older type, such as OM1. If
> you're using OM1, mode-conditioning jumpers at both ends are pretty much a
> must.
>
> The problems with shooting an LX/LH beam over MMF are threefold:
> 1. Attenuation on some flavors of MMF can be significantly higher than an
> equivalent run of SMF.
>
+1 Assumed again..


> 2. Modal dispersion on MMF will scatter and distort the LX beam, likely
> resulting in link errors because the receiver can't recover the data
> correctly.
>

Not that I'm advocating this, but it's fine over short distances.  I did
this for a few lab routers where I wasn't concerned with link quality, but
I was able to fill a 10G pipe with no errors/retransmit over about 10M.


> 3. Shooting a 9 micron beam into a 50 (or worse, 62.5) micron core, and
> getting enough of the beam to reach the 9 micron target at the other end to
> result in a recoverable signal is problematic.


Again for short distances it's doable.  I agree not to even try over 62.5
though.

Re: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56

[Justin M. Streiner]

On Wed, 14 Dec 2011, Keegan Holley wrote:


inappropriate. We are attempting to use Juniper single-mode SFPs (LX
variety) across multi-mode fiber. Standard listed distance is always
for SFPs using the appropriate type of fiber. Does anyone out there
know how much distance we are likely to get? Thanks for your help in
advance.

Single mode just has a smaller core size for the smaller "beam" emitted by
laser vs. LED.  it works although I've never done it outside of a lab (MM
is cheaper). As for the distance it theory that should come down to the
optics and your transmit power.  Hopefully this is just a cable connecting
the router to a long line.  I've never heard of a 10K MM fiber run since SX
optics can't shoot that far.  You should be able to get through the 500m or
so that MM optics are rated for, but YMMV (errors, light levels, bounces,
etc etc)


In a nutshell, don't do it if at all possible.  This issue gets significantly
worse at 10G.  If there's any way to get SMF in place for this link, do it.

In practice, you will likely get something less than the rated distance, 
particularly if the MM fiber in question is an older type, such as OM1. 
If you're using OM1, mode-conditioning jumpers at both ends are pretty 
much a must.


The problems with shooting an LX/LH beam over MMF are threefold:
1. Attenuation on some flavors of MMF can be significantly higher than an 
equivalent run of SMF.
2. Modal dispersion on MMF will scatter and distort the LX beam, likely 
resulting in link errors because the receiver can't recover the data 
correctly.
3. Shooting a 9 micron beam into a 50 (or worse, 62.5) micron core, and 
getting enough of the beam to reach the 9 micron target at the other end 
to result in a recoverable signal is problematic.


jms

Re: Range using single-mode SFPs across multi-mode fiber

[Jeff Kell]

On 12/14/2011 3:37 PM, Keegan Holley wrote:

> Single mode just has a smaller core size for the smaller "beam" emitted by
> laser vs. LED.  it works although I've never done it outside of a lab (MM
> is cheaper). As for the distance it theory that should come down to the
> optics and your transmit power.  Hopefully this is just a cable connecting
> the router to a long line.  I've never heard of a 10K MM fiber run since SX
> optics can't shoot that far.  You should be able to get through the 500m or
> so that MM optics are rated for, but YMMV (errors, light levels, bounces,
> etc etc)

Cisco gives specs for SFP LX over MM (they aren't that great at gig, and really 
suck at
10G; if you have 50u OM3/OM4 you can do much better at 10G).

See SFP/fiber/distance table at
http://www.cisco.com/en/US/prod/collateral/modules/ps5455/ps6577/product_data_sheet0900aecd8033f885.html

We have run LX-over-MM (62.5) on short building runs as a band-aid until SM is
available, and trying to do all new building MM with 50u OM3/OM4.  We do have 
some
dependence on 62.5u MM - used by our aging Simplex alarm system - which does
point-to-point looped token ring <*cough*> on the alarm side.  I'm trying to 
get them to
confirm 50u will work point-to-point, but at some non-alarm-points there would 
be a
necessary 50-to-62.5 exchange taking place and I'm not certain how to 
accomplish that
(50->62.5 would likely have tolerable loss, but not 62.5->50).

(I would suspect similar results cross-vendor but YMMV)

Jeff

Time Warner Routing Issue

[Brian Christopher Raaen]

I have a Time Warner circuit that has been giving me issues and what their
tech support has been telling me has not matched my previous experience
with other backbones.  I have been trying to move the backbone on one site
from a tier-3 provider to Time Warner.  Yesterday TW started advertising
BGP for the ip blocks I have (68.68.176.0/22 in /24's) before they had the
circuit completed, so I had to make an emergency mid-day switch to move to
Time Warner.  Then yesterday night they stopped announcing my blocks so my
site went down again and would still be completely down if we had not added
NAT to the /30 point-to-point link.  They said the reason was they didn't
have an LOA (which they had gotten back in October) and the ip blocks were
not in the Level3 Radb list.  I could still see announcement to some peers
(Shaw Cable in Canada) in a few looking glasses and BGP routers.  However
my network blocks were not showing for the larger US carriers like Qwest
and AT&T.  One of their techs just called me back and said that Level3
should be advertising it, but I still do not see the routes on the AT&T
route server.  After noting that the tech said that it may take another day
for BGP to "propagate" to other peers as they update their radb tables.  In
my experience I've never seen anything where I had to wait for a route to
propagate other than standard routing table updates which usually take less
then an hour, and I'd really not expect this many problems between Tier1
and Tier2 providers.  I need to know if this matches other's experience and
wanting to know what other people were seeing with traceroutes and "show ip
bgp".  The networks in question at the following 4 /24's

68.68.176.0/24
68.68.177.0/24
68.68.178.0/24
68.68.179.0/24

the serial ip address is 72.43.84.254

Thanks for your assistance.

---
Brian Raaen
Zcorum
Network Architect

RE: Multiple ISP Load Balancing

[Rampley Jr, Jim F]

We have specific situations where we have successfully used the Avaya CNA tool 
(old Route Science Patch Control).  Not for load balancing, but for sub second 
failover from primary to a backup paths over MPLS VPN's.  This is done on our 
internal network where we have MPLS VPN's sometimes over multiple carriers 
where normal convergence times are 30 seconds to 1 minute across an external 
provider.  It's not easy to setup initially, but once you get it setup and the 
kinks worked out I've been impressed with its ability to test a path and move 
traffic at the first hint of trouble.  


Jim 



-Original Message-
From: Justin M. Streiner [mailto:strei...@cluebyfour.org] 
Sent: Wednesday, December 14, 2011 2:10 PM
To: nanog@nanog.org
Subject: Re: Multiple ISP Load Balancing

On Wed, 14 Dec 2011, Holmes,David A wrote:

> From time to time some have posted questions asking if BGP load 
> balancers such as the old Routescience Pathcontrol device are still 
> around, and if not what have others found to replace that function. I 
> have used the Routescience device with much success 10 years ago when it 
> first came on the market, but since then a full BGP feed has become much 
> larger, Routescience has been bought by Avaya, then discontinued, and 
> other competitors such as Sockeye, Netvmg have been acquired by other 
> companies.

It's important to keep in mind what load-balancing is and isn't in this 
case.  The terminology gap can be important because load-balancing (more
accurately, load-sharing) in the context of internetwork traffic
engineering is very different from load-balancing pools of servers in a 
data center.  Some people can (and sometimes do) confuse the two, which 
can cause unrealistic expectations to be set :)

Achieving a perfect split of network traffic across two or more upstream 
links rarely happens in the real world.  General good practice is to put 
bandwidth where the network traffic wants to go, but that can be a moving 
target, and executives and accountants don't like those :)  Traffic 
engineering still has a place on many networks, for a veriety of reasons 
(technical, financial, political, some combination of these), but as 
other posters have mentioned, it's often done manually, i.e. looking at 
Netflow reports, seeing where your traffic is going/coming from, adjusting 
BGP policies accordingly.  Repeat as needed.  Since traffic profiles can 
change over time, any policy tweaks that are put in place need to be 
reviewed periodically.

Depending on how much prep work and planning you're willing to do, you can 
put a fairly rich set of internal BGP communities in place to control 
things like localpref, MEDs, selective prepends, and tagging outbound 
advertisements with provider-specific communities.  With that kind of 
structure, you could control many aspects of your traffic engineering from 
a route server, rather than having to tinker with route policies on each 
outside-facing router.

One caveat: If your route server crashes or has to be taken down for 
maintenance, the traffic patterns that were being tweaked by your policy 
framework could start to revert to the way the traffic would flow in its 
un-altered state, which could cause you some unintended headaches.

jms


E-MAIL CONFIDENTIALITY NOTICE: 

 

 

 

The contents of this e-mail message and 
any attachments are intended solely for the 
addressee(s) and may contain confidential 
and/or legally privileged information. If you 
are not the intended recipient of this message 
or if this message has been addressed to you 
in error, please immediately alert the sender
 by reply e-mail and then delete this message 
and any attachments. If you are not the 
intended recipient, you are notified that 
any use, dissemination, distribution, copying, 
or storage of this message or any attachment 
is strictly prohibited.

Re: Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56

[Keegan Holley]

> > inappropriate. We are attempting to use Juniper single-mode SFPs (LX
> > variety) across multi-mode fiber. Standard listed distance is always
> > for SFPs using the appropriate type of fiber. Does anyone out there
> > know how much distance we are likely to get? Thanks for your help in
> > advance.
>

Single mode just has a smaller core size for the smaller "beam" emitted by
laser vs. LED.  it works although I've never done it outside of a lab (MM
is cheaper). As for the distance it theory that should come down to the
optics and your transmit power.  Hopefully this is just a cable connecting
the router to a long line.  I've never heard of a 10K MM fiber run since SX
optics can't shoot that far.  You should be able to get through the 500m or
so that MM optics are rated for, but YMMV (errors, light levels, bounces,
etc etc)

Range using single-mode SFPs across multi-mode fiber - was Re: NANOG Digest, Vol 47, Issue 56

[Marshall Eubanks]

ich lists those who have space available or prequalify as a recipient)
>>> but not required to do so.  Similarly, parties which may have space 
>>> available
>>> for transfer or wish to prequalify in advance to receive address space via
>>> transfer may also register in the Specified Transfer Listing Service (STLS).
>>> More information is available on the ARIN web site  under
>>> "IPv4 SPECIFIED TRANSFER OPTIONS" section.
>>>
>>> FYI (and Happy Holidays :-)
>>> /John
>>>
>>> John Curran
>>> President and CEO
>>> ARIN
>>>
>>>
>>>
>>>
>>> __
>>> This email has been scanned by the Symantec Email Security.cloud service.
>>> For more information please visit http://www.symanteccloud.com
>>> __
>>
>> __
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> __
>>
>>
>>
>> --
>>
>> Message: 5
>> Date: Wed, 14 Dec 2011 18:01:06 +0530
>> From: Suresh Ramasubramanian 
>> To: "O'Reirdan, Michael" 
>> Cc: "nanog@nanog.org" , Hal Murray
>>        
>> Subject: Re: EFF call for signatures from Internet engineers against
>>        censorship
>> Message-ID:
>>        
>> Content-Type: text/plain; charset=UTF-8
>>
>> Wonderful.  I would urge SPs based stateside to strongly consider
>> endorsing the MAAWG comments.
>>
>> thanks
>> suresh
>>
>> On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael
>>  wrote:
>>> MAAWG has written voicing its concerns on SOPA and PIPA.
>>>
>>> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf
>>>
>>> Mike
>>> 
>>> From: Suresh Ramasubramanian [ops.li...@gmail.com]
>>> Sent: 14 December 2011 05:12
>>> To: Hal Murray
>>> Cc: nanog@nanog.org
>>> Subject: Re: EFF call for signatures from Internet engineers against 
>>> censorship
>>>
>>> I would strongly suggest that operators work with their legal
>>> departments to endorse this paper by Crocker and others.
>>>
>>> If other ISP organizations (such as say MAAWG) come out with
>>> something, other operators could sign on to that as well.
>>>
>>> The EFF petition has way too much propaganda and far less content than
>>> would be entirely productive in a policy discussion.
>>>
>>> --srs
>>>
>>>
>>> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray  
>>> wrote:
>>>>
>>>> ?Security and Other Technical Concerns Raised by the
>>>> ? ?DNS Filtering Requirements in the PROTECT IP Bill
>>>> ?Authors:
>>>> ? ?Steve Crocker, Shinkuro, Inc.
>>>> ? ?David Dagon, Georgia Tech
>>>> ? ?Dan Kaminsky, DKH
>>>> ? ?Danny McPherson, Verisign, Inc.
>>>> ? ?Paul Vixie, Internet Systems Consortium
>>>
>>>
>>>
>>> --
>>> Suresh Ramasubramanian (ops.li...@gmail.com)
>>>
>>
>>
>>
>> --
>> Suresh Ramasubramanian (ops.li...@gmail.com)
>>
>>
>>
>> --
>>
>> Message: 6
>> Date: Wed, 14 Dec 2011 14:10:52 +
>> From: bmann...@vacation.karoshi.com
>> To: Chaim Rieger 
>> Cc: nanog@nanog.org
>> Subject: Re: Your Christmas Bonus Has Arrived
>> Message-ID: <20111214141052.ga7...@vacation.karoshi.com.>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote:
>>> What do you have for those that don't do the whole Jesus thing ?
>>
>> babalyonian fertility icons?  (you -did- bring an evergreen tree into your
>> home, yes?)
>>
>> /bill
>>
>>
>>
>> --
>>
>> Message: 7
>> Date: Wed, 14 Dec 2011 09:16:27 -0500 (EST)
>> From: "Justin M. Streiner" 
>> To: NANOG list 
>> Subject: Re: Recognized Address Transfer Facilitators (was: Your
>>        Christmas Bonus Has Arrived)
>> Message

Re: Multiple ISP Load Balancing

[Justin M. Streiner]

On Wed, 14 Dec 2011, Holmes,David A wrote:

From time to time some have posted questions asking if BGP load 
balancers such as the old Routescience Pathcontrol device are still 
around, and if not what have others found to replace that function. I 
have used the Routescience device with much success 10 years ago when it 
first came on the market, but since then a full BGP feed has become much 
larger, Routescience has been bought by Avaya, then discontinued, and 
other competitors such as Sockeye, Netvmg have been acquired by other 
companies.


It's important to keep in mind what load-balancing is and isn't in this 
case.  The terminology gap can be important because load-balancing (more

accurately, load-sharing) in the context of internetwork traffic
engineering is very different from load-balancing pools of servers in a 
data center.  Some people can (and sometimes do) confuse the two, which 
can cause unrealistic expectations to be set :)


Achieving a perfect split of network traffic across two or more upstream 
links rarely happens in the real world.  General good practice is to put 
bandwidth where the network traffic wants to go, but that can be a moving 
target, and executives and accountants don't like those :)  Traffic 
engineering still has a place on many networks, for a veriety of reasons 
(technical, financial, political, some combination of these), but as 
other posters have mentioned, it's often done manually, i.e. looking at 
Netflow reports, seeing where your traffic is going/coming from, adjusting 
BGP policies accordingly.  Repeat as needed.  Since traffic profiles can 
change over time, any policy tweaks that are put in place need to be 
reviewed periodically.


Depending on how much prep work and planning you're willing to do, you can 
put a fairly rich set of internal BGP communities in place to control 
things like localpref, MEDs, selective prepends, and tagging outbound 
advertisements with provider-specific communities.  With that kind of 
structure, you could control many aspects of your traffic engineering from 
a route server, rather than having to tinker with route policies on each 
outside-facing router.


One caveat: If your route server crashes or has to be taken down for 
maintenance, the traffic patterns that were being tweaked by your policy 
framework could start to revert to the way the traffic would flow in its 
un-altered state, which could cause you some unintended headaches.


jms

RE: Multiple ISP Load Balancing

[Drew Weaver]

>seems the feeling is that if you have multiple full feeds and need to 
>loadshare, you really don't want (in most cases) ispa=500mbps + ispb=500mbps.
>
>
>you really want destinationA to be reached across the 'best path'
>(best ... in some form, distance? packetdrop%? jitter? cost?)  you'll most 
>likely have to tweak things in order to achieve what you want since only 
>distance is really used in the stock bgp calculation (distance by as-hops, 
>presuming you don't listen to closely to med from your providers)

Yes, but performance from your network to $destination_AS via $ISPx can be 
variable and how do you know when it changes before someone starts complaining?

There are traditionally two pieces involved with optimization.

1) "Cost" (Commitment/oversubscribe management and monitoring)
2) "Performance"

Usually "cost control" is #1 so systems like that are configured so that as 
long as the traffic isn't breaking your commits or filling your pipes they will 
then optimize X number of your top prefixes for performance (based on what the 
system can see).

The performance aspect is generally just sending basic probes in all directions 
towards a destination host and seeing which ones reply the fastest.

Although obviously this only impacts traffic outbound from your AS.

-Drew

Re: Multiple ISP Load Balancing

[Jonathan Lassoff]

The best applications for analyzing paths, that I've seen, have been
in-house development projects. So, admittedly, I don't have much experience
with commercial products for route optimization.

Projects I've seen that analyze "best" paths to Internet destinations via
multiple ISPs add instrumentation to content-serving applications to log
stream performance details to a database or log collection system along
with a timestamp. Another database keeps a periodic log of RIB data that
lists the specific next-hops out of the AS. Another log keeps a running log
of UPDATEs.
>From joining up all of this information, you can figure out the ISP you're
taking to a destination (at a given time) and how the stream performed.
Then, add some logic to inject routes to try out different next-hop ISPs
for some destinations.

Then, compare the newer ISP-path to the older one and see which performs
"best". Where "best" means something specific to your application
(optimizing for latency, cost, etc.)

Cheers,
jof

RE: Multiple ISP Load Balancing

[Jeff Tantsura]

Hi David,

You might want to take a look at work happening in ALTO 
(http://tools.ietf.org/wg/alto/)

Regards,
Jeff
-Original Message-
From: Holmes,David A [mailto:dhol...@mwdh2o.com] 
Sent: Wednesday, December 14, 2011 11:07 AM
To: nanog@nanog.org
Subject: Multiple ISP Load Balancing

>From time to time some have posted questions asking if BGP load balancers such 
>as the old Routescience Pathcontrol device are still around, and if not what 
>have others found to replace that function. I have used the Routescience 
>device with much success 10 years ago when it first came on the market, but 
>since then a full BGP feed has become much larger, Routescience has been 
>bought by Avaya, then discontinued, and other competitors such as Sockeye, 
>Netvmg have been acquired by other companies.

Doing some research on how load balancing can be accomplished in 2011, I have 
come across Cisco's performance routing feature, and features from load 
balancing companies such as F5's Link Controller. I have always found BGP to be 
easy to work with, and an elegant, simple solution to load balancing using a 
route-reflector configuration in which one BGP client (Routescience Pathcontrol 
in my background) learns the best route to destination networks, and then 
announces that best route to BGP border routers using common and widely 
understood BGP concepts such as communities and local pref, and found this to 
lead to a deterministic Internet routing architecture. This required a 
knowledge only of IETF standards (common BGP concepts and configurations), 
required no specialized scripting, or any other knowledge lying outside IETF 
boundaries, and it seemed reasonable to expect that network engineers should 
eagerly and enthusiastically want to master this technology, just as any other 
technology must be mastered to run high availability networks.

So I am wondering if anyone has experience with implementing load balancing 
across multiple ISP links in 2011, and if there have been any comparisons 
between IETF standards-based methods using BGP, and other proprietary methods 
which may use a particular vendor's approach to solving the same problem, but 
involves some complexity with more variables to be plugged in to the 
architecture.

David



  
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 you are not the intended recipient, you 
are hereby notified that any review, disclosure, copying, dissemination, 
distribution or use of this communication is strictly prohibited. If you have 
received this communication in error, please notify the sender immediately by 
return e-mail message and delete the original and all copies of the 
communication, along with any attachments or embedded links, from your system.

Re: NANOG Digest, Vol 47, Issue 56

[oliver rothschild]

> Message: 5
> Date: Wed, 14 Dec 2011 18:01:06 +0530
> From: Suresh Ramasubramanian 
> To: "O'Reirdan, Michael" 
> Cc: "nanog@nanog.org" , Hal Murray
>        
> Subject: Re: EFF call for signatures from Internet engineers against
>        censorship
> Message-ID:
>        
> Content-Type: text/plain; charset=UTF-8
>
> Wonderful.  I would urge SPs based stateside to strongly consider
> endorsing the MAAWG comments.
>
> thanks
> suresh
>
> On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael
>  wrote:
>> MAAWG has written voicing its concerns on SOPA and PIPA.
>>
>> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf
>>
>> Mike
>> 
>> From: Suresh Ramasubramanian [ops.li...@gmail.com]
>> Sent: 14 December 2011 05:12
>> To: Hal Murray
>> Cc: nanog@nanog.org
>> Subject: Re: EFF call for signatures from Internet engineers against 
>> censorship
>>
>> I would strongly suggest that operators work with their legal
>> departments to endorse this paper by Crocker and others.
>>
>> If other ISP organizations (such as say MAAWG) come out with
>> something, other operators could sign on to that as well.
>>
>> The EFF petition has way too much propaganda and far less content than
>> would be entirely productive in a policy discussion.
>>
>> --srs
>>
>>
>> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray  wrote:
>>>
>>> ?Security and Other Technical Concerns Raised by the
>>> ? ?DNS Filtering Requirements in the PROTECT IP Bill
>>> ?Authors:
>>> ? ?Steve Crocker, Shinkuro, Inc.
>>> ? ?David Dagon, Georgia Tech
>>> ? ?Dan Kaminsky, DKH
>>> ? ?Danny McPherson, Verisign, Inc.
>>> ? ?Paul Vixie, Internet Systems Consortium
>>
>>
>>
>> --
>> Suresh Ramasubramanian (ops.li...@gmail.com)
>>
>
>
>
> --
> Suresh Ramasubramanian (ops.li...@gmail.com)
>
>
>
> --
>
> Message: 6
> Date: Wed, 14 Dec 2011 14:10:52 +
> From: bmann...@vacation.karoshi.com
> To: Chaim Rieger 
> Cc: nanog@nanog.org
> Subject: Re: Your Christmas Bonus Has Arrived
> Message-ID: <20111214141052.ga7...@vacation.karoshi.com.>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote:
>> What do you have for those that don't do the whole Jesus thing ?
>
> babalyonian fertility icons?  (you -did- bring an evergreen tree into your
> home, yes?)
>
> /bill
>
>
>
> --
>
> Message: 7
> Date: Wed, 14 Dec 2011 09:16:27 -0500 (EST)
> From: "Justin M. Streiner" 
> To: NANOG list 
> Subject: Re: Recognized Address Transfer Facilitators (was: Your
>        Christmas Bonus Has Arrived)
> Message-ID: 
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Wed, 14 Dec 2011, Leigh Porter wrote:
>
>> I love the anti v6 stuff on some of their sites!
>>
>> http://www.iptrading.com/news/news.htm
>
> Some of which seems to float between fear-mongering, possibly
> mis-appropriated quotes, half-truths and information that is flat-out
> wrong.  I would not trust the judgment and opinions of someone who even
> admitted in one of their blog posts that they had "no hands-on Service
> Provider IPv6 experience."
>
> While I can understand why IPv4 address brokers would take a decidedly
> anti-IPv6 stance (deploying IPv6 cuts into their potential business), that
> doesn't make it any less underhanded.
>
> jms
>
>
>
> --
>
> Message: 8
> Date: Wed, 14 Dec 2011 22:18:41 +0800
> From: Mark Tinka 
> To: nanog@nanog.org
> Cc: John Curran 
> Subject: Re: Recognized Address Transfer Facilitators (was: Your
>        Christmas Bonus Has Arrived)
> Message-ID: <201112142218.42329.mti...@globaltransit.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wednesday, December 14, 2011 08:30:06 PM Leigh Porter
> wrote:
>
>> I love the anti v6 stuff on some of their sites!
>>
>> http://www.iptrading.com/news/news.htm
>
> I'd have been more impressed if they actually came up with
> the stories by themselves, as opposed to linking to existing
> stories that their link titles take out of context.
>
> Mark.
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: This is a digitally s

Re: Multiple ISP Load Balancing

[Christopher Morrow]

On Wed, Dec 14, 2011 at 2:28 PM, Drew Weaver  wrote:
> I've asked several times about this in the past; although I learned quickly 
> to stop asking.
>
> It seems that the consensus has generally been that the best way to handle 
> traffic engineering in networks where you have multiple full-feed up-streams 
> is to do it manually (i.e. set preference for your top N AS/prefix 
> destinations) or don't do it at all (let BGP figure it out..?).
>

seems the feeling is that if you have multiple full feeds and need to
loadshare, you really don't want (in most cases) ispa=500mbps +
ispb=500mbps.

you really want destinationA to be reached across the 'best path'
(best ... in some form, distance? packetdrop%? jitter? cost?)  you'll
most likely have to tweak things in order to achieve what you want
since only distance is really used in the stock bgp calculation
(distance by as-hops, presuming you don't listen to closely to med
from your providers)

> Suggesting that a "route optimization system" has any value generally makes 
> people cranky.
>

ha! :)

-chris

> Thanks,
> -Drew
>
> -Original Message-
> From: Holmes,David A [mailto:dhol...@mwdh2o.com]
> Sent: Wednesday, December 14, 2011 2:07 PM
> To: nanog@nanog.org
> Subject: Multiple ISP Load Balancing
>
> From time to time some have posted questions asking if BGP load balancers 
> such as the old Routescience Pathcontrol device are still around, and if not 
> what have others found to replace that function. I have used the Routescience 
> device with much success 10 years ago when it first came on the market, but 
> since then a full BGP feed has become much larger, Routescience has been 
> bought by Avaya, then discontinued, and other competitors such as Sockeye, 
> Netvmg have been acquired by other companies.
>
> Doing some research on how load balancing can be accomplished in 2011, I have 
> come across Cisco's performance routing feature, and features from load 
> balancing companies such as F5's Link Controller. I have always found BGP to 
> be easy to work with, and an elegant, simple solution to load balancing using 
> a route-reflector configuration in which one BGP client (Routescience 
> Pathcontrol in my background) learns the best route to destination networks, 
> and then announces that best route to BGP border routers using common and 
> widely understood BGP concepts such as communities and local pref, and found 
> this to lead to a deterministic Internet routing architecture. This required 
> a knowledge only of IETF standards (common BGP concepts and configurations), 
> required no specialized scripting, or any other knowledge lying outside IETF 
> boundaries, and it seemed reasonable to expect that network engineers should 
> eagerly and enthusiastically want to master this technology, just as any 
> other technology must be mastered to run high availability networks.
>
> So I am wondering if anyone has experience with implementing load balancing 
> across multiple ISP links in 2011, and if there have been any comparisons 
> between IETF standards-based methods using BGP, and other proprietary methods 
> which may use a particular vendor's approach to solving the same problem, but 
> involves some complexity with more variables to be plugged in to the 
> architecture.
>
> David
>
>
>
>  
> 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 you are not the intended recipient, you 
> are hereby notified that any review, disclosure, copying, dissemination, 
> distribution or use of this communication is strictly prohibited. If you have 
> received this communication in error, please notify the sender immediately by 
> return e-mail message and delete the original and all copies of the 
> communication, along with any attachments or embedded links, from your system.
>

RE: Multiple ISP Load Balancing

[Drew Weaver]

I've asked several times about this in the past; although I learned quickly to 
stop asking.

It seems that the consensus has generally been that the best way to handle 
traffic engineering in networks where you have multiple full-feed up-streams is 
to do it manually (i.e. set preference for your top N AS/prefix destinations) 
or don't do it at all (let BGP figure it out..?).

Suggesting that a "route optimization system" has any value generally makes 
people cranky.

Thanks,
-Drew

-Original Message-
From: Holmes,David A [mailto:dhol...@mwdh2o.com] 
Sent: Wednesday, December 14, 2011 2:07 PM
To: nanog@nanog.org
Subject: Multiple ISP Load Balancing

>From time to time some have posted questions asking if BGP load balancers such 
>as the old Routescience Pathcontrol device are still around, and if not what 
>have others found to replace that function. I have used the Routescience 
>device with much success 10 years ago when it first came on the market, but 
>since then a full BGP feed has become much larger, Routescience has been 
>bought by Avaya, then discontinued, and other competitors such as Sockeye, 
>Netvmg have been acquired by other companies.

Doing some research on how load balancing can be accomplished in 2011, I have 
come across Cisco's performance routing feature, and features from load 
balancing companies such as F5's Link Controller. I have always found BGP to be 
easy to work with, and an elegant, simple solution to load balancing using a 
route-reflector configuration in which one BGP client (Routescience Pathcontrol 
in my background) learns the best route to destination networks, and then 
announces that best route to BGP border routers using common and widely 
understood BGP concepts such as communities and local pref, and found this to 
lead to a deterministic Internet routing architecture. This required a 
knowledge only of IETF standards (common BGP concepts and configurations), 
required no specialized scripting, or any other knowledge lying outside IETF 
boundaries, and it seemed reasonable to expect that network engineers should 
eagerly and enthusiastically want to master this technology, just as any other 
technology must be mastered to run high availability networks.

So I am wondering if anyone has experience with implementing load balancing 
across multiple ISP links in 2011, and if there have been any comparisons 
between IETF standards-based methods using BGP, and other proprietary methods 
which may use a particular vendor's approach to solving the same problem, but 
involves some complexity with more variables to be plugged in to the 
architecture.

David



  
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 you are not the intended recipient, you 
are hereby notified that any review, disclosure, copying, dissemination, 
distribution or use of this communication is strictly prohibited. If you have 
received this communication in error, please notify the sender immediately by 
return e-mail message and delete the original and all copies of the 
communication, along with any attachments or embedded links, from your system.

Multiple ISP Load Balancing

[Holmes,David A]

>From time to time some have posted questions asking if BGP load balancers such 
>as the old Routescience Pathcontrol device are still around, and if not what 
>have others found to replace that function. I have used the Routescience 
>device with much success 10 years ago when it first came on the market, but 
>since then a full BGP feed has become much larger, Routescience has been 
>bought by Avaya, then discontinued, and other competitors such as Sockeye, 
>Netvmg have been acquired by other companies.

Doing some research on how load balancing can be accomplished in 2011, I have 
come across Cisco's performance routing feature, and features from load 
balancing companies such as F5's Link Controller. I have always found BGP to be 
easy to work with, and an elegant, simple solution to load balancing using a 
route-reflector configuration in which one BGP client (Routescience Pathcontrol 
in my background) learns the best route to destination networks, and then 
announces that best route to BGP border routers using common and widely 
understood BGP concepts such as communities and local pref, and found this to 
lead to a deterministic Internet routing architecture. This required a 
knowledge only of IETF standards (common BGP concepts and configurations), 
required no specialized scripting, or any other knowledge lying outside IETF 
boundaries, and it seemed reasonable to expect that network engineers should 
eagerly and enthusiastically want to master this technology, just as any other 
technology must be mastered to run high availability networks.

So I am wondering if anyone has experience with implementing load balancing 
across multiple ISP links in 2011, and if there have been any comparisons 
between IETF standards-based methods using BGP, and other proprietary methods 
which may use a particular vendor's approach to solving the same problem, but 
involves some complexity with more variables to be plugged in to the 
architecture.

David



  
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 you are not the intended recipient, you 
are hereby notified that any review, disclosure, copying, dissemination, 
distribution or use of this communication is strictly prohibited. If you have 
received this communication in error, please notify the sender immediately by 
return e-mail message and delete the original and all copies of the 
communication, along with any attachments or embedded links, from your system.

Re: Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived)

[Mark Tinka]

On Wednesday, December 14, 2011 08:30:06 PM Leigh Porter 
wrote:

> I love the anti v6 stuff on some of their sites!
> 
> http://www.iptrading.com/news/news.htm

I'd have been more impressed if they actually came up with 
the stories by themselves, as opposed to linking to existing 
stories that their link titles take out of context.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived)

[Justin M. Streiner]

On Wed, 14 Dec 2011, Leigh Porter wrote:


I love the anti v6 stuff on some of their sites!

http://www.iptrading.com/news/news.htm


Some of which seems to float between fear-mongering, possibly 
mis-appropriated quotes, half-truths and information that is flat-out 
wrong.  I would not trust the judgment and opinions of someone who even 
admitted in one of their blog posts that they had "no hands-on Service 
Provider IPv6 experience."


While I can understand why IPv4 address brokers would take a decidedly 
anti-IPv6 stance (deploying IPv6 cuts into their potential business), that 
doesn't make it any less underhanded.


jms

Re: Your Christmas Bonus Has Arrived

[bmanning]

On Tue, Dec 13, 2011 at 10:07:44PM -0800, Chaim Rieger wrote:
> What do you have for those that don't do the whole Jesus thing ?

babalyonian fertility icons?  (you -did- bring an evergreen tree into your
home, yes?)

/bill

Re: EFF call for signatures from Internet engineers against censorship

[Suresh Ramasubramanian]

Wonderful.  I would urge SPs based stateside to strongly consider
endorsing the MAAWG comments.

thanks
suresh

On Wed, Dec 14, 2011 at 5:06 PM, O'Reirdan, Michael
 wrote:
> MAAWG has written voicing its concerns on SOPA and PIPA.
>
> http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf
>
> Mike
> 
> From: Suresh Ramasubramanian [ops.li...@gmail.com]
> Sent: 14 December 2011 05:12
> To: Hal Murray
> Cc: nanog@nanog.org
> Subject: Re: EFF call for signatures from Internet engineers against 
> censorship
>
> I would strongly suggest that operators work with their legal
> departments to endorse this paper by Crocker and others.
>
> If other ISP organizations (such as say MAAWG) come out with
> something, other operators could sign on to that as well.
>
> The EFF petition has way too much propaganda and far less content than
> would be entirely productive in a policy discussion.
>
> --srs
>
>
> On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray  wrote:
>>
>>  Security and Other Technical Concerns Raised by the
>>    DNS Filtering Requirements in the PROTECT IP Bill
>>  Authors:
>>    Steve Crocker, Shinkuro, Inc.
>>    David Dagon, Georgia Tech
>>    Dan Kaminsky, DKH
>>    Danny McPherson, Verisign, Inc.
>>    Paul Vixie, Internet Systems Consortium
>
>
>
> --
> Suresh Ramasubramanian (ops.li...@gmail.com)
>



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived)

[Leigh Porter]

I love the anti v6 stuff on some of their sites!

http://www.iptrading.com/news/news.htm


-- 
Leigh


On 14 Dec 2011, at 12:21, "John Curran"  wrote:

> On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote:
> 
>> I believe this company is the one that sold the MS & Borders blocks, so they 
>> may be "legit" (whatever that means in this context).
> 
> I also do not know what "legit" means in this context, but will note
> that we have added a public list of all recognized specified transfer 
> facilitators to the ARIN web site:
> 
> 
> 
> Facilitators are aware of ARIN's address transfer policies and agree to 
> comply with same.  Note that any qualifying parties may transfer space in 
> compliance with policy, but folks may find it easier to work with one of 
> these facilitators to find a matching party for transfer.  Facilitators may 
> make use of information in the optional Specified Transfer Listing Service 
> (which lists those who have space available or prequalify as a recipient) 
> but not required to do so.  Similarly, parties which may have space available
> for transfer or wish to prequalify in advance to receive address space via 
> transfer may also register in the Specified Transfer Listing Service (STLS).  
> More information is available on the ARIN web site  under 
> "IPv4 SPECIFIED TRANSFER OPTIONS" section.
> 
> FYI (and Happy Holidays :-)
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> 
> 
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Recognized Address Transfer Facilitators (was: Your Christmas Bonus Has Arrived)

[John Curran]

On Dec 14, 2011, at 12:40 AM, Patrick W. Gilmore wrote:

> I believe this company is the one that sold the MS & Borders blocks, so they 
> may be "legit" (whatever that means in this context).

I also do not know what "legit" means in this context, but will note
that we have added a public list of all recognized specified transfer 
facilitators to the ARIN web site:



Facilitators are aware of ARIN's address transfer policies and agree to 
comply with same.  Note that any qualifying parties may transfer space in 
compliance with policy, but folks may find it easier to work with one of 
these facilitators to find a matching party for transfer.  Facilitators may 
make use of information in the optional Specified Transfer Listing Service 
(which lists those who have space available or prequalify as a recipient) 
but not required to do so.  Similarly, parties which may have space available
for transfer or wish to prequalify in advance to receive address space via 
transfer may also register in the Specified Transfer Listing Service (STLS).  
More information is available on the ARIN web site  under 
"IPv4 SPECIFIED TRANSFER OPTIONS" section.

FYI (and Happy Holidays :-)
/John

John Curran
President and CEO
ARIN


 

RE: EFF call for signatures from Internet engineers against censorship

[O'Reirdan, Michael]

MAAWG has written voicing its concerns on SOPA and PIPA. 

http://www.maawg.org/sites/maawg/files/news/MAAWG_US_Congress_S968-HR3261_Comments_2011-12.pdf

Mike

From: Suresh Ramasubramanian [ops.li...@gmail.com]
Sent: 14 December 2011 05:12
To: Hal Murray
Cc: nanog@nanog.org
Subject: Re: EFF call for signatures from Internet engineers against censorship

I would strongly suggest that operators work with their legal
departments to endorse this paper by Crocker and others.

If other ISP organizations (such as say MAAWG) come out with
something, other operators could sign on to that as well.

The EFF petition has way too much propaganda and far less content than
would be entirely productive in a policy discussion.

--srs


On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray  wrote:
>
>  Security and Other Technical Concerns Raised by the
>DNS Filtering Requirements in the PROTECT IP Bill
>  Authors:
>Steve Crocker, Shinkuro, Inc.
>David Dagon, Georgia Tech
>Dan Kaminsky, DKH
>Danny McPherson, Verisign, Inc.
>Paul Vixie, Internet Systems Consortium



--
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: EFF call for signatures from Internet engineers against censorship

[Suresh Ramasubramanian]

I would strongly suggest that operators work with their legal
departments to endorse this paper by Crocker and others.

If other ISP organizations (such as say MAAWG) come out with
something, other operators could sign on to that as well.

The EFF petition has way too much propaganda and far less content than
would be entirely productive in a policy discussion.

--srs


On Wed, Dec 14, 2011 at 12:51 PM, Hal Murray  wrote:
>
>  Security and Other Technical Concerns Raised by the
>    DNS Filtering Requirements in the PROTECT IP Bill
>  Authors:
>    Steve Crocker, Shinkuro, Inc.
>    David Dagon, Georgia Tech
>    Dan Kaminsky, DKH
>    Danny McPherson, Verisign, Inc.
>    Paul Vixie, Internet Systems Consortium



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: Sad IPv4 story?

[Mark Tinka]

On Wednesday, December 14, 2011 02:36:49 PM Don Gould wrote:

> I've been researching solutions with NAT and double NAT
> in mind because it's obvious that v4 space is going to
> become a growing problem.

We've started playing with Stateful NAT64 on a couple of 
Cisco ASR1006's. 

In general, it works okay, save for issues with applications 
that have no IPv6 support, e.g., Skype, e.t.c. We hope to 
find more issues as more customers sign up to be guinea 
pigs.

> The only thing that is really clear is the lack of 
> clarity.

Indeed. We're doing what we can to be part of the solution, 
by picking technologies we think will be useful for us and 
going out and testing them at scale, with a goal to start 
rolling out v6 in droves as well provide usable operator 
feedback re: our deployment to vendors and other operators 
alike.

As much as we'd like to see how the market unravels re: v4, 
e.t.c., the fact remains that v6 is the inevitable solution. 
So best to get cracking now with real deployments.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Your Christmas Bonus Has Arrived

[Mohacsi Janos]

On Tue, 13 Dec 2011, IPv4 Brokers wrote:


Do you have subnets that are  not in use, or only used for specific
purposes?  If so, please contact us.

We are paying up-front (or escrow) for the use of networks that are not
used.  The networks are used for honeypots and other research.

You do not have to modify your BGP announcements, establish a GRE tunnel to
our network and forward packets over the tunnel.

The networks may be used for a month or longer, you are paid an agreed upon
price per each month of use.

Your confidentiality is absolutely guaranteed.  Only you will know that
you're making money on your un-used or single/special-use networks.

We do require a minimum of /24.



And you remain responsible for malicious activity of IPv4 Brokers .

Regards,
Janos Mohacsi

Re: EFF call for signatures from Internet engineers against censorship

[Stephane Bortzmeyer]

On Tue, Dec 13, 2011 at 06:12:34PM -0800,
 Peter Eckersley  wrote 
 a message of 86 lines which said:

>   To date, the leading role the US has played in this infrastructure
>   has been fairly uncontroversial [sic and re-sic] because America
>   is seen as a trustworthy arbiter and a neutral bastion of free
>   expression.

I am just a lurker on Nanog since I do not operate a network in North
America and therefore I hesitated to sign the letter but this sentence
is too much: it means you cannot sign unless you endorse this
ridiculous propaganda. It's bad to use the fight for freedom of speech
in this way :-(