Re: What services does Microsoft AS8075 provide when peering at IXPs?
My direct peering is within my control, the traffic has to follow basically the same path internally to Internet and IXP. Internet path is definitely variable. IXP path is definitely fixed. It's already there, just needed to know what Microsoft provided (if anyone knew). Actually, a MS peering engineer answered the question for me privately. My marketing people aren't terribly concerned with security, that wasn't the issue. The issue was shorter path/better performance. I'm still not clear if it's public or private Azure that the customer is trying to access. On Sunday, April 3, 2016 4:04 PM, "valdis.kletni...@vt.edu" wrote: On Fri, 01 Apr 2016 18:02:56 -, Eric A Louie via NANOG said: > I suppose we have a customer who is an Azure customer that wants to know if > their Azure traffic will stay in our network or still go through the Internet. As a practical matter, if they're using the answer for a security baseline, they're doing it wrong - they should be planning that based on the assumption that their traffic *will* ride the rails of the commodity Internet (due to outages or whatever). Similarly, if they're looking at it for performance/latency, they need to fix their assumptions - your direct peering can be slow and congested, while there's actually a longer but faster path through someplace else
What services does Microsoft AS8075 provide when peering at IXPs?
I had this question posed by a marketing type in my office. Does anyone know the answer? Is it microsoft.com, msdn, outllook365, msn.com, outlook.com, azure, windows updates, xbox? what else is possibly covered or omitted in their peering service? I suppose we have a customer who is an Azure customer that wants to know if their Azure traffic will stay in our network or still go through the Internet. I've tried asking peer...@microsoft.com twice, but it looks like they have their ignore filter up. Thanks, -e-
Recommendations, Colo Reno, Albuquerque, Phoenix, Las Vegas
Does anyone have recommendations for Colocation space in any of those 4 cities? thanks Eric
MPLS product offering questions
My company is investigating offering MPLS service in a very limited regional area. We're interested in any input in the following: Pricing strategy Order form Operational considerations Service level agreements If you have something to offer, on or off-list responses are invited. thanks Eric
Re: Kit to split a 19" closet?
Divided into vertical sections, it requires a new set of hinges and doors and lock slots front and rear, as well as solid shelves between the sections. Think about it for a moment, or go visit your nearest colocation center and ask to see a 1/2 or 1/3 rack. I actually have a 1/3 rack at one of my POPs. Start with your cabinet manufacturer. I've seen 1/2 racks, 1/3 racks, and 1/4 racks in a full 84" enclosure. > > From: Hank Nussbacher >To: nanog@nanog.org >Sent: Saturday, April 12, 2014 12:03 PM >Subject: Kit to split a 19" closet? > > >Suppose you have an existing server closet. You want to split it so that >two different organizations can have access to it. Separate doors and a >divider in the middle. Does anyone make kit for this for hosting centers? > >Thanks, >Hank > > > > >
Re: ISP inbound failover without BGP
Honestly? Because the end-customers are not technically competent enough to run dual-homed BGP, and we don't want to be their managed service providers on the IT side. And announcing the AT&T space is fine until something goes wrong, and I have to troubleshoot the problem (Customer - "How come AT&T is down, and we're not getting inbound traffic to our servers?", and I discover L3 or CenturyLink isn't accepting my advertisement for some weird reason, but they won't fess up to it for a few frustrating hours) >________ > From: Randy Carpenter >To: Eric A Louie >Cc: NANOG >Sent: Monday, March 3, 2014 7:20 PM >Subject: Re: ISP inbound failover without BGP > > > >Is there some technical reason that BGP is not an option? You could allow them >to announce their AT&T space via you as a secondary. > >-Randy > >- Original Message - >> This may sound like dumb question, but... I'm used to asking those. >> >> Here's the scenario >> >> Another ISP, say AT&T, is the primary ISP for a customer. >> >> Customer has publicly accessible servers in their office, using the AT&T >> address space. >> >> I am the customer's secondary ISP. >> >> Now, if AT&T link fails, I can provide the customer outbound Internet access >> fairly easily. So they can surf and get to the Internet. >> >> What about the publicly accessible servers that have AT&T addresses, though? >> >> One thought I had was having them use Dynamic DNS service. >> >> Are there any other solutions, short of using BGP multihoming and having them >> try to get their own ASN and IPv4 /24 block? >> >> >> It looks like a few router manufacturers have devices that might work, but it >> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the >> primary ISP fails, the secondary ISP address is advertised. >> >> > > >
Re: ISP inbound failover without BGP
That's a good point Ray - thank you. > > From: Ray >To: Matthew Crocker ; Eric A Louie > >Cc: NANOG >Sent: Monday, March 3, 2014 6:31 PM >Subject: RE: ISP inbound failover without BGP > > > > >Depending on their business, using dynamic DNS providers could be a really bad >idea. If they deal only with home users who won't even know, it'll probably >work. If their customers are security-aware businesses, they probably block >all sites hosted with dynamic DNS systems. > >Ray > > >> Subject: Re: ISP inbound failover without BGP >> From: matt...@corp.crocker.com >> Date: Mon, 3 Mar 2014 20:50:26 -0500 >> To: elo...@yahoo.com >> CC: nanog@nanog.org >> >> >> >> Depends on the application, >> >> SIP, VPN, SMTP, etc just setup both IPs and let the end-user application >> figure it out (SIP-UA register to both IPs for example) >> >> HTTP/HTTPS setup a proxy server in a colo that is multi-homed to frontend >> the requests. Then it can load balance traffic over both IPs. >> >> DNS TTL ‘tricks’ are just that, they work ‘kinda’ >> >> Fatpipe? Crazy expensive IMHO but I hear they work ok. >> >> -Matt >> >> -- >> Matthew S. Crocker >> President >> Crocker Communications, Inc. >> PO BOX 710 >> Greenfield, MA 01302-0710 >> >> E: matt...@crocker.com >> P: (413) 746-2760 >> F: (413) 746-3704 >> W: http://www.crocker.com >> >> >> >> On Mar 3, 2014, at 8:11 PM, Eric A Louie wrote: >> >> > This may sound like dumb question, but... I'm used to asking those. >> > >> > Here's the scenario >> > >> > Another ISP, say AT&T, is the primary ISP for a customer. >> > >> > Customer has publicly accessible servers in their office, using the AT&T >> > address space. >> > >> > I am the customer's secondary ISP. >> > >> > Now, if AT&T link fails, I can provide the customer outbound Internet >> > access fairly easily. So they can surf and get to the Internet. >> > >> > What about the publicly accessible servers that have AT&T addresses, >> > though? >> > >> > One thought I had was having them use Dynamic DNS service. >> > >> > Are there any other solutions, short of using BGP multihoming and having >> > them try to get their own ASN and IPv4 /24 block? >> > >> > >> > It looks like a few router manufacturers have devices that might work, but >> > it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the >> > primary ISP fails, the secondary ISP address is advertised. >> > >> >> > > >
ISP inbound failover without BGP
This may sound like dumb question, but... I'm used to asking those. Here's the scenario Another ISP, say AT&T, is the primary ISP for a customer. Customer has publicly accessible servers in their office, using the AT&T address space. I am the customer's secondary ISP. Now, if AT&T link fails, I can provide the customer outbound Internet access fairly easily. So they can surf and get to the Internet. What about the publicly accessible servers that have AT&T addresses, though? One thought I had was having them use Dynamic DNS service. Are there any other solutions, short of using BGP multihoming and having them try to get their own ASN and IPv4 /24 block? It looks like a few router manufacturers have devices that might work, but it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the primary ISP fails, the secondary ISP address is advertised.
Dark fiber providers, Southern California
Who would I start talking to if I wanted to lease "dark fiber" from point to point? I'm located in San Diego and am interested in leasing fiber from major datacenters in SD and LA I found Freedom Telecommunications (http://freedomtelecommunications.com) - doubtless there are others I can and should talk to. thanks Eric Louie
Re: best practice for advertising peering fabric routes
Ok, so the right way to do it is in iBGP. That pretty much answers the question - don't redistribute those ixp-participant prefixes into my IGP. I have a lot of iBGP homework to do, to make it work with the 5 POPs that are all taking full route feeds. I tried once and couldn't get the BGP tables working correctly with a full mesh of the 5 routers, so it looks like time to try it again, this time with a route reflector. > > From: Christopher Morrow >To: Eric A Louie >Cc: Patrick W. Gilmore ; NANOG list >Sent: Tuesday, January 14, 2014 10:37 PM >Subject: Re: best practice for advertising peering fabric routes > > >On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie wrote: >> Thank you - I will heed the warning. I want to be a good community member >> and make sure we're maintaining the agreed-upon practices (I'll >> re-read/review my agreement with the IXP) >> >> >> So if that is the case, I have to rely on the peering fabric to just return >> traffic, since the rest of my network (save the directly connected router) >> will not know about those routes outbound? And what about my customers who >> are counting on me routing their office traffic through my network into the >> peering fabric to their properties? (I have one specifically who is >> eventually looking for that capability) Do I have to provide them some sort >> of VPN to make that happen across my network to the peering fabric router? >> > >perhaps I'm confused, but you have sort of this situation: > ixp-participants -> ixp -> your-router -> your-network -> your-customer > >you get routes for ixp-participants from 'ixp' >you send to the 'ixp' (and on to 'ixp-participants') routes for >'your-customer' and 'your-network' > >right? > >then so long as you send 'your-customer' the routes you learn from >'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to >'your-network' (in the ibgp-mesh that you will setup) ... everything >just works. > >All routers behind 'your-router' in 'your-netowrk' see >'ixp-participants' with a next-hop of 'your-router' who still knows >'send to ixp!' for the route(s) in question. > >> >> >> >>> >>> From: Patrick W. Gilmore >>>To: NANOG list >>>Sent: Tuesday, January 14, 2014 7:11 PM >>>Subject: Re: best practice for advertising peering fabric routes >>> >>> >>>Pardon the top post, but I really don't have anything to comment below other >>>than to agree with Chris and say rfc5963 is broken. >>> >>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP >>>LAN should not be reachable from any device not directly attached to that >>>LAN. Period. >>> >>>Doing so endangers your peers & the IX itself. It is on the order of not >>>implementing BCP38, except no one has the (lame, ridiculous, idiotic, and >>>pure cost-shifting BS) excuse that they "can't" do this. >>> >>>-- >>>TTFN, >>>patrick >>> >>> >>>On Jan 14, 2014, at 21:22 , Christopher Morrow >>>wrote: >>> >>>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>>>> >>>>>> I have a connection to a peering fabric and I'm not distributing the >>>>> peering fabric routes into my network. >>>>>> >>>> >>>> good plan. >>>> >>>>>> I see three options >>>>>> 1. redistribute into my igp (OSPF) >>>>>> >>>>>> 2. configure ibgp and route them within that infrastructure. All the >>>>> default routes go out through the POPs so iBGP would see packets destined >>>>> for the peering fabric and route it that-a-way >>>>>> >>>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>>>> the inbound traffic come back through the peering fabric >>>>>> >>>>>> >>>> >>>> 4. all peering-fabric routes get next-hop-self on your peering router >>>> before going into ibgp... >>>> all the rest of your network sees your local loopback as nexthop and >>>> things just work. >>>> >>>>>> Advantages and disadvantages, pros and cons? Recommendations? >>>>> Experiences, good and bad? >>>>>> >>>>>> >>>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>>>> POPs yet. That's another issue completely from a planning perspective. >>>>>> >>>>>> thanks >>>>>> Eric >>>>>> >>>>> >>>>> http://tools.ietf.org/html/rfc5963 >>>>> >>>>> I like no-export >>>> >>> >>> >>> >>> >>> > > >
Re: best practice for advertising peering fabric routes
Never mind, I just carefully re-read the point. Right, I'll filter the prefix(es) of the IXP LAN(s) that I'm connected to and not let THAT get out, no reason to advertise it since no traffic ever goes to it. That still has me asking to how best to advertise the rest of the public prefixes coming from the other fabric members. > > From: Eric A Louie >To: Patrick W. Gilmore ; NANOG list >Sent: Tuesday, January 14, 2014 10:22 PM >Subject: Re: best practice for advertising peering fabric routes > > >Thank you - I will heed the warning. I want to be a good community member and >make sure we're maintaining the agreed-upon practices (I'll re-read/review my >agreement with the IXP) > > >So if that is the case, I have to rely on the peering fabric to just return >traffic, since the rest of my network (save the directly connected router) >will not know about those routes outbound? And what about my customers who >are counting on me routing their office traffic through my network into the >peering fabric to their properties? (I have one specifically who is >eventually looking for that capability) Do I have to provide them some sort >of VPN to make that happen across my network to the peering fabric router? > > > > >> >> From: Patrick W. Gilmore >>To: NANOG list >>Sent: Tuesday, January 14, 2014 7:11 PM >>Subject: Re: best practice for advertising peering fabric routes >> >> >>Pardon the top post, but I really don't have anything to comment below other >>than to agree with Chris and say rfc5963 is broken. >> >>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP >>LAN should not be reachable from any device not directly attached to that >>LAN. Period. >> >>Doing so endangers your peers & the IX itself. It is on the order of not >>implementing BCP38, except no one has the (lame, ridiculous, idiotic, and >>pure cost-shifting BS) excuse that they "can't" do this. >> >>-- >>TTFN, >>patrick >> >> >>On Jan 14, 2014, at 21:22 , Christopher Morrow >>wrote: >> >>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>>> >>>>> I have a connection to a peering fabric and I'm not distributing the >>>> peering fabric routes into my network. >>>>> >>> >>> good plan. >>> >>>>> I see three options >>>>> 1. redistribute into my igp (OSPF) >>>>> >>>>> 2. configure ibgp and route them within that infrastructure. All the >>>> default routes go out through the POPs so iBGP would see packets destined >>>> for the peering fabric and route it that-a-way >>>>> >>>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>>> the inbound traffic come back through the peering fabric >>>>> >>>>> >>> >>> 4. all peering-fabric routes get next-hop-self on your peering router >>> before going into ibgp... >>> all the rest of your network sees your local loopback as nexthop and >>> things just work. >>> >>>>> Advantages and disadvantages, pros and cons? Recommendations? >>>> Experiences, good and bad? >>>>> >>>>> >>>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>>> POPs yet. That's another issue completely from a planning perspective. >>>>> >>>>> thanks >>>>> Eric >>>>> >>>> >>>> http://tools.ietf.org/html/rfc5963 >>>> >>>> I like no-export >>> >> >> >> >> >> > > >
Re: best practice for advertising peering fabric routes
Thank you - I will heed the warning. I want to be a good community member and make sure we're maintaining the agreed-upon practices (I'll re-read/review my agreement with the IXP) So if that is the case, I have to rely on the peering fabric to just return traffic, since the rest of my network (save the directly connected router) will not know about those routes outbound? And what about my customers who are counting on me routing their office traffic through my network into the peering fabric to their properties? (I have one specifically who is eventually looking for that capability) Do I have to provide them some sort of VPN to make that happen across my network to the peering fabric router? > > From: Patrick W. Gilmore >To: NANOG list >Sent: Tuesday, January 14, 2014 7:11 PM >Subject: Re: best practice for advertising peering fabric routes > > >Pardon the top post, but I really don't have anything to comment below other >than to agree with Chris and say rfc5963 is broken. > >NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP >LAN should not be reachable from any device not directly attached to that LAN. >Period. > >Doing so endangers your peers & the IX itself. It is on the order of not >implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure >cost-shifting BS) excuse that they "can't" do this. > >-- >TTFN, >patrick > > >On Jan 14, 2014, at 21:22 , Christopher Morrow wrote: > >> On Tue, Jan 14, 2014 at 9:09 PM, Cb B wrote: >>> On Jan 14, 2014 6:01 PM, "Eric A Louie" wrote: >>>> >>>> I have a connection to a peering fabric and I'm not distributing the >>> peering fabric routes into my network. >>>> >> >> good plan. >> >>>> I see three options >>>> 1. redistribute into my igp (OSPF) >>>> >>>> 2. configure ibgp and route them within that infrastructure. All the >>> default routes go out through the POPs so iBGP would see packets destined >>> for the peering fabric and route it that-a-way >>>> >>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and >>> the inbound traffic come back through the peering fabric >>>> >>>> >> >> 4. all peering-fabric routes get next-hop-self on your peering router >> before going into ibgp... >> all the rest of your network sees your local loopback as nexthop and >> things just work. >> >>>> Advantages and disadvantages, pros and cons? Recommendations? >>> Experiences, good and bad? >>>> >>>> >>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the >>> POPs yet. That's another issue completely from a planning perspective. >>>> >>>> thanks >>>> Eric >>>> >>> >>> http://tools.ietf.org/html/rfc5963 >>> >>> I like no-export >> > > > > >
best practice for advertising peering fabric routes
I have a connection to a peering fabric and I'm not distributing the peering fabric routes into my network. I see three options 1. redistribute into my igp (OSPF) 2. configure ibgp and route them within that infrastructure. All the default routes go out through the POPs so iBGP would see packets destined for the peering fabric and route it that-a-way 3. leave it "as is", and let the outbound traffic go out my upstreams and the inbound traffic come back through the peering fabric Advantages and disadvantages, pros and cons? Recommendations? Experiences, good and bad? I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet. That's another issue completely from a planning perspective. thanks Eric
Re: BGP from Juniper to Cisco ASR
When I had that problem, it was because the max-prefixes on the Juniper router was being triggered. If I remember correctly. It's a strange return message for the wrong issue. > > From: Philip Lavine >To: NANOG list >Sent: Wednesday, December 18, 2013 7:48 AM >Subject: BGP from Juniper to Cisco ASR > > >Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor >active 2/5 (authentication failure) 0 bytes >Dec 18 15:46:33.615: BGP: ses global (0x7FB1CD209CF0:0) act >Receive NOTIFICATION 2/5 (authentication failure) 0 bytes > >Although I have seem this on the message boards I am little confused in that >the ISP is telling me that there is no authentication enabled on the Juniper >and I do not have authentication enabled on the ASR. So what is going on here? > > > >
Re: BGP from Juniper to Cisco ASR
When I had that problem, it was because the max-prefixes on the Juniper router was being triggered. If I remember correctly. It's a strange return message for the wrong issue. > > From: Philip Lavine >To: NANOG list >Sent: Wednesday, December 18, 2013 7:48 AM >Subject: BGP from Juniper to Cisco ASR > > >Dec 18 07:46:33: %BGP-3-NOTIFICATION: received from neighbor >active 2/5 (authentication failure) 0 bytes >Dec 18 15:46:33.615: BGP: ses global (0x7FB1CD209CF0:0) act >Receive NOTIFICATION 2/5 (authentication failure) 0 bytes > >Although I have seem this on the message boards I am little confused in that >the ISP is telling me that there is no authentication enabled on the Juniper >and I do not have authentication enabled on the ASR. So what is going on here? > > > >
Re: Anyone competent within AT&T Uverse?
Ask to be escalated to Tier 2. If they can't help, ask for another escalation. Show them traceroutes if you can (maybe from your phone or from one of us) from other networks so they can see where it's dying. > > From: Phil Karn >To: NANOG >Sent: Tuesday, December 3, 2013 7:04 PM >Subject: Anyone competent within AT&T Uverse? > > >Does anyone know anyone within AT&T Uverse who actually knows what >TCP/IP is? Maybe even how to read a packet trace? > >I've been trying to get my static IP block working again since Saturday >when they broke it while fixing an unrelated problem. I can't believe >how incompetent their tech support has been on this. An hour into a chat >with them and I finally realize they don't have a clue what I'm talking >about...this is very frustrating... > >Their premise techs try very hard, but I get the strong impression that >the network support people randomly perturb provisioning until it works >again, and that's why they keep breaking unrelated things. > >I'm still wondering if this Internet stuff is ready for prime time... > >Thanks, > >Phil > > > >
Re: BGP neighbor/configuration testing
Update. Turned up session with provider. They had to increase max-prefixes when I "no shutdown" my BGP session in order to Establish it, then decreased it to their standard customer value. Why it didn't come right up out of "no shutdown" and required the increase in max-prefix is still unknown. Subsequent resets of the BGP session brought the session down and back up. Shutdown/no shutdown will be tested tomorrow. It has been an excellent lesson in establishing a 2nd upstream provider on the same router. Something I'll be doing 2 more times next month. >____ > From: Eric A Louie >To: "nanog@nanog.org" >Sent: Monday, November 25, 2013 5:21 PM >Subject: Re: BGP neighbor/configuration testing > > >No logged error with mismatched neighbor IP address - neither router had an >entry. Session did not establish nor go active, I could wait forever and >neither would happen. Point is, an error message is not generated on the >downstream router so it's probably not the cause for the error message. > >I asked my upstream to check if the "local interface" command was being used >(that would cause the multihop, but I did put in 2 or 3 as the ebgp-multihop >value and still didn't get the session up. > >Your last comment about max-prefix is probably the problem and the solution. >Right now, the entire configuration is in the router with a "neighbor >shutdown". When we bring it up tomorrow, the filters will all be there so >that only 13 of my prefixes are advertised, hopefully keeping the BGP session >up and closing this saga. (the router already has another upstream connected, >so when I turned up the neighbor without a filter, I flooded the upstream's >router with routes, but it took us this long to figure that out.) > > > > >On a Cisco to Cisco when the max-prefixes is exceeded and there's a restart >specified, the error (on the offender) is not quite the same as the error I'm >seeing: >*Apr 9 02:41:39.827: %BGP-3-NOTIFICATION: received from neighbor >10.250.254.253 3/1 (update malformed) 0 bytes >*Apr 9 02:41:39.827: %BGP-5-ADJCHANGE: neighbor 10.250.254.253 Down BGP >Notification received > >On the upstream (where the max-prefix was configured), > >*Nov 26 04:10:02.108: %BGP-4-MAXPFX: No. of prefix received from >10.250.254.254 (afi 0) reaches 2, max 2 >*Nov 26 04:10:02.108: %BGP-3-MAXPFXEXCEED: No. of prefix received from >10.250.254.254 (afi 0): 3 exceed limit 2 >*Nov 26 04:10:02.108: %BGP-5-ADJCHANGE: neighbor 10.250.254.254 Down BGP >Notification sent >*Nov 26 04:10:02.108: %BGP-3-NOTIFICATION: sent to neighbor 10.250.254.254 3/1 >(update malformed) 0 bytes 0032 0200 > 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0802 > > > > > >> >> From: Chuck Anderson >>To: nanog@nanog.org >>Sent: Monday, November 25, 2013 3:37 PM >>Subject: Re: BGP neighbor/configuration testing >> >> >>When you say "no logged error" with mismatched neighbor IP address, >>what do you mean? Did the session just not establish at all? How >>long did you wait for it to attempt to establish? >> >>On Juniper, if it sees a BGP connection come from an IP address that >>doesn't match a local "neighbor" statement, it will send a BGP >>Notification, code 2 (Open Message Error), subcode 5 (authentication >>failure), which is exactly what you are seeing. >> >>If one side is using a loopback IP instead of a physical IP for the >>local-address, that would cause both a multihop/TTL issue and a >>neighbor IP mismatch. >> >>Another possibility is if you have exceeded the max prefix limit for >>the session. One side will get stuck in Idle state which may cause >>the other side to send the same "authentication failure" notification. >> >>On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote: >>> All Cisco/Cisco, I don't have a Juniper here to test with >>> >>> mismatch AS >>> *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor >>> 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 >>> >>> mismatch neighbor IP address >>> no logged error >>> >>> MTU mismatch >>> no logged error, session remained up >>> >>> Subnet mask mismatch >>> session remained up, no logged error >>> >>> I haven't created the multihop scenario to see the error messages. >>> >>> >>> None of these issues caused the (authentication failure). >>> >>> >>> >>> >>> >>> > >>> > From: Chuck Anderson >>> >To: nanog@nanog.org >>> >Sent: Monday, November 25, 2013 11:10 AM >>> >Subject: Re: BGP neighbor/configuration testing >>> > >>> > >>> >Authentication failure might mean (without knowing for sure which on >>> >Cisco): >>> > >>> >- mismatch AS numbers >>> >- mismatch neighbor IP addresses >>> >- multihop/TTL issues >>> >- MTU issues >> >> >> >> > > >
Re: BGP neighbor/configuration testing
No logged error with mismatched neighbor IP address - neither router had an entry. Session did not establish nor go active, I could wait forever and neither would happen. Point is, an error message is not generated on the downstream router so it's probably not the cause for the error message. I asked my upstream to check if the "local interface" command was being used (that would cause the multihop, but I did put in 2 or 3 as the ebgp-multihop value and still didn't get the session up. Your last comment about max-prefix is probably the problem and the solution. Right now, the entire configuration is in the router with a "neighbor shutdown". When we bring it up tomorrow, the filters will all be there so that only 13 of my prefixes are advertised, hopefully keeping the BGP session up and closing this saga. (the router already has another upstream connected, so when I turned up the neighbor without a filter, I flooded the upstream's router with routes, but it took us this long to figure that out.) On a Cisco to Cisco when the max-prefixes is exceeded and there's a restart specified, the error (on the offender) is not quite the same as the error I'm seeing: *Apr 9 02:41:39.827: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 3/1 (update malformed) 0 bytes *Apr 9 02:41:39.827: %BGP-5-ADJCHANGE: neighbor 10.250.254.253 Down BGP Notification received On the upstream (where the max-prefix was configured), *Nov 26 04:10:02.108: %BGP-4-MAXPFX: No. of prefix received from 10.250.254.254 (afi 0) reaches 2, max 2 *Nov 26 04:10:02.108: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.250.254.254 (afi 0): 3 exceed limit 2 *Nov 26 04:10:02.108: %BGP-5-ADJCHANGE: neighbor 10.250.254.254 Down BGP Notification sent *Nov 26 04:10:02.108: %BGP-3-NOTIFICATION: sent to neighbor 10.250.254.254 3/1 (update malformed) 0 bytes 0032 0200 1940 0101 0040 0204 0201 6A39 4003 040A FAFE FE80 0404 0802 > > From: Chuck Anderson >To: nanog@nanog.org >Sent: Monday, November 25, 2013 3:37 PM >Subject: Re: BGP neighbor/configuration testing > > >When you say "no logged error" with mismatched neighbor IP address, >what do you mean? Did the session just not establish at all? How >long did you wait for it to attempt to establish? > >On Juniper, if it sees a BGP connection come from an IP address that >doesn't match a local "neighbor" statement, it will send a BGP >Notification, code 2 (Open Message Error), subcode 5 (authentication >failure), which is exactly what you are seeing. > >If one side is using a loopback IP instead of a physical IP for the >local-address, that would cause both a multihop/TTL issue and a >neighbor IP mismatch. > >Another possibility is if you have exceeded the max prefix limit for >the session. One side will get stuck in Idle state which may cause >the other side to send the same "authentication failure" notification. > >On Mon, Nov 25, 2013 at 03:07:28PM -0800, Eric A Louie wrote: >> All Cisco/Cisco, I don't have a Juniper here to test with >> >> mismatch AS >> *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor >> 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 >> >> mismatch neighbor IP address >> no logged error >> >> MTU mismatch >> no logged error, session remained up >> >> Subnet mask mismatch >> session remained up, no logged error >> >> I haven't created the multihop scenario to see the error messages. >> >> >> None of these issues caused the (authentication failure). >> >> >> >> >> >> > >> > From: Chuck Anderson >> >To: nanog@nanog.org >> >Sent: Monday, November 25, 2013 11:10 AM >> >Subject: Re: BGP neighbor/configuration testing >> > >> > >> >Authentication failure might mean (without knowing for sure which on >> >Cisco): >> > >> >- mismatch AS numbers >> >- mismatch neighbor IP addresses >> >- multihop/TTL issues >> >- MTU issues > > > >
Re: BGP neighbor/configuration testing
All Cisco/Cisco, I don't have a Juniper here to test with mismatch AS *Apr 9 00:31:47.691: %BGP-3-NOTIFICATION: received from neighbor 10.250.254.253 2/2 (peer in wrong AS) 2 bytes 6A39 mismatch neighbor IP address no logged error MTU mismatch no logged error, session remained up Subnet mask mismatch session remained up, no logged error I haven't created the multihop scenario to see the error messages. None of these issues caused the (authentication failure). > > From: Chuck Anderson >To: nanog@nanog.org >Sent: Monday, November 25, 2013 11:10 AM >Subject: Re: BGP neighbor/configuration testing > > >Authentication failure might mean (without knowing for sure which on >Cisco): > >- mismatch AS numbers >- mismatch neighbor IP addresses >- multihop/TTL issues >- MTU issues > >On Mon, Nov 25, 2013 at 11:06:33AM -0800, Eric A Louie wrote: >> That's a natural first impression but there are no passwords configured on >> the BGP session on either router. I know it looks like an authentication >> error but it's a "misnomer" (at least from the searches I did on the error >> message). From the sequence of messages, we get Established and 2 seconds >> later the session Closes. The reason for the Close may lead us to the >> solution. >> >> I'm reluctant to turn on debug bgp because this is a live production router, >> and if I hose it, there will be a lot of 'splainin to do [1] >> >> [1] >> http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html >> >> >> >> >> >> > >> > From: Daniel Rohan >> >To: Eric A Louie >> >Cc: Joe Abley ; "nanog@nanog.org" >> >Sent: Monday, November 25, 2013 10:55 AM >> >Subject: Re: BGP neighbor/configuration testing >> > >> > >> > >> >Seems like: >> > >> >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor >> >xxx.118.92.149 2/5 (authentication failure) 0 bytes >> >> >> >should be a good starting place. I'm assuming you've already discussed auth >> >keys with your provider and if everyone is putting that in correctly, I'd >> >suggest turning on debugging to see what exactly that message is all about. >> > >> > >> >Dan > > > >
Re: BGP neighbor/configuration testing
That's a natural first impression but there are no passwords configured on the BGP session on either router. I know it looks like an authentication error but it's a "misnomer" (at least from the searches I did on the error message). From the sequence of messages, we get Established and 2 seconds later the session Closes. The reason for the Close may lead us to the solution. I'm reluctant to turn on debug bgp because this is a live production router, and if I hose it, there will be a lot of 'splainin to do [1] [1] http://www.quotecounterquote.com/2011/05/lucy-you-got-some-splainin-to-do.html >____ > From: Daniel Rohan >To: Eric A Louie >Cc: Joe Abley ; "nanog@nanog.org" >Sent: Monday, November 25, 2013 10:55 AM >Subject: Re: BGP neighbor/configuration testing > > > >Seems like: > >Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor >xxx.118.92.149 2/5 (authentication failure) 0 bytes >> >should be a good starting place. I'm assuming you've already discussed auth >keys with your provider and if everyone is putting that in correctly, I'd >suggest turning on debugging to see what exactly that message is all about. > > >Dan > >
Re: BGP neighbor/configuration testing
The turn-up was unsuccessful. The provider and I could not get an Established BGP session. Here's the log results from my router: Nov 25 06:28:34.837 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 2/5 (authentication failure) 0 bytes Nov 25 06:29:09.690 pacific: %BGP-5-ADJCHANGE: neighbor xxx.118.92.149 Up Nov 25 06:29:10.562 pacific: %BGP-3-NOTIFICATION: received from neighbor xxx.118.92.149 6/1 (cease) 7 bytes 00010100 000320 Nov 25 06:29:10.562 pacific: %BGP-5-ADJCHANGE: neighbor xxx.118.92.149 Down BGP Notification received My interface is at xxx.118.92.150. They scrubbed their (Juniper) configuration and said all looks good. I scrubbed my (Cisco) configuration - all I had was "neighbor xxx.118.92.149 remote-as xx9" and couldn't get the neighbor established. Pings to xxx.118.92.149 are successful. I have the output of "sh tcp brief all" and "sh tcp" - we are not getting the TCP connection to stay up. Has anyone seen this series of messages on a Cisco/Juniper BGP session? Any resolution? >________ > From: Joe Abley >To: Eric A Louie >Cc: "nanog@nanog.org" >Sent: Wednesday, November 20, 2013 12:01 PM >Subject: Re: BGP neighbor/configuration testing > > > >On 2013-11-20, at 14:53, Eric A Louie wrote: > >> Scenario: a regional ISP preparing to cutover to a new upstream BGP provider >> at one of my POPs. Want minimal or no network disruption, and want to >> ensure everything is ready to go prior to the cutover. >> >> I'm planning to use the following order of operations: >> 1. Establish IP connectivity to the new ISP (already done) >> 2. Configure my BGP router and shutdown the new neighbor (ISP says their >> side is already configured and ready) > >Leave the adjacency up, and just deny all inbound and outbound on the >corresponding route filter. You never want a maintenance's success to depend >on "no neigh x.x.x.x shut" working smoothly; much better to be able to confirm >that the session is up before you start and just change the import/export >policy. > >> 3. During the maintenance window for this change, activate the new BGP >> connection (remove neighbor shutdown) >> 4. Do the appropriate tests (sh bgp nei, login to my upstream's route server >> and check route advertisements, sign in to looking glass and/or route >> servers from other providers to see if my routes from the new ISP are being >> advertised, and I'm open to any other tests) > >You could insert "wait N days" here, with a rollback plan (e.g. in case of >customer-enraging congestion or packet loss) that restores the original >configuration by shutting down the new adjacency. > >> 5. Turn down the old connection (neighbor shutdown) >> 6. Watch the old connection get removed from route servers/looking glasses >> from step 4 >> >> A. Does that order make sense or does it need some tweaking, additions, or >> "other"? >> >> B. I'd like to test the new upstream BGP configuration without passing >> traffic to and through it. What can I do (if anything) on my configuration >> end to put up the BGP configuration, establish a neighbor connection, and >> NOT actually pass any traffic through it? After putting my configuration >> up, I'd like to do a show bgp nei 1.1.1.1 advertised-routes to ensure my >> routes are going out, and then shut the neighbor down until the cutover. > >Bring the session up with deny all in both directions, and use the appropriate >show commands (show neigh ... received-routes since you're talking cisco) to >show what routes were received upstream of the filter. You are presumably >already testing your export policy on your live session; if the configuration >on the new session is the same, then you're really just talking about making >sure that the internal route set visible on the router with the new session is >right. > > >Joe > > >
BGP neighbor/configuration testing
Scenario: a regional ISP preparing to cutover to a new upstream BGP provider at one of my POPs. Want minimal or no network disruption, and want to ensure everything is ready to go prior to the cutover. I'm planning to use the following order of operations: 1. Establish IP connectivity to the new ISP (already done) 2. Configure my BGP router and shutdown the new neighbor (ISP says their side is already configured and ready) 3. During the maintenance window for this change, activate the new BGP connection (remove neighbor shutdown) 4. Do the appropriate tests (sh bgp nei, login to my upstream's route server and check route advertisements, sign in to looking glass and/or route servers from other providers to see if my routes from the new ISP are being advertised, and I'm open to any other tests) 5. Turn down the old connection (neighbor shutdown) 6. Watch the old connection get removed from route servers/looking glasses from step 4 A. Does that order make sense or does it need some tweaking, additions, or "other"? B. I'd like to test the new upstream BGP configuration without passing traffic to and through it. What can I do (if anything) on my configuration end to put up the BGP configuration, establish a neighbor connection, and NOT actually pass any traffic through it? After putting my configuration up, I'd like to do a show bgp nei 1.1.1.1 advertised-routes to ensure my routes are going out, and then shut the neighbor down until the cutover. thanks for your input Eric
Re: Network configuration archiving
I know you said open source, but we're using Solarwinds Cattools with very good results. We also have Rancid running in the background. > > From: Job Snijders >To: nanog@nanog.org >Sent: Thursday, October 24, 2013 2:25 PM >Subject: Network configuration archiving > > >Dear all, > >I am unsure what we as networkers have done in the past, but I am sure >we've done our fair share of atonement and don't have to keep using >RANCID. > >Some might say "it took ages to get rancid to do kinda what we want!", >but not all software ages well. One might work in environments where >archived configurations are needed to even start provisioning, one >might desire a separation between actual config and transcient data. > >As I am evaluating our path forward, I've compiled a small list of open >source projects with some biased highlights. Your feedback is most >welcome, maybe I missed some interesting projects or developments. I >would also be very interested in what other operators seek in a network >config/state archive tool. > >RANCID - http://www.shrubbery.net/rancid/ > * Support for a wild variery of devices and operating systems > * complex perl code base [1] > * no central developer team, the internet is littered with forks > >Oxidized - https://github.com/ytti/oxidized > * modern & sexy approach with queue & workers > * RESTful API (example: can bump devices to the head of the queue) > * small user & developer base > * written in that ruby language > >Gerty - https://github.com/ssinyagin/gerty > * Seems easier to extend than RANCID > * perl... > * small user & developer base > >punc - https://code.google.com/p/punc/ > * written in python, based on notch [2] > * no recent developments (although 2011 was a good wine year) > >[1] - >http://honestnetworker.wordpress.com/2013/06/28/adding-new-device-support-to-rancid/ >[2] - https://code.google.com/p/notch/ > >Kind regards, > >Job > > > >
Re: Need offlist contact for relay.globetrotter.net
Have you tried the (possible stale) info from ARIN? http://whois.arin.net/rest/poc/DS538-ARIN.html > > From: Alain Hebert >To: 'NANOG list' >Sent: Thursday, October 10, 2013 9:06 AM >Subject: Need offlist contact for relay.globetrotter.net > > > Well, > > If anyone has any postmaster/abused contacts for > > relay.globetrotter.net > 142.169.1.45 > (Telus Quebec?) > > For the past few days, we're getting some customers complaint about >cryptic "452 4.1.0 ... temporary failure" message from them. > > And the usual channel as dead as usual. > > Have fun. > >-- >- >Alain Hebert aheb...@pubnix.net >PubNIX Inc. >50 boul. St-Charles >P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > > > >
Re: Phoenix - Single Mode SFP GBIC
try calling the local datacenters and see if one of them will "loan" you one for a day or two. > > From: Chris Cariffe >To: NANOG >Sent: Saturday, October 5, 2013 7:19 PM >Subject: Phoenix - Single Mode SFP GBIC > > >Any chance someone can help me out with one in the Phoenix area? Tried >Fry's, MMF only... >CDW won't get one here till Tuesday. >thanks > >-chris > > >
Re: minimum IPv6 announcement size
"...and leave my BN alone, please - go play with the AGS" > > From: "valdis.kletni...@vt.edu" >To: Ben >Cc: nanog@nanog.org >Sent: Monday, September 30, 2013 7:40 AM >Subject: Re: minimum IPv6 announcement size > > >On Mon, 30 Sep 2013 13:05:01 +0100, Ben said: > >> Most people here were probably not of working age in 1985 ;-) > >"All you kids, get off my Proteon!" :) > > >
Re: Evaluating Tier 1 Internet providers
how is that really much different than "reachability"? If I look at my present Netflow results, it's actually a pretty amusing mix - lots of Netflix traffic (bear in mind we're a business ISP, not residential), Google (probably YouTube in there, I haven't dissected it thoroughly), Amazon, Yahoo, Microsoft/MSN, and that's all covered in the peering fabric connection. Outside of that, some private VPN-type traffic, I don't see a lot of government networks, just "normal" Internet browsing and email. Since I'm not at the Data Center much, I don't interact with the other customers there. (It's 150 miles away) Due to non-disclosure, the Data Center gang aren't much going to share their customer contact info with me. But it's a nice thought, for sure. -e- > > From: Michael Smith >To: Eric Louie >Cc: nanog@nanog.org >Sent: Tuesday, August 27, 2013 6:48 PM >Subject: Re: Evaluating Tier 1 Internet providers > > >You should also consider who exactly your customers (or you alone) want to >reach. Are you mostly looking to connect to eyeball networks? Enterprise >networks? Government networks? If you have some target networks you should >do some due diligence to find out how well connected your various options are >to the networks that mean the most to you. > >If possible, I would also recommend talking to other people that are in your >data centers, if that's possible. You might find out about hidden >vendor-specific gremlins in that location. > >Regards, > >Mike > > >On Aug 27, 2013, at 12:02 PM, Eric Louie wrote: > >> Based on various conversation threads on Nanog I've come up with a few >> criteria for evaluating Tier 1 providers. I'm open to add other criteria - >> what would you add to this list? And how would I get a quantitative or >> qualitative measure of it? >> >> >> >> routing stability >> >> BGP community offerings >> >> congestion issues >> >> BGP Peering relationships >> >> path diversity >> >> IPv6 table size >> >> >> >> Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 >> customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. >> I'm shopping for new service and want to do better than choosing on >> reputation. (or, is reputation also a criteria?) >> >> >> >> much appreciated, >> >> Eric Louie >> >> >> > > > >
Colo recommendations
I'm investigating colocation space in the following cities Irvine, CA San Francisco, CA Las Vegas, NV Phoenix, AZ Does anyone have recommendations for (or against) any specific colo? I'll need 1/3 rack, 16 amp power (or 8 amp 220V), fiber cross to 1GB ISP upstream (haven't chosen the ISP yet, either), roof or tower access to mount an antenna. Private replies are welcome, as are replies to the list. thanks Eric
Re: IP Address Management IPAM software for small ISP
Thanks James. We just activated a demo with 6Connect last week. We'll see how it goes. Much appreciated, Eric From: James Wininger To: Eric A Louie Cc: "" Sent: Mon, December 17, 2012 8:56:53 AM Subject: Re: IP Address Management IPAM software for small ISP Eric, We recently migrate away from IPPlan to 6connect. There is significant cost to the application but the end result (IMHO) is well worth it. IPPlan was great that is used MySQL, as many of us use that DB, so integration was easy, but what we were trying to do with the integration on the "backend" with IPPlan, 6connect does out of the box. DNS integration, RESTful with ARIN, user access control etc. Not trying to sell the product here, just saying that we went through what you are going through and if it helps, I wish we had the time back that we put into IPPlan. They have hosted and "local" installs available, but they prefer the hosted model. We did local install. -- Jim On Dec 12, 2012, at 8:22 PM, Eric A Louie wrote: I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 >Tier 2 personnel and 2 NOC technicians who would be using the tool, and a >small >staff of engineers. > >They have regionalized IP addresses so blocks are local, but there are subnets >that are global. > >don't care if it's a linux or windows solution. > >Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > >We're not dealing with a lot now, but the potential for growth is pretty high. > >What are you using and how is it working for you? > >Much appreciated, Eric > >
Re: IP Address Management IPAM software for small ISP
Only if you install it for me, Pierre! :-) (I'm not a sysadmin, I just play one on the Internet) Software prerequisite Netmagis needs the following software:(not the usual yada yada yada, to quote Google) Much appreciated, Eric From: Pierre DAVID To: NANOG Operators' Group Sent: Fri, December 21, 2012 7:20:14 AM Subject: Re: IP Address Management IPAM software for small ISP On Wed, Dec 19, 2012 at 09:09:40PM -0600, Beavis wrote: > +1 for ipplan http://iptrack.sourceforge.net/ > May I suggest Netmagis http://netmagis.org ? Pierre P.S.: I'm one of the authors
Re: IP Address Management IPAM software for small ISP
It looks like it's hosted only - true? That's neither a good or bad - but the MRC could be a concern. Much appreciated, Eric From: Mike Walter To: Eric A Louie ; "nanog@nanog.org" Sent: Thu, December 13, 2012 12:25:44 PM Subject: RE: IP Address Management IPAM software for small ISP Eric, you should look at 6connect. They have a good product for IPv4 and IPv6 address management. -Mike -Original Message- From: Eric A Louie [mailto:elo...@yahoo.com] Sent: Wednesday, December 12, 2012 8:23 PM To: nanog@nanog.org Subject: IP Address Management IPAM software for small ISP I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. They have regionalized IP addresses so blocks are local, but there are subnets that are global. don't care if it's a linux or windows solution. Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) We're not dealing with a lot now, but the potential for growth is pretty high. What are you using and how is it working for you? Much appreciated, Eric
Re: IP Address Management IPAM software for small ISP
Thanks Jeremy - looks pretty good, and specific, and I like the DNS integration. I haven't downloaded or installed it yet. Do you think it's robust enough for a 24x7 Network Operations Center that has 8 or so users? Is the database a flat file that is easily backed up and restored? or are you using MySQL? Much appreciated, Eric From: Jeremy Malli To: nanog@nanog.org; elo...@yahoo.com Sent: Thu, December 13, 2012 8:26:17 AM Subject: Re: IP Address Management IPAM software for small ISP A colleague and myself wrote one in PHP that supports v4 and v6. It's available on sourceforge: http://sourceforge.net/projects/subnetsmngr/?source=directory Jeremy Malli Mammoth Networks On 12/12/2012 6:22 PM, Eric A Louie wrote: > I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 > Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small > staff of engineers. > > They have regionalized IP addresses so blocks are local, but there are subnets > that are global. > > don't care if it's a linux or windows solution. > > Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > > We're not dealing with a lot now, but the potential for growth is pretty high. > > What are you using and how is it working for you? > > Much appreciated, Eric >
Re: IP Address Management IPAM software for small ISP
Racktables = no IPv6. Bummer, and it does more than what I need. Netdot looks very interesting. It didn't show up when I searched for "IPAM". I'll have to evaluate it, to see if it does any kind of wireless documentation (frequency, modulation, etc) Any Netdot users out there who want to comment? Much appreciated, Eric From: Nick Hilliard To: Aftab Siddiqui Cc: Eric A Louie ; NANOG Operators' Group Sent: Thu, December 13, 2012 2:25:10 AM Subject: Re: IP Address Management IPAM software for small ISP On 13/12/2012 10:10, Aftab Siddiqui wrote: > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The > first one I assume should serve your purpose for both v4 and v6. I've had a lot more success with Racktables and Netdot, both of which are really good at what they do. Racktables in particular. Nick
Re: IP Address Management IPAM software for small ISP
That is a superb suggestion, Aftab. I actually did a search through the archives for "IPAM" and "IP address management" and the results were ... unsatisfactory. Perhaps I used the wrong archive, and you direct me to an alternate: http://mailman.nanog.org/pipermail/nanog/ is the one I used. I've looked at IPPLan but have not installed it yet. Does anyone with direct experience with it care to share their view? Much appreciated, Eric From: Aftab Siddiqui To: Eric A Louie Cc: NANOG Operators' Group Sent: Thu, December 13, 2012 2:10:24 AM Subject: Re: IP Address Management IPAM software for small ISP Kindly search the archives for many threads on the same subject, which should be the normal practice. nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The first one I assume should serve your purpose for both v4 and v6. Regards, Aftab A. Siddiqui On Thu, Dec 13, 2012 at 6:22 AM, Eric A Louie wrote: I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 >Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small >staff of engineers. > >They have regionalized IP addresses so blocks are local, but there are subnets >that are global. > >don't care if it's a linux or windows solution. > >Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > >We're not dealing with a lot now, but the potential for growth is pretty high. > >What are you using and how is it working for you? > > Much appreciated, Eric >
IP Address Management IPAM software for small ISP
I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. They have regionalized IP addresses so blocks are local, but there are subnets that are global. don't care if it's a linux or windows solution. Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) We're not dealing with a lot now, but the potential for growth is pretty high. What are you using and how is it working for you? Much appreciated, Eric
