Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Encrypted MPLS between MXes

On 27 March 2016 at 23:44, Alex K. wrote: > But as far as Juniper documentation is concerned, MIC-3D-20GE-SFP-E only > supports MACSec. As Trio does not support today MacSec, you'll need specific MICs. You gotta wait or use workaround like Tim. -- ++ytti

Re: [j-nsp] Encrypted MPLS between MXes

Yes, sounds great. But as far as Juniper documentation is concerned, MIC-3D-20GE-SFP-E only supports MACSec. Am I missing something? בתאריך 27 במרץ 2016 21:32,‏ "Tim Jackson" כתב: > That's good news to hear.. Today EX4600 was my solution, and it actually > works quite

Re: [j-nsp] Encrypted MPLS between MXes

That's good news to hear.. Today EX4600 was my solution, and it actually works quite well. On Sun, Mar 27, 2016, 1:27 PM Saku Ytti wrote: > On 27 March 2016 at 21:12, Tim Jackson wrote: > > Run EX4600s as your P routers, and encrypt w/ MACSec on them. > >

Re: [j-nsp] Encrypted MPLS between MXes

On 27 March 2016 at 21:12, Tim Jackson wrote: > Run EX4600s as your P routers, and encrypt w/ MACSec on them. IIRC next-gen Trio does MacSec, so all ports will support it. -- ++ytti ___ juniper-nsp mailing list

Re: [j-nsp] Encrypted MPLS between MXes

Run EX4600s as your P routers, and encrypt w/ MACSec on them. On Mar 27, 2016 1:11 PM, "Alex K." wrote: > Hello everyone, > > I was just wondering if there's a new way to encrypt MPLS traffic between > MX boxes without the good old encrypted GRE? > > MPLS over encrypted

[j-nsp] Encrypted MPLS between MXes

Hello everyone, I was just wondering if there's a new way to encrypt MPLS traffic between MX boxes without the good old encrypted GRE? MPLS over encrypted MACSec links, encrypted internal tunnels between logical systems, everything goes. If that was your network, what's the craziest idea you'd

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Separate internet transit network versus converged

On 27 March 2016 at 13:37, Mark Tinka wrote: Hey, > As costs and management got out of control, they run l3vpn's and > Internet in the same chassis, but on different line cards. > > Eventually, everything converged. I tend to agree. If there is significant CAPEX delta

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Separate internet transit network versus converged

On 27/Mar/16 01:46, Mark Tees wrote: > My gut feeling is that the safer option is to run things separately > but I also do not wish to create an administrative nightmare for other > people to work on the network. > > Any input, experience, or additional points would be greatly appreciated. I

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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.

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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

Re: [j-nsp] Core network design for an ISP

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