ISC DHCPD

[Butch Evans]

I have a cisco cmts that forwards dhcp requests to an ISC dhcp server.
I have a working configuration for this.  I am trying to set up ISC
DHCPD so that it can handle multiple shared-networks.  I cannot seem to
get this working correctly.  If there is an expert "in the house" who
can offer me a few minutes of your time to look over a configuration for
me, please send me a phone number/email offlist and I'll discuss
specifics.  

-- 

* Butch Evans   * Professional Network Consultation*
* http://www.butchevans.com/* Network Engineering  *
* http://store.wispgear.net/* Wired or Wireless Networks   *
* http://blog.butchevans.com/   * ImageStream, Mikrotik and MORE!  *

Re: [c-nsp] L2VPN with IP address

[Engine Networks | Luca Simonetti]

 Just pay attention to MTU with GRE tunnel and packet fragmentation.

--
Luca Simonetti

Engine Networks

http://www.enginenetworks.net

Datacenter GENEVA 1: Rue de la Confédération, 6 1204 Geneve - CH
Datacenter ZURICH 1: Josefstrasse, 225 - 8005 Zürich - CH
Datacenter MILAN 1: Caldera, 21 - 20100 Milan - IT

Re: On another security note... (of sorts)

[Sean Donelan]

On Thu, 15 Jul 2010, valdis.kletni...@vt.edu wrote:

On Thu, 15 Jul 2010 13:46:24 EDT, "J. Oquendo" said:

RFP anyone.. Botnet Mitigation for Networks surely collectively it would
and CAN work.


A nice idea, but consider if a more automated tool/system was created to
behead a botnet (50,000 null0 routes to blackhole all the nodes? Or accept
collateral damage? etc).  Now consider that jujutsu is designed around using
the opponent's energy against him.

How can this possibly go wrong? :)



Damned if they do, Damned if they don't.

It seems like every 4-6 weeks people alternate between ISPs are bad 
because they don't try to prevent X, Y or Z; and then 4-6 weeks later

ISPs are bad because they tried to prevent A, B or C.  It doesn't matter
what A, B, C or X, Y, Z are; it must be the ISPs fault.

Everyone agrees that ISPs are bad, they just disagree about what ISPs
are supposed to do about whatever.

And so it goes...

Re: Vyatta as a BRAS

[Valdis . Kletnieks]

On Thu, 15 Jul 2010 20:57:15 PDT, Henry Linneweh said:

Your definitions seem to be rather ATM-specific, which may be a bit of a
problem in a world dominated by Ethernet...

> Can we get a consensus definition on these definition's and what hardware 
> vender's make edge routers and what hardware vender's make core routers.

I got a router, it's got 5-6 10GE interfaces talking to other routers on
my network backbone, and a bunch of 10GE links to end-user-facing aggregation
switches. Since it's only forwarding inside my network, it's a core router
by your definition.

I now turn up an identical hardware 10GE link - connected to Level3. I just
became an edge router by your definition since I'm talking to another network.
(I know, I probably don't want to do that - but I *could*, maybe even without
a full BGP feed if the routing situation allows. The point is the definition
is busticated).

Adding to the confusion is the fact that the edge routers of some large 
providers
need more capacity than the core routers of smaller organizations

Maybe we need to ditch the terms edge and core, and instead talk about:

1/4" plastic tubing - 
http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nut.jpg
garden hose - 
http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg
fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg
NYC Delaware Aqueduct - 
http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/

Everybody good with that? ;)

(Man.. it *leaks* 15 million gallons a day. That's capacity. :)


pgp7S3BXcEYfv.pgp
Description: PGP signature

Re: On another security note... (of sorts)

[J. Oquendo]

Sean Donelan wrote:
>
> Damned if they do, Damned if they don't.
>
> It seems like every 4-6 weeks people alternate between ISPs are bad
> because they don't try to prevent X, Y or Z; and then 4-6 weeks later
> ISPs are bad because they tried to prevent A, B or C.  It doesn't matter
> what A, B, C or X, Y, Z are; it must be the ISPs fault.
>
> Everyone agrees that ISPs are bad, they just disagree about what ISPs
> are supposed to do about whatever.
>
> And so it goes...
>
>
Odd, I definitely don't recall saying outright ISP's are bad. More to
the tune of "ISP's can do more given they're in the best position to do
so..." which brings things full-circle, what can be done? How about an
RFC, then building from there. Anyone can comment about the potential of
"I'm not adding hundreds of thousands of null0's to my Cisco!@" and the
point would be missed. As an NSP/NAP/ISP (pick your poison), you have
the potential to see where your machines are connecting to. And I don't
mean snooping their traffic outright, but its as simple as keeping tabs
on a "destination", if you KNOW and it has been CONFIRMED, that the
destination is a known purveyor "of un-fine" goods, wouldn't you like to
potentially help your clients before they become zombiefied?

If there was a method for operators to obtain information and share it,
(think an unbiased, validated, "most wanted" list) do you really want to
state that you wouldn't care about it, you couldn't use it. Surely I'd
like to use something similar and if I were in a position to do
something on a massive scale to eliminate bad traffic from 1) reaching
my customers (since money is obvious the main concern) and 2) from
making sure my customers don't affect your customers (YOUR money), I
would jump up and down on it doing whatever I could.

