Re: Multiple VRFs from provider, IP addressing

[Hugo Slabbert]

On Thu 2016-Apr-28 05:22:26 +, Craig Rivenburg  wrote:


Hi Nanog...looking for some advice.  I have a customer who has a large
network...approximately 130 sites across the US.  Each site is fed via two
providers, via two Separate CE Routers.  It's a  L3-VPN service.  Each
provider currently provides connectivity for 6 VRFs, each over a single
service multiplexed UNI.  Ie...there are 6 dot1q interfaces facing each
provider, each sub-interface is in its own VRF.

The network is going through a redesign, and one of my tasks is to
consolidate and "streamline" IP addressing.

Looking for a sanity check...I have this idea to make every dot1q
sub-interface facing the provider the same point-to-point subnet.
Specifically, facing a single provider, I want to use the same /30 subnet
for all 6 VRFs.  I'd use a separate /30 for each of the CE routers per
site, so I could go from 12 /30s to 2 per site.  I should note, PE-CE
protocol is BGP, and behind the CE routers is a small iBGP network.

I know it's technically possible to configure the OPs this way and under
normal circumstances its fine.  But, in this case, there is a whole lot of
route leaking / cross target exchanges happening between VRFs.  I still
think it's okay...but can anyone think of a a failure mode that I may not
have?  Is what I'm thinking common practice?  Is there a best practice for
this sort of thing?


6 VRFs per site, across the board, with extensive leaking between VRFs.  At 
the risk of second-guessing a design with very little insight into whatever 
requirements are going on behind the curtain: what's the point of all of 
those VRFs, especially if you're leaking routes back and forth fairly 
frequently/commonly?  Are you using routing policy to split security zones 
or something?


For the IP addressing "streamlining": I fail to see the benefit of having 
the same /30 across each dot1q sub-interface.  If anything, this seems to 
confuse things and complicate troubleshooting (`ping no-resolve 
 routing-instance `).  If you're dealing with apparently complex route leaking between 
VRFs, I could see the fun of fat fingering your exports/imports and having 
the shared touchdown /30 of the local or remote sites leak into the wrong 
VRF(s).


What problem are you trying to solve?  Are you short on IPs for these 
touchdowns?  Are they at a position in the topology where you could just 
swing them over to RFC1918 space?  Or drop them to /31s (since they are ptp 
on dot1q sub-interfaces anyway) and half your IP allocation requirement for 
the touchdowns if that's the issue?



Thanks!


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: PGP signature

Re: Arista Routing Solutions

[Ryan Woolley]

On Thu, Apr 28, 2016 at 1:33 AM, lincoln dale  wrote:

> On Wed, Apr 27, 2016 at 4:41 PM, Peter Kranz 
> wrote:
>
>> Curious if you have any thoughts on the longevity of the 7500R
>> and 7280R survival's with IPv4 full tables? How full are you seeing the
>> TCAM getting today (I'm assuming they are doing some form of selective
>> download)? And if we are currently adding 100k/routes a year, how much
>> longer will it last?
>
> [...]
>
> One could ask Geoff Huston where he thinks combined IPv4+v6 will exceed 1M
> entries but I would expect it to be many years away based on
> http://bgp.potaroo.net/ and we'd welcome discussions about if it you want
> to know our opinion [*] on how we're doing it will scale.  What we're doing
> doesn't explode at 1M, there's headroom in it hence why we say "1M+". Again
> we're happy to talk about it, just ask your friendly arista person and if
> you don't know who to ask, ask me and i'll put you in touch with the right
> folks.
>

