I’m not sure exactly what you’re looking for but the peer group system under JunOS is fairly efficient. If you set your export and import policies per group the bgp process will place these in a peer group and dynamically break off slow members in to their own groups so that one slower peer won’t cause the other members in the same peer group to synchronize as slowly. Cisco does not or at least did not do this as I understand things. In the cisco case if a peer group member lags it causes the other members of the same peer group to lag and doesn’t allow updates until the slowest member catches up. Since BGP under Junos breaks this slow guy off on it’s own you don’t have the same limitation. This all happens dynamically.
On May 18, 2015, at 7:00 AM, Adam Vitkovsky <[email protected]> wrote: > Hey buddy, > > >> Saku Ytti >> Sent: 18 May 2015 11:12 >> >> On (2015-05-18 10:04 +0000), Adam Vitkovsky wrote: >> >> Hey Adam, >> >>> I'd like to ask if the "90's" way of BGP generating updates per peer-group >>> is >> a cause for concern on a modern gear. >>> And if not then anyways am I the only one missing some flexibility in BGP >> peers configuration in Junos? >>> It's really annoying that every time one needs to adjust something for a >> peer, might even be something session related, a new peer-group has to be >> carved up. >> >> Is there some efficient 2010's way you're thinking about? >> >> Spamming same TCP datagram to multiple hosts has great efficiency >> benefits, >> but to be able to capitalize this, you need to group neighbours who are to >> receive same set of routes, or TCP messages. > > Yes I'm thinking about "BGP Dynamic Update Peer-Groups" > - the improved BGP update message generation where the update-group > memberships is calculated automatically/dynamically by the system based on > common egress policies assigned to peers. > And of course the configuration using templates (i.e. session templates and > policy templates) and inheritance. > I've been relying on the above since ever in Cisco world and I miss that much > in Junos. > >> >> Making 1 peer == 1 update-group would be easy, but it would make already >> hella >> slow rpd lot worse. >> > You see this is what I mean, the RPD is slow so why not use the above to > speed things up. > >> It is best to optimize advertised routes to as few sets as possible, to gain >> best benefits. I would recommend not setting export filters on per- >> neighbour >> basis, only on group-level. >> (i.e. not micro-optimize neighbours to receive exactly what is needed, if >> extra routes are not actively harmful) >> >> -- >> ++ytti > > That is an interesting approach indeed though it's a sacrifice we are forced > into because the update generation is not optimal in Junos. > > adam > --------------------------------------------------------------------------------------- > This email has been scanned for email related threats and delivered safely by > Mimecast. > For more information please visit http://www.mimecast.com > --------------------------------------------------------------------------------------- > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