So it's not the ISP's are bad (at least to me they're not), it's more
like "ISP OPERATORS/OWNERS are too busy fighting AGAINST things like
this from happening, often spending more time and effort against it,
then they are trying to collaboratively solve a problem."

Analogy: "ALL gunmakers have seen their firearms mistakenly fire off at
will (purposefully or accidentally). They all agree that by putting a
safety mechanism, the rates of fatalities and injuries will go down.
Some choose not to, because after all, they would need to spend more
money to do so... Many protest against it: Smith and Wesson doesn't have
that, why should I?!... Fatalities continue and gunmakers complain: All
gunmakers are bad right, sure... uh-huh"

What's wrong with that analogy. What about responsibility. Forget the
politricks for a moment and think about the *ultimate* bottom line
here... Would you like to prevent someone from possibly wrecking havoc
on your personal bank account? Remember, what goes around comes around.
You're not only doing neighbors (peers) a favor but if collectively the
same approach was taken by many, there would be less "dirty traffic"
around. No one on this list can seriously counter this claim. We can get
into: "oh yea smart ass... They could encry...@... They could fast
flux!!!, they could..." Guess what? What is anyone going to do when they
can't connect?

E.g:
src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net)
My_NSP(hourly) ---> Mega_Peer_Dirty_Host_Watcher --> get_list_apply_filter

Result:

src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net) -->
My_Provider --> ::1

Anyway, just a thought, maybe a far out there thought, but I truly
believe it can be done at an upstream level with little to no cost. I
believe it costs more to sit around complaining and doing nothing than
it does when you start losing customers because someone compromised them
and wiped out their accounts driving them to bankruptcy.
(http://krebsonsecurity.com/2010/02/n-y-firm-faces-bankruptcy-from-164000-e-banking-loss/)

-- 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT

"It takes 20 years to build a reputation and five minutes to
ruin it. If you think about that, you'll do things
differently." - Warren Buffett

227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E

Re: Vyatta as a BRAS

[Joe Greco]

> I got a router, it's got 5-6 10GE interfaces talking to other routers on
> my network backbone, and a bunch of 10GE links to end-user-facing aggregation
> switches. Since it's only forwarding inside my network, it's a core router
> by your definition.
> 
> I now turn up an identical hardware 10GE link - connected to Level3. I just
> became an edge router by your definition since I'm talking to another network.
> (I know, I probably don't want to do that - but I *could*, maybe even without
> a full BGP feed if the routing situation allows. The point is the definition
> is busticated).
> 
> Adding to the confusion is the fact that the edge routers of some large 
> providers
> need more capacity than the core routers of smaller organizations

There's a problem here in that some people want 'core router' to mean
'biggest fscking router', while other people want a functional 
definition that explains a router's role in the design of a network.

For an enterprise, for example, it doesn't make sense for them to have
a router in the middle of their network and then tell them "but you can
not call it your core router, because that term is reserved for routers
with 200g or more capacity per slot (Jared's def'n)."

I'm going to submit that the "big fscking router" definition is stupid
and meaningless, because today's big fscking router is tomorrow's small
aggregation router, and then a few years later just a coffee table stand.
Hello, 7513 from .. what, 1995?  :-)

A more customary understanding of border, core, etc., can be found in
places like RFC4098.

Generally speaking, a core router is an internal router, i.e. one that
speaks only to other devices/endpoints/whatever in the same AS.  Various
refinements to the definition might want it to speak BGP, etc.

That definition is very reasonable.  A small enterprise with a DS3 to the
'net has a border router that connects them to their ISP, which connects
to a firewall/IDS that protects their net, and then a core router that
connects all their internal networks and links to the firewall for 
external connectivity.  You could talk to most network engineers and 
they'd understand the terminology without further explanation.

There are of course problems with the core and border definitions as
well, of course, such as what happens when you connect a core router
interface to an upstream and you wind up with a mongrel.  However, the
"core means bfr" definition strikes me as singularly useless and
something that's really more marketingspeak from router vendors who
would like you to think of these routers powering the core of the
Internet, or whatever.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Vyatta as a BRAS

[Lamar Owen]

On Thursday, July 15, 2010 02:24:06 pm Łukasz Bromirski wrote:
> (and I'm all for FreeBSD boxes, don't get me wrong, the whole point
>   of this discussion is that either you're doing hardware forwarding
>   and you're pretty safe [unfortunately often with a lot of caveats,
>   but still], or you're doing software forwarding and you have
>   a nice attack vector open for anyone willing)

This distills one of the points of view nicely.

