The deadline for nominations for the NANOG Steering Committee is tomorrow, at
11:59 PM EDT on Monday, August 30.
If you are interested in running for an SC position, or know someone who might
be a good candidate, please send the nomination to nominati...@nanog.org. More
details are below.
Thi
> Every BGP message header has a portion that starts with 16
> all-bits-1 octets, for compatibility.
> This is distinctive enough an implementation can guess where the next
> message starts.
i desperately feared reading this. i do not want to bet the internet on
guessing where anythings starts
On Sun, Aug 29, 2010 at 3:12 PM, Thomas Mangin
wrote:
> However to make sense you would need to find a resynchronisation point to
> only exclude the one faulty message. Initially I thought that the last
> received KEEPALIVE (for the receiver of the error message) could do - but you
> find yours
As the 6to4 is an "default" option on Apple Airport Extreme to enable ipv6, I
would have thought that Apple would have provided a few gateways? Same for
Microsoft that has it in its OS?
Reminds me of the ntp servers issue built in on some devices...
> It would seem to me that there should actually be a better option, e.g.
> recognizing the malformed update, and simply discarding it (and sending the
> originator an error message) instead of resetting the session.
>
> Resetting of BGP sessions should only be done in the most dire of
> circumsta
> It seems that creating a worst case BGP test suite for all kinds of nastiness
> (in light of the recent RIPE thing) might not be a bad idea - so that we can
> all test the implementation ourselves before we deploy new code.
Normally those things are done by vendors - that what we pay them good
Before we turned up our own relays the closest 6to4 relay was a single relay
hosted by a mid-western university. Regardless where the next closest
relays are located deploying our own resulted in improvements (as you
pointed out below).
John
On 8/29/10 12:24 PM, "Joel Jaeggli" wrote:
> On 8/2
On 8/27/10 1:07 PM, Mike Gatti wrote:
> where's the change management process in all of this.
> basically now we are going to starting changing things that can
> potentially have an adverse affect on users without letting anyone know
> before hand Interesting concept.
BGP is transitive, cha
On 8/29/10 9:31 AM, Bjørn Mork wrote:
> Richard A Steenbergen writes:
>
>> Just out of curiosity, at what point will we as operators rise up
>> against the ivory tower protocol designers at the IETF and demand that
>> they add a mechanism to not bring down the entire BGP session because of
>>
On 8/29/10 3:23 AM, Mikael Abrahamsson wrote:
On Sat, 28 Aug 2010, Brett Frankenberger wrote:
The implementor is to blame becuase the code he wrote send out BGP messages
which were not properly formed.
People talk about not dropping sessions but instead dropping malformed
messages. This is
Richard A Steenbergen writes:
> Just out of curiosity, at what point will we as operators rise up
> against the ivory tower protocol designers at the IETF and demand that
> they add a mechanism to not bring down the entire BGP session because of
> a single malformed attribute? Did I miss the m
On 8/29/10 6:25 AM, John Jason Brzozowski wrote:
> Franck,
>
> As you know 6to4 is enabled by default in many cases and is used perhaps
> more than folks realize. Because of this and other observations we decided
> to deploy our own relays.
Right prior to this the nearest 6to4 relay router from
John Jason Brzozowski writes:
> This does not alter our plans for our native dual stack trials, in fact, I
> hope to have more news on this front soon.
comcast native dual stack is working fine at my house.
"traceroute6 -q1 mol.redbarn.org" shows details.
On Sun, Aug 29, 2010 at 12:30:21AM -0700, Paul Ferguson wrote:
>
> It would seem to me that there should actually be a better option, e.g.
> recognizing the malformed update, and simply discarding it (and sending the
> originator an error message) instead of resetting the session.
>
> Resetting o
Mikael,
I agree with your points and echoed them in my earlier reply. 6to4 is out
there and is likely not to go away any time soon. Folks should definitely
see what 6to4 relay they default to, you might be surprised (or not).
FWIW - I updated ARIN's wiki for 6to4 relay deployment with some gene
Franck,
As you know 6to4 is enabled by default in many cases and is used perhaps
more than folks realize. Because of this and other observations we decided
to deploy our own relays.
This does not alter our plans for our native dual stack trials, in fact, I
hope to have more news on this front so
On Aug 29, 2010, at 2:30 PM, Paul Ferguson wrote:
> It would seem to me that there should actually be a better option, e.g.
> recognizing the malformed update, and simply discarding it (and sending the
> originator an error message) instead of resetting the session.
Generation of the error mes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 29, 2010 at 12:35 AM, Adrian Chadd
wrote:
> Guys/girls/furry-creatures-from-!Earth,
>
> Complaining on nanog-ml is likely to only achieve personal stress relief.
>
> This is something you should bring up with your vendor. Say that you'll
Guys/girls/furry-creatures-from-!Earth,
Complaining on nanog-ml is likely to only achieve personal stress relief.
This is something you should bring up with your vendor. Say that you'll
move vendors if they don't start making "better" BGP implementations and
adding the features you guys want. Mak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Aug 29, 2010 at 12:23 AM, Mikael Abrahamsson
wrote:
> On Sat, 28 Aug 2010, Brett Frankenberger wrote:
>
>> The implementor is to blame becuase the code he wrote send out BGP
>> messages which were not properly formed.
>
> People talk about no
> This was *silent* error/corruption. I'm not sure I prefer to have
> silent problems instead of tearing down the session which is
> definitely noticable.
i call the silent fix "do-gooder software." it means to do good. when
it works, nobody notices or says thanks. when it fails, there is hell
On Sat, 28 Aug 2010, Brett Frankenberger wrote:
The implementor is to blame becuase the code he wrote send out BGP
messages which were not properly formed.
People talk about not dropping sessions but instead dropping malformed
messages. This is not safe. We've seen ISIS (which is TLV based an
On Sat, 28 Aug 2010, John Jason Brzozowski wrote:
In most cases, we observed that 6to4-enabled operating systems and devices
were attempting to use a 6to4 relay infrastructure hosted by a midwestern
university.
Before that they used our (Tele2) 6to4 relays in Amsterdam and Paris. I
think this
23 matches
Mail list logo
