Re: Max Prefix Out, was Re: Verizon 701 Route leak?

[Randy Bush]

>>> i have 142 largish bgp customers, a large enough number that the number
>>> of prefixes i receive from them varies annoyingly.  how do i reasonably
>>> automate setting of my outbound prefix limit?
>>
>> First, it seems you know the inbound so automating the outbound is simple
>> arithmetic.
>
> I would have said the same... i ought to know high-water marks for your
> inbound peer count(s), and can work out a +20% outbound...

you just assumed that the transitive closure of everybody's cones
implement and propagate count.  ain't gonna happen.

Re: BGP Optimizers (Was: Validating possible BGP MITM attack)

[Tom Paseka via NANOG]

We regularly see poorly configured "optimizers" or networks hijacking our
prefixes (originating /25's, /24 of /23's etc).

Thankfully, most of the time filters are in place to stop them leaking
badly, but I agree, these are toxic.

-Tom

On Fri, Sep 1, 2017 at 6:06 AM, Job Snijders  wrote:

> Dear all,
>
> disclaimer:
>
> [ The following is targetted at the context where a BGP optimizer
> generates BGP announcement that are ordinarily not seen in the
> Default-Free Zone. The OP indicated they announce a /23, and were
> unpleasantly surprised to see two unauthorized announcements for /24
> more-specifics pop up in their alerting system. No permission was
> granted to create and announce these more-specifics. The AS_PATH
> for those /24 announcements was entirely fabricated. Original thread
> https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ]
>
> On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote:
> > Presuming it was a route optimizer and the issue was ongoing, what
> > would be the suggested course of action?
>
> I strongly recommend to turn off those BGP optimizers, glue the ports
> shut, burn the hardware, and salt the grounds on which the BGP optimizer
> sales people walked.
>
> It is extremely irresponsible behavior to use software that generates
> _fake_ BGP more-specifics for the purpose of traffic engineering. You
> simply cannot expect that those more-specifics will never escape into
> the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see
> software bugs related to NO_EXPORT, and community-squashing
> configuration mistakes happen all the time.
>
> Consider the following: if you leak your own internal more-specifics, at
> least you are the legitimate destination. (You may suffer from
> suboptimal routing, but it isn't guaranteed downtime.) However if you
> generate fake more-specifics for prefixes belonging to OTHER
> organisations, you essentially are complicit in BGP hijacking. If those
> fake more-specifics accidentally leak into the DFZ, you are bringing
> down the actual owner of such prefixes, and depriving people from access
> to the Internet. Example case:
> https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html
>
> > reach out to those 2 AS owners and see if they could stop it?
>
> Yes, absolutely! And if everyone of the affected parties of this
> localized hijack leak (or should we say 'victims') reaches out to the
> wrongdoers, they contribute peer pressure to rectify the situation. Just
> make sure you assign blame to the correct party. :)
>
> > Or is it something I just have to live with as a traffic engineering
> > solution they are using and mark the alerts as false positives?
>
> No, this is not something we should just accept. The Default-Free Zone
> is a shared resource. Anyone using "BGP optimizers" is not only risking
> their own online presence, but also everyone else's. Using a BGP
> optimizer is essentially trading a degree of risk to society for the
> purpose of saving a few bucks or milliseconds. It is basically saying:
> "The optimizer helps me, but may hurt others, and I am fine with that".
>
> An analogy: We don't want transporters of radioactive material to cut
> corners by using non-existant roads to bring the spent nuclear fuels
> from A to B faster, nor do we want them to rely on non-robust shielding
> that works "most of the time".
>
> We share the BGP DFZ environment, 'BGP optimizers' are downright
> pollution contributors.
>
> Kind regards,
>
> Job
>
> ps. If you want to do BGP optimization: don't have the BGP optimizer
> generate fake BGP announcements, but focus only on manipulating
> non-transitive attributes (like LOCAL_PREF) on real announcements you
> actually received from others. Or Perhaps BGP optimizers shouldn't even
> talk BGP but rather push freshly generated TE-optimized routing-policy
> to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come
> to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate
> real announcements)... there are ways to do this, without risk to others!
>
> p.s. providing a publicly available BGP looking glasses will contribute
> to proving your innocence in cases like these. Since in many cases the
> AS_PATH is a complete fabrication, we need to manually check every AS in
> the AS_PATH to see whether the AS carries the fake more-specific. A
> public looking glass speeds up this fault-finding process. If you don't
> want to host a webinterface yourself, please consider sending a BGP feed
> to the Route Views Project or RIPE RIS, or for something queryable in a
> real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/
>

