Typical last mile battery runtime (protecting against power cuts)

[Israel G. Lugo]

Hi folks,

At $day_job, I have a team of engineers who are oncall for critical 
services in the United Kingdom. For $reasons, the national power grid is 
announcing the possibility of rolling power cuts over the coming months. 
Right now it's "unlikely", but possible. If cuts do happen, it'll be 3+ 
hours, possibly several times/day.


I'm looking at the cost/benefit of deploying small UPSes at people's 
homes, to protect their network access when oncall. Just to power the 
home router (+ONT if FTTP), and keep a charged laptop. I figure anything 
smallish should be enough for a few hours.


Question is, how much battery runtime can I typically expect from ISPs' 
last mile infra.


People will have a random mix of DSL, FTTP, DOCSIS. Another alternative 
is tethering with 4G.


- For FTTP, I *think* (but am not sure) that the UK mostly uses PON, so 
guess it would be runtime of OLT and onwards

- For DSL: runtime of DSLAM cabinet and onwards
- For CATV: CMTS and onwards, maybe any active equipments in the HFC to 
the CPE?

- For 4G: BSS and onwards

Could anyone with last mile experience help with some ballpark figures? 
I.e. 15 min vs 8h or 8 days.


Thank you,
Israel

Re: Software for network modelling / documentation / GIS

[Israel G. Lugo]

Hey, that's really interesting!

I'm from Portugal, so the language isn't a problem ;)

>From the overview, it seems to be more focused on the passive infra, but
perhaps there may be room for developing a campus side and active
equipments. I didn't find a way to access the demo, but I'll get in
touch with them to see if we can get some cooperation going. My need is
actually for a uni, so it would be a nice touch if we work together with
an NREN.

Thanks,
Israel


On 02/24/2017 05:04 PM, Alex Moura wrote:
> There is the Giiro:
>
> http://pop-ba.rnp.br/GTGIIRO
>
> Despite the content is in Brazilian Portuguese, it may work well to
> use Google Translator to read the overview.
>
> The software developed was funded by the Brazilian NREN. The software
> is maintained by a team of research and development.
>
> Alex
>
> Em 24 de fev de 2017, às 13:36, Israel G. Lugo
> <israel.l...@lugosys.com <mailto:israel.l...@lugosys.com>> escreveu:
>
>> On 02/24/2017 03:52 AM, Mel Beckman wrote:
>>> This tool is not cheap, but I believe it can handle all the physical
>>> plant inventory and provisioning objectives you listed:
>>>
>>> http://synchronoss.com/wp-content/uploads/spatialNET.pdf
>>>
>>
>> Judging from the description on the PDF, that does seem to be very
>> complete. Have you used the software, had a good experience?
>>
>> I don't have an idea of the price ballpark, but I can try to get in
>> touch with them to find out.
>>
>> Regards,
>> Israel

Re: Software for network modelling / documentation / GIS

[Israel G. Lugo]

On 02/24/2017 03:52 AM, Mel Beckman wrote:
> This tool is not cheap, but I believe it can handle all the physical plant 
> inventory and provisioning objectives you listed:
>
> http://synchronoss.com/wp-content/uploads/spatialNET.pdf
>

Judging from the description on the PDF, that does seem to be very
complete. Have you used the software, had a good experience?

I don't have an idea of the price ballpark, but I can try to get in
touch with them to find out.

Regards,
Israel

Re: Software for network modelling / documentation / GIS

[Israel G. Lugo]

That actually seems nice!

I tried a quick demo of the Pro version and it has a distinct DCIM-like
feel. Still not sure it can place things e.g. on a floor plant but
perhaps there's a way to integrate with some API.

The community version does lack multiple useful features, though. I'll
have to try one and the other.

Thank you,
Israel


On 02/24/2017 06:59 AM, ML-NANOG-Stefan-Jakob wrote:
> Hi,
>
> If you want to go the full stack, start open source and to have the support
> and com.ext. option you can check iDoIT.
>
> Good thing is, it has also a nice API for further automation and you can
> use it as generall CMDB.
>
> https://www.i-doit.org/
>
> Rgds, SJ

Re: Software for network modelling / documentation / GIS

[Israel G. Lugo]

On 02/24/2017 03:58 AM, Hugo Slabbert wrote:
> None of these necessarily get to your ideal state, but at least get
> you going wrt discovery for semi-dynamic documentation.

Thank you for the suggestions.

I've used Netdisco in the past, older 1.x version. It was nice and
useful. I've gone ahead and looked at a recent Netdisco demo and it
looks even better. Doesn't seem to include passive equipment (e.g.
cabling), though, but it might be useful even on its own.

mnet seems to be a bit more rudimentary, more towards basic discovery
indeed.

As for Netdot, I've only ever used it for IPAM, but I will try it.
Perhaps with some plugins it may fit the bill.

Regards,
Israel

Software for network modelling / documentation / GIS

[Israel G. Lugo]

Hello,

Does anyone have any recommendations for software to do network
modelling / documentation / GIS, for a campus network? Mid-scale, a few
campuses with the largest being around 25 buildings. Free/open source
would be excellent, but commercial is also an option.

This is a live network, with very little documentation.

At the very least, I would like to document things. Ideally, though, if
I were designing the software, I would like to have an intelligent model
of the network from L1 to L3, serving not only for documentation but
also to validate existing configuration and creating new work orders.
Something like this:

  * conduit
  o has vertices (locations on the campus plant)
  o has a cross-section area
  o has links
  * link
  o has 1 port on each end
  o has media types (OS2, OM3, ...)
  o may have a cross-section area (when inside a conduit)
  * node
  o can be a switch, a router, a patch panel, an access point, a phone
  o has ports
  * circuit
  o can be a VLAN, or a VPN, etc
  o spans multiple links / nodes / circuits
  o has 1 port on each end (logical port, circuit endpoint)
  * port
  o has physical characteristics (E2000, SC, LC, ST, 8P8C, logical
endpoint ...)
  o may have other properties (link speed, PoE)

User Bob requests activation of the network socket D-78 in his office on
building A, floor 5, room 29. An operator will use the software to
connect port D-78 on the corresponding patch panel to an available port
on a switch, and specify the desired VLAN (circuit).

The software knows where the VLAN exists and will provide instructions
on how to propagate it, taking into account redundant links. It will
also provide instructions for the physical part: take one 2m patch,
connect panel port D-78 to switch 2 port 17. Remember to bring the
keyring because that cabinet opens with a non-standard key.

