Re: MPLS Reference Designs

[Mark Tinka]

On 27/May/16 20:36, Alain Hebert wrote:

>
> ( Obviously interoperability is just ridiculous when talking MPLS... )

Why would you think so?

>
> Too many times we ended up finding boxes that look the part but are
> limited in such a way to accomplish only the task that fit the vendor
> own MPLS paradigm.
> ( TLDR: Make us spend more $$$ than needed =D long gone is the
> swiss-knife concept )

What platforms have you worked on before that have caused you grief?

Mark.

Re: Preferring RSVP for only one l2circuit.

[Mark Tinka]

On 27/May/16 15:46, Mohamed Kamal wrote:

> tried this Timothy, and the RSVP didn't appear in the inet.3. Failed to work!

Best option is to create a separate Loopback interface on each router,
and use that to signal the RSVP tunnels.

It's the only way to keep your LDP and RSVP tunnels from mingling with
each other for EoMPLS circuits you want to nail on a given path.

Mark.

MPLS Reference Designs

[Alain Hebert]

Hi,
   
( it might be a bit much to look for that here, but meh its Friday )


Goals

Usual Multi-point L2 services, with L3 path(s) to the Internet
-and/or- inter-site L3 routing (VRF per customer).

This is a simple project involving upgrading a L2 MAN into and more
flexible and isolated (MACs wise) MPLS infrastructure.


Road blocks

We're wasting way too much time with sales rep/engineer, for then,
ending up finding some irrelevant limitation after having spent ~20h of
man power looking at their offering.


Question

( Obviously interoperability is just ridiculous when talking MPLS... )

Thus I'm looking for reference designs from different vendor viewpoint.

Simple enough, but I would like to put the "make/model of the actual
device capable" of doing the function at the P, PE and CE level of their
design.

Too many times we ended up finding boxes that look the part but are
limited in such a way to accomplish only the task that fit the vendor
own MPLS paradigm.
( TLDR: Make us spend more $$$ than needed =D long gone is the
swiss-knife concept )


Offlist answers are fine.

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, AusNOG, SANOG, PacNOG,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG 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 28 May, 2016

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

Analysis Summary


BGP routing table entries examined:  594503
Prefixes after maximum aggregation (per Origin AS):  217631
Deaggregation factor:  2.73
Unique aggregates announced (without unneeded subnets):  291513
Total ASes present in the Internet Routing Table: 53890
Prefixes per ASN: 11.03
Origin-only ASes present in the Internet Routing Table:   36576
Origin ASes announcing only one prefix:   15650
Transit ASes present in the Internet Routing Table:6452
Transit-only ASes present in the Internet Routing Table:170
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  54
Max AS path prepend of ASN ( 55644)  51
Prefixes from unregistered ASNs in the Routing Table:  1029
Unregistered ASNs in the Routing Table: 368
Number of 32-bit ASNs allocated by the RIRs:  14035
Number of 32-bit ASNs visible in the Routing Table:   10862
Prefixes from 32-bit ASNs in the Routing Table:   42481
Number of bogon 32-bit ASNs visible in the Routing Table: 7
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:362
Number of addresses announced to Internet:   2808989828
Equivalent to 167 /8s, 109 /16s and 200 /24s
Percentage of available address space announced:   75.9
Percentage of allocated address space announced:   75.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.2
Total number of prefixes smaller than registry allocations:  193849

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   152413
Total APNIC prefixes after maximum aggregation:   42506
APNIC Deaggregation factor:3.59
Prefixes being announced from the APNIC address blocks:  163652
Unique aggregates announced from the APNIC address blocks:67122
APNIC Region origin ASes present in the Internet Routing Table:5193
APNIC Prefixes per ASN:   31.51
APNIC Region origin ASes announcing only one prefix:   1187
APNIC Region transit ASes present in the Internet Routing Table:919
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2096
Number of APNIC addresses announced to Internet:  754412868
Equivalent to 44 /8s, 247 /16s and 109 /24s
Percentage of available APNIC address space announced: 88.2

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, 131072-135580
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:181275
Total ARIN prefixes after maximum aggregation:89149
ARIN Deaggregation factor: 2.03
Prefixes being announced from the ARIN address blocks:   186737
Unique aggregates announced from the ARIN address blocks: 88167
ARIN Region origin ASes present in the Internet Routing Table:16356