Peter, I'd point you to https://labs.apnic.net/?p=767 for more historical
detail and a table with some (recent) predictions.  The summary is that the
rate is mostly linear at around 10% per year and even 1MM routes lasts
quite comfortably beyond 5 years at the current growth rate.  I am not
particularly worried about the table growth rate (or Moore's law) changing
dramatically.

With respect to the utilization of the hardware, our setup is basically the
same as Lincoln's scenario #1 and so utilization looks about the same, on
both platforms.

Multiple VRFs from provider, IP addressing

[Craig Rivenburg]

Hi Nanog...looking for some advice.  I have a customer who has a large
network...approximately 130 sites across the US.  Each site is fed via two
providers, via two Separate CE Routers.  It's a  L3-VPN service.  Each
provider currently provides connectivity for 6 VRFs, each over a single
service multiplexed UNI.  Ie...there are 6 dot1q interfaces facing each
provider, each sub-interface is in its own VRF.

The network is going through a redesign, and one of my tasks is to
consolidate and "streamline" IP addressing.

Looking for a sanity check...I have this idea to make every dot1q
sub-interface facing the provider the same point-to-point subnet.
Specifically, facing a single provider, I want to use the same /30 subnet
for all 6 VRFs.  I'd use a separate /30 for each of the CE routers per
site, so I could go from 12 /30s to 2 per site.  I should note, PE-CE
protocol is BGP, and behind the CE routers is a small iBGP network.

I know it's technically possible to configure the OPs this way and under
normal circumstances its fine.  But, in this case, there is a whole lot of
route leaking / cross target exchanges happening between VRFs.  I still
think it's okay...but can anyone think of a a failure mode that I may not
have?  Is what I'm thinking common practice?  Is there a best practice for
this sort of thing?

Thanks!

Re: carrier grade fax boards?

[Pete Mundy]

> On 28/04/2016, at 6:36 pm, valdis.kletni...@vt.edu wrote:
> 
> On Thu, 28 Apr 2016 04:30:23 -, Ryan Finnesey said:
>> I was wondering if anyone had any recommendations on carrier grade fax boards
>> that are SIP based?
> 
> What would "carrier grade" even *mean* for a fax board?

I took it to mean "expensive". :)



smime.p7s
Description: S/MIME cryptographic signature

RE: carrier grade fax boards?

[Colin Bodor]

If looking for old school industrial faxing capabilities then maybe something 
like:

https://www.dialogic.com/en/products/fax-boards-and-software/fax-boards.aspx

I have a client who used to us them with a custom inbound dictation application 
and multiple PRIs to feed them (not the fax board, but dialogic) worked well. 
Not cheap for licensing...

-C

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hale
Sent: Thursday, April 28, 2016 11:14 AM
To: Robert Jacobs 
Cc: nanog@nanog.org
Subject: Re: carrier grade fax boards?

Not really fax board, but there are ATA (analog telephony (?)
adapters) that handle fax very well (and others that just suck at it).

Certain versions of the Cisco ATA 180 series worked really well even over 
satellite; others were terrible.  It's somewhat of a hit or miss area.

How many users are you supporting?  If you're looking for a device to just put 
on-prem at a customer site to handle fax, those ATAs are pretty easy to find.

On Thu, Apr 28, 2016 at 8:06 AM, Robert Jacobs  wrote:
> I would not consider any fax board "carrier grade" that uses sip  sip to 
> pots for faxes is still hit and miss.
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of 
> valdis.kletni...@vt.edu
> Sent: Thursday, April 28, 2016 1:36 AM
> To: Ryan Finnesey 
> Cc: nanog@nanog.org
> Subject: Re: carrier grade fax boards?
>
> On Thu, 28 Apr 2016 04:30:23 -, Ryan Finnesey said:
>> I was wondering if anyone had any recommendations on carrier grade 
>> fax boards that are SIP based?
>
> What would "carrier grade" even *mean* for a fax board?



--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: Network Weathermap

[James Bensley]

On 28 April 2016 at 20:33, Peter Phaal  wrote:
> Many drawing tools support SVG as a file export format. Exporting or
> converting the map to SVG format allows the map attributes (link
> colors, widths, etc) to be modulated using JavaScript embedded in the
> web page.
>
> As an example, the following SC15 weathermap was created by converting
> a PDF diagram of the network into an SVG file:
>
> http://blog.sflow.com/2015/11/sc15-live-real-time-weathermap.html
>
> The code is on GitHub and it wouldn't be hard to re-purpose:
>
> https://github.com/pphaal/sc15-weather
>
> The ESnet weathermap is very cool and they have open sourced the code:
>
> https://my.es.net/
> http://www.hpcwire.com/2015/10/05/esnet-releases-software-for-building-interactive-network-portals/

https://github.com/esnet/react-timeseries-charts/
https://github.com/esnet/react-network-diagrams/

Fwoor!

Sorry Weathermap, you've been usurped! I think I'll write a wrapper in
PHP to pull the data from RRDs and feed into that.

Cheers,
James.

Re: Network Weathermap

[James Bensley]

On 28 April 2016 at 19:41, Ishmael Rufus  wrote:
> You could probably build the converter in PHP and make it a plugin of
> weathermap.
>
> You kids and your Python :)

