Re: Alcatel-Lucent 7750 Service Router (SR)

[Tim Franklin]

> I am worried as most tech's know Cisco and Juniper, so going to ALU would
> be a learning curve based on replies I am getting off list.

It's definitely quite different from the CLI.  I'm still dabbling, but the guys 
here who have been through the training and are immersed in it really like it.  
We're using a couple for feature-rich BNG - lots of MLPPP at high bandwidths 
(for broadband), heavyweight QoS, BGP to the CE, etc.  It's very controllable 
by RADIUS - template configs that you can fill in the values for, rather than 
the Cisco approach of AVPs with pages of config in.

ALU have an e-learning "SR-OS introduction" course, which is going down pretty 
well for jump-starting our Ops people.

Regards,
Tim.

Re: IP DSCP across the Internet

[James Bensley]

On 6 May 2015 at 03:27, Blake Dunlap  wrote:
> If there isn't a specific peering agreement which sets up DSCP marks
> with your Z side, you're going to have a bad time doing anything other
> than remarking to 0.
>
> -Blake


This.

You can't really put SLAs on traffic that has to egress/ingress the
Internet, if you try to you're asking for trouble, so we simply remark
to 0 on all inbound traffic.

Jamas.

Re: IP DSCP across the Internet

[Mikael Abrahamsson]

On Wed, 6 May 2015, Mark Tinka wrote:

With color-aware policing toward a customer in Uganda, any traffic 
coming from that peer in South Africa was getting dropped toward that 
customer in Uganda. After a very odd sequence of troubleshooting events, 
we found that the AF DSCP alues being set by the peer in South Africa 
(and us passing them due to the old kit not being able to remark on 
ingress) was causing the color-aware policer in Uganda to drop traffic 
toward the customer there.


I have heard similar stories where game traffic ended up in a 100 
kilobit/s VoIP queue which worked fine until there were a lot of nearby 
players in the game, then things started working very badly. Also nice 
corner case :P


So yes, setting all external Internet traffic to DSCP=BE (0) is something 
one wants to do.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: IP DSCP across the Internet

[Mark Tinka]

On 7/May/15 11:12, James Bensley wrote:
>
>
> This.
>
> You can't really put SLAs on traffic that has to egress/ingress the
> Internet, if you try to you're asking for trouble, so we simply remark
> to 0 on all inbound traffic.

And this is what sales and marketing droids don't get - so-called
"Premium Internet" products abound that don't really mean anything.

The competition that offer these products are basically hoping nothing
happens, and that when it does, it seems as palatable as flying First
Class in a plane that's going down.

Focus energies on other things, I say... the customers that buy such
services should know better, but alas...

Mark.

Re: IP DSCP across the Internet

[Mike Hammett]

That sounds like a rather poor implementation. What if they had more than one 
VoIP call? 

Seems like this thread has more FUD than real examples. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message -

From: "Mikael Abrahamsson"  
To: "Mark Tinka"  
Cc: "nanog list"  
Sent: Thursday, May 7, 2015 4:32:52 AM 
Subject: Re: IP DSCP across the Internet 

On Wed, 6 May 2015, Mark Tinka wrote: 

> With color-aware policing toward a customer in Uganda, any traffic 
> coming from that peer in South Africa was getting dropped toward that 
> customer in Uganda. After a very odd sequence of troubleshooting events, 
> we found that the AF DSCP alues being set by the peer in South Africa 
> (and us passing them due to the old kit not being able to remark on 
> ingress) was causing the color-aware policer in Uganda to drop traffic 
> toward the customer there. 

I have heard similar stories where game traffic ended up in a 100 
kilobit/s VoIP queue which worked fine until there were a lot of nearby 
players in the game, then things started working very badly. Also nice 
corner case :P 

So yes, setting all external Internet traffic to DSCP=BE (0) is something 
one wants to do. 

-- 
Mikael Abrahamsson email: swm...@swm.pp.se 

Re: Network Segmentation Approaches

[Rich Kulawiec]

Ah...got it, this was sloppy phrasing on my part.  I meant "first"
in the sense of "first rule that one should write".  Depending on
the firewall type/implementation, that might be the rule that's
lexically first or last (or maybe somewhere else).

---rsk

Re: Alcatel-Lucent 7750 Service Router (SR)

[Phil Bedard]

Forgot to send this yesterday… 

We use them in our networks along with ASR9Ks and MXs.  There are a lot of them 
deployed around the world doing very similar things as ASRs and MXs.  The 
config is more like Juniper than Cisco IMHO.  Being kind of the “3rd” vendor 
they have a tendency to implement features proposed by both Cisco and Juniper 
faster than Cisco and Juniper when proposed by the other vendor.  For instance 
Segment Routing is a Cisco thing, but ALU has already implemented it in their 
latest 13.0 software, Juniper is sort of dragging their feet on it because it’s 
a Cisco thing.   Same goes for NG-MVPN (BGP signaled multicast VPN).  Cisco 
dragged their feet on it because it was a Juniper thing, ALU had no issues 
implementing it much sooner.  Most of ALUs innovation is on the MPLS services 
side.  We use them for business VPN (L2 and L3) but the underlying protocols 
are all standard stuff and interoperate with everything else. 

Phil  