Global/distributed IXP operators?

[Daniel Rohan]

If there are any operators working at distributed/global IXPs and wouldn't
mind having their brains picked regarding design questions, would you make
yourselves known to me (on or off-list is fine).

Thanks,

Dan

Re: LLDP via SNMP

[Leo Bicknell]

In a message written on Thu, May 26, 2016 at 10:16:21PM +0300, Saku Ytti wrote:
> LLDP standard itself is in my non-humble opinion broken. There are no
> guarantees that standard compliant LLDP will produce useful data.

Including inside a particular vendor's own implementation.  For
instance some junipers advertise the interface name (ge-0/0/0) and
some the description ("To Bob's ISP") for the "interface name" field
in the CLI.  So depending on the platform and version of code you
get totally different information from "show lldp neighbors".

It really makes it difficult to consume the data by script.  Lots
of special cases.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgpZ7GiEeRfO8.pgp
Description: PGP signature

Re: Preferring RSVP for only one l2circuit.

[Mohamed Kamal]

tried this Timothy, and the RSVP didn't appear in the inet.3. Failed to work!

- Original Message -
From: "Timothy Creswick" 
To: "Mohamed Kamal" , nanog@nanog.org
Sent: Friday, May 27, 2016 3:30:08 PM
Subject: RE: Preferring RSVP for only one l2circuit.

> I have increased the preference of the RSVP, and it has been taken out of the 
> inet.3, so the l2circuit didn't prefer
> the RSVP path anymore!

Just add "no-install-to-address" to the LSP.

RE: Preferring RSVP for only one l2circuit.

[Timothy Creswick]

> I have increased the preference of the RSVP, and it has been taken out of the 
> inet.3, so the l2circuit didn't prefer
> the RSVP path anymore!

Just add "no-install-to-address" to the LSP.

Preferring RSVP for only one l2circuit.

[Mohamed Kamal]

I have a full-mesh LDP LSPs between my MX-104 routers, however, between two 
specific routers and on the same loopbacks I configured RSVP LSP to be used as 
the transport for only one l2circuit and no more. The problem is, when the RSVP 
gets signaled, it gets installed in the inet.3 and gets preferred over any 
other LDP LSP. So all the traffic destined to RSVP tail-end will prefer the 
RSVP over the LDP.

I have increased the preference of the RSVP, and it has been taken out of the 
inet.3, so the l2circuit didn't prefer the RSVP path anymore!

Do anyone has a working configuration for this? or should I configured another 
loopback address on every pair of routers for the RSVP signalling?

-- mk

Re: NANOG Digest, Vol 100, Issue 26

[mark]

X rj45 3m × 4



Tks

mark






On Fri, May 27, 2016 at 5:00 AM -0700,  wrote:










Send NANOG mailing list submissions to
nanog@nanog.org

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
nanog-requ...@nanog.org

You can reach the person managing the list at
nanog-ow...@nanog.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."


Today's Topics:

   1. Frontier routing issue? (Matt Hoppes)
   2. AS 714/6185 IX Peering (Graham Johnston)
   3. LLDP via SNMP (Avi Freedman)
   4. Re: LLDP via SNMP (Spencer Ryan)
   5. RE: LLDP via SNMP (Michael Hare)
   6. Re: LLDP via SNMP (Jeff Gehlbach)
   7. Re: LLDP via SNMP (Saku Ytti)
   8. Re: Network traffic simulator (David)
   9. Re: Network traffic simulator (Jim Greene)
  10. Re: Network traffic simulator (Tom Smyth)
  11. VOIP Monitoring Solution (segs)
  12. Re: Frontier routing issue? (Gambill, Nate)
  13. Re: LLDP via SNMP (Fedor Sumkin)
  14. GRE on ASR9001 (Rukka Pal)
  15. Re: GRE on ASR9001 (Saku Ytti)
  16. Re: GRE on ASR9001 (Rukka Pal)
  17. Re: GRE on ASR9001 (Saku Ytti)