I would prefer it to be PHP actually, people keep moaning at me for
using PHP, which I am much more fluent in. However if it were in PHP
it comes with the advantage of being in the same language the the rest
 of Cacti (more or less).

Cheers,
James.

Re: Network Weathermap

[Peter Phaal]

Many drawing tools support SVG as a file export format. Exporting or
converting the map to SVG format allows the map attributes (link
colors, widths, etc) to be modulated using JavaScript embedded in the
web page.

As an example, the following SC15 weathermap was created by converting
a PDF diagram of the network into an SVG file:

http://blog.sflow.com/2015/11/sc15-live-real-time-weathermap.html

The code is on GitHub and it wouldn't be hard to re-purpose:

https://github.com/pphaal/sc15-weather

The ESnet weathermap is very cool and they have open sourced the code:

https://my.es.net/
http://www.hpcwire.com/2015/10/05/esnet-releases-software-for-building-interactive-network-portals/

On Thu, Apr 28, 2016 at 11:32 AM, James Bensley  wrote:
> Hi all,
>
> I know its been a while since I posted this thread, I've been swamped.
> Finally I'm getting time to look back at this. I think I had 0 on-list
> replies and about 10 off-list private replies, so clearly others are having
> the same problem but not speaking openly about it.
>
> There were two main themes in the off list replies;
>
> 1. Several people are drawing in a tool like Visio and then importing the
> picture as a background to the weathermap plugin and adding the links and
> nodes over the top.
>
> 2. A couple of people were drawing in something else other than Visio that
> would spit out files containing objects and coordinates and then had
> written scripts to convert those coordinates to Weathermap plugin file
> format.
>
> Method 1 is OK, I really want it to be less hassle than that so 2 seems
> like the best idea. Only one person would share their conversion script
> with me briefly on PasteBin then it expired and it wasn't for Visio format
> files, so I didn't save it.
>
> Having a quick play in Visio just now the files are saved as XML formatted
> X/Y axis values. Bit of a Python novice but I'm thinking I could basically
> ingest a Visio file and parse the the XML and then iterate over it
> converting each "object" into weathermap syntax.
>
> That isn't too difficult however for the maps to be any good I need to
> think about the "via" feature for links in Weathermap to map them  more
> clearly if they cross over each other. There might still also be a lot of
> hackery when it comes to mapping the imported nodes and links to actual
> ones in Cacti. It might be that you have to match all the imported nodes
> and links to RRDs the first time you import the diagram then on all future
> imports just new links and nodes.
>
> Before I commit the time to this, has anyone done this already or is anyone
> a absolute Lord of Python who wants to do it quicker than I can do it? :)
>
> Cheers,
> James.

RE: Arista Routing Solutions

[Timothy Creswick]

> Just wanted to interject, the port density of the Arista switches is quite
> impressive, especially considering the price point they're at.

Not in response to any point specifically, but the major issue which stopped us 
buying Arista a few months ago was the rather out-dated attitude to 3rd party 
transceiver support.

I'm sure there are plenty of people running Arista on 3rd party optics, but all 
the noises that were being made by the sales and technical guys suggested that 
we could find ourselves abandoned by their support or a policy change in the 
future. 

I don't fundamentally have an issue with vendor optics, except when they are 
excessively priced. One or two vendors will actually sell their 10Gbps optics 
at a price that's pretty hard to refuse, given that it's all supported. The 
same couldn't be said in this case.

Additionally, the insistence that we would have to buy a "small number" of 
Arista optics with each device for testing purposes gets old very quickly. 
Again, I could get on-board with this if it's just for troubleshooting, but not 
when these additional optics suddenly add 15% to the overall buy price of each 
switch. At that point, other vendors are firmly back on the table.

YMMV of course, I suspect especially if you're buying 100s of boxes.

T

Re: Network Weathermap

[Ishmael Rufus]

You could probably build the converter in PHP and make it a plugin of
weathermap.

You kids and your Python :)

On Thu, Apr 28, 2016 at 1:32 PM, James Bensley  wrote:

> Hi all,
>
> I know its been a while since I posted this thread, I've been swamped.
> Finally I'm getting time to look back at this. I think I had 0 on-list
> replies and about 10 off-list private replies, so clearly others are having
> the same problem but not speaking openly about it.
>
> There were two main themes in the off list replies;
>
> 1. Several people are drawing in a tool like Visio and then importing the
> picture as a background to the weathermap plugin and adding the links and
> nodes over the top.
>
> 2. A couple of people were drawing in something else other than Visio that
> would spit out files containing objects and coordinates and then had
> written scripts to convert those coordinates to Weathermap plugin file
> format.
>
> Method 1 is OK, I really want it to be less hassle than that so 2 seems
> like the best idea. Only one person would share their conversion script
> with me briefly on PasteBin then it expired and it wasn't for Visio format
> files, so I didn't save it.
>
> Having a quick play in Visio just now the files are saved as XML formatted
> X/Y axis values. Bit of a Python novice but I'm thinking I could basically
> ingest a Visio file and parse the the XML and then iterate over it
> converting each "object" into weathermap syntax.
>
> That isn't too difficult however for the maps to be any good I need to
> think about the "via" feature for links in Weathermap to map them  more
> clearly if they cross over each other. There might still also be a lot of
> hackery when it comes to mapping the imported nodes and links to actual
> ones in Cacti. It might be that you have to match all the imported nodes
> and links to RRDs the first time you import the diagram then on all future
> imports just new links and nodes.
>
> Before I commit the time to this, has anyone done this already or is anyone
> a absolute Lord of Python who wants to do it quicker than I can do it? :)
>
> Cheers,
> James.
>

Re: Network Weathermap

[James Bensley]

Hi all,

I know its been a while since I posted this thread, I've been swamped.
Finally I'm getting time to look back at this. I think I had 0 on-list
replies and about 10 off-list private replies, so clearly others are having
the same problem but not speaking openly about it.

There were two main themes in the off list replies;

1. Several people are drawing in a tool like Visio and then importing the
picture as a background to the weathermap plugin and adding the links and
nodes over the top.

2. A couple of people were drawing in something else other than Visio that
would spit out files containing objects and coordinates and then had
written scripts to convert those coordinates to Weathermap plugin file
format.

Method 1 is OK, I really want it to be less hassle than that so 2 seems
like the best idea. Only one person would share their conversion script
with me briefly on PasteBin then it expired and it wasn't for Visio format
files, so I didn't save it.

Having a quick play in Visio just now the files are saved as XML formatted
X/Y axis values. Bit of a Python novice but I'm thinking I could basically
ingest a Visio file and parse the the XML and then iterate over it
converting each "object" into weathermap syntax.

That isn't too difficult however for the maps to be any good I need to
think about the "via" feature for links in Weathermap to map them  more
clearly if they cross over each other. There might still also be a lot of
hackery when it comes to mapping the imported nodes and links to actual
ones in Cacti. It might be that you have to match all the imported nodes
and links to RRDs the first time you import the diagram then on all future
imports just new links and nodes.

Before I commit the time to this, has anyone done this already or is anyone
a absolute Lord of Python who wants to do it quicker than I can do it? :)

Cheers,
James.

Re: carrier grade fax boards?

[Mike Hale]

Not really fax board, but there are ATA (analog telephony (?)
adapters) that handle fax very well (and others that just suck at it).

Certain versions of the Cisco ATA 180 series worked really well even
over satellite; others were terrible.  It's somewhat of a hit or miss
area.

How many users are you supporting?  If you're looking for a device to
just put on-prem at a customer site to handle fax, those ATAs are
pretty easy to find.

On Thu, Apr 28, 2016 at 8:06 AM, Robert Jacobs  wrote:
> I would not consider any fax board "carrier grade" that uses sip  sip to 
> pots for faxes is still hit and miss.
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of 
> valdis.kletni...@vt.edu
> Sent: Thursday, April 28, 2016 1:36 AM
> To: Ryan Finnesey 
> Cc: nanog@nanog.org
> Subject: Re: carrier grade fax boards?
>
> On Thu, 28 Apr 2016 04:30:23 -, Ryan Finnesey said:
>> I was wondering if anyone had any recommendations on carrier grade fax
>> boards that are SIP based?
>
> What would "carrier grade" even *mean* for a fax board?



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: carrier grade fax boards?

[Kraig Beahn]

100% Dialogic, we are currently using both of their carrier-grade boards
and IMG's to deliver fax services in various flavors of transport
configurations to end-users and wholesale customers.

Pricey, but well worth every penny...