-Original Message-
From: Colton Conor
Date: Wednesday, May 6, 2015 at 17:48
To: NANOG
Subject: Alcatel-Lucent 7750 Service Router (SR)

>I was wondering if anyone was using a  Alcatel-Lucent 7750 Service Router
>(SR) in their network? How does this platform compare the the Cisco ASR,
>Brocade MLXe, and Juniper MX line?

Re: Alcatel-Lucent 7750 Service Router (SR)

[Mick O'Donovan]

+1 for the command structure and configuration being pretty simple to 
follow if you're used to a Cisco or Juniper.


In the main they are pretty good at what they do I guess but I'm not 
sure whether or not we're having seriously bad luck or there's something 
else a miss but sadly we've had a near 50% hardware failure rate on some 
of the cards we have deployed in our 7750 SR12 infrastructure.


Reply off list if you need any more information.

Mick

--
Mick O'Donovan | Network Engineer | BT Ireland |
Website: http://www.btireland.net
Looking Glass: http://lg.as2110.net
Peering Record: http://as2110.peeringdb.com
AS-SET Macro: AS-BTIRE | ASN: 2110


On 07/05/15 05:29, Phil Bedard wrote:

The show stuff is certainly there but the config is a bit different.  You may have to get 
used to using the "info" command.  :)

They also use logical IP interfaces which are then tied to physical, you don't directly 
configure L3 on a physical interface.  You also have designations between service and 
network physical interfaces, although nowadays they can be set as "hybrid.".

It's really pretty simple if you are used to a Cisco or Juniper.  They have tab 
and ? completion now for both commands as well as elements similar to Junos 
which is helpful.

Phil

-Original Message-
From: "Bob Evans" 
Sent: ‎5/‎6/‎2015 11:55 PM
To: "nanog@nanog.org" 
Subject: Re: Alcatel-Lucent 7750 Service Router (SR)


I will be getting one to try.  I am pretty sure it will support the ol'
"show ?   ,config  ?"  If not that might be a problem :-)

Thank You
Bob Evans
CTO





What's the price point of an SR-A4?  Comparable to the MX104 or ASR9001?

-- Stephen

On 2015-05-06 7:13 PM, Craig wrote:

If you know Juniper and Cisco, the learning curve isn't so bad to pick
up
the ALU CLI, after working with it for a brief time, you catch on
quickly.
Their products are quite impressive, and a # of the carriers, are moving
to
them and some have already moved to them and are quite happy with their
decision.


On Wed, May 6, 2015 at 6:24 PM, Colton Conor 
wrote:


I am worried as most tech's know Cisco and Juniper, so going to ALU
would
be a learning curve based on replies I am getting off list.

On Wed, May 6, 2015 at 5:22 PM, Dan Snyder  wrote:



They are definitely good for that. We use them in part of our network
for
something very similar.

I am not sure why they aren't mentioned that much. I know that they
have
been pretty popular in the past couple years.

We are planning on using 7750 SR-a4's in the future but right now we
mainly have 7750SR7/12s.

Sent from my iPhone

On May 6, 2015, at 6:00 PM, Colton Conor 
wrote:

Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU
never mentioned, but Juniper MX and Cisco are all day long?

The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer.

On Wed, May 6, 2015 at 4:58 PM, Dan Snyder 
wrote:


We have been using them for almost 8 years now and have been pretty
happy. What are you looking to use them for?

Sent from my iPhone


On May 6, 2015, at 5:48 PM, Colton Conor 

wrote:


I was wondering if anyone was using a  Alcatel-Lucent 7750 Service

Router

(SR) in their network? How does this platform compare the the Cisco

ASR,

Brocade MLXe, and Juniper MX line?

Re: Alcatel-Lucent 7750 Service Router (SR)

[Chris Boyd]

> On May 6, 2015, at 5:24 PM, Colton Conor  wrote:
> 
> I am worried as most tech's know Cisco and Juniper, so going to ALU would
> be a learning curve based on replies I am getting off list.

It’s not that hard to learn if you know the basics of IP routing.  I just did 
an implementation of A-L 7705 SAR 8s and 18s.  Now I really wish that Cisco 
supported the “info” command.

—Chris

Re: Alcatel-Lucent 7750 Service Router (SR)

[Craig]

yep.. its way easier and faster to take a look at what is configured:

A:R01>config>service>vprn# interface "to-what-ever-eBGP"
A:R01>config>service>vprn>if# info
--
description "L3 Ckt ID: "
enable-ingress-stats
cpu-protection 231
address 299.299.299.299/30
cflowd interface
ipv6
address 2001::x::x/126
exit
sap 1/1/2 create
cpu-protection 231
ingress
filter ip 3356
filter ipv6 3356
flowspec
exit
exit
--







On Thu, May 7, 2015 at 12:08 PM, Chris Boyd  wrote:

>
> > On May 6, 2015, at 5:24 PM, Colton Conor  wrote:
> >
> > I am worried as most tech's know Cisco and Juniper, so going to ALU would
> > be a learning curve based on replies I am getting off list.
>
> It’s not that hard to learn if you know the basics of IP routing.  I just
> did an implementation of A-L 7705 SAR 8s and 18s.  Now I really wish that
> Cisco supported the “info” command.
>
> —Chris
>
>

Re: Alcatel-Lucent 7750 Service Router (SR)

[Trent Farrell]

And if you ever need to find out what can commands exist for a certain
string "xxx"

