Re: Propagating /32 from OSPF to BGP
On Wed, Jun 19, 2013 at 12:46:04PM +1200, Michael Ludvig wrote: Hi we've got a private AS with two uplinks to our ISP, and we've got a number of subnets that we advertise. Now we got a new assignment and it doesn't work as expected. Here is the situation: ... As it is now a ping from outside to x.x.74.113 (that's advertised as /31) goes to GW_1, which is correct and a ping to x.x.74.114 (that's advertised as /32) goes to GW_2, that's incorrect. How come? I can't see what am I doing wrong...? Hi The main question is whether there is any reason why ISP should prefer these routers from GW_1 or from GW_2. Unless you do some attribute modification in export filters then IMHO there is no such reason - IGP metric is not propagated through eBGP and therefore ISP receives two more or less equivalent routes for the same prefix. It is strange that it chooses different GW for x.x.74.112/31 and for x.x.74.114/32 - when routes are the same, ISP should consistently choose one received from the router with smaller router ID, but it could be configured to use RFC 5004 behavior and prefer the older one, which would be nondeterministic. The solution would be to propagate IGP metric as BGP MED attribute (and ensure that ISP do not ignore this attribute). If you are sure that ospf_metric2 is the same, you could do that simply by using 'bgp_med = ospf_metric1;' for routes from OSPF in BGP export filters. Also, the best info would be to see these routes (with their BGP attributes) on ISP router. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) To err is human -- to blame it on a computer is even more so. signature.asc Description: Digital signature
Re: Propagating /32 from OSPF to BGP
On 19/06/13 13:08, Simon Dickhoven wrote: Is it possible that your ISP is accepting le 32 on their BGP session with GW_2 (and that's the one they checked when you asked them to verify) but only le 31 on their BGP session with GW_1? That was indeed that the case! They insisted they've got it correctly but I kept pushing until they fixed their filter. All works now. On 19/06/13 23:32, Ondrej Zajicek wrote: The solution would be to propagate IGP metric as BGP MED attribute (and ensure that ISP do not ignore this attribute). If you are sure that ospf_metric2 is the same, you could do that simply by using 'bgp_med = ospf_metric1;' for routes from OSPF in BGP export filters. Yes that's what I do. Didn't mention it in my first email, sorry. Thanks guys Michael
Re: Propagating /32 from OSPF to BGP
A more detailed topology (with IPs and interface names) would be helpful to understand the setup better. Is it possible that your ISP is accepting le 32 on their BGP session with GW_2 (and that's the one they checked when you asked them to verify) but only le 31 on their BGP session with GW_1? I have certainly run into this problem before: Asked the ISP to verify. They did and said that all is good on their end. But when I finally asked them to send me their configs it turned out that they had screwed something up. One thing I noticed is that GW_1 shows interface tunVpnCust for OSPF and ifDmz1 for BGP whereas GW_2 shows interface tunO2Oorc4 for both. Since I don't have a more detailed topology that explains where 172.31.253.1 and 172.31.253.32 are and what the respective interfaces connect to it's difficult to guess what's going on. But double-checking with your ISP and possibly asking them for their configs is one thing you could do to rule out the possibility that the problem is on their end. Sorry I couldn't be more helpful. - Simon On 06/18/2013 05:46 PM, Michael Ludvig wrote: Hi we've got a private AS with two uplinks to our ISP, and we've got a number of subnets that we advertise. Now we got a new assignment and it doesn't work as expected. Here is the situation: x.x.74.113 x.x.74.114 [DMZ1_box_1] || [DMZ1_GW] -- OSPF -- [GW_1] -- OSPF -- [GW_2] -- OSPF -- ... x.x.24.227 | | BGP BGP | | ISP_rtr_1ISP_rtr_2 \ / ISP Internet Now if I advertise the new subnet /29 (or up to /31) from DMZ1_GW it gets propagated to both BGPs and the ISP correctly routes the traffic to GW_1 as it's closer to the box. However if I advertise the IP/32 from DMZ1_GW then for some reason the traffic is routed from Internet to GW_2 first. ISP confirmed they accept up to /32 from us. This is the relevant output from GW_1: GW_1 ~ # birdc show route protocol ospf_eit | grep ^x.x.74 BIRD 1.3.8 ready. x.x.74.114/32 via 172.31.253.32 on tunVpnCust [ospf_eit 11:44] * E2 (150/1/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.32 on tunVpnCust [ospf_eit 11:44] * E2 (150/1/1) [x.x.24.227] GW_1 ~ # birdc show route export bgp_isp | grep ^x.x.74 BIRD 1.3.8 ready. x.x.74.114/32 via 172.31.253.32 on ifDmz1 [ospf_eit 11:44] * E2 (150/1/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.32 on ifDmz1 [ospf_eit 11:44] * E2 (150/1/1) [x.x.24.227] This is the relevant output from GW_2: GW_2 ~ # birdc show route protocol ospf_eit| grep ^x.x.74 BIRD 1.3.8 ready. x.x.74.114/32 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [x.x.24.227] GW_2 ~ # birdc show route export bgp_isp | grep ^x.x.74 BIRD 1.3.8 ready. x.x.74.114/32 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [x.x.24.227] x.x.74.112/31 via 172.31.253.1 on tunO2Oorc4 [ospf_eit 11:44] * E2 (150/11/1) [x.x.24.227] As it is now a ping from outside to x.x.74.113 (that's advertised as /31) goes to GW_1, which is correct and a ping to x.x.74.114 (that's advertised as /32) goes to GW_2, that's incorrect. How come? I can't see what am I doing wrong...? Any ideas? Thanks Michael