--

Message: 1
Date: Thu, 26 May 2016 08:22:18 -0400
From: Matt Hoppes 
To: nanog@nanog.org
Subject: Frontier routing issue?
Message-ID:
<40ad53f9-beb3-4930-9603-381de1901...@rivervalleyinternet.net>
Content-Type: text/plain;   charset=us-ascii

Is anyone else in the north east seeing routing issues on frontier right now?  
Unable to get to many websites. Trace route seems to complete fine but you 
can't bring up any content. 


--

Message: 2
Date: Thu, 26 May 2016 13:11:35 +
From: Graham Johnston 
To: NANOG 
Subject: AS 714/6185 IX Peering
Message-ID: <82c0ce81789fe64d8f4d152631918297b14...@msg6.westman.int>
Content-Type: text/plain; charset="us-ascii"

Is there anyone from AS 714/6185 that can reach out to me, AS 19016, to try and 
get traffic from your network to come to me via your Equinix IX connection 
instead of a transit connections.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com
P think green; don't print this email.



--

Message: 3
Date: Thu, 26 May 2016 10:47:15 -0400 (EDT)
From: freed...@freedman.net (Avi Freedman)
To: nanog@nanog.org
Subject: LLDP via SNMP
Message-ID: <20160526144715.aa0d655006...@freedman.net>
Content-Type: text/plain; charset="US-ASCII"


Have had the question come up a few times, so I wanted to poll the community to 
see...

For those who are monitoring LLDP, how have you found the SNMP MIB support 
support for it on Juniper, Cisco, Brocade, Arista, and others?

Wondering if you've needed to resort to CLI scraping or APIs to get the data?

Thanks,

Avi Freedman
CEO, Kentik



--

Message: 4
Date: Thu, 26 May 2016 10:51:03 -0400
From: Spencer Ryan 
To: a...@kentik.com
Cc: "North American Network Operators' Group" 
Subject: Re: LLDP via SNMP
Message-ID:

Content-Type: text/plain; charset=UTF-8

We use Observium for most of our SNMP monitoring, and it correctly pulls
LLDP and CDP data from all of our Cisco and Arista gear.


*Spencer Ryan* | Senior Systems Administrator | sr...@arbor.net
*Arbor Networks*
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

On Thu, May 26, 2016 at 10:47 AM, Avi Freedman 
wrote:

>
> Have had the question come up a few times, so I wanted to poll the
> community to see...
>
> For those who are monitoring LLDP, how have you found the SNMP MIB support
> support for it on Juniper, Cisco, Brocade, Arista, and others?
>
> Wondering if you've needed to resort to CLI scraping or APIs to get the
> data?
>
> Thanks,
>
> Avi Freedman
> CEO, Kentik
>
>


--

Message: 5
Date: Thu, 26 May 2016 15:53:53 +
From: Michael Hare 
To: Spencer Ryan , "a...@kentik.com" 
Cc: North American Network Operators' Group 
Subject: RE: LLDP via SNMP
Message-ID:


Content-Type: text/plain; CHARSET=US-ASCII

My experience with Juniper has been mixed, experience with 12.X and 13.X made 
me wonder if I had a poor understanding of how to do a proper decode or if 
Juniper's implementation itself had issues as I would often get incomplete 
results.

We've now grab over XML and have been pleased with that choice to the point I 
no longer see it as a "resort" but the most efficient way for us to move 
forward.  I used to open JTAC cases on each SNMP problem I'd come across [ CoS, 
mac-accounting ] and it generally wasn't a good use of our time.

-Michael

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Spencer Ryan
Sent: Thursday, May 26, 2016 9:51 AM
To: a...@kentik.com
Cc: North American Network 

Re: AS 714/6185 IX Peering

[Ren Provo]

Third time should be the charm?
(Thanks Job!)

Cheers! -Ren
Sent from my iPhone 6S Plus