tree flat detail | match xxx

is a huge helper when learning.

e.g.

A:router# tree flat detail | match aspath-regex
show router bgp routes [ [type ]] aspath-regex 
show router bgp routes [ []] aspath-regex 

On Thu, May 7, 2015 at 9:16 AM, Craig  wrote:

> yep.. its way easier and faster to take a look at what is configured:
>
> A:R01>config>service>vprn# interface "to-what-ever-eBGP"
> A:R01>config>service>vprn>if# info
> --
> description "L3 Ckt ID: "
> enable-ingress-stats
> cpu-protection 231
> address 299.299.299.299/30
> cflowd interface
> ipv6
> address 2001::x::x/126
> exit
> sap 1/1/2 create
> cpu-protection 231
> ingress
> filter ip 3356
> filter ipv6 3356
> flowspec
> exit
> exit
> --
>
>
>
>
>
>
>
> On Thu, May 7, 2015 at 12:08 PM, Chris Boyd 
> wrote:
>
> >
> > > On May 6, 2015, at 5:24 PM, Colton Conor 
> wrote:
> > >
> > > I am worried as most tech's know Cisco and Juniper, so going to ALU
> would
> > > be a learning curve based on replies I am getting off list.
> >
> > It’s not that hard to learn if you know the basics of IP routing.  I just
> > did an implementation of A-L 7705 SAR 8s and 18s.  Now I really wish that
> > Cisco supported the “info” command.
> >
> > —Chris
> >
> >
>



-- 

*Trent Farrell*

*Riot Games*

*IP Network Engineer*

E: tfarr...@riotgames.com | IE:  +353 83 446 6809 | US: +1 424 285 9825

Summoner name: Foro

Re: Alcatel-Lucent 7750 Service Router (SR)

[Josh Reynolds]

It really bothers me to see that people in this industry are so worried about a 
change of syntax or terminology. If there's one thing about the big vendors 
that bothers me, it's that these batteries of vendor specific tests have 
allowed many "techs" to get lazy. They simply can't seem to operate well, if at 
all, in a non-Cisco (primarily) environment. 


On May 7, 2015 1:12:11 AM AKDT, Tim Franklin  wrote:
>> I am worried as most tech's know Cisco and Juniper, so going to ALU
>would
>> be a learning curve based on replies I am getting off list.
>
>It's definitely quite different from the CLI.  I'm still dabbling, but
>the guys here who have been through the training and are immersed in it
>really like it.  We're using a couple for feature-rich BNG - lots of
>MLPPP at high bandwidths (for broadband), heavyweight QoS, BGP to the
>CE, etc.  It's very controllable by RADIUS - template configs that you
>can fill in the values for, rather than the Cisco approach of AVPs with
>pages of config in.
>
>ALU have an e-learning "SR-OS introduction" course, which is going down
>pretty well for jump-starting our Ops people.
>
>Regards,
>Tim.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Alcatel-Lucent 7750 Service Router (SR)

[Rob Seastrom]

Josh Reynolds  writes:

> It really bothers me to see that people in this industry are so
> worried about a change of syntax or terminology. If there's one
> thing about the big vendors that bothers me, it's that these
> batteries of vendor specific tests have allowed many "techs" to get
> lazy. They simply can't seem to operate well, if at all, in a
> non-Cisco (primarily) environment.

If that bothers you, I recommend you not look at what passes for a
"system administrator" these days.  It will make you cry.

-r

Re: Alcatel-Lucent 7750 Service Router (SR)

[Tim Franklin]

> It really bothers me to see that people in this industry are so worried about
> a change of syntax or terminology. If there's one thing about the big
> vendors that bothers me, it's that these batteries of vendor specific tests
> have allowed many "techs" to get lazy. They simply can't seem to operate
> well, if at all, in a non-Cisco (primarily) environment.

I'd half-agree :)

Making "it's different" in and of itself a reason not to use a particular 
vendor does seem to head towards laziness.

But with the best will in the world, your good engineers *will* be slower until 
they familiarise with the new mind-maps (particularly things like the 
logical/physical split, SAPs, etc on the ALU) and the new magic words - 
although hopefully they'll be excited to learn something new too.  Your weaker 
engineers are going to need more of a push and/or some help, and the further 
towards helpdesk and scripts you get, the more you're going to need to provide 
training - be that internal, external, new scripts and cribs sheets or 
whatever.  That's an impact and cost it's unwise to ignore.

Regards,
Tim.

Re: Alcatel-Lucent 7750 Service Router (SR)

[Josh Reynolds]

*grumble, grumble, grumble*

"Get off my lawn!"

:)

On May 7, 2015 8:49:43 AM AKDT, Rob Seastrom  wrote:
>
>Josh Reynolds  writes:
>
>> It really bothers me to see that people in this industry are so
>> worried about a change of syntax or terminology. If there's one
>> thing about the big vendors that bothers me, it's that these
>> batteries of vendor specific tests have allowed many "techs" to get
>> lazy. They simply can't seem to operate well, if at all, in a
>> non-Cisco (primarily) environment.
>
>If that bothers you, I recommend you not look at what passes for a
>"system administrator" these days.  It will make you cry.
>
>-r

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Alcatel-Lucent 7750 Service Router (SR)

[Craig]