An operationally useful question is to ask (yourself) at what point (bandwidth- 
and type of traffic- speaking) does a particular box become vulnerable? 10Mb/s? 
 100Mb/s?  1Gb/s? 100Gb/s? Traffic directed at the control plane?  Small packet 
traffic?  Any traffic?  

Any box; hardware-based or software-based is irrelevant, because at some data 
volume all boxes become vulnerable; the variance is only in what volume the box 
can handle and how well the control plane is protected from that volume.  Test 
with reasonable traffic loads (and drawing on the collective wisdom of this 
group as to what is 'reasonable' for a BRAS is good!), and derive conclusions 
that fit your need. Knowing these things allows you to scale your solution to 
avoid the majority of the problems and buy what fits your projected scale over 
the design life of the solution. 

Take a 2003-vintage OSR7609 (Sup2/MSFC2) still running 12.1E.  Definitely a 
hardware-based router.  Does it have a nice attack vector?  Perhaps.  Is this 
combination still in use?  I'm not sure I want to know (Sup2/MSFC2 is, I know; 
the 12.1E part is the scary one). 

Hardware-based is not a magic bullet that destroys attack vectors dead in their 
tracks (as Łukasz hints at with the parenthetical caveats remark).  And 
software-based is not defenseless, either.

Root Zone DNSSEC Deployment Technical Status Update

[Joe Abley]

Root Zone DNSSEC Deployment
Technical Status Update 2010-07-16

This is the twelfth of a series of technical status updates intended
to inform a technical audience on progress in signing the root zone
of the DNS.


RESOURCES

Details of the project, including documentation published to date,
can be found at .

We'd like to hear from you. If you have feedback for us, please
send it to roots...@icann.org.


FULL PRODUCTION SIGNED ROOT ZONE

The transition from Deliberately-Unvalidatable Root Zone (DURZ) to
production signed root zone took place on 2010-07-15 at 2050 UTC. The
first full production signed root zone had SOA serial 2010071501. There
have been no reported harmful effects.  The root zone trust anchor can
be found at .


PLANNED DEPLOYMENT SCHEDULE

Already completed:

  2010-01-27: L starts to serve DURZ

  2010-02-10: A starts to serve DURZ

  2010-03-03: M, I start to serve DURZ

  2010-03-24: D, K, E start to serve DURZ

  2010-04-14: B, H, C, G, F start to serve DURZ

  2010-05-05: J starts to serve DURZ

  2010-06-16: First Key Signing Key (KSK) Ceremony

  2010-07-12: Second Key Signing Key (KSK) Ceremony

  2010-07-15: Distribution of validatable, production, signed root
zone; publication of root zone trust anchor

Re: On another security note... (of sorts)

[Lamar Owen]

On Thursday, July 15, 2010 02:40:50 pm Michael Holstein wrote:
> > Why is it that network operators can't work together
> > on instances like this and have a "botnet killswitch" 

> Trust (or lack thereof).

That's certainly one of the biggest non-technical reasons.  Others go by the 
acronyms NIH and NIMBY.

But to me it boils down to some hard questions: what is a botnet, who gets to 
make that definition, what is a killswitch, and who is allowed to push it?

I'm sure the collective wisdom here is capable of pulling the task off at least 
in theory; the hard part would be deciding whether to do it in hardware or 
software

Re: Root Zone DNSSEC Deployment Technical Status Update

[Leo Bicknell]

In a message written on Fri, Jul 16, 2010 at 02:35:39PM +, Joe Abley wrote:
> The transition from Deliberately-Unvalidatable Root Zone (DURZ) to
> production signed root zone took place on 2010-07-15 at 2050 UTC. The
> first full production signed root zone had SOA serial 2010071501. There
> have been no reported harmful effects.  The root zone trust anchor can
> be found at .

Perhaps you could explain why the keys are being made available in
formats that, as far as I can tell, no nameserver software on the
planet uses?  Pretty much 100% of the users will need a conversion
from one of the 6 formats you provided, when you could have provided
6 example configs for the 6 most popular nameserver packages and
covered 99% of the users with cut and paste.

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


pgpB5VodXXPzu.pgp
Description: PGP signature

Re: Root Zone DNSSEC Deployment Technical Status Update

[Steven Bellovin]

Wonderful news!

Re: Root Zone DNSSEC Deployment Technical Status Update

[Mike]

Leo Bicknell wrote:


Perhaps you could explain why the keys are being made available in
formats that, as far as I can tell, no nameserver software on the
planet uses?  Pretty much 100% of the users will need a conversion
from one of the 6 formats you provided, when you could have provided
6 example configs for the 6 most popular nameserver packages and
covered 99% of the users with cut and paste.

  
Ditto. Rapid deployment follows where cut-and-past mostly works to 
implement.

(for better or worse)

Re: Root Zone DNSSEC Deployment Technical Status Update

[Chris Adams]

