Re: [j-nsp] Prioritize route advertisement
--- Begin Message --- > On Apr 17, 2020, at 4:10 AM, > wrote: > >>> The question is if there is a way to work around this change that >>> behavior? >>> Wondering if it was due to some slow peer(s) Not sure if juniper BGP >>> works similarly to cisco BGP in this area (but considering the >>> differences in update groups between the two it might very well NOT be >>> the case) But cisco has the following to address slow peers holding >>> down the whole update group more info at: >> >> Yeah, we don't need that. We just form optimal micro-groups for the peers >> that are in the same sync level at a given part of the queue and are ready > to >> write. >> > Hi Jeff, > Can you please expand on this last statement please? > How do these 17 output queues of the route prioritization system interwork > with the micro-groups you mentioned please? Because there's 17 queues. :-) > The doc quoted by OP says " The queue servicing procedure operates per-BGP > peer group with each group maintaining its own token buckets." - I think it > means update-group rather than peer-group, where update-group might or might > not have a one-to-one relationship to actual update-group. No, it means that when we end up with a peer group (see "show bgp groups") we'll have a set of distinct token buckets for that group. > But it also says > " This means that route priority can vary in each BGP peer group as well as > in specific neighbor configurations within the BGP peer groups" so I'm > guessing if it differs per peer then that peer is assigned to its own update > group (hence the reset of the session)? This is the usual global to group to neighbor config inheritance along with the usual group split if you configure contrary per-neighbor vs. the group split. -- Jeff > Thank you. > > adam > --- End Message --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
> From: Saku Ytti > Sent: Friday, April 17, 2020 11:53 AM > > On Fri, 17 Apr 2020 at 13:23, wrote: > > > Yup this bit was clear, actually on this one, when I was searching I > > stumbled > upon a XR-9k cmd to enable connecting management port to fabric ... "rp > mgmtethernet forwarding" > > I don't think you can. I think you enable forwarding through RE, but the port > isn't NPU connected. Junos has hidden toggle for that too. > But you really don't want to do that, as you lose all protection. > NPU/fabric to RE is blood-brain barrier to humans, without it, we'll get > easily > very seriously sick. > No agree 100% :) adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
On Fri, 17 Apr 2020 at 13:23, wrote: > Yup this bit was clear, actually on this one, when I was searching I stumbled > upon a XR-9k cmd to enable connecting management port to fabric ... "rp > mgmtethernet forwarding" I don't think you can. I think you enable forwarding through RE, but the port isn't NPU connected. Junos has hidden toggle for that too. But you really don't want to do that, as you lose all protection. NPU/fabric to RE is blood-brain barrier to humans, without it, we'll get easily very seriously sick. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
> From: Saku Ytti > Sent: Friday, April 17, 2020 8:49 AM > > On Fri, 17 Apr 2020 at 10:39, wrote: > > > Can you expand on the above please? > > Say comparing RE/RSP management port on ASR9k and MX, > > No management port is revenue port, and will kill your flow export, if flow > export is supported directly from the NPU. Because if it works, it means NPU > has to _punt_ the traffic to control-plane, to export it. > Where as if NPU supports exporting off the NPU, then exporting from non- > revenue ports can be done without touching control-plane or stealing punt > capacity. > If flow is exported by the RE, it's much less important. > Yup this bit was clear, actually on this one, when I was searching I stumbled upon a XR-9k cmd to enable connecting management port to fabric ... "rp mgmtethernet forwarding" > I would personally not use any RE attached ETH port for any purpose. > However I'd happily use ASR9k CMP port or Cisco 8k BMC port for out-of- > band. > Aah that clears it up, sure BMC like OOB (CMP included) is the true separate management plane. Sorry I was wondering how is standard management ethernet port on RSP not sharing control plane -I can point static routes at it after all so yeah didn't occur to me you were referring to BMC OOB MGMT ports there. adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
On 17/Apr/20 09:49, Saku Ytti wrote: > No management port is revenue port, and will kill your flow export, if > flow export is supported directly from the NPU. Because if it works, > it means NPU has to _punt_ the traffic to control-plane, to export it. > Where as if NPU supports exporting off the NPU, then exporting from > non-revenue ports can be done without touching control-plane or > stealing punt capacity. > If flow is exported by the RE, it's much less important. > > I would personally not use any RE attached ETH port for any purpose. > However I'd happily use ASR9k CMP port or Cisco 8k BMC port for > out-of-band. This is what we do in our network. We don't use any control plane ports for anything. The farthest we go is attach a serial cable to the console port and back into a terminal server, for out-of-band access. fxp0 and such ports are shutdown to disable the alarms that assume they should always be connected :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Prioritize route advertisement
> From: Jeffrey Haas > Sent: Monday, April 6, 2020 6:06 PM > > > On Apr 6, 2020, at 12:59 PM, > wrote: > > > >> Gustavo Santos > >> Sent: Monday, April 6, 2020 4:06 PM > >> > >> Is there a way to prioritize advertisement on some BGP sessions above > >> others? I tried the > >> https://www.juniper.net/documentation/en_US/junos/topics/topic- > >> map/bgp-route-prioritization.html > >> > > The feature you mentioned is used to say first send L3VPN routes > > before L2VPN routes when talking to a given peer. > > I'm not aware of any such mechanism to say peer 192.0.2.1 should be > > served first and then peer 192.0.2.2 should be next, etc... > > Junos roughly serves the back queue for the peer group based on the > subsets of peers that get common updates vs. the peers that are ready to > write. In the presence of a large back queue for a peer in the group, we > might appear sluggish to service some of the more in sync peers. However, > what will tend to happen is those slower and more out of sync peers will > write block and next round we just move along to do other work. > > > > >> The question is if there is a way to work around this change that > > behavior? > >> > > Wondering if it was due to some slow peer(s) Not sure if juniper BGP > > works similarly to cisco BGP in this area (but considering the > > differences in update groups between the two it might very well NOT be > > the case) But cisco has the following to address slow peers holding > > down the whole update group more info at: > > Yeah, we don't need that. We just form optimal micro-groups for the peers > that are in the same sync level at a given part of the queue and are ready to > write. > Hi Jeff, Can you please expand on this last statement please? How do these 17 output queues of the route prioritization system interwork with the micro-groups you mentioned please? The doc quoted by OP says " The queue servicing procedure operates per-BGP peer group with each group maintaining its own token buckets." - I think it means update-group rather than peer-group, where update-group might or might not have a one-to-one relationship to actual update-group. But it also says " This means that route priority can vary in each BGP peer group as well as in specific neighbor configurations within the BGP peer groups" so I'm guessing if it differs per peer then that peer is assigned to its own update group (hence the reset of the session)? Thank you. adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
On Fri, 17 Apr 2020 at 10:39, wrote: > Can you expand on the above please? > Say comparing RE/RSP management port on ASR9k and MX, No management port is revenue port, and will kill your flow export, if flow export is supported directly from the NPU. Because if it works, it means NPU has to _punt_ the traffic to control-plane, to export it. Where as if NPU supports exporting off the NPU, then exporting from non-revenue ports can be done without touching control-plane or stealing punt capacity. If flow is exported by the RE, it's much less important. I would personally not use any RE attached ETH port for any purpose. However I'd happily use ASR9k CMP port or Cisco 8k BMC port for out-of-band. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow config for MX204
> Saku Ytti > Sent: Sunday, April 12, 2020 9:44 AM > > On Sun, 12 Apr 2020 at 03:53, Mark Tinka wrote: > > > On 11/Apr/20 08:04, Nick Schmalenberger via juniper-nsp wrote: > > > I had the same issue with first trying to export over fxp0, then > > > > We just export flows in-band. Just seems simpler, and has been > > reliable for close to 10 years. > > in-band is right, Trio can export the flow itself, you will kill your performance > if you do non-revenue port export. > > In my mind JNPR non-revenue ports have no use-case. They are dangerous > with no utility. Cisco is much better here, as they offer true OOB non- > revenue ports. JNPR non-revenue port is a convenient way to quickly break a > lot of your network at the same time, as they entirely fate-share the control- > plane. Cisco has non-revenue ports with their own isolated management- > plane, so state of your control-plane will not impact the management-plane > vice versa. Hey, Can you expand on the above please? Say comparing RE/RSP management port on ASR9k and MX, adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