If the cable guy goes on site and sees that switch 2 port 17 is already
used, he will flag an inconsistency and request another port.

Periodically, the software will go crawl the active equipments via SNMP
or somesuch and detect existing state (port VLAN assignments, port
state, link speeds, switch capacity, LLDP neighbors). If it finds any
inconsistency with the configured model, it will alert an operator.

Of course, all that is an ideal case. I would be happy if I can just use
this for static documentation: on building A, network socket D-78
connects to switch 2 port 17, and is on VLAN 30.

Does anyone know of something similar to this exist in commodity
software, outside of custom solutions developed for a specific network?
Anything between "purely for static documentation", and "this
autodetects your cables, configures your switches and sends a robot to
connect everything".

Thank you and best regards,

Israel G. Lugo

netcalc: a tool for aggregating networks, subtracting, and more

[Israel G. Lugo]

Hello,

In the spirit of Ken's script below, I've started development of a tool
which I called NetCalc:

https://github.com/israel-lugo/netcalc (source code)

https://pypi.python.org/pypi/netcalc (Python package)

Currently, NetCalc allows one to add (aggregate) multiple networks,
subtract a network from a larger network, and mix add/subtract
operations with an arbitrary mathematical expression. It supports both
IPv4 and IPv6, and works very efficiently even with very large networks.
It uses the excellent netaddr library for the core address manipulation.

Example usage:

$ netcalc add 198.18.0.0/24 198.18.1.0/24 10.1/16 10/16
10.0.0.0/15
198.18.0.0/23
$ netcalc sub 192.0.2.0/24 192.0.2.0/28
192.0.2.16/28
192.0.2.32/27
192.0.2.64/26
192.0.2.128/25
$ netcalc expr 2001:db8::/34 - 2001:db8::/38 + 2001:db8:100::/41
2001:db8:100::/41
2001:db8:400::/38
2001:db8:800::/37
2001:db8:1000::/36
2001:db8:2000::/35

More features are planned, this is still just an early release. Right
now, things that I can think of being useful:

  * new command for static information (netmask/bitmask, IP range)
  * new command for WHOIS queries
  * new command for splitting a network into smaller networks by prefix
length
  * ability to specify network arguments through a file
  * ???

The tool is made in Python, and supports both Python 3 (preferred) and
Python 2.

I'm releasing here with the desire that it will be useful to someone,
and hopefully to get some feedback on useful functionality, behavior and
so on.

Regards,

Israel G. Lugo



On 10/20/2016 07:59 PM, Ken Chase wrote:
> re more general 'network utilities' and scripts:
>
>  http://sizone.org/m/hacks/cidrmath.pl
>
> adds and removes subnets from networks giving list of remaining/aggregated 
> (sub)nets.
>
> I couldnt find an online calculator that does this, most are just for 
> 'translation' 
> from subnet masks<>cidr or cisco inverse masks, etc.
>
> Wrote it years ago cuz I had an itch. The included perl module populates a
> hash entry per ip and I didnt want to write my own, so uses lots of ram+cpu on
> big ops (/8 - /9 for eg). But great for earthly operations like /23 - /27 +
> /28.
>
> Yes I should start my own git repo, but i've been lazy.
>
> No warranties provided.
>
> If anyone has a faster/better one, that'd be handy.
>
> /kc
> --
> Ken Chase - k...@sizone.org Toronto & Guelph Canada

Re: How to force rapid ipv6 adoption

[Israel G. Lugo]

On 10/03/2015 08:40 PM, Owen DeLong wrote:
> So a /48 isn’t about being able to support 295,147,905,179,352,825,856 
> devices in every home, it’s about being able to have 16 bits of subnet mask 
> to use in delegating addresses in a dynamic plug-and-play hierarchical 
> topology that can evolve on demand without user configuration or intervention.

Which is IMO scarcely enough to be as flexible as IPv6 is being touted.
I've always considered 16 bits of subnetting way too small for an end
site. Especially if you want to do things like dynamic plug-and-play
hierarchical topology. Just following Robin Johansson's example in
another email:


On 10/02/2015 07:08 PM, Robin Johansson wrote:
> If a /48 is assigned to each customer, then the first wireless router
> gets a /52, second router a /56 and there is room to connect one more
> level of devices. All works out of the box, everyone is happy, no
> support calls.

We only have up to 3 levels, and each level only supports 16 branches.
May be fine for mom and dad now, but certainly not for other complex
cases. And when you start factoring the whole "soup cans with IPv6" thing...

I still think IPv6 should've been at least 192 bits long.

Israel G. Lugo

Facebook down (was: Re: Facebook invisible in Italy)

[Israel G. Lugo]

Hello,

Was down in Portugal until just now, and from downforeveryoneorjustme.com.

Just tried and it seems to be working again, though.



On 09/28/2015 09:39 PM, Raymond Dijkxhoorn wrote:
> Hai Marco,
>
> Same in NL so most likely bigger then Italy alone. 
>
> Thanks,
> Raymond Dijkxhoorn, Prolocation
>
>> Op 28 sep. 2015 om 22:35 heeft Marco Paesani  het volgende 
>> geschreven:
>>
>> Hi,
>> some issues from FB network ??
>> Do you have some info ?
>> Regards,
>>
>> -- 
>>
>> Marco Paesani
>> MPAE Srl
>>
>> Skype: mpaesani
>> Mobile: +39 348 6019349
>> Success depends on the right choice !
>> Email: ma...@paesani.it

Re: Dual stack IPv6 for IPv4 depletion

[Israel G. Lugo]

On 07/05/2015 06:26 PM, Owen DeLong wrote:
 On Jul 4, 2015, at 23:51 , valdis.kletni...@vt.edu wrote:

 Put their IPv4 behind a NAT and a globally routed /56.

 There, FTFY. :)
 Or better yet globally routed /48.

 /56 is still a bad idea.

 Owen
I've read this many times and am aware it's the standard recommendation.
Makes perfect sense for the customer side, as it would be hard for him
to subnet properly otherwise.

Doesn't seem to make sense at all for the ISP side, though. Standard
allocation /32. Giving out /48s. Even if we leave out proper subnet
organization and allocate fully densely, that's at most 65,536 subnets.
Not a very large ISP.