Once upon a time, Leo Bicknell  said:
> Perhaps you could explain why the keys are being made available in
> formats that, as far as I can tell, no nameserver software on the
> planet uses?  Pretty much 100% of the users will need a conversion
> from one of the 6 formats you provided, when you could have provided
> 6 example configs for the 6 most popular nameserver packages and
> covered 99% of the users with cut and paste.

There aren't 6 formats, there is just one format provided for the
current trust anchor set: XML.  A simple XSLT will transform it into any
needed format.

Individual trust anchors (there's only one at the moment) are provided
in two formats: PKCS#10 (for signing) and X509 (signed by ICANN).  There
are also detached signatures (in PKCS#7 format for validation against
the ICANN cert bundle and in OpenPGP format) of the XML anchor set file.

This is all in the documentation in the same directory (in plain-text
and HTML formats).
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Root Zone DNSSEC Deployment Technical Status Update

[Edward Lewis]

At 7:53 -0700 7/16/10, Leo Bicknell wrote:


Perhaps you could explain why the keys are being made available in
formats that, as far as I can tell, no nameserver software on the
planet uses?


(My guess:)

There's no standard input format for name servers, especially 
regarding configuration information.  The problem isn't (just) that 
the root anchor isn't in the format for any name server, the problem 
is that name servers can't read the formats given.


If you want it for BIND, for example, ISC would be the place to get 
it in the "trusted-keys" syntax.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.

Re: Vyatta as a BRAS

[Tony Li]

On Jul 16, 2010, at 6:02 AM, valdis.kletni...@vt.edu wrote:

> 1/4" plastic tubing - 
> http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nut.jpg
> garden hose - 
> http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg
> fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg
> NYC Delaware Aqueduct - 
> http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/


So, you finally admit it.

The Internet is just a bunch of tubes.

;-)

Tony

Re: Vyatta as a BRAS

[Joel Jaeggli]

On 7/16/10 6:02 AM, valdis.kletni...@vt.edu wrote:

On Thu, 15 Jul 2010 20:57:15 PDT, Henry Linneweh said:

Can we get a consensus definition on these definition's and what hardware
vender's make edge routers and what hardware vender's make core routers.


I got a router, it's got 5-6 10GE interfaces talking to other routers on
my network backbone, and a bunch of 10GE links to end-user-facing aggregation
switches. Since it's only forwarding inside my network, it's a core router
by your definition.

I now turn up an identical hardware 10GE link - connected to Level3. I just
became an edge router by your definition since I'm talking to another network.
(I know, I probably don't want to do that - but I *could*, maybe even without
a full BGP feed if the routing situation allows. The point is the definition
is busticated).


There's also virtualization due to the ubiquitous deployment of VRF's 
moderate to size extra-large routers are entirely likely to be serving 
in multiple roles.



Adding to the confusion is the fact that the edge routers of some large 
providers
need more capacity than the core routers of smaller organizations

Maybe we need to ditch the terms edge and core, and instead talk about:

1/4" plastic tubing - 
http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nut.jpg
garden hose - 
http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg
fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg
NYC Delaware Aqueduct - 
http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/

Everybody good with that? ;)

