Hi
I am search one or more carrier for connect 3 sites in Brasil, Mexico
and Argentina to one of our pop
in USA or Spain.
if you have a name and contact ;=)
best regards
Olivier
Another big-name-big-$$$ vendor whose name begins with "C". Sounds like
a "c"onspiracy to me
On 11/14/2012 5:09 PM, Mark Gauvin wrote:
Careful though cause the crayons must be crayola approved
Sent from my iPhone
On 2012-11-14, at 5:28 PM, "joel jaeggli" wrote:
On 11/14/12 2:4
Careful though cause the crayons must be crayola approved
Sent from my iPhone
On 2012-11-14, at 5:28 PM, "joel jaeggli" wrote:
> On 11/14/12 2:40 PM, Joe Abley wrote:
>> On 2012-11-12, at 14:43, Jim Mercer wrote:
>>
>>> Is there a common practice of providers to vet / validate requests to
>>
On Wed, Nov 14, 2012 at 6:31 PM, Michael Smith wrote:
>
> On Nov 14, 2012, at 1:50 PM, William Herrin wrote:
>
>> On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote:
>>> I guess I'm confused. I have a /32 that I have broken up
>>> into /47's for my discrete POP locations. I don't have a
>>>
Hi,
" Again, I thought the discussion was about PI, not PA. I don't announce any
PA."
My point, which I feel may be getting lost, and for which ARIN may already have
policies in place for, is that an IP assignment is made out of a block with a
defined minimum assignment size.
Now some people
On Nov 14, 2012, at 1:50 PM, William Herrin wrote:
> On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote:
>> I guess I'm confused. I have a /32 that I have broken up
>> into /47's for my discrete POP locations. I don't have a
>> network between them, by design. And, I won't
>> announce the
On 11/14/12 2:40 PM, Joe Abley wrote:
On 2012-11-12, at 14:43, Jim Mercer wrote:
Is there a common practice of providers to vet / validate requests to advertise
blocks?
Yes, most providers whose customers request a particular route to be pointed
towards them will ask for ambiguous instructio
On 2012-11-12, at 14:43, Jim Mercer wrote:
> Is there a common practice of providers to vet / validate requests to
> advertise
> blocks?
Yes, most providers whose customers request a particular route to be pointed
towards them will ask for ambiguous instructions, written on letterhead with
c
On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith wrote:
> I guess I'm confused. I have a /32 that I have broken up
> into /47's for my discrete POP locations. I don't have a
> network between them, by design. And, I won't
> announce the /32 covering route because there is
> no single POP that can
On Wed, 14 Nov 2012 14:57:06 -0500, "Robert E. Seastrom"
wrote:
> Hi everyone,
>
> I'm looking for a gigabit ethernet media converter to go from SFP
> plugable optics to 802.3at POE+. The application involves wireless
> access points some distance from a central switch for a venue.
>
> Difficul
On Nov 14, 2012, at 10:06 AM, William Herrin wrote:
> On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler
> wrote:
>> Yes, nice. But... It does not address the case when this is
>> not the ISPs customers but the ISP (read content provider)
>> that operates globally but without a network interconne
Hi everyone,
I'm looking for a gigabit ethernet media converter to go from SFP
plugable optics to 802.3at POE+. The application involves wireless
access points some distance from a central switch for a venue.
Difficulty: in my old age, I've become allergic to installing
completely unmanaged bum
Well I guess someone is already working on it, +1
Since this is a relay-only message, though. I think it would be
better as a sub-option of RFC 6422 with a requirement that
relay-agents drop the option if the client tries to source it. But, I
guess it's splitting hairs.
On Wed, Nov 14, 2012
On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler
wrote:
> Yes, nice. But... It does not address the case when this is
>not the ISPs customers but the ISP (read content provider)
>that operates globally but without a network interconnecting
>their routers.
Hi Ben,
That case is covered by things l
What about
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03
?
--
Tim
On 14 Nov 2012, at 17:46, Ray Soucy wrote:
> Saw yet another attempt at a solution pop up to try and deal with the
> lack of a MAC address in DHCPv6 messages.
>
> I've been giving this some tho
In a message written on Wed, Nov 14, 2012 at 01:10:57PM +, Ben S. Butler
wrote:
> I am hoping for a bit of advice. We are rolling out IPv6 en mass now to
> peers and I am finding that our "strict" IPv6 ingress prefix filter is
> meaning a lot of peers are sending me zero prefixes. Upon inv
FWIW ISC DHCPd listens on raw sockets.
On Tue, Nov 6, 2012 at 11:12 AM, George Herbert
wrote:
> Oh, horrors, part of my infrastructure needs raw socket data?
>
> We should ban that, for security. Who needs those pesky switches anyways?
>
>
> George William Herbert
> Sent from my iPhone
>
> On No
Saw yet another attempt at a solution pop up to try and deal with the
lack of a MAC address in DHCPv6 messages.
I've been giving this some thought about how this should be best
accomplished without requiring that host implementations of DHCPv6 be
modified.
Taking advantage of the relay-agent seems
On 11/14/2012 8:08 PM, Ben S. Butler wrote:
> Hi,
>
> Yes, nice. But... It does not address the case when this is not the ISPs
> customers but the ISP (read content provider) that operates globally but
> without a network interconnecting their routers. They then advertise a /24
> v4 and /48 v
Hi,
Yes, nice. But... It does not address the case when this is not the ISPs
customers but the ISP (read content provider) that operates globally but
without a network interconnecting their routers. They then advertise a /24 v4
and /48 v6 at each Internet exchange that they are connected to.
On 11/14/2012 6:02 PM, William Herrin wrote:
> and send a polite email to the POC to the effect of, "Please beware
> that because you have not offered a covering route matching your
> allocation, your IPv6 network is not reachable from ours. IPv6 is not
> IPv4: end users requiring /48s for multiho
On Wed, Nov 14, 2012 at 8:10 AM, Ben S. Butler
wrote:
> So what is the "best" answer.
>
>
> 1> Don't advertise islands of space under assignment minimum, without
> providing a covering aggregate route?
>
> 2> Don't use strict filters, they don't work well and de-agragegation
> with IPv6
Are these UPS units going inside the racks? Would it not be better to do
something in the power room with an inverter on the circuits that feed the
racks, such as a large Outback unit with sufficient battery capacity?
http://www.amazon.com/OutBack-Inverter-3600-Watts-Volt/dp/B002MWAAYU
With one de
Hi,
Yes, but a multi-homing customer would have PI space from an appropriately
filtered block allowing /24 PI v4 or /48 PI v6. An ISP would have their own
RIR PA allocation /22 to /19 v4 or /29, /32 v6 block that are from blocks that
follow along the lines of minimum assignment size for that b
I've had issues and experience with many types of UPSes, including HP (probably
OEM'd from someone else), APC, EATON/Powerware, and Liebert/Emerson. I keep
coming back to APC. Solid units, and are always slightly 'ahead' in
technology. Sure, I've seen each model have failures and even faults
On Wed, Nov 14, 2012 at 6:40 PM, Ben S. Butler wrote:
>
> 3> Don't use filters, generate it from an IRR?
>
> Given there is no "right" answer what is considered to be the best fit one?
This sounds like your best bet. Assuming you can find an IRR with
comprehensive enough coverage.
The othe
Hi,
I am hoping for a bit of advice. We are rolling out IPv6 en mass now to peers
and I am finding that our "strict" IPv6 ingress prefix filter is meaning a lot
of peers are sending me zero prefixes. Upon investigation I determine they
have de-agregrated their /32 for routing reasons / non in
27 matches
Mail list logo