You can say get more blocks, or get larger blocks. Sure, let's give
each ISP a /24. That lets them have up to 16M customers (and that's
still subnetting densely, which sucks rather a lot). Doesn't leave that
many allocation blocks for the RIRs to hand out, though.

People usually look at IPv6 and focus on the vast numbers of individual
addresses. Naysayers usually get shot down with some quote mentioning
the number of atoms in the universe or some such. Personally, I think
that's a red herring; the real problem is subnets. At this rate I
believe subnets will become the scarce resource sooner or later.

Sure, in the LAN side we'll never have to worry about address scarcity.
But what's the point of having addresses to spare, if it just means
you've got to start worrying about subnet scarcity? If the goal was
never having to worry about counting anymore, I propose that 128 bits is
far too little. Should've gone a full 256 and be done with it.

Regards,
Israel G. Lugo

P.S.: I'm 100% for IPv6 and $dayjob has been fully dual stacked for 10
years now.

Re: Dual stack IPv6 for IPv4 depletion

[Israel G. Lugo]

On 07/09/2015 02:15 AM, Owen DeLong wrote:
 If you’re trying to build a decent sized ISP in a /32, you’re doing it
 wrong. /32 is not the “standard size” — It’s the MINIMUM size. 

I've addressed this and most of what you said in my earlier reply to
Mike Hammet (00:57:29 UTC). I was going to reply in more detail here but
I see you've replied to the other email now as well.

I'll just say that I am aware of the math, and I'm not trying to
disprove IPv6 -- nor am I making the typical argument that we will run
out of IPv6 addresses.

Re: Dual stack IPv6 for IPv4 depletion

[Israel G. Lugo]

I'm sorry Mel, I only now saw your email.