> On May 27, 2016, at 11:36 AM, Ren Provo  wrote:
> 
> Several folks have written to ensure I spotted this during RIPE.  Indeed, the 
> reminder to engage contacts posted at http://as714.peeringdb.com - namely 
> peering-...@apple.com - was sent.  Y'all didn't see it because it was sent 
> from an email that is not registered on this list.  Spotted the rejection 
> later.  Hence take two today and a confirmation Graham's concern has been 
> noted within Apple.
> 
> Cheers! -Ren
> Sent from my iPhone 6S Plus
> 
>> On May 26, 2016, at 3:11 PM, Graham Johnston  
>> wrote:
>> 
>> Is there anyone from AS 714/6185 that can reach out to me, AS 19016, to try 
>> and get traffic from your network to come to me via your Equinix IX 
>> connection instead of a transit connections.
>> 
>> Graham Johnston
>> Network Planner
>> Westman Communications Group
>> 204.717.2829
>> johnst...@westmancom.com
>> P think green; don't print this email.
>> 

Re: GRE on ASR9001

[Saku Ytti]

Original work. But I lied, I read my notes and performance was capped
at 12Mpps, after which counters which indicate NPU starvation start to
increase.

On 27 May 2016 at 14:04, Rukka Pal  wrote:
> Thanks! May I know where you found this information? Did you calculate this
> using "BRKSPG-2904" or is this a result of your own testing?
>
> On Fri, May 27, 2016 at 11:40 AM, Saku Ytti  wrote:
>>
>> On 27 May 2016 at 11:28, Rukka Pal  wrote:
>>
>> > I believe this should present no significant problems to the ASR9001,
>> > just
>> > wanted to get a confirmation. Thanks!
>>
>> Performance will be about 15Mpps per NPU.
>>
>> --
>>   ++ytti
>
>



-- 
  ++ytti

Re: GRE on ASR9001

[Rukka Pal]

Thanks! May I know where you found this information? Did you calculate this
using "BRKSPG-2904" or is this a result of your own testing?

On Fri, May 27, 2016 at 11:40 AM, Saku Ytti  wrote:

> On 27 May 2016 at 11:28, Rukka Pal  wrote:
>
> > I believe this should present no significant problems to the ASR9001,
> just
> > wanted to get a confirmation. Thanks!
>
> Performance will be about 15Mpps per NPU.
>
> --
>   ++ytti
>

Re: GRE on ASR9001

[Saku Ytti]

On 27 May 2016 at 11:28, Rukka Pal  wrote:

> I believe this should present no significant problems to the ASR9001, just
> wanted to get a confirmation. Thanks!

Performance will be about 15Mpps per NPU.

-- 
  ++ytti

GRE on ASR9001

[Rukka Pal]

Anyone here running GRE tunnels between ASR9001series? I am planning to
connect some special-purpose remote sites to my core infra using
unencrypted GRE tunnels and OSPF routing. The estimated bandwidth
requirements are between 500Mbps and several Gbps. I am not planning to use
MPAs, instead the fixed 10G ports

I believe this should present no significant problems to the ASR9001, just
wanted to get a confirmation. Thanks!

Re: LLDP via SNMP

[Fedor Sumkin]

Most of the vendors support standard LLDP-MIB::lldpMIB mib(i.e. Cisco,
Huawei, Juniper, Arista, EdgeCore..).
Only few of them have vendor-specific Mibs(Alcatel, a3com-huawei, Motorola
WiNG).

On Thu, May 26, 2016 at 5:51 PM, Spencer Ryan  wrote:

> We use Observium for most of our SNMP monitoring, and it correctly pulls
> LLDP and CDP data from all of our Cisco and Arista gear.
>
>
> *Spencer Ryan* | Senior Systems Administrator | sr...@arbor.net
> *Arbor Networks*
> +1.734.794.5033 (d) | +1.734.846.2053 (m)
> www.arbornetworks.com
>
> On Thu, May 26, 2016 at 10:47 AM, Avi Freedman 
> wrote:
>
> >
> > Have had the question come up a few times, so I wanted to poll the
> > community to see...
> >
> > For those who are monitoring LLDP, how have you found the SNMP MIB
> support
> > support for it on Juniper, Cisco, Brocade, Arista, and others?
> >
> > Wondering if you've needed to resort to CLI scraping or APIs to get the
> > data?
> >
> > Thanks,
> >
> > Avi Freedman
> > CEO, Kentik
> >
> >
>

