Re: [c-nsp] Best practise/security design for BGP and OSPF

[CiscoNSP List]

Cheers for the replies - Just to clarify, these templates were for purely 
PE->RR (Not for transit), we do run key-chain auth on OSPF, and I was hoping to 
do likewise for iBGP -> RR's, but I dont *think* key-chains are supported in XE 
(Yet?)...I need to do some more reading, but I believe XR supports it, but not 
XE?  Regarding TTL(In both OSPF and BGP)hop count can be arbitrary, if 
we encounter a link failure...do we just use worse case scenario hops ?  Is 
there anything you'd add/remove from the templates that Ive sent through?  
(Obviously soft-reconfig inbound chews memory, and can be removed, but things 
like max-prefix .have it currently set at warning only...recommend killing 
the session for x minutes if it's exceed?)any other suggestions are greatly 
appreciatedthanks.



From: Saku Ytti 
Sent: Tuesday, 23 May 2017 7:10 PM
To: adamv0...@netconsultings.com
Cc: CiscoNSP List; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Best practise/security design for BGP and OSPF

On 23 May 2017 at 12:00,   wrote:

Hey,

> Regarding OSPF,
> Best security is to use it solely for routing PE loopbacks (i.e. no
> connectivity outside the core).

But because it's IP, you might receive spooffed packet further down
the line and believe you received it from far-end. So OP's question
about TTL-security is valid one, and I'd support that. I'd also run
MD5 auth.
But of course if you have good iACL, stopping internet from sending
other than ICMP, UDP highports to links and loops, you should be
pretty safe.

ISIS and OSPF have quite interesting properties, ISIS is more secure
out-of-the-box, but in many cases you cannot stop box from punting
CLNS packets, so any edge-interface may reach control-plane by crafted
CLNS packets (without ISIS being configured on the interface).
Where-as OSPF out-of-the-box is less secure due to IP, but pretty much
every box supports ACLs, allowing you to consistently protect box.'

--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco ASR vs Juniper

[Mark Tinka]

On 5/24/17 4:35 PM, Aaron Gould wrote:

> About the MX104 and ACX5000
>
> I have ~7,000 dsl customers being nat'd behind /24 of address space on a
> pair of MX104's... they run nicely on two mpls l3vpn's... nat inside vrf
> (ri) and nat outside vrf (ri)

The RE sucks. It's too slow.

We are now running them out in some sites and replacing them with
MX480's. Pity, since the MX104 data plane is solid.


>
> I have deployed (~30) ACX5048's as mpls p's and pe's and they are running
> well.  I have hit a bug with VPLS that requires a vpls routing-instance
> bounce to revive, but JTAC just told me the PR is hitting D20 software and
> fixed in D25 still need to test that.  But all in all, I like the
> ACX5048's.

For our use-case, the Broadcom in those routers presents some
limitations Juniper are never going to fix.

That said, the Broadcom chipset does make them cheaper, but you also pay
for that in other ways.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco ASR vs Juniper

[Aaron Gould]

...i re-read some of your criteria... ummm, so I use MX104's and ACX5048's
with MP-iBGP for just learning my internal core routes, not big table for
world routes... so for what I use those boxes for, they are nice.

-Aaron

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Aaron Gould
Sent: Wednesday, May 24, 2017 9:36 AM
To: 'Mark Tinka' ; 'Mark Mason'
; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cisco ASR vs Juniper

About the MX104 and ACX5000

I have ~7,000 dsl customers being nat'd behind /24 of address space on a
pair of MX104's... they run nicely on two mpls l3vpn's... nat inside vrf
(ri) and nat outside vrf (ri)

I have deployed (~30) ACX5048's as mpls p's and pe's and they are running
well.  I have hit a bug with VPLS that requires a vpls routing-instance
bounce to revive, but JTAC just told me the PR is hitting D20 software and
fixed in D25 still need to test that.  But all in all, I like the
ACX5048's.

-Aaron

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark
Tinka
Sent: Wednesday, May 24, 2017 2:16 AM
To: Mark Mason ; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cisco ASR vs Juniper



On 5/9/17 7:29 PM, Mark Mason wrote:

> Alright crowd...Ready the rifles and prepare for battle...Cisco ASR or
Juniper. Cost, operability, chassis lifespan new vs. old, memory
requirements, etc. So many details. Feel free to take the post anywhere
you'd like.

I'm really liking the new ASR1000 family of routers.

But we did the month since December last year, and any way we cut it, the
MX480 works out cheaper.

Stay away from the MX104 or ACX5000.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco ASR vs Juniper

[Aaron Gould]

About the MX104 and ACX5000

I have ~7,000 dsl customers being nat'd behind /24 of address space on a
pair of MX104's... they run nicely on two mpls l3vpn's... nat inside vrf
(ri) and nat outside vrf (ri)

I have deployed (~30) ACX5048's as mpls p's and pe's and they are running
well.  I have hit a bug with VPLS that requires a vpls routing-instance
bounce to revive, but JTAC just told me the PR is hitting D20 software and
fixed in D25 still need to test that.  But all in all, I like the
ACX5048's.

-Aaron

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark
Tinka
Sent: Wednesday, May 24, 2017 2:16 AM
To: Mark Mason ; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cisco ASR vs Juniper



On 5/9/17 7:29 PM, Mark Mason wrote:

> Alright crowd...Ready the rifles and prepare for battle...Cisco ASR or
Juniper. Cost, operability, chassis lifespan new vs. old, memory
requirements, etc. So many details. Feel free to take the post anywhere
you'd like.

I'm really liking the new ASR1000 family of routers.

But we did the month since December last year, and any way we cut it, the
MX480 works out cheaper.

Stay away from the MX104 or ACX5000.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco ASR vs Juniper

[adamv0025]

> Mark Mason
> Sent: Tuesday, May 09, 2017 6:29 PM
> 
> Alright crowd...Ready the rifles and prepare for battle...Cisco ASR or
Juniper.
> Cost, operability, chassis lifespan new vs. old, memory requirements, etc.
So
> many details. Feel free to take the post anywhere you'd like.
> 
> Deployments:
> EDGE
> Pure internet router/edge with single eBGP toward ISP - 10Gb up to ISP and
> 10Gb down to Aggregation Point
> MX10 w/ licensing get me 4x10Gb (but sys cap. At 20Gb?), MX40 vs ASR1001X
> (or ASR1001-HX)
> +pretty vanilla installation
> +not running security at this level
> +just a router doing routing
> +single eBGP so/so on memory requirements single iBGP down to Core/Agg
> 
If it's just pure ipv4 Internet routing (i.e. no need for protecting high
priority packets) you might be ok even with 1st gen Trio from Juniper so
either one would do I guess.  