I'll quote from my reply to Owen, for the motivation behind my question:

 Speaking of IPv6's full potential: we're considering 32 subscriptions
 per client. I've read people thinking of things like IPv6-aware soda
 cans. Refrigerators. Wearables. Cars and their internal components...
 You could have the on-board computer talking to the suspension via IPv6,
 and reporting back to the manufacturer or whatnot.

 Personally, I'm not particularly fond of the whole refrigerators
 ordering milk bottles craze, but hey, it may very well become a thing.
 And other stuff we haven't thought of yet.

 My point is: we're changing to a brand new protocol, and only now
 beginning to scratch its full potential. Yes, everything seems very big
 right now. Yes, 128 bits can be enough. Even 64 bits could be more than
 enough. But why limit ourselves? Someone decided (corretly) that 64
 would be too limiting.

 Please don't fall into the usual you've got more addresses than
 atoms... I've heard that, and am not disputing it. I'm not just talking
 about individual addresses (or /48's).

 What I am proposing here, as food for thought, is: what if we had e.g.
 192 bits, or 256? For one, we could have much sparser allocations. Heck,
 we could even go as far as having a bit for each day of the month. What
 would this be good for? I don't know. Perhaps someone may come up with a
 use for it.


Regards,
Israel



On 07/09/2015 02:46 AM, Mel Beckman wrote:
 Israel,

 A better question is why bit-map your allocation plan at all? That seems ill 
 advised, since you must arbitrarily allocate huge swaths of ip space equally 
 between category classes when it's rarely efficient to do so. For example, 
 two bits for network infrastructure because infrastructure addresses are 
 likely far fewer than any customer class. Similarly three bits for geographic 
 region on the /38 boundary illogically assumes all geographic regions are the 
 same size.

 There isn't a good routing reason for a bitwise address structure, since 
 nobody routes that way. The only other rationale I can think of is human 
 mnemonic value, but 128-bit addresses are not very amenable to such mnemonics 
 (::DEAD:BEEF not withstanding :)

  -mel beckman

 On Jul 8, 2015, at 6:32 PM, Owen DeLong o...@delong.com wrote:


 Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:

 - I reserve 1 bit for future allocation schemes, leaving me a /33;
 - 2 bits for network type (infrastructure, residential, business, LTE): /35
 - 3 bits for geographic region, state, whatever: /38
 - 5 bits for PoP, or city: /43

 This leaves me 5 bits for end sites: no joy.
 Here’s the problem… You started at the wrong end and worked in the wrong 
 direction in your planning.

 Let’s say you’re a national ISP. Let’s say you want to support 4 levels of 
 aggregation.
 Let’s say that at the lowest level (POP/City) you serve 50,000 end-sites in 
 your largest POP/City. (16 bits)
 Let’s say you plan to max out at 32 POPs/Cities per region (your number from 
 above) (5 bits)
 Let’s say you plan to divide the country into 8 regions (3 bits)
 Let’s say for some reason you want to break your aggregation along the lines 
 of service class (infrastructure, residential, business)
as your top level division (rarely a good idea, but I’ll go with it for 
 now) and that you have 4 service classes (2 bits)
 Further, let’s say you decide to set aside half your address space for 
 “future allocation schemes”.

 Each POP needs a /32.
 We can combine the Region/POP number into an 8-bit field — You need a /24 
 per Region.
 You need 3 additional bits for your higher level sub-divisions. Let’s round 
 to a nibble boundary and give you a /20.

 With that /20, you can support up to 67 Million end sites in your first plan 
 still leaving 3/4 of your address space fallow.

 (That’s at /48 per end-site, by the way).

 Now, let’s consider: 7 Billion People, each of which represents 32 different 
 end-sites — 224 billion end-sites world wide.
 224,000,000,000 / 67,000,000 = 3,344 (rounded up) total ISPs requiring /20s 
 to serve every possible end-site on the
 planet.


 There are 1,048,576 /20s total, so after allocating all the ISPs in the 
 world /20s, we still have 1,045,232 remaining.

 Let’s assume that every end-site goes with dual-address multi-homing (an 
 IPv6 prefix from each provider).

 We are now left with only 1,041,888 /20s remaining. You still haven’t put a 
 dent in it.

 Even if we divide by 8 and just consider the current /3 being allocated as 
 global unicast, you still have 130,236 free /20s
 left.

 Granted, this is just a silly example, and I don't have to divide my
 address space like this. In fact, I really can't, unless I want to have
 more than 32 customers per city. But I don't think it's a very
 far-fetched example.
 It’s not… It’s a great example of how not to plan your address space in IPv6.

 However, if we repeat the same exercise 

Re: Dual stack IPv6 for IPv4 depletion

[Israel G. Lugo]

On 07/09/2015 02:31 AM, Owen DeLong wrote:
 Here’s the problem… You started at the wrong end and worked in the wrong 
 direction in your planning.

 [...get larger allocation...]

 We are now left with only 1,041,888 /20s remaining. You still haven’t put a 
 dent in it.

I am aware of the math, and how it can fit. I will concede that a /20 is
sufficient.

Note, however, the difference in orders of magnitude for typical
allocations. I realize in ARIN side you've got e.g. Comcast with
multiple /20s, but in RIPE that is not so common. My home ISP has 3x
/32s. As I said, default ISP/LIR allocation here is from /32 to /29.
Yes, shorter prefixes can be justified and obtained, but it's not the norm.


 It’s not… It’s a great example of how not to plan your address space in IPv6.

 However, if we repeat the same exercise in the correct direction, not only 
 does each of your end-sites get a /48, you get the /20 you need in order to 
 properly deploy your network. You get lots of space left over, and we still 
 don’t make a dent in the IPv6 free pool. Everyone wins.

You basically just said get a larger allocation... Which was my point
all along. /32 is not enough, and even /24 could be made much roomier.

Speaking of IPv6's full potential: we're considering 32 subscriptions
per client. I've read people thinking of things like IPv6-aware soda
cans. Refrigerators. Wearables. Cars and their internal components...
You could have the on-board computer talking to the suspension via IPv6,
and reporting back to the manufacturer or whatnot.

Personally, I'm not particularly fond of the whole refrigerators
ordering milk bottles craze, but hey, it may very well become a thing.
And other stuff we haven't thought of yet.

My point is: we're changing to a brand new protocol, and only now
beginning to scratch its full potential. Yes, everything seems very big
right now. Yes, 128 bits can be enough. Even 64 bits could be more than
enough. But why limit ourselves? Someone decided (corretly) that 64
would be too limiting.

Please don't fall into the usual you've got more addresses than
atoms... I've heard that, and am not disputing it. I'm not just talking
about individual addresses (or /48's).

What I am proposing here, as food for thought, is: what if we had e.g.
192 bits, or 256? For one, we could have much sparser allocations. Heck,
we could even go as far as having a bit for each day of the month. What
would this be good for? I don't know. Perhaps someone may come up with a
use for it.

Re: Dual stack IPv6 for IPv4 depletion

[Israel G. Lugo]

On 07/09/2015 02:38 AM, Mark Andrews wrote:
 A single /48 has enough space/subnets cover the entire infrastructure
 of 99.% of ISPs even using /64's for p2p links rather than taking
 one /64 and subdividing that for all of the p2p links. Treat the ISP
 as a business customer of itself when allocating address space for
 itself. A single /48 or one /48 per site. 

A single /48 is more than enough for infrastructure, yes. It was a
5-minute example. Bitmapping the allocations can't be done right now in
IPv4 (technically it can, but there's not enough to go around).

One of the good things about IPv6 is supposed to be not having to worry
about address waste. You're never going to fill up even a single /64
with current technology (you'll run out of MAC addresses first). Taking
the infrastructure example above: sure, a /48 is a waste. Who cares? So
is a /64 for my home network. Again, who cares? There are enough
addresses. As someone said here, they're just integers.

My whole point is: why not allow some room for more flexible
allocations? Compatibility was already broken by changing address length.


 The thinking is that ISP's are experts and can deal with managing
 complex allocation policy. They can also deal with multiple more
 specific routes etc. They already cope with this in IPv4. 

Uh... okay?

Re: Dual stack IPv6 for IPv4 depletion

[Israel G. Lugo]

On 07/09/2015 12:59 AM, Mark Andrews wrote:
 In message 559db604.8060...@lugosys.com, Israel G. Lugo writes:
 Doesn't seem to make sense at all for the ISP side, though. Standard
 allocation /32. Giving out /48s. Even if we leave out proper subnet
 organization and allocate fully densely, that's at most 65,536 subnets.
 Not a very large ISP.
 /32 is not the standard allocation.  It is the *minimum* allocation
 for a ISP.  ISPs are expected to ask for *more* addresses to meet their
 actual requirements.

Thank you for pointing that out. When speaking of /32 I was referring
specifically to RIPE policy, with which I am more familiar: Initial
allocation size for a LIR is /32, extensive to a /29 with minimal
bureaucracy. Perhaps I should have said default allocation.

I understand ISPs should ask for more addresses; however, even e.g. a
/24 (8x /32) seems to me like it could be roomier.


 People usually look at IPv6 and focus on the vast numbers of individual
 addresses. Naysayers usually get shot down with some quote mentioning
 the number of atoms in the universe or some such. Personally, I think
 that's a red herring; the real problem is subnets. At this rate I
 believe subnets will become the scarce resource sooner or later.
 No.  People look at /48's for sites.  35,184,372,088,832 /48 sites out of the
 1/8th of the total IPv6 space currently in use.  That is 35 trillion sites
 and if we use that up we can look at using a different default size in the
 next 1/8th.
Yes, if we look at end sites individually. My hypothesis is that these
astronomic numbers are in fact misleading. There isn't, after all, one
single ISP-Of-The-World, with The-One-Big-Router.

We must divide the addresses by ISPs/LIRs, and so on. Several bits in
the prefix must be used for subaddressing. A larger ISP will probably
want to further subdivide its addressing by region, and so on. With
subdivisions comes waste. Which is something we don't need to worry
about at the LAN level, but it would be nice to have that level of
comfort at the subaddressing level as well.

Let's say I'm a national ISP, using 2001:db8::/32. I divide it like so:

- I reserve 1 bit for future allocation schemes, leaving me a /33;
- 2 bits for network type (infrastructure, residential, business, LTE): /35
- 3 bits for geographic region, state, whatever: /38
- 5 bits for PoP, or city: /43

This leaves me 5 bits for end sites: no joy.

Granted, this is just a silly example, and I don't have to divide my
address space like this. In fact, I really can't, unless I want to have
more than 32 customers per city. But I don't think it's a very
far-fetched example.

Perhaps I'm missing something obvious here, but it seems to me that it
would've been nice to have these kinds of possibilities, and more. It
seems counterintuitive, especially given the IPv6 way of thinking
which is normally encouraged: stop counting beans, this isn't IPv4.

Regards,
Israel G. Lugo

Re: Inexpensive software bgp router that supports route tags?

[Israel G. Lugo]

+1 for BIRD.

Basically, what you want is to have several different static (blackhole)
routes, and be able to differenciate them at BGP level, for marking with
communities, etc. Correct?

This is easy with BIRD. Just use separate instances of the static
protocol, and filter using proto to distinguish between them.

E.g.:

protocol static default_sink {
  # sink all local prefixes by default, to avoid loops
  # (low localpref, let other routes override us)
  import filter { preference = 1; accept; };

  route 192.0.2.0/24 blackhole;
}

protocol static forbidden {
  # these guys looked at me the wrong way
  route 198.51.100.0/24 blackhole;
}

protocol static temp_block {
  # DDOS mitigation, etc
  route 203.0.113.17/32 blackhole;
}

protocol bgp customer1 {
  export filter {
if proto = default_sink then reject;
if proto = temp_block then set_tempblock_community();
if proto = forbidden then do_other_stuff();
  }
  # ...
}



On 07/01/2015 08:47 PM, David H wrote:
 Sorry I wasn't clear on that.  Traditionally on a hardware, e.g.
 cisco/brocade, router performing the RTBH role, I'd add blackhole routes by
 way of static routes with a particular tag; one tag for block this source,
 one tag for block this destination.  Redistribute static would let route
 maps operate against those tags to turn into bgp communities being applied
 to the announcements, and then the real routers can do what they need to
 do.  When I tried out Quagga/Zebra as an alternative, it doesn't work this
 way, so while it was nice that it could pick up static routes from the OS,
 or have them added manually just like a hardware router, there was no
 concept of the route tag getting to Zebra for it to do the rest of the work
 on the BGP side.

 I'll check out Bird too; thanks.

 On Wed, Jul 1, 2015 at 3:41 PM, Job Snijders j...@instituut.net wrote:

 On Wed, Jul 01, 2015 at 11:19:45AM -0400, David H wrote:
 I was wondering if anyone can recommend a software (preferable), or
 hardware-based router with an API, that supports BGP with tags on
 advertised routes?  I want to use it for a RTBH feed [ ... ]
 Did you look at BIRD? It is one of the most beautiful open source BGP
 speakers: http://bird.network.cz/

 BIRD does not have anything like an restful API, but you can just
 generate the config file and reload it on the fly to accomplish the
 same.

 Can you elaborate on what you mean with 'tags'? Could you use BGP
 communities instead?

 Kind regards,

 Job

Re: Inexpensive software bgp router that supports route tags?

[Israel G. Lugo]

On 07/02/2015 04:23 AM, Israel G. Lugo wrote:
 protocol static temp_block {
   # DDOS mitigation, etc
   route 203.0.113.17/32 blackhole;
 }

Didn't make it clear in my example, but you can obviously have multiple
routes in a static instance:

protocol static temp_block {
  route 203.0.113.17/32 blackhole;
  route 203.0.113.28/32 blackhole;

  # redirect to honeypot for gathering info
  route 203.0.113.99/32 via 10.0.0.15;
}

Looking for core L3 switch for campus network; feedback on Juniper EX8208?

[Israel G. Lugo]

Hello,

I'm thinking of buying a Juniper EX8208 to serve as the core L3 switch
on an collapsed campus network (faculty, academia).

Rough figures: around 6,000 eyeballs, up to around 10,000 MACs, spread
over some 30 buildings of varying size. OM2/OM3 fiber from the buildings
to the core, using 1Gb optics. Planning to upgrade to monomode within 2
years and may migrate some buildings to 10 Gb.

From the spec sheets, the EX8208 seems to fit the bill. It will be
teaming up with an older Alcatel L3 switch, which will work as backup.
VRRP, OSPF, MSTP. It'll be replacing another Alcatel L3 switch that
we're sending back due to way too many bugs and reliability issues over
the 1.5 year span that we had it.

We are fully IPv6 dual-stack (for over 10 years now), so this needs to
support fully working OSPFv3, VRRPv3, MLD and so on. According to the
manuals for the EX line, that seems to be the case (with some
limitations regarding OSPFv3, it seems).

Access and aggregation switches are mostly Alcatel. There are a few
other routers for VLANs with specific requirements (NAT, firewalling,
etc). All using OSPFv2 and OSPFv3.

I'd welcome any feedback regarding the EX820x, positive or negative.
Bugs, support quality, stability issues, scalability, IPv6 support...

I could go up to the EX9200 if necessary.

I've had very good experience with the SRX2x0 line in a separate
setting, and Juniper TAC in general always seemed quite good. Of course
the EX8200 is a different ballpark so things may be different. I'm
curious for example: as a switch, I'd expect the EX8200 to work in
packet mode, yes? Or does it have flowd and its security {...} section?
I wouldn't really use the flow features at this level and wouldn't like
to have it there waiting to catch a bug from some weird packets thrown
at it.

Thank you for reading. Regards,
Israel G. Lugo

[curiosity] Internet's first router, 1969

[Israel G. Lugo]

Old days... :)

http://www.snotr.com/video/14338/In_Honor_Of_The_Internet_Turning_45_Today__Here_Is_Its_First_Router

Re: Linux: concerns over systemd adoption and Debian's decision to switch

[Israel G. Lugo]

On 22-10-2014 17:12, Miles Fidelman wrote:
 Seems to me, this has been a very rational discussion, confined to one
 very identifiable thread, containing what at least this reader finds
 very useful (operational impacts of systemd in server-side
 environments, and what alternatives people are looking at).

 If you're not interested, you have a delete key.  Please use it, and
 don't turn this into a flame war.

Agreed.

I've found this thread to be very interesting, and appreciate listening
to everyone's opinions on the matter. It does have a meaningful
operational impact, and from what I've read it seems we should at least
think about how to deal with this.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

[Israel G. Lugo]

On 22-10-2014 17:30, Jeffrey Ollie wrote:
 Hardly. The discussion so far has been weighted very heavily on the
 side of Dana Carvey's Grumpy Old Man-style whining. That's the way
 it was and we liked it!. The people that like systemd (like myself)
 have wisely learned that the people that hate systemd, hate it mostly
 because it's different from what came before and don't want to change.
 There's no way to argue rationally with that.

Not everyone hates it. I for one would be very much interested in
listening to what you have to say about systemd, if you find it to be a
positive change. How is it better, and how you look at some of the
concerns raised in this thread. At least for me, a balancing opinion
would be welcome.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

[Israel G. Lugo]

On 10/23/2014 12:05 AM, Jeffrey Ollie wrote:

 systemd is a tool designed to get the system to a state where real
 work can be done.  NTP servers, DHCP clients, consoles, aren't the
 real work of a system, or at least I hope not, because that would be
 boring to me.

That idea sounds interesting. I can see where you're coming from.
Basically, these things are details, that shouldn't really be all that
important, so systemd is supposed to take care of it all and leave you
to worry about the actual bread and butter. That about it?

Legitimate question, not trying to be sarcastic: would you concede that
the amount to which something is a detail may vary significantly per
the use case, and requirements? On my desktop I might not care about
whatever the DHCP client is doing, or the NTP server, but on a server
that may very well be a different story.

For example, I'm very interested in NTP and accurate timekeeping --
mostly as a personal hobby, but it's been useful at work as well. I for
one would definitely not consider NTP one of those details that just
come with the bootup process.


 [regarding the Leatherman]
 Software doesn't have mass so your analogy doesn't quite work.

Analogies can only be taken so far before they cease to make sense.
However, in the software world you could consider a mass equivalent:
code size / complexity. Building on that, just as the Leatherman can't
be as good as all the individual tools combined without weighing too
much, one could say systemd can't be as good as all the individual tools
it aims to replace without being too big and complex.

Program mass, in this case, may impact anything from performance, to
ease of configuration, to complicated dependencies, to security problems.

I did find it interesting, however, what you mentioned in another email,
about systemd implementing certain isolation features such as separate
filesystem namespaces and so on. That may be very useful.


I think the main point that we could hopefully all agree on here, is
that it would be very difficult to have a single one size fits all
solution. The requirements and concerns of the desktop, for example, are
simply too different from those of the server or router space. systemd,
for better or for worse, can't be the one magic bullet. Great or
terrible as though it may be, I don't much like the total break in
compatibility (correct me if I'm wrong). I'm not saying SysV is all that
good, but there are other replacements, and new ones can be designed,
but don't make it so that everyone-has-to-use-yours-or-else! I guess we
have GNOME to thank for that... And that's what troubles me the most:
the lack of choice that seems to be creeping up, with everyone just
ganging up and jumping to systemd like the floor is on fire. I'm with
Jay Ashworth on this one: what gives??

Also, for the person who considered this OT for not being about Cisco,
keep in mind all the world is not a VAX^H^H^HCisco ;)

Re: Linux: concerns over systemd adoption and Debian's decision to switch

[Israel G. Lugo]

I was actually not aware of this. I've been told that systemd also
includes fsck's functionality (or is planning to?). That just seems
absurd to me.

I didn't really have a strong opinion on either side of this yet. Seeing
the replies from other people here, though, and reading some more about
it, this seems to be a very bad idea.

The binary logs for example worry me, especially corruption issues:

http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/
https://bbs.archlinux.org/viewtopic.php?id=169966



On 21-10-2014 14:40, valdis.kletni...@vt.edu wrote:
 On Tue, 21 Oct 2014 14:44:57 +0900, Randy Bush said:
 systemd is insanity.  one would have hoped that deb and others would
 know better.  sigh.
 It started as a replacement init system.  I suspected it had jumped
 the shark when it sprouted an entirely new DHCP and NTP service.  And this
 was confirmed when I saw this:

 Leading up to this has been cursor rendering support, keyboard mapping
 support, screen renderer, DRM back-end, input interface, and dozens of other
 commits.

 http://www.phoronix.com/scan.php?page=news_itempx=MTgwNzQ

 When your init system is worrying about cursor rendering, you have truly
 fallen victim to severe feature bloat.  I guess Jamie Zawinski was right:
 Every program attempts to expand until it can read mail.




signature.asc
Description: OpenPGP digital signature

Re: Linux: concerns over systemd [OT]

[Israel G. Lugo]

On 10/21/2014 11:55 PM, Jay Ashworth wrote:
 - Original Message -
 From: Capi c...@lugosys.com

Whoops, used the wrong alias to reply.


 Not *every single* distribution...
 I had meant to put an asterisk on that.

My remark was meant to be tongue-in-cheek :)


 Ok, but how does it handle providing initscripts?  I gather any upstreams
 which used to provide them aren't anymore...

The Gentoo devs take care of that. I presume they reuse what they can
from upstream... They do a lot of hard work (sometimes more work than
they have the manpower for, unfortunately). I remember, for example,
back in KDE 3.5 days they were already dividing the upstream KDE mega
packages (kde-games, kde-office) into individual packages, so you could
choose specific programs instead of 300 MB bundles.

Re: Linux: concerns over systemd [OT]

[Israel G. Lugo]

On 10/21/2014 11:59 PM, Tom Hill wrote:
 On 21/10/14 23:55, Jay Ashworth wrote:
 Ok, but how does it handle providing initscripts?  I gather any upstreams
 which used to provide them aren't anymore...
 It's Gentoo: You should write your own is the most likely answer.

Actually, not at all; although I realize that's a very common misconception.

Gentoo Linux is, unfortunately, often associated with the whole gcc
-O9000 -msuperfast -fwtf wow-look-at-me crowd.

It's true that some people who use Gentoo go on and rave about how many
nanoseconds they were able to shave off of their boot time, or how many
obscure undocumented GCC options they managed to squeeze in without a
compile error. I suppose the flexible nature of Gentoo is appealing to
those who like to look cool and show off how they can watch the
compiler do its thing. However, that's not at all what the distribution
is about.

Gentoo is about flexibility and choice. It's got a steepish learning
curve, yes, but the documentation is very good; sadly, much of it was
lost a few years ago, due to a bad mishap on the community Gentoo Wiki
server, apparently without any backups. Back in the day, if I wanted to
learn about Samba, I'd Google howto linux samba and Gentoo's Wiki
would usually be among the first 3 hits. Their devs take stability very
seriously; it's a rolling distro, but there is still a reasonable
stabilization period for each package as new versions come out, during
which any open bugs may hold up the package until they're fixed.

It's all about choice. In my view, Gentoo is no better or worse than
Debian, Red Hat, or Ubuntu. Different species, they all make for a
better ecosystem.

Linux: concerns over systemd adoption and Debian's decision to switch

[Israel G. Lugo]

Hi,

Not intending to start a flame war here. I have been referred to the
website below, and believe they certainly raise some valid concerns.

http://www.debianfork.org/

If you have the time, please take a moment to read over the text, and
follow a few links. I am quoting the first few paragraphs as a summary:

 We are Veteran Unix Admins and we are concerned about what is
 happening to Debian GNU/Linux to the point of considering a
 fork of the project.

 Some of us are upstream developers, some professional
 sysadmins: we are all concerned peers interacting with Debian
 and derivatives on a daily basis.

 We don't want to be forced to use systemd in substitution to
 the traditional UNIX sysvinit init, because systemd betrays
 the UNIX philosophy.

 We contemplate adopting more recent alternatives to sysvinit,
 but not those undermining the basic design principles of do
 one thing and do it well with a complex collection of dozens
 of tightly coupled binaries and opaque logs.

I understand discussion on this matter has been quite polarized in some
circles. As stated, it's not my intention to start an argument on
whether A is better than B, nor do I believe that to be the site's
purpose. Rather, I would like to divulge and hopefully incite some
productive discussion.

Regards,
Israel G. Lugo

Re: Problem reaching Wikipedia (AS43821) via Tele2

[Israel G. Lugo]

Indeed, although I wouldn't know why.

The problem lasted the whole day yesterday, but it seems to be gone now.
I was given the tech contact for Wikimedia off-list; if anything rises
up again I'll get in touch with them.

Thank you for the reply, and also to everyone who replied off-list.

Regards,
Israel G. Lugo

On 05/02/2013 07:08 PM, Grant Ridder wrote:
 Looks like ge-2-5.br1-knams.wikimedia.org (130.244.6.250) is filtering you 
 somehow.

 Grant 

 Sent from my iPhone

 On May 2, 2013, at 9:01 AM, Israel G. Lugo israel.l...@lugosys.com wrote:

 Hello,

 Anyone else having problems reaching Wikipedia?

 I can't reach AS43821 (Wikimedia RIPE) from within the Portuguese NREN
 (AS1930), via Cogent (AS174) - Tele2 (AS1257):

 traceroute to en.wikipedia.org (91.198.174.225), 30 hops max, 60 byte
 packets
 1  Router3.10GE.Lisboa.fccn.pt (193.136.1.89) [AS1930]  0.953 ms
 2  ROUTER10.10GE.Lisboa.fccn.pt (193.137.0.8) [AS1930]  0.939 ms
 3  ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) [AS1930]  1.000 ms
 4  fccn.mx2.lis.pt.geant.net (62.40.124.97) [AS20965]  1.000 ms
 5  xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) [AS20965]  13.926 ms
 6  as2.rt1.gen.ch.geant2.net (62.40.112.25) [AS20965]  37.882 ms
 7  ae3.mx1.gen.ch.geant.net (62.40.112.14) [AS20965]  37.874 ms
 8  ae1.mx1.fra.de.geant.net (62.40.98.109) [AS20965]  44.154 ms
 9  ae4.rt1.fra.de.geant.net (62.40.98.135) [AS20965]  43.935 ms
 10  te0-4-0-2.mag21.fra03.atlas.cogentco.com (149.6.42.73) [AS174] 
 44.842 ms
 11  fra36-peer-1.xe-1-2-0-unit0.tele2.net (130.244.200.41) [AS1257] 
 44.368 ms
 12  fra36-core-1.bundle-ether2.tele2.net (130.244.64.186) [AS1257] 
 44.977 ms
 13  *
 14  ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) [AS1257]  50.299 ms
 15  *
 16  *
 17  *
 18  *
 19  *
 20  *

 Tele2's traceroute server (http://services.tele2net.at/traceroute.html)
 reaches the same IP without problems:

 1 213.90.34.4 (213.90.34.4) 0.268 ms 0.124 ms 0.151 ms
 2 213.90.1.20 (213.90.1.20) 0.430 ms 0.382 ms 0.303 ms
 3 wat1-15-93.net.uta.at (62.218.15.93) 0.497 ms 0.368 ms 0.387 ms
 4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.644 ms 0.572 ms
 0.599 ms
 5 wen1-core-2.tengige0-0-1-1.tele2.net (130.244.205.57) 0.836 ms 0.874
 ms 0.737 ms
 6 fra36-core-1.bundle-ether7.tele2.net (130.244.206.28) 13.683 ms 13.472
 ms 13.817 ms
 7 ams-core-2.bundle-ether4.tele2.net (130.244.64.201) 20.421 ms 20.482
 ms 20.762 ms
 8 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) 19.972 ms 19.936 ms
 19.962 ms
 9 ge-2-5.br1-knams.wikimedia.org (130.244.6.250) 20.727 ms 20.641 ms
 20.660 ms
 10 wikipedia-lb.esams.wikimedia.org (91.198.174.225) 20.610 ms 20.539 ms
 20.615 ms

 Trying from $HOME_ISP, via AS6453 (Globe) - AS1299 (Telia) works fine.

 Regards,
 Israel G. Lugo