(Man.. it *leaks* 15 million gallons a day. That's capacity. :)

virtual switches

[Greg Whynott]

Cisco has VSS (on 6500 class) and H3C has IRF;   allowing you to virtualize 2 
or more physical switches/routers in an active/active configuration where you 
can use all links and terminate LACP aggregates between the two devices.   Is 
anyone using this or similar technology from another vendor?   any 
recommendations or comments would be appreciated.  thanks very much for your 
time!

-g

Re: Root Zone DNSSEC Deployment Technical Status Update

[Tony Finch]

On Fri, 16 Jul 2010, Chris Adams wrote:
>
> A simple XSLT will transform it into any needed format.

XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
TYNE DOGGER FISHER: SOUTHERLY VEERING WESTERLY 5 TO 7, DECREASING 4 OR 5.
MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH AT FIRST IN FISHER, BECOMING SLIGHT
OR MODERATE. SQUALLY, THUNDERY SHOWERS. MODERATE OR GOOD.

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG and
the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 17 Jul, 2010

Report Website: http://thyme.apnic.net
Detailed Analysis:  http://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  325312
Prefixes after maximum aggregation:  149926
Deaggregation factor:  2.17
Unique aggregates announced to Internet: 159012
Total ASes present in the Internet Routing Table: 34366
Prefixes per ASN:  9.47
Origin-only ASes present in the Internet Routing Table:   29833
Origin ASes announcing only one prefix:   14455
Transit ASes present in the Internet Routing Table:4533
Transit-only ASes present in the Internet Routing Table:100
Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  25
Max AS path prepend of ASN (41664)   21
Prefixes from unregistered ASNs in the Routing Table:   308
Unregistered ASNs in the Routing Table: 118
Number of 32-bit ASNs allocated by the RIRs:686
Prefixes from 32-bit ASNs in the Routing Table: 825
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:166
Number of addresses announced to Internet:   2276042112
Equivalent to 135 /8s, 169 /16s and 165 /24s
Percentage of available address space announced:   61.4
Percentage of allocated address space announced:   66.2
Percentage of available address space allocated:   92.8
Percentage of address space in use by end-sites:   83.8
Total number of prefixes smaller than registry allocations:  154768

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:78953
Total APNIC prefixes after maximum aggregation:   27110
APNIC Deaggregation factor:2.91
Prefixes being announced from the APNIC address blocks:   75847
Unique aggregates announced from the APNIC address blocks:33498
APNIC Region origin ASes present in the Internet Routing Table:4111
APNIC Prefixes per ASN:   18.45
APNIC Region origin ASes announcing only one prefix:   1138
APNIC Region transit ASes present in the Internet Routing Table:633
Average APNIC Region AS path length visible:3.6
Max APNIC Region AS path length visible: 15
Number of APNIC addresses announced to Internet:  531282208
Equivalent to 31 /8s, 170 /16s and 185 /24s
Percentage of available APNIC address space announced: 79.2

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
   55296-56319, 131072-132095
APNIC Address Blocks 1/8,  14/8,  27/8,  43/8,  58/8,  59/8,  60/8,
61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
   182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
   219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:134218
Total ARIN prefixes after maximum aggregation:69466
ARIN Deaggregation factor: 1.93
Prefixes being announced from the ARIN address blocks:   107063
Unique aggregates announced from the ARIN address blocks: 41911
ARIN Region origin ASes present in the Internet Routing Table:13792
ARIN Prefixes per ASN: 7.76
ARIN Region origin ASes announcing only one prefix:5279
ARIN Region transit ASes present in the Internet Routing Table:1357
Average ARIN Region AS path length visible: 3.4
Max ARIN Region AS path length visible:  22
Number of ARIN addresses announced to Internet:   729625120

Re: Root Zone DNSSEC Deployment Technical Status Update

[Joel Jaeggli]

On 7/16/10 11:07 AM, Tony Finch wrote:

On Fri, 16 Jul 2010, Chris Adams wrote:


A simple XSLT will transform it into any needed format.


XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.

Tony.


anchors2keys will.

Re: Root Zone DNSSEC Deployment Technical Status Update

[Chris Adams]

Once upon a time, Tony Finch  said:
> On Fri, 16 Jul 2010, Chris Adams wrote:
> > A simple XSLT will transform it into any needed format.
> 
> XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.

That sounds like a problem with BIND then. :-)
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: NOC Best Practices

[Kasper Adel]

Thanks for all the people that replied off list, asking me to send them
responses i will get.

I got nothing other than :
http://www.nanog.org/meetings/nanog24/abstracts.php?pt=OTM1Jm5hbm9nMjQ=&nm=nanog24
and

Network Management-  Accounting and Performance Strategies - Just the first
three chapters

Which is useful but i am looking for more stuff from the best people that
run the best NOCs in the world.

So i'm throwing this out again.

I am looking for pointers, suggestions, URLs, documents, donations on what a
professional NOC would have on the below topics:

1) Briefly, how they handle their own tickets with vendors or internal
2) How they create a learning environment for their people (Documenting
Syslog, lessons learned from problems...etc)
3) Shift to Shift hand over procedures
4) Manual tests  they start their day with and what they automate (common
stuff)
5) Change management best practices and working with operations/engineering
when a change will be implemented

Should i be looking for ITIL stuff or its not any good?

Thanks,
Kim

On Wed, Jul 14, 2010 at 8:24 PM, Kasper Adel  wrote:

> Hello Everyone,
>
> I am currently working on building a NOC so i'm looking for
> materials/pointers to Best Practices documented out there.
>
> On the top of my head are things like:
>
> 1) Documenting Incidents and handling them
> 2) Documenting Syslog messages
> 3) Documenting Vendor Software Bugs
> 4) Shift to Shift Hand over procedures
> 5) Commonly used scripts for monitoring
> 6) Frequently testing High Availability
> 7) Capturing config changes.
> etc
>
> I can see that this is years of experience but i am wondering if any of
> this was captured some where.
>
> Thanks,
> Kim
>

Re: ISC DHCPD

[Butch Evans]

On Fri, 2010-07-16 at 02:10 -0500, Butch Evans wrote: 
> I have a cisco cmts that forwards dhcp requests to an ISC dhcp server.
> I have a working configuration for this.  I am trying to set up ISC
> DHCPD so that it can handle multiple shared-networks.  I cannot seem to
> get this working correctly.  If there is an expert "in the house" who
> can offer me a few minutes of your time to look over a configuration for
> me, please send me a phone number/email offlist and I'll discuss
> specifics.  