we do "cry" when we interview people that claim to have "advanced
knowledge" of BGP and we ask them some very basic BGP questions, and we get
a blank stare.

On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom  wrote:

>
> Josh Reynolds  writes:
>
> > It really bothers me to see that people in this industry are so
> > worried about a change of syntax or terminology. If there's one
> > thing about the big vendors that bothers me, it's that these
> > batteries of vendor specific tests have allowed many "techs" to get
> > lazy. They simply can't seem to operate well, if at all, in a
> > non-Cisco (primarily) environment.
>
> If that bothers you, I recommend you not look at what passes for a
> "system administrator" these days.  It will make you cry.
>
> -r
>
>
>

Re: Alcatel-Lucent 7750 Service Router (SR)

[Josh Reynolds]

You know where these people wouldn't fit? W/ISPs.

Every three years or so you are forklifting the majority of your wireless PtMP 
for either a new series or a totally different vendor. New backhaul vendors 
often. You're building AC and DC power plants. You likely touch Cisco, juniper, 
HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, accedian/ciena, 
etc due to various client and network requirements all in the same week, AND 
you have to make them work together nicely :)

It's not the environment for somebody like that, and I truly don't understand 
how people of that.. "caliber" end up working on large scale WANs and global 
transit networks.

Frankly, it scares me a bit.

On May 7, 2015 9:07:35 AM AKDT, Craig  wrote:
>we do "cry" when we interview people that claim to have "advanced
>knowledge" of BGP and we ask them some very basic BGP questions, and we
>get
>a blank stare.
>
>On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom  wrote:
>
>>
>> Josh Reynolds  writes:
>>
>> > It really bothers me to see that people in this industry are so
>> > worried about a change of syntax or terminology. If there's one
>> > thing about the big vendors that bothers me, it's that these
>> > batteries of vendor specific tests have allowed many "techs" to get
>> > lazy. They simply can't seem to operate well, if at all, in a
>> > non-Cisco (primarily) environment.
>>
>> If that bothers you, I recommend you not look at what passes for a
>> "system administrator" these days.  It will make you cry.
>>
>> -r
>>
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Alcatel-Lucent 7750 Service Router (SR)

[Rob Seastrom]

More like "at least be willing to man up and learn your way around
some platform other than RHEL without whining if there is a business
need for it".

-r

Josh Reynolds  writes:

> *grumble, grumble, grumble*
> "Get off my lawn!"
> :)
>
>
> On May 7, 2015 8:49:43 AM AKDT, Rob Seastrom  wrote:
>
>   
>  
>>Josh Reynolds  writes:
>  
>>
>  
>>
>
> It really bothers me to see that people in this
>   industry are so
>   > worried about a change of syntax or terminology. If
>   there's one
>   > thing about the big vendors that bothers me, it's that
>   these
>   > batteries of vendor specific tests have allowed many
>   "techs" to get
>   > lazy. They simply can't seem to operate well, if at all,
>   in a
>   > non-Cisco (primarily) environment.
>   >
>
>   >If that bothers you, I recommend you not look at what passes
>  for a
>  >"system administrator" these days. It will make you cry.
>  >
>  >-r
>  >
>  >
>  >
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Alcatel-Lucent 7750 Service Router (SR)

[Josh Reynolds]

LOL :)

On May 7, 2015 9:38:15 AM AKDT, Rob Seastrom  wrote:
>
>More like "at least be willing to man up and learn your way around
>some platform other than RHEL without whining if there is a business
>need for it".
>
>-r
>
>Josh Reynolds  writes:
>
>> *grumble, grumble, grumble*
>> "Get off my lawn!"
>> :)
>>
>>
>> On May 7, 2015 8:49:43 AM AKDT, Rob Seastrom  wrote:
>>
>>   
>>  
>>>Josh Reynolds  writes:
>>  
>>>
>>  
>>>
>>
>> It really bothers me to see that people in this
>>   industry are so
>>   > worried about a change of syntax or terminology. If
>>   there's one
>>   > thing about the big vendors that bothers me, it's that
>>   these
>>   > batteries of vendor specific tests have allowed many
>>   "techs" to get
>>   > lazy. They simply can't seem to operate well, if at all,
>>   in a
>>   > non-Cisco (primarily) environment.
>>   >
>>
>>   >If that bothers you, I recommend you not look at what
>passes
>>  for a
>>  >"system administrator" these days. It will make you cry.
>>  >
>>  >-r
>>  >
>>  >
>>  >
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Huawei and ZTE Routers

[Colton Conor]

The other thread about the Alcatel-Lucent routers has been pleasantly
delightful. Our organization used to believe that Juniper, Cisco, and
Brocade were the only true vendors for carrier grade routing, but now we
are going to throw Alcatel-Lucent into the mix.

ZTE and Huawei, the big chinese vendors, have also been mentioned to us. I
know there are large national security issues with using these vendors in
the US, but I know Level3 and other large American vendors use Huawei and
ZTE in their networks.

How do their products perform? How are they compared to Cisco and Juniper
on the performance side of the house? Is their pricing really half or less
of that of Cisco and Juniper? Is it worth using these vendors or not worth
the hassle?

Re: Huawei and ZTE Routers

[Daniel Corbe]

Colton Conor  writes:

> The other thread about the Alcatel-Lucent routers has been pleasantly
> delightful. Our organization used to believe that Juniper, Cisco, and
> Brocade were the only true vendors for carrier grade routing, but now we
> are going to throw Alcatel-Lucent into the mix.
>
> ZTE and Huawei, the big chinese vendors, have also been mentioned to us. I
> know there are large national security issues with using these vendors in
> the US, but I know Level3 and other large American vendors use Huawei and
> ZTE in their networks.
>
> How do their products perform? How are they compared to Cisco and Juniper
> on the performance side of the house? Is their pricing really half or less
> of that of Cisco and Juniper? Is it worth using these vendors or not worth
> the hassle?

I don't know much about Huawei but be wary of ZTE's claims.  They love
their vendor lock-in.  They have a bad habit of giving away hardware for
next to nothing and then ratcheting up support costs.

Opex needs to be a consideration when selecting an equipment vendor as
well as capex.

Re: Huawei and ZTE Routers

[ML]

On 5/7/2015 2:25 PM, Daniel Corbe wrote:

Colton Conor  writes:


The other thread about the Alcatel-Lucent routers has been pleasantly
delightful. Our organization used to believe that Juniper, Cisco, and
Brocade were the only true vendors for carrier grade routing, but now we
are going to throw Alcatel-Lucent into the mix.

ZTE and Huawei, the big chinese vendors, have also been mentioned to us. I
know there are large national security issues with using these vendors in
the US, but I know Level3 and other large American vendors use Huawei and
ZTE in their networks.

How do their products perform? How are they compared to Cisco and Juniper
on the performance side of the house? Is their pricing really half or less
of that of Cisco and Juniper? Is it worth using these vendors or not worth
the hassle?

I don't know much about Huawei but be wary of ZTE's claims.  They love
their vendor lock-in.  They have a bad habit of giving away hardware for
next to nothing and then ratcheting up support costs.

Opex needs to be a consideration when selecting an equipment vendor as
well as capex.



2nd hand information:

Apparently the NMS for ZTE's GPON gear is an ugly contraption.
When upgrades are needed:
"we have to deploy a series of convuluted batch files"
"and it has to be installed in the directory that whatever they 
installed it to in China"

"paths are hardcoded in the app"


Hopefully there is no crossover into ZTE's other products.

RE: IP DSCP across the Internet

[John van Oppen]

seems pretty real to me, I know we (AS11404) mark to zero on ingress...   I 
think that is the typical case otherwise people would just tag their flood 
style ddos traffic as max and try to take out everything.

John 

From: NANOG [nanog-boun...@nanog.org] on behalf of Mike Hammett 
[na...@ics-il.net]
Sent: Thursday, May 07, 2015 4:46 AM
To: nanog list
Subject: Re: IP DSCP across the Internet

That sounds like a rather poor implementation. What if they had more than one 
VoIP call?

Seems like this thread has more FUD than real examples.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -

From: "Mikael Abrahamsson" 
To: "Mark Tinka" 
Cc: "nanog list" 
Sent: Thursday, May 7, 2015 4:32:52 AM
Subject: Re: IP DSCP across the Internet

On Wed, 6 May 2015, Mark Tinka wrote:

> With color-aware policing toward a customer in Uganda, any traffic
> coming from that peer in South Africa was getting dropped toward that
> customer in Uganda. After a very odd sequence of troubleshooting events,
> we found that the AF DSCP alues being set by the peer in South Africa
> (and us passing them due to the old kit not being able to remark on
> ingress) was causing the color-aware policer in Uganda to drop traffic
> toward the customer there.

I have heard similar stories where game traffic ended up in a 100
kilobit/s VoIP queue which worked fine until there were a lot of nearby
players in the game, then things started working very badly. Also nice
corner case :P

So yes, setting all external Internet traffic to DSCP=BE (0) is something
one wants to do.

--
Mikael Abrahamsson email: swm...@swm.pp.se

[no subject]

[Mark Tinka via NANOG]

--- Begin Message ---


On 7/May/15 15:16, Phil Bedard wrote:
> Forgot to send this yesterday… 
>
> We use them in our networks along with ASR9Ks and MXs.  There are a lot of 
> them deployed around the world doing very similar things as ASRs and MXs.  
> The config is more like Juniper than Cisco IMHO.  Being kind of the “3rd” 
> vendor they have a tendency to implement features proposed by both Cisco and 
> Juniper faster than Cisco and Juniper when proposed by the other vendor.  For 
> instance Segment Routing is a Cisco thing, but ALU has already implemented it 
> in their latest 13.0 software, Juniper is sort of dragging their feet on it 
> because it’s a Cisco thing.   Same goes for NG-MVPN (BGP signaled multicast 
> VPN).  Cisco dragged their feet on it because it was a Juniper thing, ALU had 
> no issues implementing it much sooner.  Most of ALUs innovation is on the 
> MPLS services side.  We use them for business VPN (L2 and L3) but the 
> underlying protocols are all standard stuff and interoperate with everything 
> else. 

I went to an ALU lab last year to look at some of their kit.

Very impressive in the BNG space, and they've had a good reputation for
that even before I laid hands on one.

The CLI is pretty neat, and easy to learn.

You're right about ALU not being fussy (but being faster) on
implementing features that Cisco and Juniper squabble over.