Problem reaching Wikipedia (AS43821) via Tele2

[Israel G. Lugo]

Hello,

Anyone else having problems reaching Wikipedia?

I can't reach AS43821 (Wikimedia RIPE) from within the Portuguese NREN
(AS1930), via Cogent (AS174) - Tele2 (AS1257):

traceroute to en.wikipedia.org (91.198.174.225), 30 hops max, 60 byte
packets
 1  Router3.10GE.Lisboa.fccn.pt (193.136.1.89) [AS1930]  0.953 ms
 2  ROUTER10.10GE.Lisboa.fccn.pt (193.137.0.8) [AS1930]  0.939 ms
 3  ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) [AS1930]  1.000 ms
 4  fccn.mx2.lis.pt.geant.net (62.40.124.97) [AS20965]  1.000 ms
 5  xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) [AS20965]  13.926 ms
 6  as2.rt1.gen.ch.geant2.net (62.40.112.25) [AS20965]  37.882 ms
 7  ae3.mx1.gen.ch.geant.net (62.40.112.14) [AS20965]  37.874 ms
 8  ae1.mx1.fra.de.geant.net (62.40.98.109) [AS20965]  44.154 ms
 9  ae4.rt1.fra.de.geant.net (62.40.98.135) [AS20965]  43.935 ms