Re: Moving fibre trunks: interruptions?

[Ricky Beam]

On Fri, 01 Sep 2017 15:52:40 -0400, Rod Beck  
 wrote:
I don't think there is virtually any aerial in Europe. So given the cost  
difference why is virtually all fiber buried on this side of the  
Atlantic?


Aerial is simple and fast... pull the cable through a stringer, move to  
the next pole and repeat; when a section (about a mile) is done, it's  
hoisted into the air and tied to the pole. The stringers are then moved to  
the next mile of poles and the process repeats.


Buried stuff requires a great deal of planning, permitting, and insurance.  
You have to know everything that's ever been stuffed in the ground within  
half a mile of where you're working to avoid the inevitable cutting of  
something important -- gas, water, sewer, power, other telcom, even vacuum  
tube lines and subways. And then you need trenching gear to get stuff in  
the ground, and crews to come along behind to remediate the "environmental  
damage".


(Once the conduit is in the ground, it's a trivial matter to blow whatever  
you need through it.)

Re: Moving fibre trunks: interruptions?

[Jean-Francois Mezei]

On 2017-09-01 16:12, Alain Hebert wrote:
>  Being somehow familiar with how things operate when it involve 
> Quebec Govt and the Fed Govt...  Expect hell.  Pray for purgatory.  
> Rejoice if it takes less than 3 months.


In this particular case, the government is giving CN new land, and once
construction crews for the highway/interchange have moved on, segments
are opened for CN to bring its crews to install tracks, portals,
signals, track service road etc.

The main contract gives CN responsability to handle the telecom under
its tracks, so I assume that once CN is given access to the full length
of new right of way, it will coordinate with the various telecom
companies that rent space under its tracks to do the move.