> AGGREGATION
> Internet Edge Aggregation/multiple iBGP sessions toward edge routers
> MX104 or MX240 (or greater chassis lineup) vs ASR9k
> +HUGE MEMORY requirements
> +Multiple BGP aggregation feeds
> +Installation of best routes from MULTIPLE carriers
> 
Yeah smells like big tables and long FIB download times.
You might want to use BGP PIC to speed things up here and be part of the
solution, but unfortunately Junos doesn't support BGP PIC for pure IPv4. 
MX240+ and ASR9k are modular so the comparison really depends on which
line-cards you're considering for each platform. 
But in general you might want to stay away from cards using first generation
of Trio chipsets and Gen1.5 Trio voodoo. And the same applies to first gen
(Trident) ASR9k LCs.   
XR has so much better BGP implementation than Junos. 


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] NCS4200 - re-badged ASR920 / ASR900 ?

[adamv0025]

> Saku Ytti
> Sent: Wednesday, May 24, 2017 9:50 AM
> 
> On 24 May 2017 at 09:32, Mark Tinka  wrote:
> 
> > Personally, I'd still prefer IOS XE on the ASR920. IOS XR is a little
> > bloated, and to keep the ASR920 competitive, I don't think it will
> > make sense to increase hardware resources needed to run IOS XR.
> 
> Just add commit to IOS-XE and maybe even RPL and we're good.
> 
..and ORR as Mark mentioned and... the list goes on, 
...or just use the damn XR instead of investing time to make XE look more
like XR :)

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] vrrpv3 + IPv6 hangs in INIT state

[Rolf Hanßen]

Hi Nick,

yes, that's it.
Comes up now, thanks for the hint.

kind regards
Rolf

> Rolf Hanßen wrote:
>> I just tried to get VRRP + IPv6 running on a Sup2T with 15.1(2)SY1.
>> I enabled VRRPv3 and it works at least for IPv4.
>
> Yeah, this caught me too.  The primary ipv6 address for a vrrpv3 needs
> to be an ipv6 link-local address:
>
>> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhrp-vrrpv3.html
>
>> VRRPv3 for IPv6 requires that a primary virtual link-local IPv6
>> address is configured to allow the group to operate. After the
>> primary link-local IPv6 address is established on the group, you can
>> add the secondary global addresses.
>
> So your configuration should look like this:
>
> fhrp version vrrp v3
> interface Vlan2000
>  vrrp 6 address-family ipv6
>   address fe80::1 primary
>   address :::::1/64
>   exit-vrrp
> end
>
> Nick


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] NCS4200 - re-badged ASR920 / ASR900 ?

[Saku Ytti]

On 24 May 2017 at 09:32, Mark Tinka  wrote:

> Personally, I'd still prefer IOS XE on the ASR920. IOS XR is a little
> bloated, and to keep the ASR920 competitive, I don't think it will make
> sense to increase hardware resources needed to run IOS XR.

Just add commit to IOS-XE and maybe even RPL and we're good.

To be fair, i'm not sure if IOS-XR is inherently that much more
expensive from HW POV. Probably somewhat more memory hungry due to IPC
being too slow, leading to duplication of state in various processes,
but DRAM isn't going to be large contributor to the BOM.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] CRS keep generating errror "cp: Can't open destination file. (/harddisk:/bcm-logger...)"

[Try Chhay]

Hi All,

A new CRS8 keeps generating messages as the below message on the console
and cannot get in with default user Administrator/ciscocisco

