Re: IPv6 and CDN's

[Gustav Ulander]

And ipv4 I presume so there is still easier and cost less money to just go with 
that. 
From our point as an MSP no customer has a requirement that they want to be 
able to be reached via IPV6 so it’s still cheaper to buy up IPV4 address space 
and do a lot of nat than to convert all our services to function properly with 
IPV6. 
Sure one could argue that they should have been made that way from the 
beginning but without customer demand why would we spend the money? 

//Gustav 


> 23 okt. 2021 kl. 15:33 skrev Ca By :
> 
> 
> 
> 
>> On Fri, Oct 22, 2021 at 8:48 AM Bryan Fields  wrote:
>> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
>> > Another aspect that flabbergasts me anno 2021 is how there *still* are
>> > BGP peering disputes between (more than two) major global internet service
>> > providers in which IPv6 is 'held hostage' as part of slow commercial
>> > negotiations. Surely end-to-end IPv6 connectivity should be a priority?
>> 
>> Even the DNS root servers are not 100% reachable via IPv6.  I would think 
>> IANA
>> would have some standard about reachability for root operators.
>> 
>> FWIW, I just was able to change my home office internet (I reside in the most
>> densely populated county of Florida).  The new provider sold me a dual stack
>> connection, however when they came to deliver it, there was no IPv6 as
>> promised.  After spending almost a week playing phone tag, I finally got some
>> one with clue.  I was told they have no support if IPv6 and no plans to ever
>> support IPv6 as there is no way to monetize it.
>> 
>> This leaves me in the same position as my prior circuit via the local cable
>> co. (no plans to offer IPv6) but at least it's faster than the 2 meg up cable
>> service.
>> 
>> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
>> being offered outside of the datacenter.
> 
> 87% of mobiles in the usa are ipv6
> 
> https://www.worldipv6launch.org/measurements/
> 
> 
> 
> 
>> 
>> -- 
>> Bryan Fields
>> 
>> 727-409-1194 - Voice
>> http://bryanfields.net

SV: IGP protocol

[Gustav Ulander]

Hello all.

We also run a small network (sub 50 PEs)
It looks pretty similar to Baldurs except we run IS-IS instead of OSPF.
IPV4 only in the global table with VPNV4 and VPNv6 services running on top of 
it.
We do run a separate OBM network to handle management without being dependent 
on service infrastructure for management.
Only real difference we notice is that Cisco seem to roll out service provider 
features and knobs for IS-IS first and then eventually for OSPF.
Good or bad is the question.

//Gustav

Från: NANOG  För Baldur Norddahl
Skickat: den 15 november 2018 02:51
Till: nanog@nanog.org
Ämne: Re: IGP protocol

We run a MPLS enabled network with internet in a VRF. Management is in VRF 
default (no VRF). The IGP is OSPFv2. IPv6 is handled by the L3VPN functionality 
of MPLS. So is IPv4.

The IPv4 that is controlled by OSPF is totally separate from everything except 
management and could really be any protocol. For a small network like ours, 
with everything in area 0 and VRF/L3VPN to handle dual stack, there is zero 
differences between is-is and OSPF. The IPv4 management network is not any more 
reachable than the is-is protocol. There are no raw IPv6 packets on the wire 
and no need for the IGP to handle IPv6.

Also not true that the management network is the last thing to boot. In 
contrary, everything else depends on that being ready first. And that would 
also be true if we used is-is.

We chose OSPF because it was one less protocol to learn and one less ethernet 
type on the wire. But really it could be toss a coin.

Regards

Baldur


ons. 14. nov. 2018 14.55 skrev James Bensley 
mailto:jwbens...@gmail.com>>:
On Tue, 13 Nov 2018 at 12:09, Saku Ytti mailto:s...@ytti.fi>> 
wrote:
>
> On Tue, 13 Nov 2018 at 12:37, Mark Tinka 
> mailto:mark.ti...@seacom.mu>> wrote:
>
> > Main reasons:
> > - Doesn't run over IP.
>
> Why is this upside? I've seen on two platforms (7600, MX) ISIS punted
> on routers running ISIS without interface having ISIS.  With no
> ability to limit it, so any connected interface can DoS device with
> trivial pps rate, if ISIS is being ran.

I guess the OPs original question wasn't clear enough because, I think
most people are talking about IS-IS vs OSPF2/3 from a theoretical
protocol perspective, and you're talking from a practical vendor
implementation perspective.

