Le 29/03/2016 15:46, Saku Ytti a écrit :
That is just 10min look. It's very complicated approach yet not
particularly secure one. But at least it's less broken than Cymru
secure template.
Few basic principles
a) never use 'port', all bidir TCP needs 'active' and 'passive' rule separately
b)
On 29 March 2016 at 16:54, Kevin Wormington wrote:
> Great points. Would you care to share an example template implementing your
> suggestions?
I don't think I ethically can. I have three but they've all been paid
for. I'm waiting to find some not-for-profit project to publish
something in git
On 29 March 2016 at 16:05, Mark Tees wrote:
> There is a very nice example in the Doug Hanks MX book of what a
> comprehensive lo0 filter looks like. Complete with instructions on how to
> roll it out from memory.
I arrogantly stand behind my statement that all lo filters I've seen
are fundamenta
There is a very nice example in the Doug Hanks MX book of what a
comprehensive lo0 filter looks like. Complete with instructions on how to
roll it out from memory.
On Wednesday, 30 March 2016, Paul S. wrote:
> Hi Saku,
>
> What would a good lo0 filter template look like, in your opinion then?
>
Hi Saku,
What would a good lo0 filter template look like, in your opinion then?
On 3/26/2016 02:50 AM, Saku Ytti wrote:
And I've not yet read any lo0 filter anywhere which isn't
fundamentally broken, including cymry secure templates.
___
juniper-nsp
On 27/Mar/16 13:47, Saku Ytti wrote:
> I think this is not really delivering the fewer state/protocols?
> You're going to run another LDP session, exposing new LDP code. It's
> probably going to more fragile than either native IPv6 or 6PE.
> I would not touch LDPv6 ever. I'd do 6PE or SR.
I won
On 27 March 2016 at 14:30, Mark Tinka wrote:
> I'm getting close.
>
> MPLSv6 for LDP is now available in IOS XR. Junos 16 will have support as
> well, if they stick to the schedule.
I think this is not really delivering the fewer state/protocols?
You're going to run another LDP session, exposing
On 27/Mar/16 13:25, Saku Ytti wrote:
> Agreed, in edge there is no escaping producing the edge service. But
> in core you're protected from defects in large amount of edge services
> code if you make core MPLS only.
I'm getting close.
MPLSv6 for LDP is now available in IOS XR. Junos 16 will ha
On 27 March 2016 at 14:15, Mark Tinka wrote:
> I could also have hit the same issue if MPLS were natively encapsulating
> IPv6, assuming the bug was exposed to both planes. When you're stuffed,
> you're stuffed.
Agreed, in edge there is no escaping producing the edge service. But
in core you're
On 27/Mar/16 13:06, Saku Ytti wrote:
> You just as well might have hit IPv6 bug which crashes iosd ending in
> completely opposite conclusion. I think it's anecdotal. I think math
> supports fewer protocols and states. With sufficient large sample
> rate, you're always going to lose with your de
On 27 March 2016 at 13:43, Mark Tinka wrote:
> We hit a severe Cisco bug on the ASR920 that broke MPLS. This broke IPv4
> traffic as it is encapsulated in MPLS.
You just as well might have hit IPv6 bug which crashes iosd ending in
completely opposite conclusion. I think it's anecdotal. I think m
On 27/Mar/16 12:30, Saku Ytti wrote:
> I hope I was clear enough that this is absolutely more important that
> edge/core separation. But if you organically have enough MPCs and
> ports, that you don't need to invest on more cards, then you should
> separate edge+core as well.
> But of course if
On 27/Mar/16 12:27, Saku Ytti wrote:
> I understand this argument, but I feel it's opposite. Let's assume
> there is 5% chance of failure to occur in some time frame, i.e. 95% of
> not occurring. If your control-plane depends on two separate instance
> working to produce services then you have o
On 27 March 2016 at 13:24, Mark Tinka wrote:
>> Interesting, but I have make the opposite, aka mixed edge and core
>> link on MPC. The idea was to provide redundancy in case of one MPC
>> failure.
>
> This is what we do.
>
> I can't tell you how many times it has saved us when MPC's die randomly.
On 25/Mar/16 18:01, Raphael Mazelier wrote:
>
> Multiple loopbacks are always a good idea.
> It make maintenance much more painless.
> One loopback for inet, one for inet6, one for *vpn.
> Also colleague of mine point that is good to separate familly who
> support GRES from those who not.
I've
On 27 March 2016 at 13:20, Mark Tinka wrote:
> I don't like 6PE due to fate-sharing, but I know a lot of people run it
> because it reduces workload.
I understand this argument, but I feel it's opposite. Let's assume
there is 5% chance of failure to occur in some time frame, i.e. 95% of
not occur
On 25/Mar/16 17:46, Raphael Mazelier wrote:
>
>
> Interesting, but I have make the opposite, aka mixed edge and core
> link on MPC. The idea was to provide redundancy in case of one MPC
> failure.
This is what we do.
I can't tell you how many times it has saved us when MPC's die randomly.
Mar
On 25/Mar/16 17:28, Raphael Mazelier wrote:
>
>
> What the point to separate upstream and downstream port on different
> MPC ? (apart FIB size)
I wouldn't put them on separate MPC's - I'd split it.
Two links to the core on separate MPC's + two links to customers on
separate MPC's.
That gives
On 25/Mar/16 17:20, Saku Ytti wrote:
> It should be safe for at least 1.5M IPv4 FIB + reasonable IPv6 FIB.
> It's pretty far future, unless you have large L3 MPLS VPN tables in
> addition.
>
> There are some other benefits running separate MPC for edge and core,
> but it might not make financial
On 25/Mar/16 17:07, Saku Ytti wrote:
> If you're gonna run L3 MPLS VPN's for what ever purpose, or might run
> in future, I strongly recommend putting Internet in VRF. Global table
> is annoying special case and doing route injection between global
> table and vrf is huge PITA in JunOS. Having I
On 25 March 2016 at 22:52, Adam Vitkovsky wrote:
> Not a fan of VRF based features or localization
> As far as I know you'll get involved with lookups on multiple NPUs either
> way, though I'm not aware of any multiple fabric travels (apart from m-cast
> replication god forbid :) )
As far as I
> Saku Ytti [mailto:s...@ytti.fi]
> Sent: Friday, March 25, 2016 7:56 PM
>
> On 25 March 2016 at 21:39, Adam Vitkovsky
> wrote:
>
> >> I believe Luis refers to FIB localisation introduced in 12.3:
> >>
> http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/f
> >> ib-localization-ove
On 25 March 2016 at 21:39, Adam Vitkovsky wrote:
>> I believe Luis refers to FIB localisation introduced in 12.3:
>> http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/f
>> ib-localization-overview.html>
>>
> Hmm interesting concept -then with this feature enabled where would the
of business is at
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
-Original Message-
> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Friday, March 25, 2016 5:50 PM
> To: Adam Vitkovsky
> Cc: Luis Balbinot; jnsp list
> Subject: Re: [j-nsp] Core network design for an I
On 25 March 2016 at 19:42, Adam Vitkovsky wrote:
Hey Adam,
> My understanding is that MX does not support(yet) "selective VRF download"
> (don't know the juniper name for the feature)
> Anyways Cisco stopped using it as it was causing more problems than it solved.
I believe Luis refers to FIB
Hey Saku,
> Saku Ytti
> Sent: Friday, March 25, 2016 3:21 PM
>
> On 25 March 2016 at 03:02, Luis Balbinot wrote:
>
> > A good practice on MX480s would be to keep upstream and downstream
> > ports at separate MPCs if possible. Depending on your config the
> > standard 256M RLDRAM from some cards m
Le 25/03/2016 02:02, Luis Balbinot a écrit :
For iBGP consider multiple loopback addresses for different families. I'd
do v4 and v6 (6PE with MPLS) with one family and inet-vpn, l2vpn, etc on
another one. Even with newer REs a full table is taking quite some time to
come up.
Multiple loopbac
On 25 March 2016 at 17:46, Raphael Mazelier wrote:
> Interesting, but I have make the opposite, aka mixed edge and core link on
> MPC. The idea was to provide redundancy in case of one MPC failure.
Yes this is absolutely more important. So if you you can buy just 2
MPC, then for sure mix and matc
Le 25/03/2016 16:37, Saku Ytti a écrit :
It's minor benefit and I wouldn't separate MPCs based on this. Only
reason I'd do edge/core MPC separation if I'm anyhow going to have
enough MPC/ports to pull it off without extra CAPEX, then it would be
no brainer.
Interesting, but I have make the
On 25 March 2016 at 17:28, Raphael Mazelier wrote:
> What the point to separate upstream and downstream port on different MPC ?
> (apart FIB size)
If you've cocked up your lo0/ddos-protection config (have not yet seen
network which has not) customer side attack won't bring your device
down if it
Le 25/03/2016 16:20, Saku Ytti a écrit :
On 25 March 2016 at 03:02, Luis Balbinot wrote:
A good practice on MX480s would be to keep upstream and downstream ports at
separate MPCs if possible. Depending on your config the standard 256M
RLDRAM from some cards might be an issue in the not so ne
On 25 March 2016 at 03:02, Luis Balbinot wrote:
> A good practice on MX480s would be to keep upstream and downstream ports at
> separate MPCs if possible. Depending on your config the standard 256M
> RLDRAM from some cards might be an issue in the not so near future. I'm not
> sure how much RLDRA
On 25 March 2016 at 01:57, Matthew Crocker wrote:
Hey,
> I’m running MPLS now and have full tables in the default route instance.
> Does it make more sense (i.e. more secure core) to run full tables in a
> separate virtual-router? I’ve been doing this small ISP thing for 20+ years,
> Cisco
Might reach out to your Juniper SE.. I believe they have some internal “gold
configs” for different sized ISPs that have been well tested internally. One of
their configs might make a good base to start from.
> On Mar 24, 2016, at 6:57 PM, Matthew Crocker wrote:
>
>
>
> Hello,
>
> What is
There are so much debate on how to construct a good network core,
but if you don't need special features, I will stay with something very
simple :
- IGP : ISIS (over OSPF because it doesn't relies on IP, more flexible,
more simple) with only loopback
- iBGP full mesh with DMZ in the main table
On 25/Mar/16 01:57, Matthew Crocker wrote:
>
> Hello,
>
> What is the current best practice for carrying full tables in MX series
> routers? I have 3 new MX480s coming soon and will use them to rebuild my
> core network (currently a mix of MX240 & MX80 routers). MPC-NG (w/ 20x1g &
> 10x10g
On 25/Mar/16 03:02, Luis Balbinot wrote:
> For iBGP consider multiple loopback addresses for different families. I'd
> do v4 and v6 (6PE with MPLS) with one family and inet-vpn, l2vpn, etc on
> another one. Even with newer REs a full table is taking quite some time to
> come up.
I'd rather nati
A good practice on MX480s would be to keep upstream and downstream ports at
separate MPCs if possible. Depending on your config the standard 256M
RLDRAM from some cards might be an issue in the not so near future. I'm not
sure how much RLDRAM those NG cards have though.
I don't see any advantages
Hello,
What is the current best practice for carrying full tables in MX series
routers? I have 3 new MX480s coming soon and will use them to rebuild my core
network (currently a mix of MX240 & MX80 routers). MPC-NG (w/ 20x1g & 10x10g
MICS )& RE-S-X6-64G-BB.
I’m running MPLS now and have f
39 matches
Mail list logo