To all who have responded.  THANK YOU.  I found the issue and it has now
been resolved.  Actually, it was Bryan Scott at Wireless Beehive that
found the issue.  For those that wonder, it was a problem where certain
attributes were being returned for some clients and not others.  After
moving the problem attributes to another area of the configuration, the
issue was resolved.  Big thanks to those who offered insights (some of
you offered assistance that I did not directly respond to, but I did
look at your suggestions and tried several of them).  

-- 

* Butch Evans   * Professional Network Consultation*
* http://www.butchevans.com/* Network Engineering  *
* http://store.wispgear.net/* Wired or Wireless Networks   *
* http://blog.butchevans.com/   * ImageStream, Mikrotik and MORE!  *

Re: NOC Best Practices

[JoeSox]

I believe, myself included, are hesitant to answer because it really
depends upon a lot of variables. Type of business your NOC is running,
the operating budget, number of racks, etc.
The details matter when narrowing things down.

But yes, I have seen this ITIL
http://www.frontrange.com/
click the Register for a Free ITIL Success Kit!

You may be interested in.
--
Thanks, Joe

On Fri, Jul 16, 2010 at 11:34 AM, Kasper Adel  wrote:
> Thanks for all the people that replied off list, asking me to send them
> responses i will get.
>
> I got nothing other than :
> http://www.nanog.org/meetings/nanog24/abstracts.php?pt=OTM1Jm5hbm9nMjQ=&nm=nanog24
> and
>
> Network Management-  Accounting and Performance Strategies - Just the first
> three chapters
>
> Which is useful but i am looking for more stuff from the best people that
> run the best NOCs in the world.
>
> So i'm throwing this out again.
>
> I am looking for pointers, suggestions, URLs, documents, donations on what a
> professional NOC would have on the below topics:
>
> 1) Briefly, how they handle their own tickets with vendors or internal
> 2) How they create a learning environment for their people (Documenting
> Syslog, lessons learned from problems...etc)
> 3) Shift to Shift hand over procedures
> 4) Manual tests  they start their day with and what they automate (common
> stuff)
> 5) Change management best practices and working with operations/engineering
> when a change will be implemented
>
> Should i be looking for ITIL stuff or its not any good?
>
> Thanks,
> Kim
>
> On Wed, Jul 14, 2010 at 8:24 PM, Kasper Adel  wrote:
>
>> Hello Everyone,
>>
>> I am currently working on building a NOC so i'm looking for
>> materials/pointers to Best Practices documented out there.
>>
>> On the top of my head are things like:
>>
>> 1) Documenting Incidents and handling them
>> 2) Documenting Syslog messages
>> 3) Documenting Vendor Software Bugs
>> 4) Shift to Shift Hand over procedures
>> 5) Commonly used scripts for monitoring
>> 6) Frequently testing High Availability
>> 7) Capturing config changes.
>> etc
>>
>> I can see that this is years of experience but i am wondering if any of
>> this was captured some where.
>>
>> Thanks,
>> Kim
>>
>

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 08-Jul-10 -to- 15-Jul-10 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS30890  249855 14.3% 577.0 -- EVOLVA Evolva Telecom s.r.l.
 2 - AS24400   45751  2.6%3812.6 -- CMNET-V4SHANGHAI-AS-AP Shanghai 
Mobile Communications Co.,Ltd.
 3 - AS980841156  2.4% 762.1 -- CMNET-GD Guangdong Mobile 
Communication Co.Ltd.
 4 - AS50075   37055  2.1% 553.1 -- INBAR-BUSINESS-CORPORATION 
INBAR BUSINESS CORPORATION S.R.L.
 5 - AS541625273  1.4% 231.9 -- BATELCO-BH
 6 - AS11981   24624  1.4%2736.0 -- SPECIALSYSTEMS - Special 
Systems Inc.
 7 - AS44475   19785  1.1% 618.3 -- TIADOLI-AS SC Tiadoli Company 
SRL
 8 - AS39543   17502  1.0% 700.1 -- TENNET-AS SC TENNET TELECOM SRL
 9 - AS845216954  1.0%  19.8 -- TEDATA TEDATA
10 - AS25620   16765  1.0%  94.7 -- COTAS LTDA.
11 - AS48838   16755  1.0% 507.7 -- EUROLAN-ASN Eurolan Solutions 
SRL
12 - AS35931   14704  0.8%7352.0 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
13 - AS37204   14341  0.8%1434.1 -- TELONE
14 - AS41852   12670  0.7% 666.8 -- EXPERTNET-AS S.C. EXPERTNET 
S.R.L.
15 - AS35805   12130  0.7%  19.3 -- SILKNET-AS SILKNET AS
16 - AS32528   11879  0.7%2969.8 -- ABBOTT Abbot Labs
17 - AS34916   11168  0.6% 620.4 -- DNET-AS SC Digital Construction 
Network SRL
18 - AS8151 9871  0.6%  10.5 -- Uninet S.A. de C.V.
19 - AS369929824  0.6%  15.1 -- ETISALAT-MISR
20 - AS454649098  0.5% 227.4 -- NEXTWEB-AS-AP Room 201, TGU Bldg


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS35931   14704  0.8%7352.0 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 2 - AS487545269  0.3%5269.0 -- SOBIS-AS SOBIS SOLUTIONS SRL
 3 - AS191744986  0.3%4986.0 -- CNC-USA - China Netcom (USA) 