We have just received a test router we have for the next couple of
months, and may consider them for some roles in the network if we are
happy. My only gripe with ALU is their Metro-E offering is currently not
where I'd like it to be.

Mark.

--- End Message ---

[no subject]

[Steve Dodd via NANOG]

--- Begin Message ---


On 5/6/15, 4:56 PM, "Randy Bush"  wrote:

>a fellow researcher wants
>
>> to make the case that in some scenarios it is very important for a
>> network operator to be able to specify that traffic should *not*
>> traverse a certain switch/link/group of switches/group of links
>> (that's true right?). Could you give some examples? Perhaps point
>> me to relevant references?
>
>if so, why? security?  congestion?  other?  but is it common?  and, if
>so, how do you do it?
>
>randy

In the wireless backhaul space I¹ve seen carriers that would prefer a
circuit to go down rather than take the long path on a ring between tower
and switching center. I assume they are concerned with some sort of
latency requirement. We used RSVP-TE with link coloring as the solution.

-Steve


>


--- End Message ---

[no subject]

[Paul Stewart via NANOG]

--- Begin Message ---
Well said Mark ...

There's a certain large transit provider that this all the time and I never 
understood why ...

Paul


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Tinka
Sent: Wednesday, May 6, 2015 5:32 AM
To: Martin T; nanog@nanog.org
Subject: Re: disadvantages of peering with own IP transit customers



On 6/May/15 11:20, Martin T wrote:
> Hi,
>
> what are the disadvantages of peering(announcing own and all customers
> prefixes) with own IP transit customers? One disadvantage is obviously 
> that amount of traffic on IP transit link is lower and thus customer 
> pays for smaller amount of Mbps. On the other hand, this can be 
> somewhat compensated with higher price per Mbps if the amount of 
> traffic on the IP transit connection is lower. However, are there any 
> other disadvantages/concerns when peering with own IP transit 
> customers?

- Potentially odd routing if customers are unfamiliar with how BGP really 
works, i.e., upload from customer hits the commercial link, but return traffic 
to customer
   follows the peering link since peering links generally have a higher 
LOCAL_PREF than commercial links.

- Since more traffic is return to (eyeball-heavy) customers, you increase 
investment on your peering side with no corresponding gain in revenue, as 
peering is,
   well, free.

- Any special policies you accord to peers will now be enjoyed by this 
customer also, since they also are a peer.

- Issues that could be caused by deliberate inconsistent routing from the 
customer's part in an effort to direct more traffic into the peering link.

- Complicated controls you may put in place to ensure the customer does not 
abuse your network from a peering standpoint (or vice versa), e.g., Internet in
   VRF's, peering in VRF's, e.t.c., and the issues that come with all that 
complexity.

- Complications with the commercial contract - a growth in your customer's 
traffic out of balance with how much money you're earning from them.

- Confusion between your customer, their account manager, the engineering 
team and the operations teams on how the service is meant to be delivered,
   operated, billed for, e.t.c.

- A host of other things I haven't thought about.

All in all, don't peer with customers if you don't have to. That should be your 
#1 and #2 peering policy rules. Too much commercial and technical confusion 
will surely ensue.

Mark.


--- End Message ---

[no subject]

[Randy Bush via NANOG]

--- Begin Message ---
> ZTE and Huawei, the big chinese vendors, have also been mentioned to
> us. I know there are large national security issues with using these
> vendors in the US

uh, you have not seen the lovely picture of the nsa implanting a cisco?

randy
--- End Message ---

[no subject]

[Jimmy Hess via NANOG]

--- Begin Message ---
On Thu, May 7, 2015 at 7:12 AM, Rich Kulawiec  wrote:
> Ah...got it, this was sloppy phrasing on my part.  I meant "first"
> in the sense of "first rule that one should write".  Depending on

Security best practice to always have an active "cleanup" rule  for
every traffic direction
applicable to every pair of zones   (or interfaces)  with a default DROP,
to  catch traffic  matching no accept rule.

In practice... however  in the real world,  many firewalls get
configured with
this only in the INBOUND direction (Default deny Write packet to
Higher integrity level
zone  from lower level security zone),  and Default Accept   for
packet from more secure
zone to less secure zone, Since this has superior usability and is
 lower maintenance.

And for client devices, in a low security environment: with just a
simple Layer4 stateful
inspection firewall, this is probably the right solution.

"Permit only traffic that is necessary"

Only works out if you are able to rigidly define what exactly that
traffic is in advance.

Which is feasible to do for servers and other single-purpose devices,
but   very expensive to do for clients,   at least without a firewall aware of
the communications at the application layer   that can look at those
UDP connections
and say  "OKAY,  This is skype...  allow it",

Or...   "This connection going out on port 80..  it's not a valid HTTP request,
Drop the connection now and cache a rule to Deny further connections
to that IP:Port number pair.".


> the firewall type/implementation, that might be the rule that's
> lexically first or last (or maybe somewhere else).
> ---rsk
-- 
-JH
--- End Message ---

[no subject]

[Watson, Bob via NANOG]

--- Begin Message ---
Many of these churn rates result from problems  self inflicted hence all the 
dramatic sdn promises, popularity in abstractions, Api all the things, let's go 
yang/netconf and retrofit every ietf standard.  There's benefits  but gotta 
rant a little. What's better than correct? Well over correct of course.




> On May 7, 2015, at 12:17 PM, Josh Reynolds  wrote:
> 
> You know where these people wouldn't fit? W/ISPs.
> 
> Every three years or so you are forklifting the majority of your wireless 
> PtMP for either a new series or a totally different vendor. New backhaul 
> vendors often. You're building AC and DC power plants. You likely touch 
> Cisco, juniper, HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, 
> accedian/ciena, etc due to various client and network requirements all in the 
> same week, AND you have to make them work together nicely :)
> 
> It's not the environment for somebody like that, and I truly don't understand 
> how people of that.. "caliber" end up working on large scale WANs and global 
> transit networks.
> 
> Frankly, it scares me a bit.
> 
>> On May 7, 2015 9:07:35 AM AKDT, Craig  wrote:
>> we do "cry" when we interview people that claim to have "advanced
>> knowledge" of BGP and we ask them some very basic BGP questions, and we
>> get
>> a blank stare.
>> 
>> On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom  wrote:
>> 
>>> 
>>> Josh Reynolds  writes:
>>> 
 It really bothers me to see that people in this industry are so
 worried about a change of syntax or terminology. If there's one
 thing about the big vendors that bothers me, it's that these
 batteries of vendor specific tests have allowed many "techs" to get
 lazy. They simply can't seem to operate well, if at all, in a
 non-Cisco (primarily) environment.