MSP/FSP -
https://www.dialogic.com/en/products/fax-boards-and-software/foip/fsp.aspx
IMG series w/SS7 support -
https://www.dialogic.com/en/products/gateways.aspx



On Thu, Apr 28, 2016 at 12:30 AM, Ryan Finnesey  wrote:

> I was wondering if anyone had any recommendations on carrier grade fax
> boards that are SIP based?
>
> Cheers
> Ryan
>
>

Re: contact with mail support for domain cisco.com

[Hugo Slabbert]

On Thu 2016-Apr-28 09:48:09 +0200, Piotr  wrote:

Hi,

There is a problem with sending emails from employees in @cisco.com 
domain to some certain domain. Emails in opposite direction pass 
without problem. No errors, warnings or any other logs at cisco's 
employees desktop.. We checked popular rbls, spamhauses, senderbase 
etc. Other domains on the same MX cluster receive emails from 
@cisco.com..


I try to get help in many ways ( cisco tac, a few  account managers, 
channel partners) but without success..


Big thanks for contact via email:   peter.handke.1966 at gmail.com
or any other advice


You've given us damn near zero information to go on.  Are you with Cisco?  
Or managing some of these "certain domains" to which cisco.com addresses 
cannot send?  It sounds like the latter and that seems more plausible as 
I'd be pretty surprised to find a cisco.com postmaster sending a vague 
request like this to nanog.  I don't really get how TAC would be involved; 
have you tried postmas...@cisco.com?  Assuming that you *are* the receiving 
side, what logs do you have on this?  What are the names of these "certain 
domains"?  Are they all under the same administrative control / same MXs 
(I'm assuming yes)?


This also seems like something for mailop[1] rather than nanog.  Fair 
warning; they're using Let's Encrypt and are having trouble with the 
rollover, so the cert's expired again.



best regards,
Peter


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

[1] https://chilli.nosignal.org/mailman/listinfo/mailop


signature.asc
Description: Digital signature

RE: carrier grade fax boards?

[Robert Jacobs]

I would not consider any fax board "carrier grade" that uses sip  sip to 
pots for faxes is still hit and miss.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of 
valdis.kletni...@vt.edu
Sent: Thursday, April 28, 2016 1:36 AM
To: Ryan Finnesey 
Cc: nanog@nanog.org
Subject: Re: carrier grade fax boards?

On Thu, 28 Apr 2016 04:30:23 -, Ryan Finnesey said:
> I was wondering if anyone had any recommendations on carrier grade fax 
> boards that are SIP based?

What would "carrier grade" even *mean* for a fax board?

NYC & Philly Metro rack stack and config

[Daniel Corbe]

If anyone in the NYC and Philly metro areas want to make a few extra bucks, 
contact me off list.

I need someone to drop an initial config on some brocade routers and run some 
cabling.  

Best,
Daniel

Re: Arista Routing Solutions

[Patrick Cole]

Laszln,

Thu, Apr 28, 2016 at 12:47:45PM +, Laszlo Hanyecz wrote:

> On 2016-04-28 11:06, Alain Hebert wrote:
> >
> >  Well,
> >
> >  Once you eliminate the ~160k superfluous prefixes (last time I
> > checked)...  This is a none issue.
> >
> >  Some work on some sort summary function would keep those devices
> > alive...  but we all know there is more money to be made the faster the
> > device become obsolete :(
> >
> >
> 
> Can you explain how this works?  How can a router determine which prefix 
> is superfluous?  How does it cope when a suppressed prefix is withdrawn 
> or a more specific prefix is added? Is this just one of those 'it works 
> some of the time' solutions or is this something that can be done safely 
> with an appropriate algorithm?
 
A fair chunk of the routing table is aggregable.  If multiple
aggregable prefixes share the same nexthop, the HW entries can be 
summarised accordingly, reducing the HW resource footprint.

Should one of the smaller prefixes be withdrawn or best path
change to another nexthop, the control plane needs to be smart 
enough to adapt and reprogram the HW accordingly.   It is a fairly
logical and reasonable algorithm to construct

-- 
Patrick Cole 
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630

Re: Arista Routing Solutions

[Laszlo Hanyecz]

On 2016-04-28 11:06, Alain Hebert wrote:

 Well,

 Once you eliminate the ~160k superfluous prefixes (last time I
checked)...  This is a none issue.

 Some work on some sort summary function would keep those devices
alive...  but we all know there is more money to be made the faster the
device become obsolete :(




Can you explain how this works?  How can a router determine which prefix 
is superfluous?  How does it cope when a suppressed prefix is withdrawn 
or a more specific prefix is added? Is this just one of those 'it works 
some of the time' solutions or is this something that can be done safely 
with an appropriate algorithm?


Thanks,
Laszlo

Re: Arista Routing Solutions

[Alain Hebert]

Well,

Once you eliminate the ~160k superfluous prefixes (last time I
checked)...  This is a none issue.

Some work on some sort summary function would keep those devices
alive...  but we all know there is more money to be made the faster the
device become obsolete :(

-
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 04/28/16 01:33, lincoln dale wrote:
> On Wed, Apr 27, 2016 at 4:41 PM, Peter Kranz  wrote:
>
>> Curious if you have any thoughts on the longevity of the 7500R and
>> 7280R survival's with IPv4 full tables? How full are you seeing the TCAM
>> getting today (I'm assuming they are doing some form of selective
>> download)? And if we are currently adding 100k/routes a year, how much
>> longer will it last?
>>
> I can't speak for Ryan or Netflix, but we (Arista) are stating our
> technique is good for 1M+ prefixes of IPv4+v6 combined.  Internet right now
> is at between 575K and 635K IPv4 and between 28K and 35K IPv6 right now and
> its taken many many many years to get there, its foreseeable there's many
> years of growth there.
> Note that we don't do static partitioning between IPv4 and IPv6 and our how
> we do it has more headroom in it than we state, so we're confident.  We're
> also not doing "selective download", this is every prefix in current table.
>
> What I can share is two different scenarios today:
>
> 1. a traditional internet edge router with multiple transit/peer providers,
> Internet as of right now, and a cloud customer  that also has hundreds of
> thousands of prefixes internally
> Ryan's case might be different to others, but here are three scenarios
> deployed today: 1. a large hosting provider with full tables and many
> internal prefixes, 2. a cloud deployment.
>
> The former is at 854K IPv4 and 35K IPv6 of 'internet' as of a few weeks ago:
>
> 7500R# show ip route summary | grep Total
> Total Routes  575127
> 7500R# show ipv6 route summary | grep Total
>  Total Routes  35511
> 7500R# show hardware capacity | grep Routing
> Forwarding Resources Usage
>
> TableFeatureChip Used   Used  Free   Committed   Best
> Case   High
>   Entries(%)   Entries Entries
> Max  Watermark
>
>  Entries
>  -- -  -- - ---
> --- -
> Routing  Resource1  815   39% 1233   0
>  2048817
> Routing  Resource2  469   45%  555   0
>  1024471
> Routing  Resource314074   42%18694   0
> 32768  14098
> Routing  V4Routes696364   88%89753   0
>  786432 697110
> Routing  V6Routes 00%89753   0
>  786432  0
>
>
> The latter is at 854K IPv4 + 45K IPv6:
>
> 7500R# show ip route summary | grep Total
> Total Routes  854393
> 7500R# show ipv6 route summary | grep Total
>  Total Routes  45678
> 7500R# show hardware capacity | grep Routing
> Forwarding Resources Usage
>
> TableFeatureChip Used   Used  Free   Committed   Best
> Case   High
>   Entries(%)   Entries Entries
> Max  Watermark
>
>  Entries
>  -- -  -- - ---
> --- -
> Routing  Resource1   131964%   729   0
>  2048   1320
> Routing  Resource280979%   215   0
>  1024814
> Routing  Resource3  2410273%  8666   0
> 32768  24104
> Routing  V4Routes  64433683%124302   0
>  786432 644364
> Routing  V6Routes   1779212%124302   0
>  786432  17795
>
>
> One could ask Geoff Huston where he thinks combined IPv4+v6 will exceed 1M
> entries but I would expect it to be many years away based on
> http://bgp.potaroo.net/ and we'd welcome discussions about if it you want
> to know our opinion [*] on how we're doing it will scale.  What we're doing
> doesn't explode at 1M, there's headroom in it hence why we say "1M+". Again
> we're happy to talk about it, just ask your friendly arista person and if
> you don't know who to ask, ask me and i'll put you in touch with the right
> folks.
>
>
> cheers,
>
> lincoln.  [*] l...@arista.com
>

Re: carrier grade fax boards?

[Faisal Imtiaz]

When you use the terms 'SIP' and 'Fax/Board' in the same sentence, it sort of 
becomes an oxymoron.

In the analog world, we used to use 'Carrier grade' Fax/boards made by 
BrookTrout which was then acquired by Dialogic. (Truefax line), and there were 
a couple of others.. mostly these were cards with large amount of DSP's used 
for fax processing multiple channels on digital links (BRI/PRI/T1's etc).

Since SIP is a 'communication protocol' which works with IP, there is no need 
for 'Fax/Board', since all everything needed can be done via software. The only 
reason one may need Hardware is to convert SIP to traditional TDM (POTS line or 
PRI/T1/E1 etc). Most of us are used to referring to these devices as IAD's.

Having said that, what are you looking to do ? Traditional TDM fax or SIP based 
FOIP ?

:)

Regards.

Faisal Imtiaz
Snappy Internet & Telecom


- Original Message -
> From: "Ryan Finnesey" 
> To: "Valdis Kletnieks" 
> Cc: "nanog list" 
> Sent: Thursday, April 28, 2016 2:41:23 AM
> Subject: RE: carrier grade fax boards?

> Fax hardware/boards that other members have used  within service provider
> environments to deliver services to their end users .
> 
> -Original Message-
> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
> Sent: Thursday, April 28, 2016 2:36 AM
> To: Ryan Finnesey 
> Cc: nanog@nanog.org
> Subject: Re: carrier grade fax boards?
> 
> On Thu, 28 Apr 2016 04:30:23 -, Ryan Finnesey said:
>> I was wondering if anyone had any recommendations on carrier grade fax
>> boards that are SIP based?
> 
> What would "carrier grade" even *mean* for a fax board?

contact with mail support for domain cisco.com

[Piotr]

Hi,

There is a problem with sending emails from employees in @cisco.com 
domain to some certain domain. Emails in opposite direction pass without 
problem. No errors, warnings or any other logs at cisco's employees 
desktop.. We checked popular rbls, spamhauses, senderbase etc. Other 
domains on the same MX cluster receive emails from @cisco.com..


I try to get help in many ways ( cisco tac, a few  account managers, 
channel partners) but without success..


Big thanks for contact via email:   peter.handke.1966 at gmail.com
or any other advice

best regards,
Peter

RE: carrier grade fax boards?

[Ryan Finnesey]

Fax hardware/boards that other members have used  within service provider 
environments to deliver services to their end users .  

-Original Message-
From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] 
Sent: Thursday, April 28, 2016 2:36 AM
To: Ryan Finnesey 
Cc: nanog@nanog.org
Subject: Re: carrier grade fax boards?

On Thu, 28 Apr 2016 04:30:23 -, Ryan Finnesey said:
> I was wondering if anyone had any recommendations on carrier grade fax 
> boards that are SIP based?

What would "carrier grade" even *mean* for a fax board?

Re: carrier grade fax boards?

[Valdis . Kletnieks]

On Thu, 28 Apr 2016 04:30:23 -, Ryan Finnesey said:
> I was wondering if anyone had any recommendations on carrier grade fax boards
> that are SIP based?

What would "carrier grade" even *mean* for a fax board?


pgpnbu6lUPiJ5.pgp
Description: PGP signature

Re: BGP FlowSpec

[Martin Bacher]

> Am 27.04.2016 um 18:09 schrieb Hank Nussbacher :
> 
> On 27/04/2016 18:58, John Kristoff wrote:
>> On Thu, 21 Apr 2016 09:46:13 +0200
>> Martin Bacher  wrote:
>> 
>>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
>>> of attacks are you using it? Are you only dropping or rate-limiting
>>> certain traffic or are you also using the redirect/remark
>>> capabilities? What are the limitations from your perspective? Are you
>>> facing any operational issues? How are you injecting the FlowSpec
>>> routes?
>> Unless you received a number of private responses, perhaps the lack of
>> public responses is telling.
> Geant runs a Firewall of Demand based on BGP Flowspec (Juniper
> routers).  You can read more about it here:
> http://www.geant.org/Networks/Network_Operations/PublishingImages/Pages/Firewall-on-Demand/Firewall%20on%20Demand%20User%20Guide.pdf
> https://www.terena.org/activities/tf-csirt/meeting44/Firewall%20on%20Demand_Las_Palmas.pdf
Thank you Hank. That’s a pretty nice intra AS implementation with a nice 
interface for customers. 

Cheers,
Martin

> 
> Regards,
> Hank
> 
>> 
>> I've heard of a few networks doing this and there is some public record
>> of it being used, including one instance where a bad rule was behind a
>> serious outage:
>> 
>>  
>> 
>> 
>>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
>>> your experience? Are there any concerns regarding Inter-AS
>>> deployments? Has anyone done interop tests?
>> You might mine public, archived BGP data and see if there are any
>> traffic filtering rules present (they are encoded in extended
>> communities, which are optional, transitive).
>> 
>> We once tried to coordinate an Inter-AS flow-spec project, but it
>> failed miserably due to lack of interest.  For posterity, here is the
>> project page:
>> 
>>  
>> 
>> Literally the only people who were interested in it at the time was one
>> of the spec's co-authors.  :-)
>> 
>> Since then, we have tried a more modest approach using the well known
>> BGP RTBH technique:
>> 
>>  
>> 
>> This has been much more successful and since we've started we've
>> probably had about a dozen networks express interest in flow-spec
>> rules.  Verification of rules is potentially tricky, but
>> widespread interest still lags in my estimation.
>> 
>>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
>>> and which applications are you using for the analysis (Peakflow,
>>> Open-Source tools, ..?)
>> Not speaking for anyone in particular, but don't forget about user
>> complaints.  In some cases a network may not notice (or care) if an
>> attack is below a certain threshold for their network, but above a
>> stress point downstream.
>> 
>> John
>> 
> 

Re: BGP FlowSpec

[Martin Bacher]

> Am 27.04.2016 um 17:58 schrieb John Kristoff :
> 
> On Thu, 21 Apr 2016 09:46:13 +0200
> Martin Bacher  wrote:
> 
>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind
>> of attacks are you using it? Are you only dropping or rate-limiting
>> certain traffic or are you also using the redirect/remark
>> capabilities? What are the limitations from your perspective? Are you
>> facing any operational issues? How are you injecting the FlowSpec
>> routes?
> 
> Unless you received a number of private responses, perhaps the lack of
> public responses is telling.
> 
> I've heard of a few networks doing this and there is some public record
> of it being used, including one instance where a bad rule was behind a
> serious outage:
> 
>  
> 

Thanks for that information.  I didn’t know about that outage and this is 
definitely something which is very important and worth mentioning in the paper. 
But i would rather say that this is a general risk. A fat fingers issue can 
always disconnect you from the internet as well as a software bug in a 
homogenous environment.

> 
>> - Inter-AS: Who is running Inter-AS FlowSpec deployments? What is
>> your experience? Are there any concerns regarding Inter-AS
>> deployments? Has anyone done interop tests?
> 
> You might mine public, archived BGP data and see if there are any
> traffic filtering rules present (they are encoded in extended
> communities, which are optional, transitive).

I don’t think that I will find anything there because it is a dedicated SAFI. 
Only traffic filtering actions are encoded as extended communities.
> 
> We once tried to coordinate an Inter-AS flow-spec project, but it
> failed miserably due to lack of interest.  For posterity, here is the
> project page:
> 
>  

I already came across your project but didn’t recognize that there is/was also 
some FlowSpec initiative.

> 
> Literally the only people who were interested in it at the time was one
> of the spec's co-authors.  :-)
That’s how it usually starts. ;)

> 
> Since then, we have tried a more modest approach using the well known
> BGP RTBH technique:
> 
>  
> 
> This has been much more successful and since we've started we've
> probably had about a dozen networks express interest in flow-spec
> rules.  Verification of rules is potentially tricky, but
> widespread interest still lags in my estimation.
Yes, RTBH is quite common and really helpful in the inter AS world. But eBGP 
FlowSpec is just offered by very few ISPs. I think that intra AS deployments 
are more common, but one wouldn’t be able to detect that unless somebody tells 
you that they are using it.

> 
>> - How are you detecting DDoS attacks (Netflow, in-line probes, ..?)
>> and which applications are you using for the analysis (Peakflow,
>> Open-Source tools, ..?)
> 
> Not speaking for anyone in particular, but don't forget about user
> complaints.  In some cases a network may not notice (or care) if an
> attack is below a certain threshold for their network, but above a
> stress point downstream.
That’s true. They are selling IP-Transit and more traffic means more money. 
Upstream providers may only care if other customers are also affected or unless 
you pay them for protection.

Thanks for your comments!

Cheers,
Martin

> 
> John