Operations Ltd.
 4 - AS24400   45751  2.6%3812.6 -- CMNET-V4SHANGHAI-AS-AP Shanghai 
Mobile Communications Co.,Ltd.
 5 - AS130307306  0.4%3653.0 -- INIT7 Init Seven AG, Zurich, 
Switzerland
 6 - AS32528   11879  0.7%2969.8 -- ABBOTT Abbot Labs
 7 - AS11981   24624  1.4%2736.0 -- SPECIALSYSTEMS - Special 
Systems Inc.
 8 - AS37204   14341  0.8%1434.1 -- TELONE
 9 - AS490861289  0.1%1289.0 -- EDC-AS SC Euro Data Construct 
SRL
10 - AS396921200  0.1%1200.0 -- ROMSERV-AS SC ROMSERV SOLUTIONS 
SRL
11 - AS398743532  0.2%1177.3 -- AUTOGENN-TELECOM Bucuresti 2, 
Romania
12 - AS510762290  0.1%1145.0 -- GE-AND-CO-COMPUTER-INDUSTRIES 
GE & CO COMPUTER INDUSTRIES SRL
13 - AS473451098  0.1%1098.0 -- RTS-TELECOM-AS RTS Telecom SRL
14 - AS389973291  0.2%1097.0 -- INTRANET-AS SC INTRANET VISION 
SRL
15 - AS436473171  0.2%1057.0 -- LINK-NET-ASN SC. Link Net SRL.
16 - AS416332077  0.1%1038.5 -- X-TREME-AS S.C. X-Treme Share 
SRL
17 - AS393456030  0.3%1005.0 -- BTS-AS SC BTS NET TELECOM SRL
18 - AS38947 999  0.1% 999.0 -- KNETWORKMEDIA K Network Media
19 - AS498298414  0.5% 934.9 -- CAPITAL-COM SC Capital 
Communication Investment SRL
20 - AS49383 909  0.1% 909.0 -- EVER-NET-AS SC M-Tel Consulting 
SRL


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 111.10.4.0/24  8088  0.4%   AS9808  -- CMNET-GD Guangdong Mobile 
Communication Co.Ltd.
 2 - 111.10.0.0/24  8088  0.4%   AS9808  -- CMNET-GD Guangdong Mobile 
Communication Co.Ltd.
 3 - 111.10.1.0/24  8086  0.4%   AS9808  -- CMNET-GD Guangdong Mobile 
Communication Co.Ltd.
 4 - 111.10.2.0/24  8085  0.4%   AS9808  -- CMNET-GD Guangdong Mobile 
Communication Co.Ltd.
 5 - 111.10.3.0/24  8085  0.4%   AS9808  -- CMNET-GD Guangdong Mobile 
Communication Co.Ltd.
 6 - 198.140.43.0/247567  0.4%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 7 - 212.51.128.0/197296  0.4%   AS13030 -- INIT7 Init Seven AG, Zurich, 
Switzerland
 8 - 63.211.68.0/22 7137  0.4%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 9 - 117.131.0.0/17 6828  0.4%   AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai 
Mobile Communications Co.,Ltd.
10 - 120.204.0.0/16 6750  0.4%   AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai 
Mobile Communications Co.,Ltd.
11 - 117.136.8.0/24 6398  0.3%   AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai 
Mobile Communications Co.,Ltd.
12 - 117.135.128.0/18   6228  0.3%   AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai 
Mobile Communications Co.,Ltd.
13 - 117.135.0.0/17 6220  0.3%   AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai 
Mobile Communications Co.,Ltd.
14 - 130.36.34.0/24  

The Cidr Report

[cidr-report]

This report has been generated at Fri Jul 16 21:11:34 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
09-07-10329107  202441
10-07-10329272  202604
11-07-10329306  202611
12-07-10329227  202212
13-07-10328424  202676
14-07-10328854  202711
15-07-10328939  202642
16-07-10329107  202892


AS Summary
 34865  Number of ASes in routing system
 14800  Number of ASes announcing only one prefix
  4480  Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
  97811776  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 16Jul10 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 329227   202838   12638938.4%   All ASes

AS6389  3891  292 359992.5%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  4480 1820 266059.4%   TWTC - tw telecom holdings,
   inc.
AS19262 1828  275 155385.0%   VZGNI-TRANSIT - Verizon
   Internet Services Inc.
AS4766  1859  507 135272.7%   KIXS-AS-KR Korea Telecom
AS22773 1173   70 110394.0%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS4755  1375  301 107478.1%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS18566 1087   63 102494.2%   COVAD - Covad Communications
   Co.