The move is expected in summer 2018. (during next winter, the last
remaining elevated structures that block the new CN right of way will be
torn down, allowing CN to then finish the work starting in spring. (it
does not lay tracks in winter).

Northeast TWC/Spectrum contact?

[Edwin Pers]

Hi
Can someone from TWC/Spectrum’s northeast division please contact me off list? 
AS11351 for what it’s worth

About a week ago my modem dropped from 24 bonded channels at about -6dBmV to 19 
channels ranging from -9.30 to -21.30dBmV, and I started seeing very high 
latency and packetloss. I’ve also been seeing a lot of Lost MDD’s and RCS 
Partial’s in my event log.

Haven’t put a tdr down the customer side cabling yet but I doubt that’s the 
issue, it’s only a 25’ run and a visual inspection doesn’t show anything out of 
the ordinary.

Sorry for spamming the list, but every time I’ve called TWC customer support 
lines in the past I’ve been transferred between 5-8 people who each told me to 
reboot my modem and check the cables.

Thanks for your time,
Ed Pers

Re: Moving fibre trunks: interruptions?

[Alain Hebert]

Yeah,

Being somehow familiar with how things operate when it involve 
Quebec Govt and the Fed Govt...  Expect hell.  Pray for purgatory.  
Rejoice if it takes less than 3 months.


PS: At least we have very good, and dedicated, cabling crews.

=D.

But yeah, there is work being done to reduce the downtime to a 
manageable timeframe.  If not simply redundancy being added to allow for 
the time to splice that bad boy.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 09/01/17 14:44, Jay Hanke wrote:

I'd expect at least a couple of hours of outage while the cable is reconnected.

When doing the move on the live cable (assuming 1 cable). There will
be a splicing crew at each end of the move. They will then break a
tube or ribbon at a time and splice into the new cable.

Splicing unused portions of the cable and then moving patches is also
done. In my experience, it's much more common to resplice on the
existing strands.

A large cable will take quite a while to resplice, likely more than
just overnight depending on the size of the cable.

Jay

On Fri, Sep 1, 2017 at 1:32 PM, Jean-Francois Mezei
 wrote:

A large highway interchange is being rebuilt in Montréal (Turcot) and
this requires that the CN mainline tracks out of downtown be moved a few
hundred metres to the north for a couple of kilometres until it rejoins
the existing alignment.

Part of the contract involves the cost of moving the fibre trunks along
with the tracks. (old alignment will become commercial properties).


So they have new cable that goes through the new alignment and joins the
old one at both ends.  So they'll have hundreds of strands to splice.

When doing that type of work, how much downtime can be expected for each
strand?

Would they typically use patch panels in central offices to move a
customer to a spare strand while they splice their assigned strand to
use the new cable segment (and then move traffic back to that assigned
strand?). Or would they switch customers around to new strands and
update their documentation on which customer is on which strand?

Or do they do nothing at patch panels in COs and just take whatever time
it is needed to have crews at both ends of the work site splice each
strand at same time (I assume about 5 minutes outage for each strand?)


Would they normally involve the customer advising them of upcoming
outage? Would the folks working trackside be limited to overnight hours
to make outages less significant, or do they work around the clock ?

Re: Moving fibre trunks: interruptions?

[Rod Beck]

I don't think there is virtually any aerial in Europe. So given the cost 
difference why is virtually all fiber buried on this side of the Atlantic?



From: NANOG  on behalf of Jared Mauch 

Sent: Friday, September 1, 2017 9:37 PM
To: Michael Loftis
Cc: Nanog@nanog.org
Subject: Re: Moving fibre trunks: interruptions?



> On Sep 1, 2017, at 3:32 PM, Michael Loftis  wrote:
>
> If it is in the railroad RoW they may be restricted to daylight working
> only. Check with your provider or OSP crew.
>


Yup.  Railroad work is complex just because you have to coordinate with the 
railroad owner and they have to be onsite for all work.  The cost of going 
underground vs aerial is also astronomical in many cases.

- Jared

Re: Moving fibre trunks: interruptions?

[Jared Mauch]

> On Sep 1, 2017, at 3:32 PM, Michael Loftis  wrote:
> 
> If it is in the railroad RoW they may be restricted to daylight working
> only. Check with your provider or OSP crew.
> 


Yup.  Railroad work is complex just because you have to coordinate with the 
railroad owner and they have to be onsite for all work.  The cost of going 
underground vs aerial is also astronomical in many cases.  

- Jared

Re: Moving fibre trunks: interruptions?

[Eric Dugas]

Re: Moving fibre trunks: interruptions?

[Michael Loftis]

If it is in the railroad RoW they may be restricted to daylight working
only. Check with your provider or OSP crew.


-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: Moving fibre trunks: interruptions?

[Jay Hanke]

I'd expect at least a couple of hours of outage while the cable is reconnected.

When doing the move on the live cable (assuming 1 cable). There will
be a splicing crew at each end of the move. They will then break a
tube or ribbon at a time and splice into the new cable.

Splicing unused portions of the cable and then moving patches is also
done. In my experience, it's much more common to resplice on the
existing strands.

A large cable will take quite a while to resplice, likely more than
just overnight depending on the size of the cable.

Jay

On Fri, Sep 1, 2017 at 1:32 PM, Jean-Francois Mezei
 wrote:
>
> A large highway interchange is being rebuilt in Montréal (Turcot) and
> this requires that the CN mainline tracks out of downtown be moved a few
> hundred metres to the north for a couple of kilometres until it rejoins
> the existing alignment.
>
> Part of the contract involves the cost of moving the fibre trunks along
> with the tracks. (old alignment will become commercial properties).
>
>
> So they have new cable that goes through the new alignment and joins the
> old one at both ends.  So they'll have hundreds of strands to splice.
>
> When doing that type of work, how much downtime can be expected for each
> strand?
>
> Would they typically use patch panels in central offices to move a
> customer to a spare strand while they splice their assigned strand to
> use the new cable segment (and then move traffic back to that assigned
> strand?). Or would they switch customers around to new strands and
> update their documentation on which customer is on which strand?
>
> Or do they do nothing at patch panels in COs and just take whatever time
> it is needed to have crews at both ends of the work site splice each
> strand at same time (I assume about 5 minutes outage for each strand?)
>
>
> Would they normally involve the customer advising them of upcoming
> outage? Would the folks working trackside be limited to overnight hours
> to make outages less significant, or do they work around the clock ?
>

RE: Management softwares

[Jameson, Daniel]

Give this a look;  the webpage doesn't do it justice.  It Doesn't do 
billing/invoicing,  but does everything else on your list.

http://www.crestpt.com/fme-platforms.html

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of K MEKKAOUI
Sent: Friday, September 01, 2017 12:56 AM
To: nanog@nanog.org
Subject: Management softwares

Hi

 

We are a medium ISP. We are looking for Management software solutions. We are 
interested in finding a solution for billing, invoicing, scheduling, ticketing, 
provisioning and monitoring, Any suggestions or recommendations will be 
appreciated? We have been using multiple systems which do not communicate. Our 
objective is to use a single system or at least reduce the number of systems.

 

Thank you

 

KARIM M.

 

Moving fibre trunks: interruptions?

[Jean-Francois Mezei]

A large highway interchange is being rebuilt in Montréal (Turcot) and
this requires that the CN mainline tracks out of downtown be moved a few
hundred metres to the north for a couple of kilometres until it rejoins
the existing alignment.

Part of the contract involves the cost of moving the fibre trunks along
with the tracks. (old alignment will become commercial properties).


So they have new cable that goes through the new alignment and joins the
old one at both ends.  So they'll have hundreds of strands to splice.

When doing that type of work, how much downtime can be expected for each
strand?

Would they typically use patch panels in central offices to move a
customer to a spare strand while they splice their assigned strand to
use the new cable segment (and then move traffic back to that assigned
strand?). Or would they switch customers around to new strands and
update their documentation on which customer is on which strand?

Or do they do nothing at patch panels in COs and just take whatever time
it is needed to have crews at both ends of the work site splice each
strand at same time (I assume about 5 minutes outage for each strand?)


Would they normally involve the customer advising them of upcoming
outage? Would the folks working trackside be limited to overnight hours
to make outages less significant, or do they work around the clock ?

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
MENOG, BJNOG, SDNOG, CMNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 02 Sep, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  659343
Prefixes after maximum aggregation (per Origin AS):  257157
Deaggregation factor:  2.56
Unique aggregates announced (without unneeded subnets):  319791
Total ASes present in the Internet Routing Table: 58257
Prefixes per ASN: 11.32
Origin-only ASes present in the Internet Routing Table:   50359
Origin ASes announcing only one prefix:   22214
Transit ASes present in the Internet Routing Table:7898
Transit-only ASes present in the Internet Routing Table:227
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  56
Max AS path prepend of ASN ( 55644)  51
Prefixes from unregistered ASNs in the Routing Table:60
Number of instances of unregistered ASNs:63
Number of 32-bit ASNs allocated by the RIRs:  19864
Number of 32-bit ASNs visible in the Routing Table:   15650
Prefixes from 32-bit ASNs in the Routing Table:   63952
Number of bogon 32-bit ASNs visible in the Routing Table:25
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:372
Number of addresses announced to Internet:   2853141856
Equivalent to 170 /8s, 15 /16s and 125 /24s
Percentage of available address space announced:   77.1
Percentage of allocated address space announced:   77.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.7
Total number of prefixes smaller than registry allocations:  219558

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   179400
Total APNIC prefixes after maximum aggregation:   51947
APNIC Deaggregation factor:3.45
Prefixes being announced from the APNIC address blocks:  178284
Unique aggregates announced from the APNIC address blocks:74914
APNIC Region origin ASes present in the Internet Routing Table:8310
APNIC Prefixes per ASN:   21.45
APNIC Region origin ASes announcing only one prefix:   2314
APNIC Region transit ASes present in the Internet Routing Table:   1181
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 56
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3170
Number of APNIC addresses announced to Internet:  764936416
Equivalent to 45 /8s, 152 /16s and 0 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:201333
Total ARIN prefixes after maximum aggregation:95798
ARIN Deaggregation factor: 2.10
Prefixes being announced from the ARIN address blocks:   203102
Unique aggregates announced from the ARIN address blocks: 93704
ARIN Region origin ASes present in the Internet Routing Table:17971
ARIN Prefixes per ASN:11.30

Re: Management softwares

[Andrew Latham]

Long term developer on Odoo, could add some functionality via module for
provisioning

On Fri, Sep 1, 2017 at 1:56 AM, K MEKKAOUI  wrote:

> Hi
>
>
>
> We are a medium ISP. We are looking for Management software solutions. We
> are interested in finding a solution for billing, invoicing, scheduling,
> ticketing, provisioning and monitoring, Any suggestions or recommendations
> will be appreciated? We have been using multiple systems which do not
> communicate. Our objective is to use a single system or at least reduce the
> number of systems.
>
>
>
> Thank you
>
>
>
> KARIM M.
>
>
>
>


-- 
- Andrew "lathama" Latham lath...@gmail.com http://lathama.com
 -

NYC Metro Fiber Cut

[Lewis,Mitchell T.]

Anyone hear about any fiber cuts in the NYC Metro that happened yesterday ? I 
had a service outage yesterday (that was area wide) with a carrier who I will 
not name that was blamed on a fiber cut. 

Any further information that could be offered would be appreciated. 


Regards, 

Mitchell T. Lewis 

mle...@techcompute.net 


|203-816-0371 

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key 

Re: Max Prefix Out, was Re: Verizon 701 Route leak?

[Christopher Morrow]

On Fri, Sep 1, 2017 at 7:56 AM, Patrick W. Gilmore 
wrote:

> On Sep 1, 2017, at 5:26 AM, Randy Bush  wrote:
> >
> > i have 142 largish bgp customers, a large enough number that the number
> > of prefixes i receive from them varies annoyingly.  how do i reasonably
> > automate setting of my outbound prefix limit?
>
> First, it seems you know the inbound so automating the outbound is simple
> arithmetic.
>
>
I would have said the same... i ought to know high-water marks for your
inbound peer count(s), and can work out a +20% outbound...

you also probably can survey your outbound peerings and +20% some
high-water mark there, or make a 'meet in the middle' between the
inbound-math and outbound-math.


> But even if that is unruly, setting the outbound to, say, 300K or so would
> keep you from spilling a full table. Not perfect, but better than nothing.
>
> Orr, perhaps this feature is not for you?
>
> --
> TTFN,
> patrick
>
>

Re: Max Prefix Out, was Re: Verizon 701 Route leak?

[Patrick W. Gilmore]

On Sep 1, 2017, at 5:26 AM, Randy Bush  wrote:
> 
> i have 142 largish bgp customers, a large enough number that the number
> of prefixes i receive from them varies annoyingly.  how do i reasonably
> automate setting of my outbound prefix limit?

First, it seems you know the inbound so automating the outbound is simple 
arithmetic.

But even if that is unruly, setting the outbound to, say, 300K or so would keep 
you from spilling a full table. Not perfect, but better than nothing.

Orr, perhaps this feature is not for you?

-- 
TTFN,
patrick

Re: Max Prefix Out, was Re: Verizon 701 Route leak?

[Randy Bush]

i have 142 largish bgp customers, a large enough number that the number
of prefixes i receive from them varies annoyingly.  how do i reasonably
automate setting of my outbound prefix limit?

randy

Re: BGP Optimizers

[Bjørn Mork]

Job Snijders  writes:

> Using a BGP
> optimizer is essentially trading a degree of risk to society for the
> purpose of saving a few bucks or milliseconds. It is basically saying:
> "The optimizer helps me, but may hurt others, and I am fine with that".

People drive SUVs.


Bjørn

Management softwares

[K MEKKAOUI]

Hi

 

We are a medium ISP. We are looking for Management software solutions. We
are interested in finding a solution for billing, invoicing, scheduling,
ticketing, provisioning and monitoring, Any suggestions or recommendations
will be appreciated? We have been using multiple systems which do not
communicate. Our objective is to use a single system or at least reduce the
number of systems.

 

Thank you

 

KARIM M.