10  te0-4-0-2.mag21.fra03.atlas.cogentco.com (149.6.42.73) [AS174] 
44.842 ms
11  fra36-peer-1.xe-1-2-0-unit0.tele2.net (130.244.200.41) [AS1257] 
44.368 ms
12  fra36-core-1.bundle-ether2.tele2.net (130.244.64.186) [AS1257] 
44.977 ms
13  *
14  ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) [AS1257]  50.299 ms
15  *
16  *
17  *
18  *
19  *
20  *

Tele2's traceroute server (http://services.tele2net.at/traceroute.html)
reaches the same IP without problems:

1 213.90.34.4 (213.90.34.4) 0.268 ms 0.124 ms 0.151 ms
2 213.90.1.20 (213.90.1.20) 0.430 ms 0.382 ms 0.303 ms
3 wat1-15-93.net.uta.at (62.218.15.93) 0.497 ms 0.368 ms 0.387 ms
4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.644 ms 0.572 ms
0.599 ms
5 wen1-core-2.tengige0-0-1-1.tele2.net (130.244.205.57) 0.836 ms 0.874
ms 0.737 ms
6 fra36-core-1.bundle-ether7.tele2.net (130.244.206.28) 13.683 ms 13.472
ms 13.817 ms
7 ams-core-2.bundle-ether4.tele2.net (130.244.64.201) 20.421 ms 20.482
ms 20.762 ms
8 ams13-peer-1.ae0-unit0.tele2.net (130.244.53.123) 19.972 ms 19.936 ms
19.962 ms
9 ge-2-5.br1-knams.wikimedia.org (130.244.6.250) 20.727 ms 20.641 ms
20.660 ms
10 wikipedia-lb.esams.wikimedia.org (91.198.174.225) 20.610 ms 20.539 ms
20.615 ms