From a purely theoretical perspective I see IS-IS not running over IP
as an advantage too. No mater what routes I inject into my IGP, IS-IS
won't stop working. I may totally fsck my IP reachability but IS-IS
will still work, which means that when I fix the issue, service should
be restored quite quickly. Several networks I've seen place management
in a VRF / L3 VPN, which means that by the time you have remote
management access, everything else is already working, it's like the
last thing to come up when there's been a problem. I like the
"management in the IGP + IS-IS" design.

However, in reality the vendor implementation blows the protocol
design out of the water. You need to consider both when evaluating a
new IGP. Cisco nearly implemented a handy feature with
prefix-suppression, whereby in IOS for OSPF only one would prevent
p-t-p links being advertised into the IGP database. But they didn't
implement this for IS-IS. Then in IOS-XR they removed this feature
from OSPF and implemented it for IS-IS ?!?! So yeah, vendors
implementations are just as important and the theoretical potential of
the protocol.

Oh yeah, forgot to answer the original question. For a greenfield
deployment I'd be happy with either OSPFv3 or IS-IS as long as it's
well designed I don't see much between them, it would come down to
vendor support then.

Cheers,
James.

SV: Proving Gig Speed

[Gustav Ulander]

We use Netrounds for this. 
We make a speedtest site available to the customer for their "click and test" 
needs which is the first step. 
If the customer doesn’t achive their allocated speed we will send out a probe 
(usually some form of Intel NUC or similar machine) that can do more advanced 
testing automatically also along different times. 
The customer then gets to send us back the device when the case is solved. 
Its not without its faults but its been a great tool so far. 

//Gustav

-Ursprungligt meddelande-
Från: NANOG  För James Bensley
Skickat: den 17 juli 2018 19:46
Till: Mark Tinka ; North American Network Operators' 
Group 
Ämne: Re: Proving Gig Speed

On 17 July 2018 at 12:50, Mark Tinka  wrote:
> But to answer your questions - for some customers, we insist on JDSU 
> testing for large capacities, but only if it's worth the effort.
>
> Mark.

Hi Mark,

Our field engineers have 1G testers, but even at 1G they are costly (in 2018!), 
so none have 10Gbps or higher testers and we also only do this for those that 
demand it (i.e. no 20Mbps EFM customer ever asks for a JSDU/EXO test, because 
iPerf can easily max out such a link, only those that pay for say 1G over 1G 
get it). Hardware testers are the best in my opinion right now but it annoys me 
that this is the current state of affairs, in 2018, even for 1Gbps!

Cheers,
James.

SV: Cisco NCS5501 as a P Router

[Gustav Ulander]

Hello.
We are running 5001 also and we have the same issue with it programming the 
wrong entry into the hardware. 
Interesting to hear that the issue is still in 6.1.2 since we were thinking 
about upgrading to that one to see if it fixes the issue but I think we will 
give it a pass. 
Seems the BU cant find why its happening only that it indeed is happening. They 
don’t seem to be able to duplicate it in the lab either last we heard. 

/Gustav


-Ursprungligt meddelande-
Från: NANOG [mailto:nanog-boun...@nanog.org] För Radu-Adrian Feurdean
Skickat: den 27 maj 2017 11:31
Till: nanog@nanog.org
Ämne: Re: Cisco NCS5501 as a P Router

On Thu, May 18, 2017, at 15:21, Erik Sundberg wrote:
> We're at the growing point where we need a dedicated P router for a 
> core device. We are taking a serious look at the NCS5501. Is there 
> anyone else using a NCS5501 as P Router or just general feedback on 
> the NCS5501 if you are using it?

Hi,

While we're not using the NCS5501, we do use the "previous version", NCS5001. 
We're not yet at a point to care about the minuscule buffers.
Set-up : initially P-router in a very small BGP-free core (ISIS + LDP), then 
added route-reflector functionality too. 

As a P-router they usually behave correctly, except for the some cases where 
they start routing incorrectly (according to Cisco, the wrong label is 
programmed into hardware). That should have been fixed with 6.1.2, which we 
have deployed, until we recently had the same issue on 6.1.2, on the exact same 
box. We expect having some fun with the TAC about that.
 
> The big downside is it's only has a single processor

Yes, but:
 - it's powerful enough (we ended-up using them as RR too, and ~1.2M  routes in 
RIB pose no problem)
 - ours being about half the price of a 5501, we have 2 of them on every  site. 
If you can afford the same (2 / site) do it; If you don't -  review the copy so 
that you can (Brocade SLX 9540 looks like a good  alternative).

SV: BGP peering strategies for smaller routers

[Gustav Ulander]

Hello.

