Re: [j-nsp] Junos and single IPv6 link-local address per IFL
On Fri, Jan 25, 2019 at 12:02:55AM +0200, Martin T wrote:
> Hi Charles,
>
> > Link-Local addresses should be in fe80::/64, not fe80::/10.
>
> As Eldon already mentioned, then I actually used /64 prefix in my
> examples. However, any address from address block fe80::/10 should be
> fine. The point is, that for some reason, Junos allows to have only
> one link-local address per IFL.
Yes, I see that Junos only allows one link-local. But I stand by my
comment--you should not be creating link locals outside of
fe80:::::/64.
> root@vmx1# show | compare
> [edit interfaces ge-0/0/9 unit 0 family inet6]
> address fe80::206:aff:fe0e:fffa/64 { ... }
> + address fe80:1::206:aff:fe0e:fffa/64;
fe80:0001::::/64 is not valid as a link-local address and I've run into
vendors that have issues with such addresses. See RFC 4291 Section 2.5.6.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos and single IPv6 link-local address per IFL
Hi Charles, > Link-Local addresses should be in fe80::/64, not fe80::/10. As Eldon already mentioned, then I actually used /64 prefix in my examples. However, any address from address block fe80::/10 should be fine. The point is, that for some reason, Junos allows to have only one link-local address per IFL. Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
Best option would be the coloring scheme along with explicit excludes in the config for the LSPs you dont want to go through said device. On Thu, Jan 24, 2019 at 3:25 PM Luis Balbinot wrote: > That’s a good idea. I’m not 100% sure that this will prevent the creation > of bypass LSPs but I’ll give it a try. > > Thanks! > > Luis > > On Thu, 24 Jan 2019 at 18:01 Colby Barth wrote: > > > Luis- > > > > You could probably set the overload bit. > > > > -Colby > > > > On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" < > > juniper-nsp-boun...@puck.nether.net on behalf of m...@geordish.org> wrote: > > > > I'm not aware of any option that will do this. > > > > The three solutions that I can think of are: > > Link colouring like Adam suggests > > An explicit path that avoids the interfaces you are worried about > > Set the RSVP cost for the interfaces really high > > > > Dave > > > > On Thu, 24 Jan 2019 at 17:01, Luis Balbinot > > wrote: > > > > > It's a permanent thing. > > > > > > These boxes are PE routers that are not supposed to handle transit > > > traffic but during certain network events a few FRR bypass LSPs are > > > established through them because that's the only remaining path. > > > > > > Something easier like a "no-eligible-backup" toggle like the one we > > > have with OSPF LFA would be nice. > > > > > > Luis > > > > > > On Thu, Jan 24, 2019 at 2:53 PM > > wrote: > > > > > > > > > Luis Balbinot > > > > > Sent: Thursday, January 24, 2019 4:45 PM > > > > > > > > > > Hi. > > > > > > > > > > How could I prevent a device from getting transit RSVP LSPs > being > > > > > established through it? I only want it to accept ingress LSPs > > destined > > > to > > > > that > > > > > box. > > > > > > > > > If this is a permanent thing, > > > > You could create a colouring scheme where all links connected to > > this > > > node > > > > have to be avoided by all LSPs with the exception of LSPs > > terminated on > > > this > > > > node (or originated by this node). > > > > > > > > If this is a maintenance thing, > > > > There's a command that can be enabled to drain all transit LSPs > > out the > > > box. > > > > But, all the LSPs would need to be configured with this > capability > > in the > > > > first place. > > > > > > > > > > > > adam > > > > > > > ___ > > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e= > > > > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e= > > > > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
That’s a good idea. I’m not 100% sure that this will prevent the creation of bypass LSPs but I’ll give it a try. Thanks! Luis On Thu, 24 Jan 2019 at 18:01 Colby Barth wrote: > Luis- > > You could probably set the overload bit. > > -Colby > > On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" < > juniper-nsp-boun...@puck.nether.net on behalf of m...@geordish.org> wrote: > > I'm not aware of any option that will do this. > > The three solutions that I can think of are: > Link colouring like Adam suggests > An explicit path that avoids the interfaces you are worried about > Set the RSVP cost for the interfaces really high > > Dave > > On Thu, 24 Jan 2019 at 17:01, Luis Balbinot > wrote: > > > It's a permanent thing. > > > > These boxes are PE routers that are not supposed to handle transit > > traffic but during certain network events a few FRR bypass LSPs are > > established through them because that's the only remaining path. > > > > Something easier like a "no-eligible-backup" toggle like the one we > > have with OSPF LFA would be nice. > > > > Luis > > > > On Thu, Jan 24, 2019 at 2:53 PM > wrote: > > > > > > > Luis Balbinot > > > > Sent: Thursday, January 24, 2019 4:45 PM > > > > > > > > Hi. > > > > > > > > How could I prevent a device from getting transit RSVP LSPs being > > > > established through it? I only want it to accept ingress LSPs > destined > > to > > > that > > > > box. > > > > > > > If this is a permanent thing, > > > You could create a colouring scheme where all links connected to > this > > node > > > have to be avoided by all LSPs with the exception of LSPs > terminated on > > this > > > node (or originated by this node). > > > > > > If this is a maintenance thing, > > > There's a command that can be enabled to drain all transit LSPs > out the > > box. > > > But, all the LSPs would need to be configured with this capability > in the > > > first place. > > > > > > > > > adam > > > > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e= > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e= > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
Luis- You could probably set the overload bit. -Colby On 1/24/19, 1:10 PM, "juniper-nsp on behalf of Dave Bell" wrote: I'm not aware of any option that will do this. The three solutions that I can think of are: Link colouring like Adam suggests An explicit path that avoids the interfaces you are worried about Set the RSVP cost for the interfaces really high Dave On Thu, 24 Jan 2019 at 17:01, Luis Balbinot wrote: > It's a permanent thing. > > These boxes are PE routers that are not supposed to handle transit > traffic but during certain network events a few FRR bypass LSPs are > established through them because that's the only remaining path. > > Something easier like a "no-eligible-backup" toggle like the one we > have with OSPF LFA would be nice. > > Luis > > On Thu, Jan 24, 2019 at 2:53 PM wrote: > > > > > Luis Balbinot > > > Sent: Thursday, January 24, 2019 4:45 PM > > > > > > Hi. > > > > > > How could I prevent a device from getting transit RSVP LSPs being > > > established through it? I only want it to accept ingress LSPs destined > to > > that > > > box. > > > > > If this is a permanent thing, > > You could create a colouring scheme where all links connected to this > node > > have to be avoided by all LSPs with the exception of LSPs terminated on > this > > node (or originated by this node). > > > > If this is a maintenance thing, > > There's a command that can be enabled to drain all transit LSPs out the > box. > > But, all the LSPs would need to be configured with this capability in the > > first place. > > > > > > adam > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e= > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3lVLtwWQROCdl4DSF6Gy-pAupMaX1AvOyICNqk7ML5U&m=xjETS_MpBQ5yJFgNOTwIgxvck93EOjA7sbBBzWEr7sE&s=fIjs_f4CA6mUSiUhoRhAYrV4mmOT5lDwryzIvSgr-KU&e= ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Dynamic VPN Stopped Working
Dears I have Juniper SRX210h configured with multiple IPSEC site to site VPNs which are still working! I have configured dynamic VPN (remote access) which was working and stopped working since a while for all configured users and I have no idea of the root cause Any ideas guys? Appreciated BR, Mohammad ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
I'm not aware of any option that will do this. The three solutions that I can think of are: Link colouring like Adam suggests An explicit path that avoids the interfaces you are worried about Set the RSVP cost for the interfaces really high Dave On Thu, 24 Jan 2019 at 17:01, Luis Balbinot wrote: > It's a permanent thing. > > These boxes are PE routers that are not supposed to handle transit > traffic but during certain network events a few FRR bypass LSPs are > established through them because that's the only remaining path. > > Something easier like a "no-eligible-backup" toggle like the one we > have with OSPF LFA would be nice. > > Luis > > On Thu, Jan 24, 2019 at 2:53 PM wrote: > > > > > Luis Balbinot > > > Sent: Thursday, January 24, 2019 4:45 PM > > > > > > Hi. > > > > > > How could I prevent a device from getting transit RSVP LSPs being > > > established through it? I only want it to accept ingress LSPs destined > to > > that > > > box. > > > > > If this is a permanent thing, > > You could create a colouring scheme where all links connected to this > node > > have to be avoided by all LSPs with the exception of LSPs terminated on > this > > node (or originated by this node). > > > > If this is a maintenance thing, > > There's a command that can be enabled to drain all transit LSPs out the > box. > > But, all the LSPs would need to be configured with this capability in the > > first place. > > > > > > adam > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
> Luis Balbinot > Sent: Thursday, January 24, 2019 4:45 PM > > Hi. > > How could I prevent a device from getting transit RSVP LSPs being > established through it? I only want it to accept ingress LSPs destined to that > box. > If this is a permanent thing, You could create a colouring scheme where all links connected to this node have to be avoided by all LSPs with the exception of LSPs terminated on this node (or originated by this node). If this is a maintenance thing, There's a command that can be enabled to drain all transit LSPs out the box. But, all the LSPs would need to be configured with this capability in the first place. adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
It's a permanent thing. These boxes are PE routers that are not supposed to handle transit traffic but during certain network events a few FRR bypass LSPs are established through them because that's the only remaining path. Something easier like a "no-eligible-backup" toggle like the one we have with OSPF LFA would be nice. Luis On Thu, Jan 24, 2019 at 2:53 PM wrote: > > > Luis Balbinot > > Sent: Thursday, January 24, 2019 4:45 PM > > > > Hi. > > > > How could I prevent a device from getting transit RSVP LSPs being > > established through it? I only want it to accept ingress LSPs destined to > that > > box. > > > If this is a permanent thing, > You could create a colouring scheme where all links connected to this node > have to be avoided by all LSPs with the exception of LSPs terminated on this > node (or originated by this node). > > If this is a maintenance thing, > There's a command that can be enabled to drain all transit LSPs out the box. > But, all the LSPs would need to be configured with this capability in the > first place. > > > adam > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Avoid transit LSPs
Hi. How could I prevent a device from getting transit RSVP LSPs being established through it? I only want it to accept ingress LSPs destined to that box. Luis ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Finding drops
Hey Adam, > On Jan 24, 2019, at 5:51 AM, > wrote: > > Is the test stream unidirectional please? -say from left (the mx1 side) to > right (mx2 side) please? Or bidirectional please? It’s been bi-directional, in that the Rx Tester is set to loopback. More or less only so I could see the number of packets received out the far side. This tester won’t count ingress packets unless it’s in loopback mode, or actually running some test. In any event, turning the loopback off doesn’t have any effect on the results. > Now that you're looking at the right router. > Can you please run the: show pfe statistics traffic fpc 0 | match > "cell|drops" > on mx1 > If it shows info cell drops then that means the PFE can't cope with the PPS > rate. No matches here. As Saku eluded to. > Since as Saku confirmed both interfaces et-0/0/2 and et-0/0/0 on mx1 are on > the same PFE then the packet processing computational load for ingress and > egress processing is not spread across two PFEs but rather executed on a > single PFE which has to handle 200Gbps (100in+100out) worth of traffic @ > 64bps, can't be bothered to calculate the pps rate there, but my guess is > that the PFE can't handle the resulting PPS rate (as it is most likely above > the PFE's overall (in+out) PPS budget) which is not that high on Gen3 > (applies to most NPUs out there with 100g ports). > > If the chip is rated for 800G(400in+400out) extrapolating from my notes on > MPC7 testing the 204PFE then should cope with ~200in+~200out @64bit (if your > traffic is bidirectional you'd be at the limit. Are there no specs published that provide the max number of pps @ 64 bytes the MPC7? > -is the flow-control disabled on all interfaces involved with this test > please? (we don't want the mx2 to send pause frames to et-0/0/0 on mx1 when > it can't cope with the ingress PPS rate, skewing the results) It is disabled. jlixfeld@mx1# wildcard range show interfaces et-0/0/[0,2] | display set | match flow set interfaces et-0/0/0 ether-options no-flow-control set interfaces et-0/0/2 ether-options no-flow-control [edit] jlixfeld@mx1# jlixfeld@mx2# wildcard range show interfaces et-0/0/[0,2] | display set | match flow set interfaces et-0/0/0 ether-options no-flow-control set interfaces et-0/0/2 ether-options no-flow-control [edit] jlixfeld@mx2# ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Finding drops
On Thu, 24 Jan 2019 at 12:52, wrote: > If it shows info cell drops then that means the PFE can't cope with the PPS > rate. It can't drop cells, as packets are never cellified, as platform does not have FAB side at all. There is only WAN side, so all is local switched. > Since as Saku confirmed both interfaces et-0/0/2 and et-0/0/0 on mx1 are on > the same PFE then the packet processing computational load for ingress and > egress processing is not spread across two PFEs but rather executed on a > single PFE which has to handle 200Gbps (100in+100out) worth of traffic @ > 64bps, can't be bothered to calculate the pps rate there, but my guess is > that the PFE can't handle the resulting PPS rate (as it is most likely above > the PFE's overall (in+out) PPS budget) which is not that high on Gen3 > (applies to most NPUs out there with 100g ports). > If the chip is rated for 800G(400in+400out) extrapolating from my notes on > MPC7 testing the 204PFE then should cope with ~200in+~200out @64bit (if your > traffic is bidirectional you'd be at the limit. EAChip (mqss) on fabric platforms has 400Gbps WAN + 400Gbps FAB, MX204 is fabless, so it's 800Gbps WAN. This test should pass with modest luss load. > -is the flow-control disabled on all interfaces involved with this test > please? (we don't want the mx2 to send pause frames to et-0/0/0 on mx1 when > it can't cope with the ingress PPS rate, skewing the results) This is really good proposal, flow-control is on by default. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF reference-bandwidth 1T
On 24/Jan/19 11:26, Saku Ytti wrote: > I don't disagree, I just disagree that there are common case where > bandwidth is most indicative of good SPT. Agreed. > I'd like to see mock-up topology, where bandwidth metric makes any > sense at all, and is more frequently right than role or latency. It doesn't. As with any thought-process that was used back in the day, the general belief was that the more bandwidth you have, the better life will always be. Real life, obviously, is very different. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Finding drops
Hey Jason, > Jason Lixfeld > Sent: Wednesday, January 23, 2019 3:02 PM > > This is somewhat embarrassing. I was looking at the wrong side of the test > when I initially observed the issue and I didn’t clue into that till now, so > some > of the previous claims are false. > > Just for completeness, here’s the actual test topology: > > [ Tx Tester ] - et-0/0/2 - [ mx1 ] - et-0/0/0 - [ mx2 ] - et-0/0/2 - [ Rx > Tester ] > Is the test stream unidirectional please? -say from left (the mx1 side) to right (mx2 side) please? Or bidirectional please? Now that you're looking at the right router. Can you please run the: show pfe statistics traffic fpc 0 | match "cell|drops" on mx1 If it shows info cell drops then that means the PFE can't cope with the PPS rate. Since as Saku confirmed both interfaces et-0/0/2 and et-0/0/0 on mx1 are on the same PFE then the packet processing computational load for ingress and egress processing is not spread across two PFEs but rather executed on a single PFE which has to handle 200Gbps (100in+100out) worth of traffic @ 64bps, can't be bothered to calculate the pps rate there, but my guess is that the PFE can't handle the resulting PPS rate (as it is most likely above the PFE's overall (in+out) PPS budget) which is not that high on Gen3 (applies to most NPUs out there with 100g ports). If the chip is rated for 800G(400in+400out) extrapolating from my notes on MPC7 testing the 204PFE then should cope with ~200in+~200out @64bit (if your traffic is bidirectional you'd be at the limit. > Incidentally, Olivier brought up hyper mode, so here are the results of that. > > et-0/0/2 @ mx1: >Input packets:100170 pps > > et-0/0/0 @ mx1: >Output packets: 766458888 pps > … This is an interesting result, Seems like hyper-mode helped with the ingress computation bit -is the flow-control disabled on all interfaces involved with this test please? (we don't want the mx2 to send pause frames to et-0/0/0 on mx1 when it can't cope with the ingress PPS rate, skewing the results) adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF reference-bandwidth 1T
On Thu, 24 Jan 2019 at 10:57, Mark Tinka wrote: > > And you have shorter paths with inferior bandwidth which you do not > > want to use, you'll rather take 9x10GE links than 1xGE to reach the > > destination? It boggles my mind which network has _common case_ where > > bandwidth is most indicative of best SPT. > > In some economies, shorter paths can be more expensive than longer ones. I don't disagree, I just disagree that there are common case where bandwidth is most indicative of good SPT. Consider I have 10GE-1: PE1 - P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - PE2 10GE-2: PE1 - P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - PE2 10GE-3: PE1 - P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - PE2 1GE: PE1 - PE2 In which realistic topology a) in 10GE-1 + 1GE, I want to prefer the 10GE between PE? b) in 10GE-2 + 1GE, I want to balance between the paths c) in 10GE-3 + 1GE, I want to prefer the 1GE All these seem nonsensical, what actually is meant '1GE has role Z, 10GE has role X, have higher metric for role Z', regardless what the actual bandwidth is. I just happens that bandwidth approximates role in that topology, but desired topology is likely achieved with distance vector or simple role topology and bandwidth is not relevant information. Even when if the P boxes are in same pop, each device adds some 5-10km of latency. So we'd prefer 40-80km latency over direct connection. Why did that direct 1GE exist when would you realistically fall back to using the lower bandwidth link? It seems ridiculously arbitrary and not indicative of any design. I'd like to see mock-up topology, where bandwidth metric makes any sense at all, and is more frequently right than role or latency. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF reference-bandwidth 1T
On 17/Jan/19 20:08, Saku Ytti wrote: > And you have shorter paths with inferior bandwidth which you do not > want to use, you'll rather take 9x10GE links than 1xGE to reach the > destination? It boggles my mind which network has _common case_ where > bandwidth is most indicative of best SPT. In some economies, shorter paths can be more expensive than longer ones. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF reference-bandwidth 1T
On 16/Jan/19 17:41, Saku Ytti wrote: > No one should be using bandwidth based metrics, it's quite > non-sensical. I would recommend that if you have only few egress > points for given prefix, adopt role based metric P-PE, P-P-city, > P-P-country etc. If you have many egress options for given prefix > latency based metric might be better bet. > > Traffic should fit your ideal SPT, if you are not able to engineer so > that SPT has enough capacity, run RSVP to move some traffic off SPT. We designed both latency- and funtion-based metrics, based on a reference bandwidth of 1Tbps. Works well, although, yes, you can design this without the reference bandwidth in mind. Luckily, when 1Tbps goes mainstream, it's easy to continue with our approach without worrying about why we needed the 1Tbps reference bandwidth in the first place. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