>>> 
>>> If that bothers you, I recommend you not look at what passes for a
>>> "system administrator" these days.  It will make you cry.
>>> 
>>> -r
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
--- End Message ---

[no subject]

[Josh Reynolds via NANOG]

--- Begin Message ---

What churn rates are you talking about?

Josh Reynolds
CIO, SPITwSPOTS
www.spitwspots.com

On 05/07/2015 05:36 PM, Watson, Bob wrote:

Many of these churn rates result from problems  self inflicted hence all the 
dramatic sdn promises, popularity in abstractions, Api all the things, let's go 
yang/netconf and retrofit every ietf standard.  There's benefits  but gotta 
rant a little. What's better than correct? Well over correct of course.





On May 7, 2015, at 12:17 PM, Josh Reynolds  wrote:

You know where these people wouldn't fit? W/ISPs.

Every three years or so you are forklifting the majority of your wireless PtMP 
for either a new series or a totally different vendor. New backhaul vendors 
often. You're building AC and DC power plants. You likely touch Cisco, juniper, 
HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, accedian/ciena, 
etc due to various client and network requirements all in the same week, AND 
you have to make them work together nicely :)

It's not the environment for somebody like that, and I truly don't understand how people 
of that.. "caliber" end up working on large scale WANs and global transit 
networks.

Frankly, it scares me a bit.


On May 7, 2015 9:07:35 AM AKDT, Craig  wrote:
we do "cry" when we interview people that claim to have "advanced
knowledge" of BGP and we ask them some very basic BGP questions, and we
get
a blank stare.

On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom  wrote:


Josh Reynolds  writes:


It really bothers me to see that people in this industry are so
worried about a change of syntax or terminology. If there's one
thing about the big vendors that bothers me, it's that these
batteries of vendor specific tests have allowed many "techs" to get
lazy. They simply can't seem to operate well, if at all, in a
non-Cisco (primarily) environment.

If that bothers you, I recommend you not look at what passes for a
"system administrator" these days.  It will make you cry.

-r

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


--- End Message ---

[no subject]

[Paul Ferguson via NANOG]

--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Does anyone any else find it weird that the last dozen or so messages
from the list have been .eml attachments?

Or is it just me?

- - ferg


- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlVMF9IACgkQKJasdVTchbIvAQEA02tfEq/u6ytdP1i10DmpUmN3
mz+ntVUnbHhwqjL1AmMBALp/7M3kQ9oP2gH9Nc36IrLG7cM5cyG6nF4cebCgZnaT
=8S9U
-END PGP SIGNATURE-
--- End Message ---

[no subject]

[Mike Hammett via NANOG]

--- Begin Message ---
I've seen the same over here and also considered it weird. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message -

From: "Paul Ferguson via NANOG"  
To: "NANOG"  
Sent: Thursday, May 7, 2015 8:56:44 PM 


--- End Message ---

[no subject]

[Nathan Angelacos via NANOG]

--- Begin Message ---

Looks like there's an extra line break after:
--- End Message ---

[no subject]

[Nathan Angelacos via NANOG]

--- Begin Message ---

Looks like there's an extra line break after this header line:

X-Virus-Scanned: ClamAV using ClamSMTP

So the SMTP headers are getting partitioned.

--- End Message ---

[no subject]

[Joel Esler (jesler) via NANOG]

--- Begin Message ---
Seeing them here too.

--
Joel Esler
Sent from my iPhone

On May 7, 2015, at 9:58 PM, Paul Ferguson via NANOG 
mailto:nanog@nanog.org>> wrote:


--- End Message ---

Re:

[Christopher Morrow]

List-Post: 
From: Nathan Angelacos via NANOG 

you are seeing the effect of whatever that new 'we will stop spam with
dns records' process (not spf, not dkim ... the other one)

On Thu, May 7, 2015 at 10:04 PM, Nathan Angelacos via NANOG
 wrote:
>
>
> -- Forwarded message --
> From: Nathan Angelacos 
> To: nanog@nanog.org
> Cc:
> Date: Thu, 07 May 2015 22:04:05 -0400
> Subject: Re: Missing Subjects
> Looks like there's an extra line break after this header line:
>
> X-Virus-Scanned: ClamAV using ClamSMTP
>
> So the SMTP headers are getting partitioned.
>
>

Re:

[Ted Cooper]

On 08/05/15 11:58, Mike Hammett via NANOG wrote:
> I've seen the same over here and also considered it weird.

It looks exactly like the the DMARC senders treatment - I think there's
something wiggy and everyone is being treated as a DMARC encumbered sender.

Mailing list posts wrapped

[Andrew Koch]

There was an inadvertent DMARC handling setting applied to all posts. This has 
been corrected. Sorry for the disruption. 

Andrew Koch

Re:

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 5/7/2015 7:11 PM, Ted Cooper wrote:

> On 08/05/15 11:58, Mike Hammett via NANOG wrote:
>> I've seen the same over here and also considered it weird.
> 
> It looks exactly like the the DMARC senders treatment - I think
> there's something wiggy and everyone is being treated as a DMARC
> encumbered sender.
> 
> 


I'm on a gazillion lists, and this is the only one which seems to have
this particularly annoying problem.

- - ferg




- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlVMHhYACgkQKJasdVTchbIy+wEAzjAATu8LDTLVTBKPDIY/joKi
4/UXTi0ZS2cnlnp1SWQA/A4ZpErA6z05UiaQ6/J+Hyaw07tcY+PNowhIjKEJP6Fc
=IFIY
-END PGP SIGNATURE-

Re:

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 5/7/2015 7:23 PM, Paul Ferguson wrote:

> I'm on a gazillion lists, and this is the only one which seems to
> have this particularly annoying problem.

And fixed!

Apologies for the noise.

- - ferg


- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlVMHyAACgkQKJasdVTchbJlEAD9G6j3FfrDWMYgcniFCFu+z5cs
B5UlX7U5vhzfKQYIv0kBAKi4mq5LTC5ESuN7dUKuILvNKiicu69DqMgH6wmCftuF
=shQ2
-END PGP SIGNATURE-

Re: Alcatel-Lucent 7750 Service Router (SR)

[Watson, Bob]

Carrier oem churn (turnover /agitation cycles)
First mover for features happen and leapfrog but the ones that matter get 
adopted across the line in time.  


> On May 7, 2015, at 8:40 PM, Josh Reynolds  wrote:
> 
> What churn rates are you talking about?
> 
> Josh Reynolds
> CIO, SPITwSPOTS
> www.spitwspots.com
> 
>> On 05/07/2015 05:36 PM, Watson, Bob wrote:
>> Many of these churn rates result from problems  self inflicted hence all the 
>> dramatic sdn promises, popularity in abstractions, Api all the things, let's 
>> go yang/netconf and retrofit every ietf standard.  There's benefits  but 
>> gotta rant a little. What's better than correct? Well over correct of course.
>> 
>> 
>> 
>> 
>>> On May 7, 2015, at 12:17 PM, Josh Reynolds  wrote:
>>> 
>>> You know where these people wouldn't fit? W/ISPs.
>>> 
>>> Every three years or so you are forklifting the majority of your wireless 
>>> PtMP for either a new series or a totally different vendor. New backhaul 
>>> vendors often. You're building AC and DC power plants. You likely touch 
>>> Cisco, juniper, HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, 
>>> lucent, accedian/ciena, etc due to various client and network requirements 
>>> all in the same week, AND you have to make them work together nicely :)
>>> 
>>> It's not the environment for somebody like that, and I truly don't 
>>> understand how people of that.. "caliber" end up working on large scale 
>>> WANs and global transit networks.
>>> 
>>> Frankly, it scares me a bit.
>>> 
 On May 7, 2015 9:07:35 AM AKDT, Craig  wrote:
 we do "cry" when we interview people that claim to have "advanced
 knowledge" of BGP and we ask them some very basic BGP questions, and we
 get
 a blank stare.
 
 On Thu, May 7, 2015 at 12:49 PM, Rob Seastrom  wrote:
 
> Josh Reynolds  writes:
> 
>> It really bothers me to see that people in this industry are so
>> worried about a change of syntax or terminology. If there's one
>> thing about the big vendors that bothers me, it's that these
>> batteries of vendor specific tests have allowed many "techs" to get
>> lazy. They simply can't seem to operate well, if at all, in a
>> non-Cisco (primarily) environment.
> If that bothers you, I recommend you not look at what passes for a
> "system administrator" these days.  It will make you cry.
> 
> -r
>>> -- 
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 

[no subject]

[Mark Andrews]

In message , Paul Ferguson via N
ANOG writes:
> 
> Does anyone any else find it weird that the last dozen or so messages
> from the list have been .eml attachments?

Nanog is encapsulating messages that are DKIM signed.  Your mailer may
not be properly handling

Content-Type: message/rfc822
Content-Disposition: inline

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Mailing list posts wrapped

[Mark Andrews]

In message , Andrew Koch writes
:
> There was an inadvertent DMARC handling setting applied to all posts. This h=
> as been corrected. Sorry for the disruption.=20
> 
> Andrew Koch=

It was also not copying the Subject: to the outer SMTP envelope.
It would pay to check that this is being done to any message getting
encapsulated.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org