Re: Any IX willing to share their config?
Alexander Shikoff wrote, 25.12.2010 15:50: On Sat, Dec 25, 2010 at 11:57:04AM +0100, Ondrej Zajicek wrote: On Sat, Dec 25, 2010 at 05:03:46AM +0200, Alexander Shikoff wrote: One possible way to do that is not to try handle full 32bit ASNs, but perhaps just ~ 24bit ASNs and use communities (65000..65255,*) for (65000+X,Y) - Do not announce to peer X*65536+Y and similarly communities (65256..65511,*) for: (65256+X,Y) - Announce to peer X*65536+Y only. You're right. If I remember correctly IANA currently allocates 1024 numbers for each RIR, so your variant covers them entirely for some future years. Some additional thoughts: - this way breaks RFC1997 a little - current draft Internet Exchange Route Server (http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-01) does not propose in details how to implement handling of 32bit ASNs via communities. Developers of this draft invite to comment this document (at Euro-IX community mailing list this summer). You may send some suggestions. - there is RFC5668 (4-Octet AS Specific BGP Extended Community, http://tools.ietf.org/search/rfc5668) but it defines only 2 octets for Local Administrator field. So BGP Ext. community support will not also allow easy implementation of 32bit ASN handling. I've googled around this problem and have not find yet another ideas/discussions etc. So your way seems to be most easy and effective at present moment. Another, even simpler, way is to assign each connected client with 32bit ASN some pseudo-ASN from private range. This pseudo-ASN would be used with standard communities (0:X, MyASN:X). MSK-IX uses this way. We not expect very large number of direct connected members with ASN 65535 in few next years. Most new members still have ASN16 numbers. Some have ASN32 and then migrated to ASN16 (due various difficulties: ddos protection, direct peerings etc.) So we can wait for new RFC with Extended Communities or for some other solution. RFC1997 community 'no-export' is also supported. Other communities including RFC1997 well-known ones are not supported and stripped. That seems a bit strange to me. Not sure what the other IXPs do but i think that communities are supposed to be propagated and RS should alter only communities destined for it. RFC1997 allows modification of community attribute according to a local policy. But Internet Exchange Route Server draft _recommends_ transparate propagation. But this recommendation requires consideration of possible security or routing issues (asymmetry etc). Just because of security/routing issues almost all of our members delete all communities received from IXP or those are not listed in IXP routing policy. If other IXP engineers are reading this maillist it would be great to hear their opinions. What's about well-known communities: for example, MSK-IX propagates 'no-export' transparately to peers. I think this approach does not meet RFC1997. MSK-IX does not support 'no-advertise' (0:MyASN is used instead). We're using 'no-export' only in an approach described by RFC1997. Our customers wanted to be able to announce some routes with 'no-export' transparently to other MSK-IX participants. That was before the BIRD became our main platform and before we implemented full-featured communities to our customers. At present, you can to propagate 'no-export' with the special community: http://www.msk-ix.ru/eng/routeserver.html#bgpcommunity Btw, as I remember, among other UNIX BGP daemons also there are some transparency with 'no-export'. Any transparent Route Server at every IXP by its nature doesn't meet RFC4271 (transparent RS doesn't update as-path attribute). All current inconsistency, including RFC1997 breaks, better to consider in the RFC about Route Servers. --- Communities sent to peers -- MyASN:X - Route is received from 16-bit ASN X 6550X:Y - Route is received from 32-bit ASN 65535*X+Y What purpose have these communities? That can be easily read from AS_PATH. If certain peer makes filters based not on AS_PATH but on community then these ones can help it.
Re: ECMP/multipath support
Other packets are sent to the neighbor IP address, which is a slight
diversion from RFC 2328, but should not cause any problems.
But a stricter router may reject OSPF msg over an ptp links if
they aren't addressed to AllSPFRouters.
I just noticed you impl. a PTMP I/F type, nice :)
I updated to new nexhp calc. patch to match your latest
changes. I hope you like it.
From b2d4b0fc32df60f0ae0e5db1d18de647ea62ae3e Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund joakim.tjernl...@transmode.se
Date: Fri, 17 Dec 2010 10:03:32 +0100
Subject: [PATCH 1/2] ospf: improve nexthop_calc
Record the lsa position in the router LSA and
use that to find the right interface in calc_next_hop()
Remove match_rtlink and match_dr too as these are not
needed anymore
Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se
---
proto/ospf/iface.c|4 ++-
proto/ospf/ospf.h | 21
proto/ospf/rt.c | 63 ++---
proto/ospf/topology.c |5 ++-
4 files changed, 45 insertions(+), 48 deletions(-)
diff --git a/proto/ospf/iface.c b/proto/ospf/iface.c
index 05442df..6fc0136 100644
--- a/proto/ospf/iface.c
+++ b/proto/ospf/iface.c
@@ -197,6 +197,8 @@ ospf_iface_down(struct ospf_iface *ifa)
ifa-cost = 0;
ifa-vip = IPA_NONE;
}
+ /* delete position in router LSA */
+ ospf_lsa_pos_set(0, 0, ifa);
}
@@ -412,7 +414,7 @@ ospf_iface_new(struct proto_ospf *po, struct iface *iface,
struct ifa *addr,
ifa-iface = iface;
ifa-addr = addr;
ifa-pool = pool;
-
+ ospf_lsa_pos_set(0, 0, ifa);
ifa-cost = ip-cost;
ifa-rxmtint = ip-rxmtint;
ifa-inftransdelay = ip-inftransdelay;
diff --git a/proto/ospf/ospf.h b/proto/ospf/ospf.h
index e260dc0..71071cd 100644
--- a/proto/ospf/ospf.h
+++ b/proto/ospf/ospf.h
@@ -190,6 +190,8 @@ struct ospf_iface
u32 csn; /* Last used crypt seq number */
bird_clock_t csn_use; /* Last time when packet with that CSN was
sent */
#endif
+ u32 lsa_pos_beg; /* inclusive, = */
+ u32 lsa_pos_end; /* exclusive, */
ip_addr drip;/* Designated router */
ip_addr bdrip; /* Backup DR */
@@ -823,6 +825,25 @@ void ospf_sh_iface(struct proto *p, char *iff);
void ospf_sh_state(struct proto *p, int verbose, int reachable);
void ospf_sh_lsadb(struct proto *p);
+static inline struct ospf_iface *
+ospf_pos_to_ifa (struct ospf_area *oa, int lsa_pos)
+{
+struct proto_ospf *po = oa-po;
+struct ospf_iface *ifa;
+
+WALK_LIST(ifa, po-iface_list)
+ if (lsa_pos = ifa-lsa_pos_beg lsa_pos ifa-lsa_pos_end)
+ return ifa;
+return NULL;
+}
+
+static inline void
+ospf_lsa_pos_set(int beg, int end,
+struct ospf_iface * ifa)
+{
+ifa-lsa_pos_beg = beg;
+ifa-lsa_pos_end = end;
+}
#define EA_OSPF_METRIC1EA_CODE(EAP_OSPF, 0)
#define EA_OSPF_METRIC2EA_CODE(EAP_OSPF, 1)
diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c
index 953a679..84fea16 100644
--- a/proto/ospf/rt.c
+++ b/proto/ospf/rt.c
@@ -10,7 +10,7 @@
static void add_cand(list * l, struct top_hash_entry *en,
struct top_hash_entry *par, u32 dist,
-struct ospf_area *oa, struct ospf_lsa_rt_link *rtl);
+struct ospf_area *oa, struct ospf_lsa_rt_link *rtl, u32
pos);
static void rt_sync(struct proto_ospf *po);
/* In ospf_area-rtr we store paths to routers, but we use RID (and not IP
address)
@@ -396,7 +396,7 @@ ospf_rt_spfa_rtlinks(struct ospf_area *oa, struct
top_hash_entry *act, struct to
if (tmp)
DBG(Going to add cand, Mydist: %u, Req: %u\n,
tmp-dist, act-dist + rtl-metric);
- add_cand(oa-cand, tmp, act, act-dist + rtl-metric, oa, rtl);
+ add_cand(oa-cand, tmp, act, act-dist + rtl-metric, oa, rtl, i);
}
}
@@ -494,7 +494,7 @@ ospf_rt_spfa(struct ospf_area *oa)
DBG(Found :-)\n);
else
DBG(Not found!\n);
- add_cand(oa-cand, tmp, act, act-dist, oa, NULL);
+ add_cand(oa-cand, tmp, act, act-dist, oa, NULL, i);
}
break;
}
@@ -1325,32 +1325,6 @@ ospf_rt_spf(struct proto_ospf *po)
po-calcrt = 0;
}
-
-static inline int
-match_dr(struct ospf_iface *ifa, struct top_hash_entry *en)
-{
-#ifdef OSPFv2
- return (ifa-drid == en-lsa.rt) (ipa_to_u32(ifa-drip) == en-lsa.id);
-#else /* OSPFv3 */
- return (ifa-drid == en-lsa.rt) (ifa-dr_iface_id == en-lsa.id);
-#endif
-}
-
-
-static inline int
-match_rtlink(struct ospf_iface *ifa, struct ospf_lsa_rt_link *rtl)
-{
-#ifdef OSPFv2
- return ((ifa-type == OSPF_IT_PTP) || (ifa-type == OSPF_IT_PTMP))
-(ifa-cost == rtl-metric)
-(((ifa-addr-flags IA_UNNUMBERED) ? ifa-iface-index :
- ipa_to_u32(ifa-addr-ip)) == rtl-data);
-#else /* OSPFv3 */
- return ((ifa-type == OSPF_IT_PTP) || (ifa-type == OSPF_IT_PTMP))
-(ifa-cost == rtl-metric) (ifa-iface-index == rtl-lif);
-#endif
-}
-
static inline int
Re: ECMP/multipath support
On Mon, Dec 27, 2010 at 08:06:17PM +0100, Joakim Tjernlund wrote: Other packets are sent to the neighbor IP address, which is a slight diversion from RFC 2328, but should not cause any problems. But a stricter router may reject OSPF msg over an ptp links if they aren't addressed to AllSPFRouters. I just noticed you impl. a PTMP I/F type, nice :) I updated to new nexhp calc. patch to match your latest changes. I hope you like it. I already done that, just didn't commited it yet, sorry. Now it is merged (after some rework and extending). -- 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: ECMP/multipath support
On Tue, Dec 28, 2010 at 01:15:28AM +0100, Joakim Tjernlund wrote:
Other packets are sent to the neighbor IP address, which is a slight
diversion from RFC 2328, but should not cause any problems.
But a stricter router may reject OSPF msg over an ptp links if
they aren't addressed to AllSPFRouters.
I just noticed you impl. a PTMP I/F type, nice :)
I updated to new nexhp calc. patch to match your latest
changes. I hope you like it.
Did some more spf improvements. Lets see if you like these too:
+ /* The first case - local network */
+ if (en-lsa.type == LSA_T_NET)
+ return new_nexthop(po, IPA_NONE, ifa-iface, ifa-ecmp_weight);
+
+ /* The second case - ptp or ptmp neighbor */
+ if (en-lsa.type == LSA_T_RT)
+ {
+ if (ifa-type == OSPF_IT_PTP)
+ return new_nexthop(po, ifa-addr-opposite, ifa-iface,
+ ifa-ecmp_weight);
As i wrote 21 Dec 2010 11:42:56, this is not correct, opposite might
be undefined.
--
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: ECMP/multipath support
Ondrej Zajicek santi...@crfreenet.org wrote on 2010/12/28 01:55:42:
On Tue, Dec 28, 2010 at 01:15:28AM +0100, Joakim Tjernlund wrote:
Other packets are sent to the neighbor IP address, which is a slight
diversion from RFC 2328, but should not cause any problems.
But a stricter router may reject OSPF msg over an ptp links if
they aren't addressed to AllSPFRouters.
I just noticed you impl. a PTMP I/F type, nice :)
I updated to new nexhp calc. patch to match your latest
changes. I hope you like it.
Did some more spf improvements. Lets see if you like these too:
+ /* The first case - local network */
+ if (en-lsa.type == LSA_T_NET)
+ return new_nexthop(po, IPA_NONE, ifa-iface, ifa-ecmp_weight);
+
+ /* The second case - ptp or ptmp neighbor */
+ if (en-lsa.type == LSA_T_RT)
+ {
+ if (ifa-type == OSPF_IT_PTP)
+ return new_nexthop(po, ifa-addr-opposite, ifa-iface,
+ ifa-ecmp_weight);
As i wrote 21 Dec 2010 11:42:56, this is not correct, opposite might
Right, forgot about that. What do you think of the other changes?
especially the goto bad; changes and the if (par == oa-rt) { /* par is root ?
*/
test to simplify the code?
Jocke
