Typically, 192.168 is used in consumer grade equipment. Let's face it - not many home networks need a lot of IP's, and those few that do don't really need to worry about route summarization. The 172.16 block is usually used in a small to medium business that would have multiple locations and more devices than a typical home network. Route summarization may or may not be used, or needed.
The 10. block is used in large networks both because of the number of available addresses and because it allows you to do some cool things with route summarization on a large WAN infrastructure. Route summarization reduces route table size, processor load, and overall complexity in the network, which are all good things:).
Say I have a building that has 18 wiring closets in it. I could build the network in such a way that each wiring closet is a VLAN. Each VLAN gets it's own, unique IP Network.
If I needed to, I could have multiple VLANs in the closet based on departments, job functions, or almost any other criteria. Assume I've built two VLANs in each closet, for a total of 36 VLANS, at least. I may have other VLANs dedicated to servers, routers, firewalls, etc.
If I have 192 ports built into each closet, planning for worst case, and make sure I have at least 192 addresses available in each of my 36 VLANs. I'd have to remember to add to the count for a router/gateway address, and any growth I could anticipate in that closet.
If I plan to add additional ports, or think it's a possibility, I might want to add another 192 addresses to the network. It's a &$*%^ to come back and re-address later - invariably there will be some mission critical device no one documented that has a static address, under someone's desk.
Based on these numbers, I'd need at least 386 addresses. Since 2^8 is only 256 addresses, I need to go to 2^9 (512 addresses).
I count bits from right to left, and I see that to have the nine bits of host address, I need to use a 23 bit network mask (32-9=23 bits of network mask).
Now remember I have two VLANs in each closet, and to make things easy, I'll build them both to my worst case scenerio. I'll need a 23 bit network for both.
Given that I've pushed my Layer 3 to the edge, I could advertise both 23 bit networks back to the core. However, if I used contigous 23 bit networks, I could also summarize them into a single 22 bit route to be advertised towards the core.
This means my core would only need to have 18 routes to route traffic to all 36 VLANs.
If you scale this approach across a WAN, you can see summarization allows you to simplify your routing and control over the network.
I read your Journal entry. A couple of things for you-
1. Are you doing Voice or Data CLEC? The type of traffic will dictate the network you use. ATM is good for data, but TDM is better for Voice, even now.
2. Have you gotten your certificate from your state PUC? Without it, the local ILEC won't (and doesn't have to) give you the time of day.
3. If you've gotten your certificate, have you negotiated your ICA (inter-connect agreement)? The ICA will specify exactly what the ILEC has to provide you, and at what prices. You might still be able to opt into an existing ICA between the ILEC and another CLEC if you can find one you like.
4. Have you applied to your area co-ordinator for your number block? Who's hosting your SS7? How are you handling connectivity to the required 911 PSAPs?
5. Do you have an OSS platform that's flexible enough to do what you need, but simple enough to operate on a shoe string?
Yeah.. I was thinking 53 (48+5) and typed 58... and it wasn't all of Europe... was France.. Propagation delay on 48 byte cells would have let them send it across the country without electrical regeneration of timing.
I'm gonna make a couple of assumptions... #1 If you're using ATM, you've got at least 4xT1 IMA group. Anything smaller and Multi-link PPP or Multi-link Frame Relay makes more sense.
#2 There's something about ATM that you need for your application. Most of the QoS functions you can get now with the DSCP bits and other IP QoS techniques.
ATM uses 58 byte cells. A 4xT1 IMA group is roughly 6.1Mbps. With these numbers, we can see that this 4xT1 IMA group will handle slightly more than 13K Cells/s.
At layer 1, ATM is easy... listen for 58 bytes, send the cell up the stack... listen for 58 bytes, send the cell up the stack...
At layer 2, though, you have segmentation and reassembly functions, which take all those 58 byte cells and turn them back into packets. The SAR code has to check every cell for packet data.
Once all that is done, then you can get your L3 IP packet, examine it as needed, and route it.
All this is to say that while a large portion of this process begs to be implemented in hardware, as most router companies have, Linux does this mostly in software, burning CPU proportionately to the ATM traffic load.
If you're going to use a PC with Linux to handle ATM and routing, then make sure you've got the CPU, memory, and backplane to handle the load. I would not use a box that is also going to be hitting the disk on a regular basis; I wouldn't want disk i/o sharing the bandwidth across the backplane.
While I don't have direct experience with the product line mentioned in the question, I have implemented Aventail in the past, and am looking at them again for a project next year.
For the most part, SSL VPN products differ from IPSEC VPN products in a fundamental way. SSL VPN products can best be imagined as reverse proxy servers that use SSL based encryption. Typically, it is the SSL VPN device that will be making connections to the "protected" network hosts, not the remote node. TCP sessions are maintained remote node to SSL device, and SSL device to "protected" host.
IPSEC products can be imagined more as encrypted water hoses. A device (or client shim) intercepts traffic at the remote node, puts it in the hose (encrypted tunnel), and pushes it out to the IPSEC device at the protected network. TCP sessions are maintained remote node to "protected" host.
Although the tunnel does normally imply some stateful translation, the session does not terminate on a tunnel device, unless that device is the remote node.
Obviously SSL products are great for Web based applications. IPSEC products lend themselves best to site-to-site connectivity. The grey area between them is remote client situations.
Which solution is better in the remote client (i.e. laptop in a hotel room, or at a client's site) really depends on the where and how the remote client is to be used.
Many organizations don't allow IPSEC tunnels to be initiated from their internal network to an outside location.
On the other hand, those same organizations (and many others) will allow outbound SSL traffic initiated from hosts on the internal network.
The easiest way, I've found, is to pull the CF card, put it in a reader on another linux box, and copy your boot image to it... I use RH -
CF installed as/dev/sda
dd if=bootnet.img of=/dev/sda
Then put the CF card back in the 650, boot it, and run the ftp based install from your local ftp server. Make sure when you format your drives that you put/boot on/dev/hda (the CF card). The IDE hard drive is/dev/hdc.
We recently replaced the Nokia/Checkpoint boxen with PIX firewalls. I don't care to get into a PIX vs Checkpoint war, but lets just say it saved us TONS of $$$$ on a yearly basis.
Having seven of these IP650's sitting on a shelf, I had to wonder... what can I use them for??? Then it hit me... I need RMON type probe capabilities in my call centers around the country, and with the four port NIC's installed, these might make good candidates.
I pull the compact flash card from the 650, put it in my reader on my RH8 desktop, dd bootnet.img to it, put it back in the IP650, and boot it. Once it boots, a simple FTP load, using the compact flash card at/dev/hda for the/boot partition works like a charm.
I've got squideral, NTOP, ethereal, and a couple of in house scripts running on each of them now collecting traffic stats, doing WCCP transparent caching, and allowing me to do remote sniffs of the call centers.
If something's worth doing, it's worth doing right. The main consideration from ARIN, as I recall, is a 70% allocation of existing address space. If you've got/28, two addresses are used for network/broadcast, at least one on a router, and at least one on a firewall.
You do have (a) firewall(s), don't you?
At a minimum, that's already 25% of the existing address space in use, without including any servers you may, or NAT addressing you may be doing.
Break your/28 up into smaller networks, maybe like this, and a larger range is easy to justify-
/28 =/29 - 6 available host addresses /29 =/30 - 2 available host addresses /30 =/32 single host (loopback) /32 single host (loopback)
This scheme gives you just 5 useable addresses left, assuming you've got two routers and a firewall. The available/30 could be used for NAT translations, or any number of other things.
With 11/16 addresses used, you're at 68% of your address space. One more host puts you over the top.
Use this type of addressing to get the better of the two ISPs you choose to delegate a routeable block to you.
Obtain from ARIN, an ASN. Inform the other ISP that you want to BGP peer with them, tell them if you want full routes, or summary routes only advertised to you, and give them your ASN and the IP addresses of the router(s) they'll be peered with. Give the first ISP the same info. Both ISP's should give you ASN's and peering info for themselves as well. Here's the catch... make sure you don't turn yourself into a transit area between the two ISPs. Filter your BGP adverts so that you're only advertising routes originated in your AS.
Ok.. Here's there deal. Working for a telco, I have some first hand knowledge here.
When a customer is willing to pay the HUGE fees associated with a "dark fiber" cross country, that's typically what they get - dark fiber.
When your telco is selling you "dark fiber" for local use, metro ethernet, whatever, as long as it stays in the same LATA, and is handled by the same carrier, it's actually just a DWDM wavelength on an already lit ring.
A lot of the time, but not always, the lambda (DWDM wavelength) will be delivered to the Customer Premise on MMF from a shelf in the basement, attic, electrical room, telco room, telco hut down the street, or somewhere near by. If the customer is large enough, they might even rate their own shelf.
Sometimes, though, customers request SMF, which can normally be handled as well. Usually, with SMF, though, a customer is buying a service such as an OC-48.
Now... what's the diff? With the "dark fiber" metro connection above, you've normally got $#@% for redundancy, unless you buy enough of those "dark fiber" pairs to implement it yourself. The telco probably won't give you much of an SLA on it. If they do... you're definitely getting a lambda.
On the other hand, though, the OC-48 service probably has a good (decent) SLA that can be negotiated to an acceptable level.
It's all about price, performance, reliability and control.
First, I don't have all the details of what happened, nor do I have any idea of what the network looked like prior to the outage. However, I have a general design philosphy based on my experience with teaching hospitals and telco networks.
The concept is that of "a network of networks", much like Cisco's DCN solution for telco operators. This is a series of interconnected networks that are capable of standing alone in an emergency. These networks are normally oriented around particular application/traffic/usage patterns. An example would be a research network for research workstations, a lab network, a cardic care network, and so on.
All of these networks could exist as seperate layer 2 vlans trunked back to the facility data center,if bandwidth is available. Within the data center, layer 3 routing could handle traffic that needed to cross between these networks. The data center would also have seperate networks for each application group so that applications aren't able to interfere with each other, generally.
Obviously this is an overly broad synopsis and leaves out many details; it is also just as obvious that I'm talking about a campus environment here and not a WAN, where the same theory will work, but with different implementation.
PRI's are in fact 23 64K B (bearer) channels plus a D channel (64K in PRI, but only 16K in BRI) for signalling. PRI's can be used for Internet access, but are typically used in dial situations; like access servers(modem banks), or call center voice switches or such.
PRI's are delivered on T1 circuits and almost always cost more than a T1 because they MUST be terminated into a PRI capable switch on one end. This is usually done in the square red brick building with the funny looking bell symbol on the front.
T1's are made up of 24 64K timeslots. Things get can get confusing because different line codings can reduce those to 56K timeslots (DS0's).
Bandwidth can be delivered with T1 signalling as either full or fractional T1, which is more or less still a T1 in which the telco allows you to send data in Nx64K timeslots(channels) where N24, and pads the remaining channels with a pattern to maintain framing.
Frame-Relay service can be delivered via 56KDDS circuit, ISDN BRI in some places, Frac T1/T1, and Frac DS3/DS3 circuits. In all cases, you buy a circuit to the closest Frame-relay switch your provider has available. This is the access portion of the charge. Then you will also purchase a port on that Frame-relay switch.
Your access circuit must match your frame port so it is important to properly size this to allow for the maximum speed you want to be able to use. Most providers will allow you to "burst to port" speed, at least for a limited time, as long as the switch has bandwidth on the backplane.
You will also buy CIR, or Committed Information Rate, on your PVCs. This is the minimum guaranteed speed of your circuit. You can send traffic up to this speed as much and as long as you want and should see no ill effects; once you exceed CIR, your data will become eligible for discard by the frame network if it experiences congestion and you will need to rely on higher layer protocols to ensure data delivery.
DLCIs are more or less pointers that have meaning only between either a switch an a router, or two switches. DLCIs are used by the network devices to tag which traffic goes to what PVC, and may be different at each point in the network, even within the same PVC.
Since I'm smack dab in the middle of rolling this out, I thought I'd mention that this system basically allows law enforcement to connect to any CALEA equipped telco switch (should be all of them soon; then fines for non-compliance are just too steep to make the business case to not do it), and initiate either a trap-n-trace, or a record look-up on a number, without telco permission, or knowledge if it works like the vendor docs say it will.
There's nothing in anything I've read in the docs that say law enforcement will be able to remotely initiate a wiretap with CALEA, but you don't have to be a brain surgeon to figure out how to setup a few switch trunks to handle that, either.
Actually, you sound like someone that's never had to worry about anything below layer 4...
MRTG is fine for pulling stats from one end of the connection, and then only for which Cisco has thought to put counter OID's into their mibs. I've got two mrtg servers polling my 400+ routers and switches now for stats like utilization, errors, etc.
However, what I'm looking for is something that lets me quantify the connection from the END USER'S point of view. I already log CDR's to a syslog server. Coupled with these Call Detail Records, and certain debugs, I can analyze my side of the connection fine, even though I have to puruse form than 9000 lines of logfile info daily to do it.
SO next time, listen to your mother, and if you don't have something constructive to say, SHUT THE HELL UP, ok?
Local companies are ILECs (incumbant local exchange carriers), not CLEC's (competitive local exchange carriers).... ILEC's are the companies that are supposed to provide unbumdled access to their copper at wholesale prices to give CLEC's a fighting chance.
Fiber installation typically runs $15K-$90K per fiber mile, if one already has the right of ways.
The fiber itself is cheap; the expensive part is installation which is highly labor intensive, even today. Add in the insurance installers have to have to cover cable cuts made when they run their directional boring machine through someone's cable, and it's obviously not a project you'd want to take on without some kind of co-op with city/regional government.
Actually, back when I was doing Token Ring on a regular basis, there was a Win driver issue with madge TR nic's that would take a ring down.
Some how, some way, every madge nic on a particular ring would decide at almost the same time that it wanted to be the RPS (ring parameter server) and/or the active controller. Not a very nice thing on a large ring, nor is it easy to troubleshoot.
We eventually figured out the problem when (for the third time) we shut every machine on the ring down, and brought them up one by one. The machine that started having the problem changed every time, but every machine that started the problem had the same driver loaded. We replaced the cards with Olicom, got the current drivers, and never had that problem again.
Notice I didn't say never had A problem again. When Token Ring worked, it was fairly good... when it didn't, almost by design it was a pain in the (insert your choice here).
Of course, most, but not all, open source (including Apache) can be compiled for Windoze as well.
Besides, as a vendor, the customer is paying you not only for the product, but for the expertise and experience you (or your company) bring to the table. Otherwise, they'd be buying something off the shelf and doing it themselves.
It never hurts to back up and look at the business reasons early in the project. Many times, by paying attention to the ins and outs of the business at hand, a techie can see a better way of doing things that will end up saving money, being easier to support, cost less to maintain, or all of the above.
A person that lives in the woods never sees anything but the trees.
Technology now exists to provision some form of DSL over most connection types, including Integrated-Fiber-In-The-Loop, FTTC (Fiber to the curb), FTTN (fiber to the neighborhood) et al.
In all these connection scenarios, there is one common element: There must be a powered cabinet in which resides the equipment that converts from the Analog voice signal to the 64Kbps G.711 stream. In many, but by no means all, cases, the fiber portion of the circuit is an STS-1 or STS-3 SONET loop back to the local CO or remote office.
Also, let me point out that a T1 is not provisoned on a single pair; a T1/DS1 uses a Transmit Pair and a Recieve Pair that must be located in seperate cable bundles to prevent cross-talk. HOWEVER, in certain areas of the country, where copper facilites are in short supply, Telcos are providing DS1/T1 connectivity by delivering the circuit as HDSL to the customer premise, at which point a special smart-jack converts the single pair HDSL signal to a two pair (four wire) DS1/T1. Telcos have been doing this for several years now.
As far as situations as yours go, most often it is simply the fact that the cost of providing the service is to high to justify the expense of rolling it out. In the markets I'm familiar with (market populations under 150K, in 22 states), there have been several cases where the cost of the bandwidth to backhaul from a particular market to the closest Internet POP was more than we could charge for the service in a given market.
Many of the DSL providers that have gone under, did so because they failed to use good business sense, and instead went with what I call the "Field of Dreams" model: Build it, and they will come... Definitely not a good approach to business.
On average, Telcos expect a two to three year payback on the investment. This investment can vary greatly, but you can expect the capital equipment costs alone to implement DSL in a given market to approach $1M. This means that the Telco must net, after subtracting the recurring cost of providing the service, approximately $30K monthly, or about $15-$20 of each subscriber's monthly bill, just to break even. Recurring operations charges to provide the service typically come in the range of $25-$35/month. Any lower, and there's something weird going on; any higher and there's usually no way to be competitive in the market.
For this reason, if the Telco can't keep the recurring cost down to a reasonable level that allows for a competitive rate for the service, then it is simply good business to NOT provide the service.
Anyway, that's my slightly more than 2 cents on the subject. Sorry for being so long winded, but it is really a complex business issue, more so than a technical issue.
Slashdot Mirror
Typically, 192.168 is used in consumer grade equipment. Let's face it - not many home networks need a lot of IP's, and those few that do don't really need to worry about route summarization. The 172.16 block is usually used in a small to medium business that would have multiple locations and more devices than a typical home network. Route summarization may or may not be used, or needed.
:).
The 10. block is used in large networks both because of the number of available addresses and because it allows you to do some cool things with route summarization on a large WAN infrastructure. Route summarization reduces route table size, processor load, and overall complexity in the network, which are all good things
Say I have a building that has 18 wiring closets in it. I could build the network in such a way that each wiring closet is a VLAN. Each VLAN gets it's own, unique IP Network.
If I needed to, I could have multiple VLANs in the closet based on departments, job functions, or almost any other criteria. Assume I've built two VLANs in each closet, for a total of 36 VLANS, at least. I may have other VLANs dedicated to servers, routers, firewalls, etc.
If I have 192 ports built into each closet, planning for worst case, and make sure I have at least 192 addresses available in each of my 36 VLANs. I'd have to remember to add to the count for a router/gateway address, and any growth I could anticipate in that closet.
If I plan to add additional ports, or think it's a possibility, I might want to add another 192 addresses to the network. It's a &$*%^ to come back and re-address later - invariably there will be some mission critical device no one documented that has a static address, under someone's desk.
Based on these numbers, I'd need at least 386 addresses. Since 2^8 is only 256 addresses, I need to go to 2^9 (512 addresses).
I count bits from right to left, and I see that to have the nine bits of host address, I need to use a 23 bit network mask (32-9=23 bits of network mask).
Now remember I have two VLANs in each closet, and to make things easy, I'll build them both to my worst case scenerio. I'll need a 23 bit network for both.
Given that I've pushed my Layer 3 to the edge, I could advertise both 23 bit networks back to the core. However, if I used contigous 23 bit networks, I could also summarize them into a single 22 bit route to be advertised towards the core.
This means my core would only need to have 18 routes to route traffic to all 36 VLANs.
If you scale this approach across a WAN, you can see summarization allows you to simplify your routing and control over the network.
I read your Journal entry. A couple of things for you-
1. Are you doing Voice or Data CLEC? The type of traffic will dictate the network you use. ATM is good for data, but TDM is better for Voice, even now.
2. Have you gotten your certificate from your state PUC? Without it, the local ILEC won't (and doesn't have to) give you the time of day.
3. If you've gotten your certificate, have you negotiated your ICA (inter-connect agreement)? The ICA will specify exactly what the ILEC has to provide you, and at what prices. You might still be able to opt into an existing ICA between the ILEC and another CLEC if you can find one you like.
4. Have you applied to your area co-ordinator for your number block? Who's hosting your SS7? How are you handling connectivity to the required 911 PSAPs?
5. Do you have an OSS platform that's flexible enough to do what you need, but simple enough to operate on a shoe string?
You might want to subscribe to the isp-clec lists at http://isp-lists.isp-planet.com .
Yeah.. I was thinking 53 (48+5) and typed 58...
and it wasn't all of Europe... was France.. Propagation delay on 48 byte cells would have let them send it across the country without electrical regeneration of timing.
If you're using an ONS, why not just use an ethernet card in the ONS?
I'm gonna make a couple of assumptions...
#1 If you're using ATM, you've got at least 4xT1 IMA group. Anything smaller and Multi-link PPP or Multi-link Frame Relay makes more sense.
#2 There's something about ATM that you need for your application. Most of the QoS functions you can get now with the DSCP bits and other IP QoS techniques.
ATM uses 58 byte cells. A 4xT1 IMA group is roughly 6.1Mbps. With these numbers, we can see that this 4xT1 IMA group will handle slightly more than 13K Cells/s.
At layer 1, ATM is easy... listen for 58 bytes, send the cell up the stack... listen for 58 bytes, send the cell up the stack...
At layer 2, though, you have segmentation and reassembly functions, which take all those 58 byte cells and turn them back into packets. The SAR code has to check every cell for packet data.
Once all that is done, then you can get your L3 IP packet, examine it as needed, and route it.
All this is to say that while a large portion of this process begs to be implemented in hardware, as most router companies have, Linux does this mostly in software, burning CPU proportionately to the ATM traffic load.
If you're going to use a PC with Linux to handle ATM and routing, then make sure you've got the CPU, memory, and backplane to handle the load. I would not use a box that is also going to be hitting the disk on a regular basis; I wouldn't want disk i/o sharing the bandwidth across the backplane.
While I don't have direct experience with the product line mentioned in the question, I have implemented Aventail in the past, and am looking at them again for a project next year.
For the most part, SSL VPN products differ from IPSEC VPN products in a fundamental way. SSL VPN products can best be imagined as reverse proxy servers that use SSL based encryption. Typically, it is the SSL VPN device that will be making connections to the "protected" network hosts, not the remote node. TCP sessions are maintained remote node to SSL device, and SSL device to "protected" host.
IPSEC products can be imagined more as encrypted water hoses. A device (or client shim) intercepts traffic at the remote node, puts it in the hose (encrypted tunnel), and pushes it out to the IPSEC device at the protected network. TCP sessions are maintained remote node to "protected" host.
Although the tunnel does normally imply some stateful translation, the session does not terminate on a tunnel device, unless that device is the remote node.
Obviously SSL products are great for Web based applications. IPSEC products lend themselves best to site-to-site connectivity. The grey area between them is remote client situations.
Which solution is better in the remote client (i.e. laptop in a hotel room, or at a client's site) really depends on the where and how the remote client is to be used.
Many organizations don't allow IPSEC tunnels to be initiated from their internal network to an outside location.
On the other hand, those same organizations (and many others) will allow outbound SSL traffic initiated from hosts on the internal network.
The main problem with this is that the drive comes up on it's own controller, and as /dev/hdc. The machine won't load the boot loader from there.
/dev/hda.
The bootloader must be on the CF card at
Joe
The easiest way, I've found, is to pull the CF card, put it in a reader on another linux box, and copy your boot image to it... I use RH -
/dev/sda
/boot on /dev/hda (the CF card). The IDE hard drive is /dev/hdc.
CF installed as
dd if=bootnet.img of=/dev/sda
Then put the CF card back in the 650, boot it, and run the ftp based install from your local ftp server. Make sure when you format your drives that you put
Joe
We recently replaced the Nokia/Checkpoint boxen with PIX firewalls. I don't care to get into a PIX vs Checkpoint war, but lets just say it saved us TONS of $$$$ on a yearly basis.
/dev/hda for the /boot partition works like a charm.
Having seven of these IP650's sitting on a shelf, I had to wonder... what can I use them for??? Then it hit me... I need RMON type probe capabilities in my call centers around the country, and with the four port NIC's installed, these might make good candidates.
I pull the compact flash card from the 650, put it in my reader on my RH8 desktop, dd bootnet.img to it, put it back in the IP650, and boot it. Once it boots, a simple FTP load, using the compact flash card at
I've got squideral, NTOP, ethereal, and a couple of in house scripts running on each of them now collecting traffic stats, doing WCCP transparent caching, and allowing me to do remote sniffs of the call centers.
If something's worth doing, it's worth doing right. The main consideration from ARIN, as I recall, is a 70% allocation of existing address space. If you've got /28, two addresses are used for network/broadcast, at least one on a router, and at least one on a firewall.
/28 up into smaller networks, maybe like this, and a larger range is easy to justify-
/28 = /29 - 6 available host addresses
/29 = /30 - 2 available host addresses
/30 = /32 single host (loopback)
/32 single host (loopback)
/30 could be used for NAT translations, or any number of other things.
You do have (a) firewall(s), don't you?
At a minimum, that's already 25% of the existing address space in use, without including any servers you may, or NAT addressing you may be doing.
Break your
This scheme gives you just 5 useable addresses left, assuming you've got two routers and a firewall. The available
With 11/16 addresses used, you're at 68% of your address space. One more host puts you over the top.
Use this type of addressing to get the better of the two ISPs you choose to delegate a routeable block to you.
Obtain from ARIN, an ASN. Inform the other ISP that you want to BGP peer with them, tell them if you want full routes, or summary routes only advertised to you, and give them your ASN and the IP addresses of the router(s) they'll be peered with. Give the first ISP the same info. Both ISP's should give you ASN's and peering info for themselves as well. Here's the catch... make sure you don't turn yourself into a transit area between the two ISPs. Filter your BGP adverts so that you're only advertising routes originated in your AS.
Simple, huh?
Joe
As of a couple of years ago, you didn't need any IP's from ARIN to get an ASN.
Ok.. Here's there deal. Working for a telco, I have some first hand knowledge here.
When a customer is willing to pay the HUGE fees associated with a "dark fiber" cross country, that's typically what they get - dark fiber.
When your telco is selling you "dark fiber" for local use, metro ethernet, whatever, as long as it stays in the same LATA, and is handled by the same carrier, it's actually just a DWDM wavelength on an already lit ring.
A lot of the time, but not always, the lambda (DWDM wavelength) will be delivered to the Customer Premise on MMF from a shelf in the basement, attic, electrical room, telco room, telco hut down the street, or somewhere near by. If the customer is large enough, they might even rate their own shelf.
Sometimes, though, customers request SMF, which can normally be handled as well. Usually, with SMF, though, a customer is buying a service such as an OC-48.
Now... what's the diff? With the "dark fiber" metro connection above, you've normally got $#@% for redundancy, unless you buy enough of those "dark fiber" pairs to implement it yourself. The telco probably won't give you much of an SLA on it. If they do... you're definitely getting a lambda.
On the other hand, though, the OC-48 service probably has a good (decent) SLA that can be negotiated to an acceptable level.
It's all about price, performance, reliability and control.
I've not read the specs myself, but hopefully that was a typo... +/- 25% is no where near precise, especially in a dosimeter.
First, I don't have all the details of what happened, nor do I have any idea of what the network looked like prior to the outage. However, I have a general design philosphy based on my experience with teaching hospitals and telco networks.
The concept is that of "a network of networks", much like Cisco's DCN solution for telco operators. This is a series of interconnected networks that are capable of standing alone in an emergency. These networks are normally oriented around particular application/traffic/usage patterns. An example would be a research network for research workstations, a lab network, a cardic care network, and so on.
All of these networks could exist as seperate layer 2 vlans trunked back to the facility data center,if bandwidth is available. Within the data center, layer 3 routing could handle traffic that needed to cross between these networks. The data center would also have seperate networks for each application group so that applications aren't able to interfere with each other, generally.
Obviously this is an overly broad synopsis and leaves out many details; it is also just as obvious that I'm talking about a campus environment here and not a WAN, where the same theory will work, but with different implementation.
PRI's are in fact 23 64K B (bearer) channels plus a D channel (64K in PRI, but only 16K in BRI) for signalling. PRI's can be used for Internet access, but are typically used in dial situations; like access servers(modem banks), or call center voice switches or such.
PRI's are delivered on T1 circuits and almost always cost more than a T1 because they MUST be terminated into a PRI capable switch on one end. This is usually done in the square red brick building with the funny looking bell symbol on the front.
T1's are made up of 24 64K timeslots. Things get can get confusing because different line codings can reduce those to 56K timeslots (DS0's).
Bandwidth can be delivered with T1 signalling as either full or fractional T1, which is more or less still a T1 in which the telco allows you to send data in Nx64K timeslots(channels) where N24, and pads the remaining channels with a pattern to maintain framing.
Frame-Relay service can be delivered via 56KDDS circuit, ISDN BRI in some places, Frac T1/T1, and Frac DS3/DS3 circuits. In all cases, you buy a circuit to the closest Frame-relay switch your provider has available. This is the access portion of the charge. Then you will also purchase a port on that Frame-relay switch.
Your access circuit must match your frame port so it is important to properly size this to allow for the maximum speed you want to be able to use. Most providers will allow you to "burst to port" speed, at least for a limited time, as long as the switch has bandwidth on the backplane.
You will also buy CIR, or Committed Information Rate, on your PVCs. This is the minimum guaranteed speed of your circuit. You can send traffic up to this speed as much and as long as you want and should see no ill effects; once you exceed CIR, your data will become eligible for discard by the frame network if it experiences congestion and you will need to rely on higher layer protocols to ensure data delivery.
DLCIs are more or less pointers that have meaning only between either a switch an a router, or two switches. DLCIs are used by the network devices to tag which traffic goes to what PVC, and may be different at each point in the network, even within the same PVC.
Hope this helps some-
Joe
Since I'm smack dab in the middle of rolling this out, I thought I'd mention that this system basically allows law enforcement to connect to any CALEA equipped telco switch (should be all of them soon; then fines for non-compliance are just too steep to make the business case to not do it), and initiate either a trap-n-trace, or a record look-up on a number, without telco permission, or knowledge if it works like the vendor docs say it will.
There's nothing in anything I've read in the docs that say law enforcement will be able to remotely initiate a wiretap with CALEA, but you don't have to be a brain surgeon to figure out how to setup a few switch trunks to handle that, either.
Anyhow... my thoughts for whatever it's worth...
Actually, assuming 60% transfer efficiency, adding ethernet header, ip, tcp headers, it would take closer to 32 minutes to move the data:
((140GB*8)/.6)/1Gbps/60=31.1 minutes
Actually, you sound like someone that's never had to worry about anything below layer 4...
MRTG is fine for pulling stats from one end of the connection, and then only for which Cisco has thought to put counter OID's into their mibs. I've got two mrtg servers polling my 400+ routers and switches now for stats like utilization, errors, etc.
However, what I'm looking for is something that lets me quantify the connection from the END USER'S point of view. I already log CDR's to a syslog server. Coupled with these Call Detail Records, and certain debugs, I can analyze my side of the connection fine, even though I have to puruse form than 9000 lines of logfile info daily to do it.
SO next time, listen to your mother, and if you don't have something constructive to say, SHUT THE HELL UP, ok?
Local companies are ILECs (incumbant local exchange carriers), not CLEC's (competitive local exchange carriers).... ILEC's are the companies that are supposed to provide unbumdled access to their copper at wholesale prices to give CLEC's a fighting chance.
Fiber installation typically runs $15K-$90K per fiber mile, if one already has the right of ways.
The fiber itself is cheap; the expensive part is installation which is highly labor intensive, even today. Add in the insurance installers have to have to cover cable cuts made when they run their directional boring machine through someone's cable, and it's obviously not a project you'd want to take on without some kind of co-op with city/regional government.
Actually, back when I was doing Token Ring on a regular basis, there was a Win driver issue with madge TR nic's that would take a ring down.
Some how, some way, every madge nic on a particular ring would decide at almost the same time that it wanted to be the RPS (ring parameter server) and/or the active controller. Not a very nice thing on a large ring, nor is it easy to troubleshoot.
We eventually figured out the problem when (for the third time) we shut every machine on the ring down, and brought them up one by one. The machine that started having the problem changed every time, but every machine that started the problem had the same driver loaded. We replaced the cards with Olicom, got the current drivers, and never had that problem again.
Notice I didn't say never had A problem again. When Token Ring worked, it was fairly good... when it didn't, almost by design it was a pain in the (insert your choice here).
Anyhow, my 2%.
In fact, they do. It retails for $699 at the moment...
Here's the data sheet!
I think Symbol technologies has some 802.11b phones now. They had a couple at Networkers in LA....
Of course, most, but not all, open source (including Apache) can be compiled for Windoze as well.
Besides, as a vendor, the customer is paying you not only for the product, but for the expertise and experience you (or your company) bring to the table. Otherwise, they'd be buying something off the shelf and doing it themselves.
It never hurts to back up and look at the business reasons early in the project. Many times, by paying attention to the ins and outs of the business at hand, a techie can see a better way of doing things that will end up saving money, being easier to support, cost less to maintain, or all of the above.
A person that lives in the woods never sees anything but the trees.
The following is a paid advertisment....
Acutally, that's not entirely true.
Technology now exists to provision some form of DSL over most connection types, including Integrated-Fiber-In-The-Loop, FTTC (Fiber to the curb), FTTN (fiber to the neighborhood) et al.
In all these connection scenarios, there is one common element: There must be a powered cabinet in which resides the equipment that converts from the Analog voice signal to the 64Kbps G.711 stream. In many, but by no means all, cases, the fiber portion of the circuit is an STS-1 or STS-3 SONET loop back to the local CO or remote office.
Also, let me point out that a T1 is not provisoned on a single pair; a T1/DS1 uses a Transmit Pair and a Recieve Pair that must be located in seperate cable bundles to prevent cross-talk. HOWEVER, in certain areas of the country, where copper facilites are in short supply, Telcos are providing DS1/T1 connectivity by delivering the circuit as HDSL to the customer premise, at which point a special smart-jack converts the single pair HDSL signal to a two pair (four wire) DS1/T1. Telcos have been doing this for several years now.
As far as situations as yours go, most often it is simply the fact that the cost of providing the service is to high to justify the expense of rolling it out. In the markets I'm familiar with (market populations under 150K, in 22 states), there have been several cases where the cost of the bandwidth to backhaul from a particular market to the closest Internet POP was more than we could charge for the service in a given market.
Many of the DSL providers that have gone under, did so because they failed to use good business sense, and instead went with what I call the "Field of Dreams" model: Build it, and they will come... Definitely not a good approach to business.
On average, Telcos expect a two to three year payback on the investment. This investment can vary greatly, but you can expect the capital equipment costs alone to implement DSL in a given market to approach $1M. This means that the Telco must net, after subtracting the recurring cost of providing the service, approximately $30K monthly, or about $15-$20 of each subscriber's monthly bill, just to break even. Recurring operations charges to provide the service typically come in the range of $25-$35/month. Any lower, and there's something weird going on; any higher and there's usually no way to be competitive in the market.
For this reason, if the Telco can't keep the recurring cost down to a reasonable level that allows for a competitive rate for the service, then it is simply good business to NOT provide the service.
Anyway, that's my slightly more than 2 cents on the subject. Sorry for being so long winded, but it is really a complex business issue, more so than a technical issue.