Trying from $HOME_ISP, via AS6453 (Globe) - AS1299 (Telia) works fine.

Regards,
Israel G. Lugo

Re: http/ssl to dropbox.com dying

[Israel G. Lugo]

Hi,

On 06/29/2012 11:20 PM, Greg Ihnen wrote:
 It seems like a transport issue.

 Is there any tools for checking where an https connection is failing, like a 
 traceroute for https?

GNU/Linux traceroute sends UDP by default. Something along the way could
be filtering UDP, so default traceroute may not be indicative.

To better replicate the problem, you can tell traceroute to send TCP
SYNs to the specific port you're trying to reach (443). Run this as root
(it needs raw sockets):

# traceroute -M tcp -p 443 dropbox.com

Regards,
Israel G. Lugo

Re: facebook.com DNS not found 20120218 2125 UTC

[Israel G. Lugo]

Likewise, working here.

$ dig +trace www.facebook.com

;  DiG 9.7.0-P1  +trace www.facebook.com
;; global options: +cmd
.   240259  IN  NS  b.root-servers.net.
.   240259  IN  NS  g.root-servers.net.
.   240259  IN  NS  i.root-servers.net.
.   240259  IN  NS  c.root-servers.net.
.   240259  IN  NS  f.root-servers.net.
.   240259  IN  NS  d.root-servers.net.
.   240259  IN  NS  l.root-servers.net.
.   240259  IN  NS  m.root-servers.net.
.   240259  IN  NS  j.root-servers.net.
.   240259  IN  NS  e.root-servers.net.
.   240259  IN  NS  a.root-servers.net.
.   240259  IN  NS  h.root-servers.net.
.   240259  IN  NS  k.root-servers.net.
;; Received 272 bytes from 192.168.100.1#53(192.168.100.1) in 1 ms