Re: Frontier routing issue?

[Gambill, Nate]

Matt,

Some of our sites in Michigan are experiencing similar outages.  I
understand that they are actively working to correct the issues.

Later,


-- 
Nate Gambill  *STM*
Network Engineer
Information Services
St. Joseph County Schools
62445 Shimmel Road
Centreville, MI  49032-9527
269.467.5315

-- 

CONFIDENTIALITY NOTICE:  This message and all attachments transmitted with 
it may contain legally privileged and confidential information intended 
solely for the use of the addressee. If the reader of this message is not 
the intended recipient, you are hereby notified that any reading, 
dissemination, distribution, copying, or other use of this message or its 
attachments is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately and delete this message and all 
copies and backups.

VOIP Monitoring Solution

[segs]

Hi All,

I Am on the lookout for a solution that can monitor IP phones in use on the
network.

 The solution should have

 -- a very intuitive GUI

 -- detailed reporting mechanism.

 --- send basic commands like restart to the phones

  monitor number of active calls on the call manager

  monitor status of trunks > --- can show visual details of two ip
phones in an active call

 --- show details of call quality.

The environment in question is using Cisco Call manager BE7k and cisco Ip
phones.

Thanks in advance.

Segun Rufai

Re: Network traffic simulator

[Tom Smyth]

Hi Michell,

the CCR series from MT is probably is as cost effictive a 10G+ Capable
system that you can use to generate and measure the packet troughput of a
core router under test... check out traffic generator
http://wiki.mikrotik.com/wiki/Manual:Tools/Traffic_Generator

you can generate small packets / large packets ... simulate TCP throughput
and play wireshark pcap files.. .. it is prety comprehensive...  somre of
the configuration syntax is not that intutive ... but its worakable...
any system that I have tested with traffic generator vs  an expensive
calibrated tests the results were always corelating between MT traffic
generator and the expensive testers with an error margin of 1-2 %
I hope that helps...

Peace out

On Tue, May 24, 2016 at 1:17 PM, Mitchell Lewis 
wrote:

> Hi,I am looking to validate the performance specs of a core router. I am
> looking for a network traffic simulator which can simulate 40 gbps of
> traffic. I am looking for a simulator with sfp+ ports.
> I am interested in any input as to brands to look at, build one myself etc.
> Thanks,Mitchell




-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
-
PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL
This email contains information which may be confidential or privileged.
The information is intended solely for the use of the individual or entity
named above.  If you are not the intended recipient, be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic
transmission in error, please notify me by telephone or by electronic mail
immediately. Any opinions expressed are those of the author, not the
company's  .This email does not constitute either offer or acceptance of
any contractually binding agreement. Such offer or acceptance must be
communicated in
writing. You are requested to carry out your own virus check before opening
any attachment. Thomas Smyth accepts no liability for any loss or damage
which may be caused by malicious software or attachments.

Re: Network traffic simulator

[Jim Greene]

 

Spirent can do this, Have worked with them at 100G. 

On 2016-05-24 08:17, Mitchell Lewis wrote: 

> Hi,I am looking to validate the performance specs of a core router. I am 
> looking for a network traffic simulator which can simulate 40 gbps of 
> traffic. I am looking for a simulator with sfp+ ports.
> I am interested in any input as to brands to look at, build one myself etc.
> Thanks,Mitchell

-- 

Jim Greene
Lockheed Martin
AFRL/RCM
2435 Fifth St
WPAFB, OH. 45433
937-656-5692
greenejk@afrl.hpc.mil 

Re: Network traffic simulator

[David]

On 2016-05-24 6:17 AM, Mitchell Lewis wrote:

Hi,I am looking to validate the performance specs of a core router. I am 
looking for a network traffic simulator which can simulate 40 gbps of traffic. 
I am looking for a simulator with sfp+ ports.
I am interested in any input as to brands to look at, build one myself etc.
Thanks,Mitchell




SPIRENT offers such products (along with Ixia already mentioned).