cp: Can't open destination file.
(/harddisk:/bcm-logger/bcm-20170524-224748/node0_RP1_CPU0/persist.0): No
such file or directory
cp: Can't open destination file.
(/harddisk:/bcm-logger/bcm-20170524-224748/node0_RP1_CPU0/stp_int.log.0):
No such file or directory
cp: Can't open destination file.
(/harddisk:/bcm-logger/bcm-20170524-224748/node0_RP1_CPU0/bcm.log.0): No
such file or directory
cp: Can't open destination file.
(/harddisk:/bcm-logger/bcm-20170524-224748/node0_RP1_CPU0/persist.1): No
such file or directory
cp: Can't open destination file.
(/harddisk:/bcm-logger/bcm-20170524-224748/node0_RP1_CPU0/stp_int.log.1):
No such file or directory
cp: Can't open destination file.
(/harddisk:/bcm-logger/bcm-20170524-224748/node0_RP1_CPU0/bcm.log.1): No
such file or directory

Cisco CRS8 version is Version 5.1.3. Could you please help to advise how to
fix this issue? Thank you

Kind regards,
Try C
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco ASR vs Juniper

[Mark Tinka]

On 5/9/17 7:29 PM, Mark Mason wrote:

> Alright crowd...Ready the rifles and prepare for battle...Cisco ASR or 
> Juniper. Cost, operability, chassis lifespan new vs. old, memory 
> requirements, etc. So many details. Feel free to take the post anywhere you'd 
> like.

I'm really liking the new ASR1000 family of routers.

But we did the month since December last year, and any way we cut it,
the MX480 works out cheaper.

Stay away from the MX104 or ACX5000.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Typhoon support on XRe

[Mark Tinka]

On 5/2/17 8:22 AM, James Jun wrote:

>
> To be honest, MX104 seems kind of same story on Juniper land, it was cool to
> see modular RE back when it was introduced and product seemed to have good 
> potential on design overall, but at this point, I think it's best to wait for
> the upcoming Summit1/3 routers or get the big boy MX.

MX104 is dead. Power budget for an x86-based RE was too thin; and
Juniper probably knew it before they even put the box out to market.

MX204 is the future there. Pity, because the ASR1000 will continue to
run unabated...

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Typhoon support on XRe

[Mark Tinka]

On 5/1/17 7:24 PM, Saku Ytti wrote:

> Clearly home users aren't driving 10GE, 100GE, 400GE demand, and I
> don't anticipate this changing soon. Perhaps vendors still think
> market is same as it was 5-10 years ago, where everyone wanted faster
> connection on every cycle, but we're now in era where there are
> different Internet needs, some of those Internet needs have no need
> for higher capacity and never will. I suspect the market of lower rate
> ports is larger than vendors think it is.

Especially when you consider that the Internet isn't just North America
and parts of Europe.

But alas, our popular friendly vendors generally develop for these regions.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Typhoon support on XRe

[Mark Tinka]

On 5/1/17 7:24 PM, Saku Ytti wrote:

> Warning largely content free pondering follows.
>
> This is not XR specific, market is no longer driven by service
> providers/access networks, but by content networks. And content
> networks want ever faster interfaces in ever denser form factor.
> 1GE is gone, non-LR 10GE is essentially gone.

This is not only happening in the IP/MPLS space, but also in the
Transport space.

It's quite unnerving watching all of this happen...

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP-ORR Scaling on vRR

[Mark Tinka]

On 4/28/17 4:54 PM, Dhamija Amit via cisco-nsp wrote:

> Hi
> I am testing  the feature BGP-ORR to have a centralized Route Reflectors in 
> our network.
> The feature works well and it ensures optimal routing to the nearest clients.
> I have some concerns on the scaling of this feature, with around 150 ORR 
> Clients/Groups in one RR and with scale of Internet Prefixes 
>
> around 650K Prefixes with 10M Paths it takes around hours to converge the 
> prefixes to the rest of the client routers.
> I understand vRR should perform best path computation per update-group and 
> each ORR client is one update group, so with around 150 update groups each 
> prefix needs to be updated per group.
> Can some one give insights on how many ORR clients do we need to configure in 
> one vRR to have optimal convergence in network.

Still chasing Cisco to add this to CSR1000v :-\...

Mark.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] NCS4200 - re-badged ASR920 / ASR900 ?

[Mark Tinka]

On 4/26/17 9:23 AM, George Giannousopoulos wrote:

> Hi,
>
> Concerning IOS-XR on ASR-900 series, during a recent meeting with Cisco we
> were told that it's coming with RSP4..
> Haven't heard anything for the ASR920 though..

Personally, I'd still prefer IOS XE on the ASR920. IOS XR is a little
bloated, and to keep the ASR920 competitive, I don't think it will make
sense to increase hardware resources needed to run IOS XR.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] NCS4200 - re-badged ASR920 / ASR900 ?

[Mark Tinka]

On 4/25/17 8:22 AM, Mattias Gyllenvarg wrote:

> Perhaps it will take the place of the ME3800X?

The ME3800X still has larger resources than an ME3600X, which is on par
with the ASR920.

I suspect a newer ASR9x0 will replace the ME3800X.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/