Im widely using l3vpn with obsd including native bgpd for vpnv4 SAFI and
rdomains far from obsd 4.8, so it is about 3 years.And im crying still... :)
note: i am not using ldpd yet, i prefered bgp vpnv4 for labels.
First, tnx to
claudio with 5.2, vpnv4 RD is no longer compared while prefix import to
rdomain, uh-oh!
Now the things which make me crazy...
1. why there is still no
sysctl option to map ip_tos while pushing shim? just like map ttl.every mpls
LSP has to be with a choice to map ip tos or reset it in pushed label or even
set it to user defined value.since 4.8 fixed for me by statically mapping tos
to exp at mpe output.
2. what is bad with bgpd received withdrawn/updates
messages for vpnv4?
the case: obgd has ebgp session to cloud PE router, there
are two remote PE routes in the cloud, one of them has loopback with connected
prefix.
obgpd got that prefix with label, everything is ok until remote
loopback label is stable. remember the second remote PE? just duplicate
loopback from PE1 to Pe2 and be sure that PE2's prefix will be the best in
cloud.obgpd receives that update but nothing changed in FIB, there is still
old outgoing label in tx packets.
note: cloud is cisco-based, and it seems
that disabling label BOS check in RDE is fixing that. But im not so skilled
with that, because in very rare conditions im still has the same issue but
dont care much and manually restarting bgpd also fixes the label, uhm ok.
loopbacks are just example, imagine how your obsd FIB will keep tons of
unreachable prefixes where the cloud has multihomed bgp to other cloud and one
of the session will down.
3. about bgpd filtersit is very weird to write the
filters where last match condition is applying to update, i only have about 20
strings of filters and every time when i need to add or change some string i
also has to keep in mind others. Cisco route-maps with continue clause are
much better to understand.
4. Not playing much with ipv4 filters, but two
words about vpnv4 ones...wildcard mask to ext-community filters are not
supported yet, sad but true, tons of exact community values and its looking
good.but seems like ext-community filters work unpredictable.havent experience
with obgpd self originated prefixes, simple case with allow to any
ext-community X set prepend works good for me.once obgpd will get second ebgp
session you may with to manipulate vpnv4 updates from one ebgp peer to second
one and now filters do something but not you could expect.
the case: i have
two ebgp peers for vpnv4 and want prefixes from one peer with ext-community Y
to send to second peer. the filter: allow to second-peer ext-community Y
transits 10 prefixes of 300. what? other prefixes have Y too, why only 10?!
restart bgpd, second-peer now receives 15 or 17 or even 8 prefixes (and most
of them even not received before restart) but not 300. how??then i played with
match from first-peer ext-community Y set community + allow to second
community (to avoid use of ext-community filter in output direction), with
option 'quick' and many many other combinations with no success, only
transited prefix count changes after each restart.As i did all of that in
production network i could not debug deeply.
5. route decision missed at
rdomain import process?i dont know how that works with route-collector case, i
have rdomains so im importing prefixes here.when i have in rib several
prefixes with the same import target but with different RD it almost always
means that the only first pt_entry in RDE LIST are actual candidate to rdomain
import.there are no bgp attrubutes which i can found to help me import prefix
i want.i already posted that issue and examples in tech@ with no success, so
just to be here too
