Re: IP Address Management IPAM software for small ISP
On Wednesday 12 December 2012 17:22:36 Eric A Louie wrote: > What are you using and how is it working for you? we are using tipp, and while it doesnt cover all our needs (yet), it's worth a look: http://tipp.tobez.org/ https://github.com/tobez/tipp
Re: IP Address Management IPAM software for small ISP
On Thursday 20 December 2012 09:11:43 Saku Ytti wrote: > On (2012-12-20 03:24 +), Blake Pfankuch wrote: > > I actually was doing research on this today as well. Anyone have any > > experience with the solutions that implement VLAN management as well like > > Gestioip? > I'm not remotely interested in externally developed software for this > problem. what do you mean. i'd be fine with an opensource project providing this. > But it's fair question. Generally this tool should not be IP or > VLAN based but generic resource reservation tool, IP, VLAN, RD, RT, > VPLS-ID, site-id, pseudowireID what have you. > > For me, humans would not do much directly with the tool. They'd give it > large chunk of resource. Then maybe mine it to pools like 'coreLink', > 'coreLoop', 'custLink', 'custLAN' etc. > Then in your provisioning tools, you'd request resource from specific pool > via restful API. Humand would never manually write RD/RT/IP/VLAN in the > tool or in the configs. And this type of system is vastly simpler than the > IPAMs I see listed, once you get rid of all the UI candy, it gets rather > easy problem to solve. this is a pretty accurate description of our requirements, as well. off the top of my head we'd also manage phone numbers, key ids, and key box ids, with it, but that would almost be a minor detail. ;-)
Re: 2-Channel CWDM Add/Drop with SC/APC connectors
On Thursday, February 07, 2013 08:04:41 PM Chuck Anderson wrote: > Years ago I was able to purchase 2-Channel CWDM Plug-In 1-Wavelength > Optical Add/Drop Multiplexors from Finisar with SC/APC connectors on > them, even though they normally only make the SC/PC version shown > here: > > FWSF-OADM-1-xx-SC > > http://www.finisar.com/products/passives/MUX-DEMUX/CWDM_OADM-1_Plug-in_Modul > e > > but they won't do the SC/APC version for me now. > > Does anyone know of a good alternative? for cwdm ADM i dont, sorry. our supplier just has regular multiplexers. [snip] > Is it that much harder to terminate the angled connectors? no - its just a different type of pigtail, but adding another splice, will increase the insertion loss slightly. we once ordered a cwdm splitter box at a different than usual place - as always with sc/apc connectors. the supplier changed the pigtails to accomodate our request. unfortunatly he didnt change the bulkheads, which was less than helpfull. kind regards Thilo > > Thanks, > Chuck
Re: pbx recco
yate hasnt been mentioned, which i am using successfully in multiple roles. http://yate.null.ro/pmwiki/ they have a distro similar to freepbx at http://www.freesentral.com/ however, we are currently evaluating sip:provider CE, which may be more than you need, but definitively worth a look. http://www.sipwise.com/products/spce/ its an open source softswitch implementation, which has made tremendous progress in recent releases. kind regards Thilo
Re: BGP Peers as basis of available routes
On Wednesday, October 19, 2011 09:35:04 AM Nathanael C. Cariaga wrote: > Ok. Thanks for the information :) So that would mean that to answer my > question, I would need to determine the web hosting provider who has the > most number of peers and most number of transit providers? > what i found usefull is to check the autnum objects in whois, as many document their peerings and transits there. robtex has also some of this info, in a webinterface... also helpful was peeringdb - you can lookup indvidual ASs without logging in like this http://as.peeringdb.com/ it may give you an indication as to which exchanges your (potential) provider is present at - though not all providers have a / maintain their peeringdb record. HTH kind regards Thilo > -nathan > > On 10/19/2011 3:20 PM, Raymond Dijkxhoorn wrote: > > Hi! > > > > You wont see those local peerings unless all those providers have looking > > glasses. So thats not gonna work out in this case. You will only see who > > they transit with... > > > > Thanks, > > Raymond Dijkxhoorn, Prolocation > > > > Op 19 okt. 2011 om 09:21 heeft "Nathanael C. Cariaga" het volgende geschreven: > >> Hi. > >> > >> Thanks for the prompt response. Actually our requirement is to find a > >> webhosting provider whose routes are widely advertised locally and > >> regionally. This is why I thought of using bgp as a basis studying the > >> availability of routes of the hosting provider. > >> > >> > >> -nathan > >> > >> On 10/19/2011 3:00 PM, Raymond Dijkxhoorn wrote: > >>> Hi! > >>> > >>> Dont mix up peering and transit connections! > >>> > >>> That you dont see that route on a lookingglass doesnt mean much. Only > >>> Could tell you they dont transit there. > >>> > >>> Its all depending what you definiëren with available routes. > >>> > >>> If i peer with all ISP's in a specific area and your looking glass isnt > >>> licated there does that mean its bad? You need to know much more. If > >>> your customers are local there its even prefered. > >>> > >>> Its never that black/white ...its depending on your needs! > >>> > >>> Thanks, > >>> Raymond Dijkxhoorn, Prolocation > >>> > >>> Op 19 okt. 2011 om 08:46 heeft "Nathanael C. Cariaga" het volgende geschreven: > Hi! > > We're currently evaluating web hosting providers in the APAC region > and one of the criteria that we are currently considering is the > availability of routes going to the web hosting provider. > > In this regard, I would like to ask for your idea regarding this. Is > it safe to conclude that the web hosting provider's available routes > would would depend on the peers who are advertising their AS / > network? (i.e if web hosting provider claims that they are peering > with telco a, b, c but as seen from a third party looking glass, only > C is seen advertising the web hosting provider network that would > mean web hosting provider is effectively utilizing c as their > upstream??) > > Thanks. > > > -- > -nathan
Re: Populating BGP from Connected or IGP routes
> > If you're a little bigger and have BGP customers, then I highly recommend > use of BGP communities to control your outbound route filtering. By > defining and setting communties on received customer routes, you can turn > up new BGP customers without having to modify anything beyond the router > they're connected to. It amazes me that there are large networks still > not setup this way. "You need an after hours maintenance window to turn > up a BGP customer?" "Yeah, we have to modify the prefix list filters on > all our backbone routers." WTF? What about traffic filtering? You may use RPF for ingress traffic, but what to do about egress? Or does your router write those ACLs based on BGP community? thanks Thilo
