Menu
▾
▴
openbts-bm2009
|
From: John G. <gn...@to...> - 2013-03-21 00:10:14
|
> 3. I'm not sure that such a v6 network will be publically routable > (so there would need to be NAT anyway) Such a v6 network would be publicly routable. If the feed to the playa is via a v4-only network, it would only require a v6-in-v4 tunnel -- which is how a large number of v6 networks are connected anyway. (I happen to have a native v6 connection over a T1 line, but I was the first customer of my ISP to ask for that. It runs fine along with native v4 packets on the same T1.) > 1. I'm not sure that everyone is as comfortable with v6 as with v4 > (I type 192.168. quite a lot faster than a v6 prefix) People who use numeric IP addresses for production systems clearly don't understand DNS. I can teach a DNS class if desired. > 4. v6 needs a little bit more infrastructure than v4 > (BM is not the place to introduce avoidable dependencies) I think v6 needs exactly the same infrastructure as v4. It's just a different packet format on the wire or on the air. What extra do you think it needs? > 5. We didn't run v6 last year I bet you say that every year! There's a more important question though, which is: Does our software fully support running on IPv6? Have we ever tested it running on IPv6? I think SIP has encodings for IPv6 addresses, but don't know if all of our specific software handles them. I am happy to provide an IPv6 tunnel for testing, to anybody who can't get IPv6 from their own ISP. I only have 1.5 Mbit/sec (shared with many other things) so don't route dozens of conference calls through it, but it'll easily be usable for testing whether the software works at all over IPv6. One plus of using a native IPv6 network would be avoiding a lot of neighbors trying to get on the network. If it doesn't offer IPv4 DHCP then few of them will succeed, and the ones who do will be the more tech-savvy neighbors. John |
|
From: Peter S. <pe...@st...> - 2013-03-21 01:33:03
|
John Gilmore wrote: > > 1. I'm not sure that everyone is as comfortable with v6 as with v4 > > (I type 192.168. quite a lot faster than a v6 prefix) > > People who use numeric IP addresses for production systems clearly > don't understand DNS. I can teach a DNS class if desired. Papa Legba isn't really a production system.. :) Maybe next year! I think a DNS class at camp could be fun. I built and ran a registrar for a decade and a half so I might be able to assist. > > 4. v6 needs a little bit more infrastructure than v4 > > (BM is not the place to introduce avoidable dependencies) > > I think v6 needs exactly the same infrastructure as v4. It's just > a different packet format on the wire or on the air. What extra do > you think it needs? I had RA configuration in mind. Could use DHCP, but see 1. A few more question marks to straighten out. Not what operation at BM needs. > > 5. We didn't run v6 last year > > I bet you say that every year! I will, and I think it's a good reason because I don't see BM as deployment of a production system but as a field test, and the thing that should be tested is not how well our people and software can do IPv6 - because testing that doesn't require a cell phone network covering a city of 50.000 built in two days in the desert. > There's a more important question though, which is: Does our software > fully support running on IPv6? Have we ever tested it running on > IPv6? Unsure, I guess no and no, which ties to all my reasons for prefering v4. > I am happy to provide an IPv6 tunnel for testing My priorities for the operations network can certainly change, and if $many want to run v6-only then let's run v6-only, but I honestly don't see the point. > One plus of using a native IPv6 network would be avoiding a lot of > neighbors trying to get on the network. If it doesn't offer IPv4 > DHCP then few of them will succeed, and the ones who do will be the > more tech-savvy neighbors. You might be surprised by how hard both Windows and Mac OS X tries to use v6. Windows Mobile too, even on packet data. I didn't look at iOS. In any case, I don't want "the network" which neighbors can get on, I really do want to separate operations from the neighborly wifi. //Peter |
|
From: David A. B. <dbu...@jc...> - 2013-03-23 17:28:53
|
I've been following this conversation for a while but haven't had much chance to give a thoughtful response. But I'll try to give some brief opinions: - The 3.5 GHz private Airmax network is for cellular operations only. It should not be used to provide public Internet access. It will probably have less than a dozen devices. In this network we should use DNS to avoid using raw IP addresses in our configurations. I had originally thought that all of the cellular equipment (RAN and core network) should be in a common subnet, but if people who know more than me about IP networks have other ideas, we can go with that. - The cellular network will tie back to the outside world through the playa NOC. We don't need any public IP addresses since we will be using a VPN to connect back to servers in the outside world. We (Range) use this approach for field operations already since it makes us pretty much agnostic to our IP connection path; we can backhaul over anything. - The primary purpose of the BGAN is to insure a reliable connection for operational and administrative purposes. In particular, we need at least one phone in the camp to work at all times, regardless of the state of the NOC. I would recommend that the wired phones in the tent be supported over BGAN, along with a wired backup IP network for emergency email, and that this BGAN-connected network be kept completely independent of both the cellular IP network and the public access network. - I think IPv6 might be a better approach to all of our routing problems, however, neither OpenBTS nor yate currently support IPv6. -- David Sent from some appliance with no real keyboard. Please excuse typos and crazy autocorrections. Am 20.03.2013 um 18:32 schrieb Peter Stuge <pe...@st...>: > John Gilmore wrote: >>> 1. I'm not sure that everyone is as comfortable with v6 as with v4 >>> (I type 192.168. quite a lot faster than a v6 prefix) >> >> People who use numeric IP addresses for production systems clearly >> don't understand DNS. I can teach a DNS class if desired. > > Papa Legba isn't really a production system.. :) Maybe next year! > > I think a DNS class at camp could be fun. I built and ran a registrar > for a decade and a half so I might be able to assist. > > >>> 4. v6 needs a little bit more infrastructure than v4 >>> (BM is not the place to introduce avoidable dependencies) >> >> I think v6 needs exactly the same infrastructure as v4. It's just >> a different packet format on the wire or on the air. What extra do >> you think it needs? > > I had RA configuration in mind. Could use DHCP, but see 1. A few more > question marks to straighten out. Not what operation at BM needs. > > >>> 5. We didn't run v6 last year >> >> I bet you say that every year! > > I will, and I think it's a good reason because I don't see BM as > deployment of a production system but as a field test, and the thing > that should be tested is not how well our people and software can > do IPv6 - because testing that doesn't require a cell phone network > covering a city of 50.000 built in two days in the desert. > > >> There's a more important question though, which is: Does our software >> fully support running on IPv6? Have we ever tested it running on >> IPv6? > > Unsure, I guess no and no, which ties to all my reasons for prefering v4. > > >> I am happy to provide an IPv6 tunnel for testing > > My priorities for the operations network can certainly change, and if > $many want to run v6-only then let's run v6-only, but I honestly don't > see the point. > > >> One plus of using a native IPv6 network would be avoiding a lot of >> neighbors trying to get on the network. If it doesn't offer IPv4 >> DHCP then few of them will succeed, and the ones who do will be the >> more tech-savvy neighbors. > > You might be surprised by how hard both Windows and Mac OS X tries to > use v6. Windows Mobile too, even on packet data. I didn't look at iOS. > > In any case, I don't want "the network" which neighbors can get on, > I really do want to separate operations from the neighborly wifi. > > > //Peter > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Openbts-bm2009 mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 |
|
From: Tim P. <tp...@vo...> - 2013-03-26 17:44:36
|
If only we could get one of the fake cactus mast/antenna sets for bm ! http://www.wired.com/rawfile/2013/03/dillon-marsh-invasive-species/#slideid-18775 On Mar 20, 2013 5:34 PM, "Peter Stuge" <pe...@st...> wrote: > Shaddi Hasan wrote: > > Re: public, in the past most of our public request was due to what we > > were running in medical. Since we're not doing that this year (right?) > > Either way anything medical will be separate and disconnected from > our operations. The RB450 could be perfect VPN boxes if we find that > we want to put some landlines over VPN in random places. > > > > we should just need one: at least for remote management/access, and I > > think for the Voxeo phone-NAT thing for incoming calls. > > I seem to remember Tim saying he would like to use IAX next time for > several reasons, in which case no public IP would be needed even for > incoming calls. Is that right Tim? > > > > But that might handled over the BGAN this year, not sure, > > My understanding is that the BGAN terminal is good as a backup in > case of playa network internet access downtime. If we can get by > without using it I think we should, but I had in mind to be able > to easily route (some) traffic over it. > > > > and we could set up remote access via VPN/reverse SSH if really needed. > > Yes, easy. > > > //Peter > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Openbts-bm2009 mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 > |
|
From: Jim F. <jim...@ra...> - 2013-03-15 03:00:08
|
Peter, all, > I would like us to gather a list of systems that will be part of our > network, to have as much as possible planned in advance. Here's what I can think of: Expanding a bit on the list below, it might be good to start designing or documenting the IP address plan, identifying the various subnets/vlans, routers, etc. You guys probably talked about it some in Berlin or elsewhere, so maybe most of this is done and dusted, but if not... > * 3.65GHz layer 2 or layer 3 operations backbone > (when we run the network ourselves layer 3 might be better) Generally agreed about L3; I think this implies a different subnet for each separate BTS behind a Ubiquity? And possibly some static routes. If we're talking a handful, static routes aren't bad. The comment below about semi-private camp wifi never using BGAN for general purpose Internet usage kind of implies that this operations backbone should be the home for that BGAN. The general purpose camp Internet (via WiFi) can see this net having a (static is ok) route to the operations backbone. The operations network will have to know about the camp network, and again static route back would be fine. > * OpenBTS at each site > > * SIP server: fs and/or yate Probably good to decide, or at least articulate which switch sw for what purpose. Also, is the SIP server(s) on the operational net, or logically on the camp net? I.E., does it's IP address belong to the former or latter? > * prism with NAT for phones Another server? > > * roaming OpenBTS site with UMTS uplink > (where will the NodeB be deployed?) ?? Not sure what you mean... I guess a mobile OpenBTS which uses a UMTS client for IP backhaul? Not a bad idea, a good test of the OpenBTS 3G Data. Implies that Range supply 3G Data capable BTS's. This might be possible, but I think stock 5150's don't support this, so it would need to be specially handled (by Harvind?) > * operations wifi at camp (I need to be more careful about giving out the password to friendly neighbors; one happily told me was able to watch a whole baseball game or something...) > * operations->internet network gateway > (please provide an exhaustive policy for permitted BGAN usage here) > > * data visualization AKA dataviz system Close to data visualization, how about basic network monitoring? We could run mrtg/cacti/nagios on one of the in-camp servers. Besides flagging network elements that are down, it would let us look at the bandwidth consumption we're drawing, and at least an estimate of the link qualities. > * semi-open camp wifi for visitors and neighbours > (will e.g. never go over BGAN) > > > Please add all the things that I haven't thought of! Getting there! -- Jim > > > //Peter > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Openbts-bm2009 mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 |
|
From: Peter S. <pe...@st...> - 2013-03-15 08:39:35
|
Jim Forster wrote: > it might be good to start designing or documenting the IP address plan That is the idea, the first step is taking inventory. > identifying the various subnets/vlans, routers, etc. I believe it will be a rather simple setup in the end, but I'd like to get started listing the parts. > > * 3.65GHz layer 2 or layer 3 operations backbone > > (when we run the network ourselves layer 3 might be better) > > Generally agreed about L3; I think this implies a different subnet > for each separate BTS behind a Ubiquity? Yes that's right. > The comment below about semi-private camp wifi never using BGAN for > general purpose Internet usage kind of implies that this operations > backbone should be the home for that BGAN. Probably not home, but yes, operations systems would be the only ones that can use the BGAN. > The general purpose camp Internet (via WiFi) can see this net > having a (static is ok) route to the operations backbone. > The operations network will have to know about the camp network I disagree. More on wifi below. > > * OpenBTS at each site > > > > * SIP server: fs and/or yate > > Probably good to decide, or at least articulate which switch sw for > what purpose. For network inventory it's actually enough to know which services should be planned for. I expect that more detailed planning about what service runs on what hardware follows later. > Also, is the SIP server(s) on the operational net, or logically on > the camp net? I.E., does it's IP address belong to the former or > latter? See about wifi below. > > * prism with NAT for phones > > Another server? Possibly, but at least it is another service. At this point I'm not too worried about hardware, just services to begin with. > > * roaming OpenBTS site with UMTS uplink > > (where will the NodeB be deployed?) > > ?? Not sure what you mean... I guess a mobile OpenBTS There was an idea about a base station on an art car, not much detail, it would no doubt be a special project and it would also be a special case in the network. There's no problem really, it just needs to be planned for. > > * operations wifi at camp > > (I need to be more careful about giving out the password to > friendly neighbors; one happily told me was able to watch a whole > baseball game or something...) The password for the operations wifi at camp MUST NOT be given out! It is STRICTLY for those working with operations. > > * semi-open camp wifi for visitors and neighbours > > (will e.g. never go over BGAN) Two different wifi networks at the camp. Operations is for anyone who is working on operations. Open is for visitors and friendly neighbors. The open network might be a little restricted in what it can and can not do, in order to discourage too many cat videos and such. At the very least its traffic will have lower priority than traffic from the operations network, and will not be allowed to use BGAN. The purpose of this separation is to allow people who are at the camp wifi access even if they are not working on operations. Last year we realized that camp visitors and neighbors got access to a lot of systems when we invited them to our wifi network. Bad idea. It also seems a bad idea to refuse people wifi access when we are clearly using wifi ourselves, so we should make a separate one. The operations wifi network would have internet access of course, and could have select traffic go out over BGAN when neccessary. I don't like "camp network" too much, because there will be several different networks at the camp. > > * operations->internet network gateway > > (please provide an exhaustive policy for permitted BGAN usage here) > > > > * data visualization AKA dataviz system > > Close to data visualization, how about basic network monitoring? .. > bandwidth consumption .. link qualities. I'm not so interested in red/green monitoring but I think traffic and link data would be interesting, and is easy enough to gather. //Peter |
|
From: Mark P. <mar...@ra...> - 2013-03-15 11:56:05
|
On 15 Mar, 2013, at 9:39 , Peter Stuge wrote: > Jim Forster wrote: >> it might be good to start designing or documenting the IP address plan > > That is the idea, the first step is taking inventory. > > >> identifying the various subnets/vlans, routers, etc. > > I believe it will be a rather simple setup in the end, but I'd like > to get started listing the parts. hmm I'm not sure it will be that simple as we can't just make one big subnet if we do that we will make it difficult to trace and find network problem and it will also limit the backbone design as we will only be able to make a single star network but if we design a network where we implement OSPF or BGP, we can design a much more reliable network with multiple route and support for failower, but this require several interfaces on either the router or openbts I have 4x RouterBoard450 that we can use for this project if needed, and I may be able to get my hand on some more http://routerboard.com/RB450 (boxed version, just need some US 18v power supply or POE) > > >>> * 3.65GHz layer 2 or layer 3 operations backbone >>> (when we run the network ourselves layer 3 might be better) >> >> Generally agreed about L3; I think this implies a different subnet >> for each separate BTS behind a Ubiquity? > > Yes that's right. > > >> The comment below about semi-private camp wifi never using BGAN for >> general purpose Internet usage kind of implies that this operations >> backbone should be the home for that BGAN. > > Probably not home, but yes, operations systems would be the only ones > that can use the BGAN. by configureng the routers correctly we can design the network only route trafic to specifik remote server over BGAN let ospf route via BGAN when primary is faling but this setup is fare from simple, as we need to work with both ospf, vlan & vpn > > >> The general purpose camp Internet (via WiFi) can see this net >> having a (static is ok) route to the operations backbone. >> The operations network will have to know about the camp network > > I disagree. More on wifi below. > > >>> * OpenBTS at each site >>> >>> * SIP server: fs and/or yate >> >> Probably good to decide, or at least articulate which switch sw for >> what purpose. > > For network inventory it's actually enough to know which services > should be planned for. I expect that more detailed planning about > what service runs on what hardware follows later. > > >> Also, is the SIP server(s) on the operational net, or logically on >> the camp net? I.E., does it's IP address belong to the former or >> latter? > > See about wifi below. > > >>> * prism with NAT for phones >> >> Another server? > > Possibly, but at least it is another service. At this point I'm not > too worried about hardware, just services to begin with. > > >>> * roaming OpenBTS site with UMTS uplink >>> (where will the NodeB be deployed?) >> >> ?? Not sure what you mean... I guess a mobile OpenBTS > > There was an idea about a base station on an art car, not much > detail, it would no doubt be a special project and it would also > be a special case in the network. There's no problem really, it > just needs to be planned for. > > >>> * operations wifi at camp >> >> (I need to be more careful about giving out the password to >> friendly neighbors; one happily told me was able to watch a whole >> baseball game or something...) > > The password for the operations wifi at camp MUST NOT be given out! > > It is STRICTLY for those working with operations. > > >>> * semi-open camp wifi for visitors and neighbours >>> (will e.g. never go over BGAN) > > Two different wifi networks at the camp. Operations is for anyone who > is working on operations. Open is for visitors and friendly neighbors. > > The open network might be a little restricted in what it can and can > not do, in order to discourage too many cat videos and such. At the > very least its traffic will have lower priority than traffic from the > operations network, and will not be allowed to use BGAN. > > The purpose of this separation is to allow people who are at the camp > wifi access even if they are not working on operations. Last year we > realized that camp visitors and neighbors got access to a lot of > systems when we invited them to our wifi network. Bad idea. > > It also seems a bad idea to refuse people wifi access when we are > clearly using wifi ourselves, so we should make a separate one. > > The operations wifi network would have internet access of course, and > could have select traffic go out over BGAN when neccessary. > > I don't like "camp network" too much, because there will be several > different networks at the camp. > > >>> * operations->internet network gateway >>> (please provide an exhaustive policy for permitted BGAN usage here) >>> >>> * data visualization AKA dataviz system >> >> Close to data visualization, how about basic network monitoring? > .. >> bandwidth consumption .. link qualities. > > I'm not so interested in red/green monitoring but I think traffic > and link data would be interesting, and is easy enough to gather. > I already working on a project for how we want to monitor openBTS and I'm planing on using http://www.zabbix.com/ as I want to use there remote agents as they can work as monitoring proxy's in case of network troubles > > //Peter -- Mark Petersen |
|
From: Shaddi H. <sh...@be...> - 2013-03-23 17:38:55
|
Is there any chance we could get an ethernet cable run from the NOC to some device on our private cellular network (say, something at Playatel or elsewhere on Rod's Road)? On Sat, Mar 23, 2013 at 10:28 AM, David A. Burgess <dbu...@jc...>wrote: > I've been following this conversation for a while but haven't had much > chance to give a thoughtful response. But I'll try to give some brief > opinions: > > - The 3.5 GHz private Airmax network is for cellular operations only. It > should not be used to provide public Internet access. It will probably have > less than a dozen devices. In this network we should use DNS to avoid using > raw IP addresses in our configurations. I had originally thought that all > of the cellular equipment (RAN and core network) should be in a common > subnet, but if people who know more than me about IP networks have other > ideas, we can go with that. > - The cellular network will tie back to the outside world through the > playa NOC. We don't need any public IP addresses since we will be using a > VPN to connect back to servers in the outside world. We (Range) use this > approach for field operations already since it makes us pretty much > agnostic to our IP connection path; we can backhaul over anything. > - The primary purpose of the BGAN is to insure a reliable connection for > operational and administrative purposes. In particular, we need at least > one phone in the camp to work at all times, regardless of the state of the > NOC. I would recommend that the wired phones in the tent be supported over > BGAN, along with a wired backup IP network for emergency email, and that > this BGAN-connected network be kept completely independent of both the > cellular IP network and the public access network. > - I think IPv6 might be a better approach to all of our routing problems, > however, neither OpenBTS nor yate currently support IPv6. > > -- David > > Sent from some appliance with no real keyboard. Please excuse typos and > crazy autocorrections. > > Am 20.03.2013 um 18:32 schrieb Peter Stuge <pe...@st...>: > > > John Gilmore wrote: > >>> 1. I'm not sure that everyone is as comfortable with v6 as with v4 > >>> (I type 192.168. quite a lot faster than a v6 prefix) > >> > >> People who use numeric IP addresses for production systems clearly > >> don't understand DNS. I can teach a DNS class if desired. > > > > Papa Legba isn't really a production system.. :) Maybe next year! > > > > I think a DNS class at camp could be fun. I built and ran a registrar > > for a decade and a half so I might be able to assist. > > > > > >>> 4. v6 needs a little bit more infrastructure than v4 > >>> (BM is not the place to introduce avoidable dependencies) > >> > >> I think v6 needs exactly the same infrastructure as v4. It's just > >> a different packet format on the wire or on the air. What extra do > >> you think it needs? > > > > I had RA configuration in mind. Could use DHCP, but see 1. A few more > > question marks to straighten out. Not what operation at BM needs. > > > > > >>> 5. We didn't run v6 last year > >> > >> I bet you say that every year! > > > > I will, and I think it's a good reason because I don't see BM as > > deployment of a production system but as a field test, and the thing > > that should be tested is not how well our people and software can > > do IPv6 - because testing that doesn't require a cell phone network > > covering a city of 50.000 built in two days in the desert. > > > > > >> There's a more important question though, which is: Does our software > >> fully support running on IPv6? Have we ever tested it running on > >> IPv6? > > > > Unsure, I guess no and no, which ties to all my reasons for prefering v4. > > > > > >> I am happy to provide an IPv6 tunnel for testing > > > > My priorities for the operations network can certainly change, and if > > $many want to run v6-only then let's run v6-only, but I honestly don't > > see the point. > > > > > >> One plus of using a native IPv6 network would be avoiding a lot of > >> neighbors trying to get on the network. If it doesn't offer IPv4 > >> DHCP then few of them will succeed, and the ones who do will be the > >> more tech-savvy neighbors. > > > > You might be surprised by how hard both Windows and Mac OS X tries to > > use v6. Windows Mobile too, even on packet data. I didn't look at iOS. > > > > In any case, I don't want "the network" which neighbors can get on, > > I really do want to separate operations from the neighborly wifi. > > > > > > //Peter > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_mar > > _______________________________________________ > > Openbts-bm2009 mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Openbts-bm2009 mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 > |
|
From: Peter S. <pe...@st...> - 2013-03-23 18:03:36
|
Shaddi Hasan wrote: > Is there any chance we could get an ethernet cable run from the NOC to > some device on our private cellular network (say, something at Playatel > or elsewhere on Rod's Road)? Probably possible, but I actually don't think we want it.. Last year, the hospital had a trenched cable. Power issues made it cause a catastrophical equipment failure at the NOC, so they needed to bring their backup online. That delayed the cable working by two days or so. Unless we can colocate one of our nodes with the NOC, I think the best connection we'll have is probably wifi.. //Peter |
|
From: Peter K. <pe...@me...> - 2013-03-24 14:03:13
|
Guys, If you do decide to connect a land line, I have about 5000 feet of conventional phone cable that would do the trick with the right set of long haul modems for power isolation etc. Best Regards, Pete C 415-283-8374 ________________________________________ From: Peter Stuge [pe...@st...] Sent: Saturday, March 23, 2013 11:03 AM To: ope...@li... Subject: Re: [Legba2013] Network inventory (ipv6) Shaddi Hasan wrote: > Is there any chance we could get an ethernet cable run from the NOC to > some device on our private cellular network (say, something at Playatel > or elsewhere on Rod's Road)? Probably possible, but I actually don't think we want it.. Last year, the hospital had a trenched cable. Power issues made it cause a catastrophical equipment failure at the NOC, so they needed to bring their backup online. That delayed the cable working by two days or so. Unless we can colocate one of our nodes with the NOC, I think the best connection we'll have is probably wifi.. //Peter ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Openbts-bm2009 mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 Filtering provided by PixelRiver Technologies, LLC |
|
From: Peter S. <pe...@st...> - 2013-03-24 14:06:47
|
Peter Killcommons wrote: > If you do decide to connect a land line, I have about 5000 feet of > conventional phone cable that would do the trick with the right set > of long haul modems for power isolation etc. That's a really good alternative to ethernet! The line doesn't have to carry 100 Mbit/s - less bandwidth would still be good as long as it is a very reliable connection. Do you know the performance of those modems, or if not, could you check the type number, then we could look them up? The cable requires trenching from Playatel to NOC however, and NOC needs to agree to keep the modem there and configure a switchport for us. Those are two potentially difficult problems. The cable would probably need to go into the ground very early - I don't know if anyone of us can be there to get that done and I also don't know if anyone else might do it for us? I fear not.. //Peter |
|
From: Peter K. <pe...@me...> - 2013-03-24 19:29:19
|
All good questions :) I will look up the current tech available. I will ask ranger backbone aka trevor for advice. Pete Invoked by wireless gizmo On Mar 24, 2013, at 10:06 AM, "Peter Stuge" <pe...@st...> wrote: > Peter Killcommons wrote: >> If you do decide to connect a land line, I have about 5000 feet of >> conventional phone cable that would do the trick with the right set >> of long haul modems for power isolation etc. > > That's a really good alternative to ethernet! The line doesn't have > to carry 100 Mbit/s - less bandwidth would still be good as long as > it is a very reliable connection. Do you know the performance of > those modems, or if not, could you check the type number, then we > could look them up? > > The cable requires trenching from Playatel to NOC however, and NOC > needs to agree to keep the modem there and configure a switchport > for us. Those are two potentially difficult problems. > > The cable would probably need to go into the ground very early - I > don't know if anyone of us can be there to get that done and I also > don't know if anyone else might do it for us? I fear not.. > > > //Peter > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Openbts-bm2009 mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 Filtering provided by PixelRiver Technologies, LLC |
|
From: Peter S. <pe...@st...> - 2013-03-20 01:09:33
|
Mark Petersen wrote: > >> identifying the various subnets/vlans, routers, etc. > > > > I believe it will be a rather simple setup in the end, but I'd like > > to get started listing the parts. > > hmm I'm not sure it will be that simple as we can't just make one big > subnet if we do that we will make it difficult to trace and find > network problem A network with five or six nodes will not have very many problems and can remain quite simple. I think of it this way: If there are more problems than with the playa wifi last year then it is pointless to build our own backbone. > OSPF or BGP I think either would be way overkill. Maybe there will be two or three VLANs and one or two VPNs, but that's all there is. I consider that a very simple network. > I have 4x RouterBoard450 that we can use That can be useful! But let's start with the service inventory. I want to minimize the number of units in the operation. Linux in e.g. 5150 is more than enough for each site. We'll certainly have a router or two, probably at camp, then I'd like it to also take care of wireless. RB450 looks like nice hardware, but I'm not at all excited about RouterOS and ideally I want a router that does wifi. > by configureng the routers correctly I think we'll probably only have one router in the ops network. > let ospf route via BGAN when primary is faling All traffic should anyway arrive to where the BGAN terminal is, or the other way around: the BGAN terminal should be where all traffic passes through anyway. I think we should simply not set it up until we actually need it, and I think we should make improvised routing decisions when we need to make them, not before, and not build systems to make them for us. I don't expect that we will actually need the BGAN terminal, but it's certainly a nice-to-have backup! > but this setup is fare from simple, as we need to work with both > ospf, vlan & vpn The point of the network inventory is so that we can think about what network will work well and still be as simple as possible. There might be a VLAN or two but that's about as exotic as it gets. > >> Close to data visualization, how about basic network monitoring? > > .. > >> bandwidth consumption .. link qualities. > > > > I'm not so interested in red/green monitoring but I think traffic > > and link data would be interesting, and is easy enough to gather. > > I already working on a project for how we want to monitor openBTS > and I'm planing on using http://www.zabbix.com/ as I want to use > there remote agents as they can work as monitoring proxy's in case > of network troubles Will you run an instance at BM? Nice! If yes, what are its key requirements? //Peter |
|
From: Jim F. <jim...@ra...> - 2013-03-20 06:37:42
|
Sorry to be thick, but these days Router has a common usage that's different than what it used to mean. It used to mean an IPv4 forwarder, with associated routing protocols (RIP, OSPF, BGP, etc), ARP, SNMP, support for various L1/L2's -- Ethernet, Serial Lines, WiFi, etc. Stuff that was documented in Router Requirements (RFC-1716, superseded by RFC-1812). Now in common usage it seems to imply a NAT function as well. Peter, what do you mean by router in your usage below? -- Jim On Mar 19, 2013, at 6:09 PM, Peter Stuge <pe...@st...> wrote: > Mark Petersen wrote: >>>> identifying the various subnets/vlans, routers, etc. >>> >>> I believe it will be a rather simple setup in the end, but I'd like >>> to get started listing the parts. >> >> hmm I'm not sure it will be that simple as we can't just make one big >> subnet if we do that we will make it difficult to trace and find >> network problem > > A network with five or six nodes will not have very many problems and > can remain quite simple. > > I think of it this way: If there are more problems than with the > playa wifi last year then it is pointless to build our own backbone. > > >> OSPF or BGP > > I think either would be way overkill. Maybe there will be two or > three VLANs and one or two VPNs, but that's all there is. I consider > that a very simple network. > > >> I have 4x RouterBoard450 that we can use > > That can be useful! But let's start with the service inventory. I > want to minimize the number of units in the operation. Linux in e.g. > 5150 is more than enough for each site. We'll certainly have a router > or two, probably at camp, then I'd like it to also take care of > wireless. RB450 looks like nice hardware, but I'm not at all excited > about RouterOS and ideally I want a router that does wifi. > > >> by configureng the routers correctly > > I think we'll probably only have one router in the ops network. > > >> let ospf route via BGAN when primary is faling > > All traffic should anyway arrive to where the BGAN terminal is, or > the other way around: the BGAN terminal should be where all traffic > passes through anyway. I think we should simply not set it up until > we actually need it, and I think we should make improvised routing > decisions when we need to make them, not before, and not build > systems to make them for us. I don't expect that we will actually > need the BGAN terminal, but it's certainly a nice-to-have backup! > > >> but this setup is fare from simple, as we need to work with both >> ospf, vlan & vpn > > The point of the network inventory is so that we can think about what > network will work well and still be as simple as possible. There > might be a VLAN or two but that's about as exotic as it gets. > > >>>> Close to data visualization, how about basic network monitoring? >>> .. >>>> bandwidth consumption .. link qualities. >>> >>> I'm not so interested in red/green monitoring but I think traffic >>> and link data would be interesting, and is easy enough to gather. >> >> I already working on a project for how we want to monitor openBTS >> and I'm planing on using http://www.zabbix.com/ as I want to use >> there remote agents as they can work as monitoring proxy's in case >> of network troubles > > Will you run an instance at BM? Nice! If yes, what are its key requirements? > > > //Peter > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Openbts-bm2009 mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 |
|
From: Peter S. <pe...@st...> - 2013-03-20 11:57:18
|
Jim Forster wrote: > Peter, what do you mean by router in your usage below? A box whose primary function is a layer 3 forwarder. It might do NAT for internet traffic and it's a natural place to provide wireless access, unless it ends up outside camp of course, which depends on where we get placed.. I consider actual routing (packet forwarding) quite distinct from administration of routes. Routing protocols automate administration of routes, they have very little to do with forwarding. Routing protocols are great in highly dynamic environments such as the internet, they're less useful in a static six node star network. //Peter |
|
From: Aaron H. <hu...@te...> - 2013-03-20 13:06:39
|
What about running ipv6 only and get rid of NAT? -- Aaron Huslage CTO - Tethr On Mar 20, 2013, at 7:57 AM, Peter Stuge <pe...@st...> wrote: > Jim Forster wrote: >> Peter, what do you mean by router in your usage below? > > A box whose primary function is a layer 3 forwarder. It might do NAT > for internet traffic and it's a natural place to provide wireless > access, unless it ends up outside camp of course, which depends on > where we get placed.. > > I consider actual routing (packet forwarding) quite distinct from > administration of routes. Routing protocols automate administration > of routes, they have very little to do with forwarding. > > Routing protocols are great in highly dynamic environments such as > the internet, they're less useful in a static six node star network. > > > //Peter > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Openbts-bm2009 mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-bm2009 |
|
From: Peter S. <pe...@st...> - 2013-03-20 12:29:09
|
Aaron Huslage wrote: > What about running ipv6 only and get rid of NAT? 1. I'm not sure that everyone is as comfortable with v6 as with v4 (I type 192.168. quite a lot faster than a v6 prefix) 2. I'm not sure that we will be assigned a v6 network from NOC (only v4 last year) 3. I'm not sure that such a v6 network will be publically routable (so there would need to be NAT anyway) 4. v6 needs a little bit more infrastructure than v4 (BM is not the place to introduce avoidable dependencies) 5. We didn't run v6 last year (see 1. and 4.) ..so I strongly prefer to stay with v4. NAT or not depends on what NOC provides, it's not really up to us. If we want I'm sure we can get a range of public v4 again, as long as we are OK with being a special case for NOC. We can not get six ranges, but I don't see the point of public addresses on the BTSes anyway. It may be nice-to-have for some of services, but most importantly: Is a public IP address *need-to-have* for any service? //Peter |
Thanks for helping keep SourceForge clean.
X