Yea its a bit strange that we would need to add memory to the platform just 
because we upgraded the image. 
But since we were in kind of a tight spot we opted to upgrade it and then move 
away from the platform in that role. 

//Gustav

-Ursprungligt meddelande-
Från: William Herrin [mailto:b...@herrin.us] 
Skickat: den 3 maj 2016 22:32
Till: Gustav Ulander <gustav.ulan...@telecomputing.se>
Kopia: Eric Sabotta <esabo...@whdh.com>; NANOG list <nanog@nanog.org>
Ämne: Re: BGP peering strategies for smaller routers

On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander 
<gustav.ulan...@telecomputing.se> wrote:
> Yes I can confirm that we also had the issue with the asr1001s.
> For us the router was fine until we upgraded it. When we rebooted it 
> after the upgrade it ran out of memory when populating 2 full feeds.
> When we contacted TAC they confirmed that indeed it was a memory 
> problem and that we would need to add more memory to the box.

Hi Gustav,

IMO, you should not accept that answer from the TAC. An IOS release that 
crashes with two 600k BGP feeds in 4 gigs of RAM is badly defective.

Regards,
Bill Herrin



--
William Herrin  her...@dirtside.com  b...@herrin.us Owner, 
Dirtside Systems . Web: <http://www.dirtside.com/>

SV: BGP peering strategies for smaller routers

[Gustav Ulander]

Hello all.

Yes I can confirm that we also had the issue with the asr1001s. 
For us the router was fine until we upgraded it. When we rebooted it after the 
upgrade it ran out of memory when populating 2 full feeds. 
When we contacted TAC they confirmed that indeed it was a memory problem and 
that we would need to add more memory to the box. 
Perhaps 1002 isnt as thirsty? 

//Gustav

-Ursprungligt meddelande-
Från: NANOG [mailto:nanog-boun...@nanog.org] För William Herrin
Skickat: den 3 maj 2016 18:13
Till: Eric Sabotta 
Kopia: NANOG list 
Ämne: Re: BGP peering strategies for smaller routers

On Mon, May 2, 2016 at 10:35 PM, Eric Sabotta  wrote:
> I just did this with a ASR1001.  I had to upgrade it to 8gb of ram (I 
> got the real Cisco stuff for ~ $500).  Before the router would crash 
> when loading the tables.

Hi Eric,

Something very fishy there because:

> router1#show ip bgp summary
> BGP using 296,835,018 total bytes of memory

Commas added for clarity.

Regards,
Bill Herrin




--
William Herrin  her...@dirtside.com  b...@herrin.us Owner, 
Dirtside Systems . Web: 

RE: BGP peering strategies for smaller routers

[Gustav Ulander]

Hello.

When we was in a similar situation we opted for one transit provider to provide 
a default to us then we filtered on AS-HOPS so prefixes that was more than 3 
hops away was denied. 
This way we got the ones that where closest to us and that where more likely to 
matter. Prefixes that’s more than 3 hops away on both links could probably just 
as well go on a default insteed. 
However it’s a rather crude way of fixing the issue. We just did it to have the 
router up while we got extra memory from it. (we had memory shortage after an 
update that we needed to apply to correct some bug I think. We couldn’t just 
rollback the update if my memory serves me correct.) 

//Gustav

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike
Sent: den 2 maj 2016 21:07
To: NANOG list 
Subject: BGP peering strategies for smaller routers

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: internet visualization

[Gustav Ulander]

Agreed. 
Everyone at the office have been flying some. :)

//Gustav

-Original Message-
From: NANOG [mailto:nanog-bounces+gustav.ulander=telecomputing...@nanog.org] On 
Behalf Of Chris Knipe
Sent: den 8 september 2015 16:50
To: nanog list
Subject: Re: internet visualization

Indeed!

One of the nicest visualizations I've seen to date.  Loving it!

On Tue, Sep 8, 2015 at 4:37 PM, Max Tulyev  wrote:

> Really nice!
>
> How can I do zoom in/zoom out?
>
> On 06.09.15 03:15, Jared Mauch wrote:
> >
> > OT: hit delete, or shameless plug disclaimer
> >
> >   one of my colleagues just posted this visualiation of the 
> > internet from the as_path view of 2914.  if you are on a mobile, you 
> > have to physically move your device around.
> >
> >   http://as2914.net/
> >
> >   If you love it, send Job your accolades.  If you hate it, see 
> > above disclaimer.  If in a country with a holiday on monday, enjoy 
> > it safely.
> >
> >   - Jared
> >
>
>


-- 

Regards,
Chris Knipe