AS17488 1333  332 100175.1%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS8151  1530  617  91359.7%   Uninet S.A. de C.V.
AS6478  1253  414  83967.0%   ATT-INTERNET3 - AT&T WorldNet
   Services
AS5668   947  134  81385.9%   AS-5668 - CenturyTel Internet
   Holdings, Inc.
AS7545  1397  590  80757.8%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS8452  1101  396  70564.0%   TEDATA TEDATA
AS10620 1072  384  68864.2%   Telmex Colombia S.A.
AS7303   761  123  63883.8%   Telecom Argentina S.A.
AS35805  652   41  61193.7%   SILKNET-AS SILKNET AS
AS4804   678   72  60689.4%   MPX-AS Microplex PTY LTD
AS4808   824  241  58370.8%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS28573 1042  508  53451.2%   NET Servicos de Comunicao S.A.
AS4780   691  168  52375.7%   SEEDNET Digital United Inc.
AS7018  1484  965  51935.0%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS7552   652  141  51178.4%   VIETEL-AS-AP Vietel
   Corporation
AS9443   571   75  49686.9%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS17676  580   84  49685.5%   GIGAINFRA Softbank BB Corp.
AS3356  1164  670  49442.4%   LEVEL3 Level 3 Communications
AS1785  1780 1288  49227.6%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS24560  957  473  48450.6%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS7011  1133  652  48142.5%   FRONTIER-AND-CITIZENS -
   Frontier Communications of
   America, Inc.
AS9198   497   40  45792.0%   KAZTELECOM-AS JSC
   Kazakhtelecom
AS7738   477   30  44793.7%   Telecomunicacoes da Bahia S.A.

Total  38269117662650369.3%   Top 30 total


Possible Bogus Route

Re: Root Zone DNSSEC Deployment Technical Status Update

[Jeffrey Ollie]

On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli  wrote:
> On 7/16/10 11:07 AM, Tony Finch wrote:
>>
>> On Fri, 16 Jul 2010, Chris Adams wrote:
>>>
>>> A simple XSLT will transform it into any needed format.
>>
>> XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.
>
> anchors2keys will.

Actually, it won't.  The ITAR anchors.xml and anchors2keys use a
different XML schema than the root-anchors.xml does.

-- 
Jeff Ollie

Re: Root Zone DNSSEC Deployment Technical Status Update

[Joel Jaeggli]

Yeah oops.

Just noticed that

Joel's iPad

On Jul 16, 2010, at 5:34 PM, Jeffrey Ollie  wrote:

> On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli  wrote:
>> On 7/16/10 11:07 AM, Tony Finch wrote:
>>> 
>>> On Fri, 16 Jul 2010, Chris Adams wrote:
 
 A simple XSLT will transform it into any needed format.
>>> 
>>> XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires.
>> 
>> anchors2keys will.
> 
> Actually, it won't.  The ITAR anchors.xml and anchors2keys use a
> different XML schema than the root-anchors.xml does.
> 
> -- 
> Jeff Ollie
> 

Re: On another security note... (of sorts)

[Dobbins, Roland]

On Jul 16, 2010, at 9:42 PM, Lamar Owen wrote:

> I'm sure the collective wisdom here is capable of pulling the task off at 
> least in theory;

The thorniest issues aren't technology-related, per se; they're legal exposure 
(both real and imagined), regulatory concerns (both real and imagined), 
antitrust concerns (both real and imagined), management/marketing/PR concerns 
(largely imagined), skillset shortages/concerns (very real), customer 
perception concerns (both real and imagined), and so forth.

The second tier of barriers are those surrounding trust.  It's basically a 
sociological analogue of 'the PKI problem'.

Technology issues form the third set of barriers.  Yes, they're real and 
they're important, but if we could wiggle our noses a la Elizabeth Montgomery 
and make all the technology issues go away, the other sets of issues would 
still preclude any kind of universal solution, for some value of 'solution'.

There's a great deal of opsec coordination and work which takes place in a sub 
rosa fashion, via individual actions, closed, vetted mitigation communities, ad 
hoc personal relationships, etc.  In actuality, a very great deal of the useful 
opsec work that gets done is accomplished by folks who in some cases are going 
beyond their portfolios to do so, as their management, legal teams, 
PR/marketing teams, et. al. would actively forbid them to do this work, were 
they to know about it.

That's one of the reasons why a lot of people who make sweeping generalizations 
and recommendations about 'cyber-this' and 'cyber-that' tend not to have a good 
grasp of even the fundamentals - they aren't the folks who do the actual work, 
they don't know who does the actual work, and they often don't know anybody who 
knows somebody who actually does the actual work.  They often don't even know 
that actual work is taking place, or what it entails, in the first place, 
because the actual work takes place out of the limelight.

> the hard part would be deciding whether to do it in hardware or software


;>

---
Roland Dobbins  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken