Re: BGP peering strategies for smaller routers
Careful with the ASR1000 and full tables at 4GB. http://www.gossamer-threads.com/lists/cisco/nsp/180710 I recommend adding some third party RAM to get 16GB. On Mon, May 2, 2016 at 12:07 PM, Mike wrote: > Hello, > > I have an ASR1000 router with 4gb of ram. The specs say I can get '1 > million routes' on it, but as far as I have been advised, a full table of > internet routes numbers more than 530k by itself, so taking 2 full tables > seems to be out of the question (?). > > I am looking to connect to a second ip transit provider and I'm > looking for any advice or strategies that would allow me to take advantage > and make good forwarding decisions while not breaking the bank on bgp > memory consumption. I simply don't understand how this would likely play > out and what memory consumption mitigation steps may be necessary here. Im > open to ideas... a pair of route reflectors? selective bgp download? static > route filter maps? > > Thank you. > > Mike- > >
Re: Someone didn't get the leap second memo...
We had some ASR1001s routers reboot. Looks like we hit this bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb01730 On Sat, Dec 31, 2016 at 5:47 PM, Hugo Slabbert wrote: > Had a set of Cisco ASR1004s running 15.4(3)S1 (on IOS-XE 03.13.01.S) all > restart at around midnight UTC, and all with `Last reload reason: > Watchdog`, with those boxes being at separate DCs in different regions. > I'm assuming when I call TAC I'll get a "whoops; sorry". > > -- > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > pgp key: B178313E | also on Signal > > > On Sun 2017-Jan-01 01:02:24 +, Matthew Huff wrote: > > [root@hayden ~]# ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> >> == >> LOCAL(0).LOCL. 10 l 20d 6400.0000.000 >> 0.000 >> -clock.xmission. 132.163.4.103 2 u 169 256 377 66.078 -1.302 >> 0.164 >> xclock.sjc.he.ne 10.200.208.2 2 u 13 256 315 65.689 999.633 >> 2.015 >> +tock.usshc.com .GPS.1 u 87 256 377 26.930 -0.550 >> 0.121 >> *ntp.your.org.CDMA. 1 u 43 256 217 23.3390.544 >> 0.069 >> >> Our batch system went belly up, but other than that, no other apparent >> leap second issues. >> >> >> Matthew Huff | 1 Manhattanville Rd >> Director of Operations | Purchase, NY 10577 >> OTA Management LLC | Phone: 914-460-4039 >> aim: matthewbhuff| Fax: 914-694-5669 >> >> >>
Re: Bandwidth Savings
I don't know the the Caribbean Internet Exchanges market. Are any worth peering at versus buying additional L2 bandwidth to Miami? https://cw.ams-ix.net/ http://www.ocix.net/ocix/ Rick On Tue, Jan 10, 2017 at 8:08 PM, Keenan Singh wrote: > Hi Guys > > We are an ISP in the Caribbean, and are faced with extremely high Bandwidth > costs, compared to the US, we currently use Peer App for Caching however > with most services now moving to HTTPS the cache is proving to be less and > less effective. We are currently looking at any way we can save on > Bandwidth or to be more Efficient with the Bandwidth we currently have. We > do have a Layer 2 Circuit between the Island and Miami, I am seeing there > are WAN Accelerators where they would put a Server on either end and sort > of Compress and decompress the Traffic before it goes over the Layer 2, I > have never used this before, has any one here used anything like this, what > results would I be able to expect for ISP Traffic? > > If not any ideas on Bandwidth Savings, or being more Efficient with want we > currently. > > Many thanks for any Help > > Keenan >
Re: BGP in a containers
I'm happy with GoBGP in a docker container for my BGP Dashboard/LookingGlass project. https://github.com/rhicks/bgp-dashboard Its just piping RIB updates, as JSON, to script to feed into MongoDB container. At work we also looked at GoBGP as a route-server for a small IXP type of setup, but ran into few issues that we didn't have the time to fully debug. So we switched to BIRD for that project. We are happy with both. On Thu, Jun 14, 2018 at 11:56 AM, james jones wrote: > I am working on an personal experiment and was wondering what is the best > option for running BGP in a docker base container. I have seen a lot blogs > and docs referencing Quagga. I just want to make sure I am not over looking > any other options before I dive in. Any thoughts or suggestions? > > -James >
Re: 4 or smaller digit ASNs
Anyone know the history behind ASN 2906 (Netflix)? How did they get a number that low? Rick On Thu, Oct 12, 2017 at 3:13 PM, Jon Lewis wrote: > On Thu, 12 Oct 2017, Hank Nussbacher wrote: > > On 12/10/2017 08:47, Mel Beckman wrote: >> >>> James, >>> >>> As far as I know, you can't buy an existing ASN for any amount of money. >>> You can buy the company that owns it, but that seems like boiling tea with >>> a blowtorch. >>> >>> I sincerely doubt there are unused low-number ASNs, but you could always >>> ask ARIN. >>> >>> I'm curious what your client's rationale is for wanting a low ASN. >>> >> It is called ASN-envy. >> > > And here smaller is better :) > > How would one go about cleaning up the provenance and either re-using or > selling an ASN, supposing: > > 1) you are all the registered contacts for the ASN and your ARIN POC is > still valid > > 2) the ASN was owned by (ok...it's ARIN[1], so "registered to") a defunct > corporation (inactive >10 years) of which you were part-owner > > 3) the ARIN maintenance fees have been unpaid >10 years...yet the ASN > still exists in whois > > [1] It was actually assigned pre-ARIN, but to an org that eventually > signed the RSA...so I wonder...are the maintenance fees really past > due...and is this why the ASN was never reclaimed while the IP space (which > was allocated by ARIN) was? > > -- > Jon Lewis, MCP :) | I route > | therefore you are > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ >
Re: IPv6 Default Allocation - What size allocation are you giving out
Sixty replies and no one linked to the BCOP? Is there a reason we are ignoring it? http://bcop.nanog.org/index.php/IPv6_Subnetting As we recently discovered ARIN is handing out IPv6 allocations on nibble boundaries. Either a /32 or /28 for service providers. A justification and utilization plan is need to get a /28. It is also double the cost per year. On Thu, Oct 9, 2014 at 9:01 AM, Owen DeLong wrote: > > On Oct 9, 2014, at 7:22 AM, Daniel Corbe wrote: > > > > > Mark Andrews writes: > > > >> In message <54366ab9.3040...@gmail.com>, Paige Thompson writes: > >>> makes more sense to hand out /48s imho. theres only a mere 65k /48s per > >>> /32 (or something like that), though. > >> > >> A /32 is the minimum allocation to a ISP. If you have more customers > >> or will have more customers request a bigger block from the RIRs. > >> > >> Mark > > > > Has anyone successfully gotten a RIR to assign anything bigger than a > > /32? I seem to recall in recent history someone tried to obtain a /31 > > through ARIN and got smacked down. > > I think I answered this before you asked it, but yes,easily on multiple > occasions. The largest two allocations I have worked on were /24s, but I’m > sure > those are not ARIN’s largest allocations. > > > Even if you're assigning a /56 to every end user, that's still on the > > order of 16 million allocations. I can't imagine anyone but the truly > > behemoth access network operators being able to justify a larger > > allocation with a straight face. > > You should, however, be assigning a /48 to every end user and that’s only > 65,536 allocations. > > Further, you want to be able to aggregate at least one level in your > network, > so you may not be able to get anything close to 100% efficiency in that > distribution. > > ARIN policy, for example, defines what is known as a Provider Allocation > Unit (PAU). > > Your PAU is the smallest allocation you give to your customers, so if > you’re > giving out /64s, then your PAU becomes /64. If you’re giving out /56s, then > your PAU is /56. As such, you’re better off to give /48s to everyone > because > that sets your PAU at /48. > > All of your utilization is measured in terms of PAUs. > > You then pick an aggregation level in your network to use as your “serving > center” > definition. It could be the POP, or some higher level of aggregation > containing > multiple POPs. > > Look at the number of end sites served by the largest of those “serving > centers” > and round that up to a power of 16 (a nibble boundary, e.g. 16, 256, 4096, > 65536) > such that the number of end sites is not more than 75% of the chosen poser > of 16. > > Then take the number of “serving centers” you expect to have in ~5 years > (though > the exact forward looking time is not actually specified in policy) and > round that > up to a nibble boundary as well. > > That is the size of allocation you can get from ARIN. > > So, for example, if you have 800,000 end-sites served from your largest > POP and > you have 400 POPs, then, 800,000 would be rounded up to 16,777,216 (24 > bits) > and your 400 POPs would be rounded up to 4096 (12 bits) so you would end up > needing 36 bits. If your PAU is /48, you would apply for and receive a /12. > > Obviously this is an unusually large example. > > At a more realistic large ISP scale, let’s say you’ve got 5,000,000 > subscribers in > your largest serving center, but only 25 serving centers. > > This would, again, round up to 16,777,216 (24 bits) subscribers per > serving center. > But your 25 serving centers would round up to 256 (8 bits). That’s 32 > bits, so instead > of a /12, you’d get a /16. > > > I hope that clarifies things for people. > > Owen > > >
Re: IPv6 Default Allocation - What size allocation are you giving out
On Thu, Oct 9, 2014 at 10:40 AM, William Herrin wrote: > On Thu, Oct 9, 2014 at 12:29 PM, Richard Hicks > wrote: > > Sixty replies and no one linked to the BCOP? > > Is there a reason we are ignoring it? > > Hi Richard, > > It's dated (a *lot* about IPv6 has changed since 2011) and a we've > learned enough to know some of the things in there are dubious. For > example: > > "Regardless of the number of hosts on an individual LAN or WAN > segment, every multi-access network (non-point-to-point) requires at > least one /64 prefix." > > But using /64s on WAN links invites needless problems with neighbor > discovery when an attacker decides to send one ping each to half a > million adresses all of which happen to land on that WAN link. WAN > links should really use something whose size is much closer to the > number of routers on the link, in the same order of magnitude anyway. > So /64s for LANs, sure, but size the WAN links small to make them less > vulnerable to attack. > The BCOP specfically addresses this in 4b: " *b. Point-to-point links should be allocated a /64 and configured with a /126 or /127*" > And: > > "Only subnet on nibble boundaries" is not reasonable. When I need two > LANs in a building I should burn 14 more to get to a nibble boundary? > Really? > > "Only delegate on nibble boundaries" is a more reasonable statement. > When you assign addresses to your customer or to a different internal > team's control, THAT should be on a nibble boundary for the customer's > convenience understanding the written-down version of what network is > theirs and for your convenience when it comes time to delegate reverse > DNS. > > Inside your network under control of the same engineers, subnet and > route just as you would with IPv4. > > Regards, > Bill Herrin > > > > -- > William Herrin her...@dirtside.com b...@herrin.us > Owner, Dirtside Systems . Web: <http://www.dirtside.com/> > May I solve your unusual networking challenges? >