com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
;; Received 494 bytes from 2001:7fd::1#53(k.root-servers.net) in 65 ms

facebook.com.   172800  IN  NS  ns1.facebook.com.
facebook.com.   172800  IN  NS  ns2.facebook.com.
facebook.com.   172800  IN  NS  ns3.facebook.com.
facebook.com.   172800  IN  NS  ns4.facebook.com.
facebook.com.   172800  IN  NS  ns5.facebook.com.
;; Received 204 bytes from 192.48.79.30#53(j.gtld-servers.net) in 361 ms

www.facebook.com.   86400   IN  NS  glb2.facebook.com.
www.facebook.com.   86400   IN  NS  glb1.facebook.com.
;; Received 104 bytes from 66.220.145.65#53(ns5.facebook.com) in 206 ms

www.facebook.com.   120 IN  A   69.63.190.22
;; Received 50 bytes from 69.171.255.10#53(glb2.facebook.com) in 146 ms



On 02/18/2012 09:39 PM, John Peach wrote:
 On Sat, 18 Feb 2012 13:32:42 -0800
 Everett Batey efba...@gmail.com wrote:

 facebook.com DNS not found 20120218 2125 UTC
 Is there any outage information for DNS for  facebook.com / www.facebook.com
  ?
   Oops! Google Chrome could not find www.facebook.com
 Not here

 dig +trace www.facebook.com

 ;  DiG 9.7.3  +trace www.facebook.com
 ;; global options: +cmd
 .   157853  IN  NS  d.root-servers.net.
 .   157853  IN  NS  j.root-servers.net.
 .   157853  IN  NS  c.root-servers.net.
 .   157853  IN  NS  f.root-servers.net.
 .   157853  IN  NS  b.root-servers.net.
 .   157853  IN  NS  l.root-servers.net.
 .   157853  IN  NS  h.root-servers.net.
 .   157853  IN  NS  m.root-servers.net.
 .   157853  IN  NS  a.root-servers.net.
 .   157853  IN  NS  k.root-servers.net.
 .   157853  IN  NS  g.root-servers.net.
 .   157853  IN  NS  e.root-servers.net.
 .   157853  IN  NS  i.root-servers.net.
 ;; Received 228 bytes from 192.168.1.2#53(192.168.1.2) in 3 ms

 com.172800  IN  NS  b.gtld-servers.net.
 com.172800  IN  NS  a.gtld-servers.net.
 com.172800  IN  NS  f.gtld-servers.net.
 com.172800  IN  NS  c.gtld-servers.net.
 com.172800  IN  NS  j.gtld-servers.net.
 com.172800  IN  NS  h.gtld-servers.net.
 com.172800  IN  NS  l.gtld-servers.net.
 com.172800  IN  NS  k.gtld-servers.net.
 com.172800  IN  NS  g.gtld-servers.net.
 com.172800  IN  NS  m.gtld-servers.net.
 com.172800  IN  NS  i.gtld-servers.net.
 com.172800  IN  NS  e.gtld-servers.net.
 com.