Re: bgpd config advice needed
On Tue, Aug 25, 2020 at 09:48:04AM -, Stuart Henderson wrote: > > Guesses can be made, but a quick email might get a more accurate > answer :) "Hi, I see you are padding your announcements at $IX and we > are seeing you from other peers with the same path length, would you > prefer we send to you directly or via 64512?" Don't forget the circuit id. SCNR -- I'm not entirely sure you are real.
Re: bgpd config advice needed
On 2020-08-25, Remi Locherer wrote: > On Tue, Aug 25, 2020 at 07:11:12AM -, Stuart Henderson wrote: >> On 2020-08-24, Claudio Jeker wrote: >> > On Mon, Aug 24, 2020 at 04:36:10PM +, Laura Smith wrote: >> >> *> N 2001:db8:::/29 2001:db8::::1 100 100 >> >> 64512 65500 i >> >> * N 2001:db8:::/29 2001:db8::::2 100 100 >> >> 65500 65500 i >> >> >> >> In this example, both 64512 and 65500 are peers (med=100) but obviously >> >> 65500 65500 should be the preferred route. >> >> That's not obvious to me. (The behaviour would be the same with the more >> common localpref setting too). > > AS path length is the same for both cases and med is also the same. The > selected path comes from the peer with the lowest IP address I guess. Or weight, optionally route-age, BGP ID/ORIGINATOR_ID. >> > Now it is a bit strange that an AS is prepending on peering. I wonder why >> > they do that (is their connection to the IX undersized?). >> > > Maybe AS 65500 just aranged a new peering with AS 64512 and now needs to > impose more traffic to suffice some peering agreements? > > Dr. Peering might give some hints. ;-) > http://drpeering.net/tools/HTML_IPP/ipptoc.html Guesses can be made, but a quick email might get a more accurate answer :) "Hi, I see you are padding your announcements at $IX and we are seeing you from other peers with the same path length, would you prefer we send to you directly or via 64512?"
Re: bgpd config advice needed
On Tue, Aug 25, 2020 at 07:11:12AM -, Stuart Henderson wrote: > On 2020-08-24, Claudio Jeker wrote: > > On Mon, Aug 24, 2020 at 04:36:10PM +, Laura Smith wrote: > >> *> N 2001:db8:::/29 2001:db8::::1 100 100 > >> 64512 65500 i > >> * N 2001:db8:::/29 2001:db8::::2 100 100 > >> 65500 65500 i > >> > >> In this example, both 64512 and 65500 are peers (med=100) but obviously > >> 65500 65500 should be the preferred route. > > That's not obvious to me. (The behaviour would be the same with the more > common localpref setting too). AS path length is the same for both cases and med is also the same. The selected path comes from the peer with the lowest IP address I guess. > > > Now it is a bit strange that an AS is prepending on peering. I wonder why > > they do that (is their connection to the IX undersized?). > Maybe AS 65500 just aranged a new peering with AS 64512 and now needs to impose more traffic to suffice some peering agreements? Dr. Peering might give some hints. ;-) http://drpeering.net/tools/HTML_IPP/ipptoc.html
Re: bgpd config advice needed
On 2020-08-24, Claudio Jeker wrote: > On Mon, Aug 24, 2020 at 04:36:10PM +, Laura Smith wrote: >> *> N 2001:db8:::/29 2001:db8::::1 100 100 64512 >> 65500 i >> * N 2001:db8:::/29 2001:db8::::2 100 100 65500 >> 65500 i >> >> In this example, both 64512 and 65500 are peers (med=100) but obviously >> 65500 65500 should be the preferred route. That's not obvious to me. (The behaviour would be the same with the more common localpref setting too). > Now it is a bit strange that an AS is prepending on peering. I wonder why > they do that (is their connection to the IX undersized?). Certainly possible. Maybe ask the peer?
bgpd config advice needed
Hi, Let's say I've got a scenario where I've got transit ISPs and peering connections. My general config rule is that I use med to prioritise peering over transit (because localpref is too high up in the BGP selection algorithm, so localpref is a sledgehammer to crack a nut). That setup has served me well. But now with increasing peering connections, I'm seeing the wrong peer being selected for a route, e.g. (IPs and ASNs obfuscated to protect the innocent) *> N 2001:db8:::/29 2001:db8::::1 100 100 64512 65500 i * N 2001:db8:::/29 2001:db8::::2 100 100 65500 65500 i In this example, both 64512 and 65500 are peers (med=100) but obviously 65500 65500 should be the preferred route. What options do I have to resolve this sort of tie-break ? Ideally I'd like to find something that would resolve all such instances rather than have to introduce config hacks on a per-peer basis. Thanks Laura
Re: bgpd config advice needed
On Mon, Aug 24, 2020 at 04:36:10PM +, Laura Smith wrote: > Hi, > > Let's say I've got a scenario where I've got transit ISPs and peering > connections. > > My general config rule is that I use med to prioritise peering over transit > (because localpref is too high up in the BGP selection algorithm, so > localpref is a sledgehammer to crack a nut). > > That setup has served me well. But now with increasing peering connections, > I'm seeing the wrong peer being selected for a route, e.g. (IPs and ASNs > obfuscated to protect the innocent) > > *> N 2001:db8:::/29 2001:db8::::1 100 100 64512 > 65500 i > * N 2001:db8:::/29 2001:db8::::2 100 100 65500 > 65500 i > > In this example, both 64512 and 65500 are peers (med=100) but obviously 65500 > 65500 should be the preferred route. > > What options do I have to resolve this sort of tie-break ? Ideally I'd > like to find something that would resolve all such instances rather than > have to introduce config hacks on a per-peer basis. > A possible option is to prefer announcements from the neighbor which is the originator. To do this you can use a rule like: match from ebgp source-as neighbor-as set med +100 Now it is a bit strange that an AS is prepending on peering. I wonder why they do that (is their connection to the IX undersized?). -- :wq Claudio
