- Original Message -
> From: "Matt Palmer"
> Fun times indeed. "Once is happenstance, twice is coincidence..."
And for the few who don't recall the last stanza -- and this is looking
less and less by the month like it requires an aluminium foil fedora to
buy as a justification:
"Three t
I have worked for the middle network when I was responsible for a
government network - typically we were the middle network. Logic was it
was good for citizens for us to essentially act like a peering exchange for
certain types of entity (who also typically were government affiliated).
One I can t
On Wed, 05 Mar 2014 21:48:26 +, "Siegel, David" said:
> I can't think of any circumstances where the business "B" would be content
> transit traffic between A and C without some form of compensation. That
> compensation may not involve payment for bits, however.
If ASN B is a cooperative vent
Been spending most of the day scrubbing away that vuln in my facility
here now here's the fun part: imagine just how many embedded devices
(most of which get orphaned from a software maintenance perspective the
moment they hit the store shelves) are gonna have this flaw. There's been
the discus
The AS I worked at back in the day did to a degree for willing parties.
Mostly small ISPs who all knew each other. We had at the time 3 regional
hub locations with interlinks, and peered settlement free with 2 - 3 ASs in
1 of the locations, and 1-2 ASs each in the other 2 locations, all of which
co
Doing some serious adjusting of my tinfoil today over his :)
-jim
On Wed, Mar 5, 2014 at 5:03 PM, Jay Ashworth wrote:
> - Original Message -
> > From: "Leo Bicknell"
>
> > On Mar 4, 2014, at 9:07 PM, Jay Ashworth wrote:
> >
> > > Is this the *same* bug that just broke in Apple code l
I can't think of any circumstances where the business "B" would be content
transit traffic between A and C without some form of compensation. That
compensation may not involve payment for bits, however. In theory, the
compensation might be derived from something occurring at the application
l
Thank you to the on and off lists replies. The DNS servers are not my
choice to have them that way. But I will mention that to my client.
It looks like Cox is now resolving things as it should be for this domain.
Sincerely,
Mark Keymer
CFO/COO
Vivio Technologies
On 3/5/2014 4:52 AM, Rob Seastr
On Wed, Mar 5, 2014 at 4:00 PM, wrote:
> On Wed, 05 Mar 2014 15:23:55 -0500, William Herrin said:
>> Can anyone tell me about a situation in which a route which was not
>> valley free was not a result of a misconfiguration or a bad actor? For
>> those who don't recall the terminology, a network p
- Original Message -
> From: "Leo Bicknell"
> On Mar 4, 2014, at 9:07 PM, Jay Ashworth wrote:
>
> > Is this the *same* bug that just broke in Apple code last week?
>
> No, the Apple bug was the existence of an /extra/ "goto fail;".
>
> The GnuTLS bug was that it was /missing/ a "goto
On Wed, 05 Mar 2014 15:23:55 -0500, William Herrin said:
> Hi folks,
>
> Can anyone tell me about a situation in which a route which was not
> valley free was not a result of a misconfiguration or a bad actor? For
> those who don't recall the terminology, a network path is valley free
> if it cross
On 3/4/14, 2:38 PM, Brielle Bruns wrote:
Hello all,
Don't suppose there's any CenturyLink engineers/tech people on this list
that can look into a problem with their IPv6 6rd service?
Thanks for the off-list replies. Think I've got the issues figured out.
6rd behaves a lot like 6to4 in how
Hi folks,
Can anyone tell me about a situation in which a route which was not
valley free was not a result of a misconfiguration or a bad actor? For
those who don't recall the terminology, a network path is valley free
if it crosses exactly zero or one free peering links when traveling
between the
On Mar 4, 2014, at 9:07 PM, Jay Ashworth wrote:
> Is this the *same* bug that just broke in Apple code last week?
No, the Apple bug was the existence of an /extra/ "goto fail;".
The GnuTLS bug was that it was /missing/ a "goto fail;".
I'm figuring the same developer worked on both, and just p
Hi,
I've been working on a basic configuration for E-OAM starting with one
domain. I have CFM working between the PEs (IOS-XR) devices tied to an
EoMPLS instance, but have a few questions below:
1) I "think" I should be seeing MIPs in my traceroute when there is a P
router in between the two PEs,
"Paul S." writes:
> For all it's worth, it might be Cox ignoring TTLs and enforcing their
> own update times instead.
>
> Wait 24-48 hours, and it should probably fix it all up.
Possibly.
> I'm not seeing anything majorly broken with your system except the SOA
> EXPIRE being ridiculously large
16 matches
Mail list logo
