- Bird-users - Mailing Lists

[PATCH] [RFC] Babel: Implement route daming with fixed delay
by Daniel Gröber 02 Jun '23

02 Jun '23

In order to prevent RTT based routing from causing persistent traffic oscillations we delay core rte announcement of each prefix by a configurable but metric invariant amount of time. Initial announcements and withdrawals will go through undelayed but a chnage in route for a prefix will cancel the previous announcement and reset the delay. --- This is just quickly thrown together to demonstrate the idea of how to replace metric smoothing with something more simplistic. Obviously the performance of using a linked list for keeping the scheduled announcements is suboptimal, our binary heap could be used instead. I'm not quite sure all the logic works out but let's discuss the concept before spending more time on it :) This could be extended to make the delay depend on metric difference if it turns out that's necessary I just skipped it for simplicity. proto/babel/babel.c | 79 +++++++++++++++++++++++++++++++++++++++++++-- proto/babel/babel.h | 11 +++++-- 2 files changed, 86 insertions(+), 4 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 2243fc89..d6d99a37 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -62,6 +62,7 @@ static inline int gt_mod64k(uint a, uint b) static void babel_expire_requests(struct babel_proto *p, struct babel_entry *e); static void babel_announce_rte(struct babel_proto *p, struct babel_entry *e, struct babel_route *r); +static void babel_sched_announce_rte(struct babel_proto *p, struct babel_entry *e, struct babel_route *r); static void babel_rte_update_unreachable(struct babel_proto *p, struct babel_entry *e, u8 announce); static void babel_send_route_request(struct babel_proto *p, struct babel_entry *e, struct babel_neighbor *n); static void babel_send_seqno_request(struct babel_proto *p, struct babel_entry *e, struct babel_seqno_request *sr, struct babel_neighbor *n); @@ -653,7 +654,7 @@ done: WALK_LIST2(r, n, nbr->routes, neigh_route) { r->metric = babel_compute_metric(nbr, r->advert_metric); - babel_announce_rte(p, r->e, r); + babel_sched_announce_rte(p, r->e, r); } } } @@ -772,6 +773,50 @@ babel_announce_rte(struct babel_proto *p, struct babel_entry *e, struct babel_ro } } +/* + * When route damping is enabled we have to delay updates to the kernel FIB. We + * do this by queueing some updates before actually announcing them to core. + */ +static void +babel_sched_announce_rte(struct babel_proto *p, struct babel_entry *e, struct babel_route *r) +{ + struct babel_config *cf = (void *) p->p.cf; + + if (!cf->route_damping || + !e->selected || + e->selected->metric < r->metric || + /*^ When the best route's metric is worse than the one we're about to + * announce it's safe to do so immediately even if route damping is on as + * it won't get exported to most other protocols. Note add-path BGP is + * still notified but we're not concerned about micromanaging the + * stability of exotic setups, only our local kernel FIB's impact. */ + r->metric == BABEL_INFINITY || !r->feasible) + /*^ This checks if announce_rte will do a withdrawal. */ + { + if (e->scheduled) { + rem_node(&e->sched); + e->scheduled = NULL; + } + + babel_announce_rte(p, r->e, r); + } + else + { + struct babel_iface *ifa = r->neigh->ifa; + + if (!e->scheduled) + add_tail(&ifa->sched_rtes, &e->sched); + e->scheduled = r; + + r->sched_time = current_time() + cf->route_damping; + + if (!ifa->want_sched) { + ifa->next_sched = r->sched_time; + ifa->want_sched = 1; + } + } +} + /* * Functions to send replies */ @@ -1371,7 +1416,7 @@ babel_handle_update(union babel_msg *m, struct babel_iface *ifa) e->updated = current_time(); } - babel_announce_rte(p, e, r); + babel_sched_announce_rte(p, e, r); } void @@ -1683,6 +1728,32 @@ babel_iface_timer(timer *t) p->triggered = 0; } + if (ifa->want_sched && now_ >= ifa->next_sched) { + TRACE(D_EVENTS, "Announcing scheduled rtes on %s", ifa->ifname); + + struct babel_entry *e, *ex; + + ifa->next_sched = TIME_INFINITY; + + u8 all_announced = 1; + WALK_LIST_DELSAFE(e, ex, ifa->sched_rtes) { + struct babel_route *r = e->scheduled; + ASSERT(r); + if (now_ >= r->sched_time) { + rem_node(&e->sched); + babel_announce_rte(p, e, r); + } else { + all_announced = 0; + if (r->sched_time < ifa->next_sched) + ifa->next_sched = r->sched_time; + } + } + + if (all_announced) { + ifa->want_sched = 0; + } + } + btime next_event = MIN(ifa->next_hello, ifa->next_regular); if (ifa->want_triggered) next_event = MIN(next_event, ifa->next_triggered); tm_set(ifa->timer, next_event); @@ -1862,6 +1933,8 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con init_list(&ifa->msg_queue); ifa->send_event = ev_new_init(ifa->pool, babel_send_queue, ifa); + init_list(&ifa->sched_rtes); + struct object_lock *lock = olock_new(ifa->pool); lock->type = OBJLOCK_UDP; lock->addr = IP6_BABEL_ROUTERS; @@ -2523,6 +2596,8 @@ babel_init(struct proto_config *CF) P->rte_better = babel_rte_better; P->rte_igp_metric = babel_rte_igp_metric; + cf->route_damping = 15 S_; // HACK for testing + return P; } diff --git a/proto/babel/babel.h b/proto/babel/babel.h index 3868d7c4..186d4297 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -134,6 +134,7 @@ struct babel_config { list iface_list; /* List of iface configs (struct babel_iface_config) */ uint hold_time; /* Time to hold stale entries and unreachable routes */ u8 randomize_router_id; + uint route_damping; struct channel_config *ip4_channel; struct channel_config *ip6_channel; @@ -216,6 +217,7 @@ struct babel_iface { int tx_length; list neigh_list; /* List of neighbors seen on this iface (struct babel_neighbor) */ list msg_queue; + list sched_rtes; /* Scheduled rte announcments for route dampening */ u16 hello_seqno; /* To be increased on each hello */ @@ -226,7 +228,9 @@ struct babel_iface { btime next_hello; btime next_regular; btime next_triggered; - btime want_triggered; + u8 want_triggered; + btime next_sched; + u8 want_sched; timer *timer; event *send_event; @@ -292,6 +296,7 @@ struct babel_route { ip_addr next_hop; btime refresh_time; btime expires; + btime sched_time; }; struct babel_seqno_request { @@ -306,7 +311,9 @@ struct babel_seqno_request { }; struct babel_entry { - struct babel_route *selected; + node sched; /* for babel_iface.sched_rtes */ + + struct babel_route *selected, *scheduled; list routes; /* Routes for this prefix (struct babel_route) */ list sources; /* Source entries for this prefix (struct babel_source). */ -- 2.30.2

3 5

AdminDown is tearing down BGP session
by Sunnat Samadov 01 Jun '23

01 Jun '23

Hi all, We are using BIRD https://gitlab.nic.cz/labs/bird/-/tags/v2.0.12 version.

1 0

Using as set a list of routes to advertise
by William 31 May '23

31 May '23

Hi All, I've been digging around trying to find a nice way of doing it but can't seem to find a valid answer. Is there a way to use a prefix set to create static routes? Ideally though being able to specify the set as the route to be added would be ideal. An alternative of something like a "for" loop that iterate through the set and adds the routes to the table would suffice. For example: define my_route_set = [ 10.1.2.3/24, 172.20.4.2/24, 10.200.0.0/23 ]; protocol static route_set { ipv4 { table Some_Routes; } route my_route_set via 192.168.55.2; # downstream static gateway } The prefix set is used to define the subnets for a remote node and used in import/export filters via BGP upstream. Being able to re-use the set without having to split it out would be hugely advantageous. I want to avoid having the neighbour device provide the routes via a routing protocol where it can be avoided. TIA. Regards, William

3 5

AddressSanitizer: heap-use-after-free lib/timer.h:61 in tm_active
by Zagorski, Michal 26 May '23

26 May '23

Hello, During stress testing I found invalid read within bgp. I use gcc's Address Sanitizer, building with config: CFLAGS="-D_FORTIFY_SOURCE=2 -fsanitize=address -fno-omit-frame-pointer -ggdb3 -g3 -O0" LDFLAGS="-fsanitize=address -fno-omit-frame-pointer" LIBS="-lasan" ./configure --with-protocols="bgp static" When breaking session links and querying "show protocols all" after expired hold timer, it hits with report: ================================================================= ==3476100==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000245508 at pc 0x56497e7af450 bp 0x7ffcae09e400 sp 0x7ffcae09e3f8 READ of size 8 at 0x606000245508 thread T0 #0 0x56497e7af44f in tm_active lib/timer.h:61 #1 0x56497e7c4e12 in bgp_show_proto_info proto/bgp/bgp.c:2624 #2 0x56497e76cb40 in proto_cmd_show nest/proto.c:2082 #3 0x56497e76d9bb in proto_apply_cmd_patt nest/proto.c:2232 #4 0x56497e76db9c in proto_apply_cmd nest/proto.c:2248 #5 0x56497e6762e6 in cf_parse nest/config.Y:623 #6 0x56497e69089c in cli_parse conf/conf.c:180 #7 0x56497e751001 in cli_command nest/cli.c:273 #8 0x56497e751273 in cli_event nest/cli.c:302 #9 0x56497e71f7a6 in ev_run lib/event.c:86 #10 0x56497e71f9af in ev_run_list lib/event.c:159 #11 0x56497e813e34 in io_loop sysdep/unix/io.c:2216 #12 0x56497e820b45 in main sysdep/unix/main.c:958 #13 0x7fa940846189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #14 0x7fa940846244 in __libc_start_main_impl ../csu/libc-start.c:381 #15 0x56497e65c940 in _start (/home/mzagorsk/git/cz-bird/bird+0x48940) 0x606000245508 is located 40 bytes inside of 64-byte region [0x6060002454e0,0x606000245520) freed by thread T0 here: #0 0x7fa940ab76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52 #1 0x56497e7376a5 in pool_free lib/resource.c:97 #2 0x56497e737c5f in rfree lib/resource.c:187 #3 0x56497e76b2bc in proto_do_down nest/proto.c:1885 #4 0x56497e76b56e in proto_notify_state nest/proto.c:1951 #5 0x56497e7b1b71 in bgp_down proto/bgp/bgp.c:475 #6 0x56497e7b1d8d in bgp_decision proto/bgp/bgp.c:493 #7 0x56497e71f7a6 in ev_run lib/event.c:86 #8 0x56497e71f9af in ev_run_list lib/event.c:159 #9 0x56497e813e34 in io_loop sysdep/unix/io.c:2216 #10 0x56497e820b45 in main sysdep/unix/main.c:958 #11 0x7fa940846189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 previously allocated by thread T0 here: #0 0x7fa940ab89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x56497e7461d4 in bird_xmalloc lib/xmalloc.c:29 #2 0x56497e73800b in ralloc lib/resource.c:245 #3 0x56497e7434df in tm_new lib/timer.c:133 #4 0x56497e7af4e6 in tm_new_init lib/timer.h:74 #5 0x56497e7bcad7 in bgp_channel_start proto/bgp/bgp.c:1796 #6 0x56497e7632da in channel_do_start nest/proto.c:560 #7 0x56497e763c89 in channel_set_state nest/proto.c:658 #8 0x56497e760cb6 in proto_start_channels nest/proto.c:217 #9 0x56497e76b081 in proto_do_up nest/proto.c:1853 #10 0x56497e76b504 in proto_notify_state nest/proto.c:1938 #11 0x56497e7b427c in bgp_conn_enter_established_state proto/bgp/bgp.c:691 #12 0x56497e7e217a in bgp_rx_keepalive proto/bgp/packets.c:3412 #13 0x56497e7e2445 in bgp_rx_packet proto/bgp/packets.c:3445 #14 0x56497e7e2683 in bgp_rx proto/bgp/packets.c:3488 #15 0x56497e8122e2 in call_rx_hook sysdep/unix/io.c:1800 #16 0x56497e8127cb in sk_read_noflush sysdep/unix/io.c:1888 #17 0x56497e812a2b in sk_read sysdep/unix/io.c:1923 #18 0x56497e8148dd in io_loop sysdep/unix/io.c:2323 #19 0x56497e820b45 in main sysdep/unix/main.c:958 #20 0x7fa940846189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-use-after-free lib/timer.h:61 in tm_active Shadow bytes around the buggy address: 0x0c0c80040a50: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x0c0c80040a60: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd 0x0c0c80040a70: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa 0x0c0c80040a80: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x0c0c80040a90: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd =>0x0c0c80040aa0: fd[fd]fd fd fa fa fa fa fd fd fd fd fd fd fd fa 0x0c0c80040ab0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x0c0c80040ac0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd 0x0c0c80040ad0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c0c80040ae0: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x0c0c80040af0: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==3476100==ABORTING Without sanitizers, similar scenario wouldn't lead to visible crashes or invalid output. If I understand it correctly, after hold timers expired, protocol's memory pool (p->pool) is freed from event with bgp_down. On other event, "show protocols all" read channels' structures and got valid pointer c->staled_timer, as timer is mostly deactivated, second condition would fail. -- Thanks, Michał Zagórski

2 1

Swapping routes without deletion
by Pim van Pelt 22 May '23

22 May '23

Hoi folks, At Coloclue AS8283, we upgraded from Bird1.6.8 to Bird2.0.12 this week. We use two separate processes, one for IPv4 and one for IPv6 - and 2.0.7 in Debian is missing the ability to select 'accept ipv4' and 'accept ipv6' in BFD, so we installed backports and version 2.0.12). I am wondering if Bird2 later than 2.0.7 perhaps has an optimization when swapping routes? I would expect a swap to be "delete + add" but I am seeing only "add with new nexthop" appear in Netlink. Considering the following topology with link names and OSPFv3 costs associated: dcg-1 bond0.130 ---- bond0.130 eun-2 | 2000 | enp1s0f3 enp1s0f2 | | | 10 10 | | | enp1s0f3 enp1s0f3 | 1000 | dcg-2 eno2.3469 ---- eno2.3469 eun-3 If I restart the OSPFv3 protocol, I see that the topology settles in the expected way. What I observed with bird 2.0.12 is that there is a deletion of the currently selected route followed by one addition, when the shortest path reveales (dcg1 - dcg2 - eun3 - eun2, ospf_metric1 is 1020, this is fine): root@dcg-1:~# birdc -s /run/bird/bird6.ctl restart ospf1 root@dcg-1:~# ip -6 monitor route | grep 2a02:898:0:300::3 Deleted 2a02:898:0:300::3 via fe80::669d:99ff:feb1:31af dev bond0.130 proto bird metric 32 pref medium 2a02:898:0:300::3 via fe80::669d:99ff:feb1:3910 dev enp1s0f3 proto bird metric 32 pref medium Now I lower the cost of the dcg-1 -- eun-2 link from 2000 to 100, so that it becomes preferred (cost ospf_metric is 120): root@dcg-1:~# birdc -s /run/bird/bird6.ctl reconfigure ospf1 root@dcg-1:~# ip -6 monitor route | grep 2a02:898:0:300::3 *[[ HERE ]]* 2a02:898:0:300::3 via fe80::669d:99ff:feb1:31af dev bond0.130 proto bird metric 32 pref medium I would expect this new addition of the installed route on bond0.130 to be *preceded by a deletion* of the previous route from enp1s0f3, but this is not the case (marked in red with [[ HERE ]]). To anyone's knowledge: *Has this behavior changed between 2.0.7 and 2.0.12 ?* groet, Pim -- Pim van Pelt <pim(a)ipng.nl> PBVP1-RIPE - http://www.ipng.nl/

3 6

Strange behaviour on filtering bgp_large_community ...
by Tim Weippert 20 May '23

20 May '23

Hi List, maybe i'm doing something wrong, but if i use some quick and dirty filter on the CLI all is working as expecting: show route where bgp_large_community ~ [(65000, 0, 1001)] show route where (65000, 0, 1001) ~ bgp_large_community both get the expected results, show all routes with the specific community attached. If i use it in a filter function to filter the routes out: function filter_large(int TestID) { if ( bgp_large_community ~ [(65000, 0, TestID)] ) then { return false; } return true; } i get "all" routes, if clause doesn't get catched. function filter_large_V2(int TestID) { if ( (65000, 0, TestID) ~ bgp_large_community ) then { return false; } return true; } with the V2 function i get what i want, filter out all routes with the community attached and show all the rest. I'm a little confused here, because the first version of the if clause is used for bgp_ext_community on several functions on my setup and working as expected, only for bgp_large_community i need to switch to if clause from version V2, and only in a function? Can someone confirm or explain this? regards, tim -- Tim Weippert http://weiti.org - weiti(a)weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8

3 3

RFC 9234 (BGP roles) possible bug
by Mikhail Grishin 18 May '23

18 May '23

Hi, We ran BGP roles at 1000+ BGP sessions. About 0.5 - 1% of them affected by some issue. Probably all of them - Juniper with the old junos. Here is description: 1) Our device (Bird) sent BGP Open to the peers, with Capability: BGP Role Type: BGP Role (9) Length: 1 Unknown: 01 2) Some "broken?" peers respond with: Border Gateway Protocol - OPEN Message Marker: ffffffffffffffffffffffffffffffff Length: 29 Type: OPEN Message (1) Version: 4 My AS: xxxxx Hold Time: 90 BGP Identifier: 10.5.5.2 Optional Parameters Length: 0 Border Gateway Protocol - NOTIFICATION Message Marker: ffffffffffffffffffffffffffffffff Length: 21 Type: NOTIFICATION Message (3) Major error Code: Cease (6) Minor error Code (Cease): Connection Rejected (5) 3) After that, Bird genarates another packet: Border Gateway Protocol - NOTIFICATION Message Marker: ffffffffffffffffffffffffffffffff Length: 21 Type: NOTIFICATION Message (3) Major error Code: OPEN Message Error (2) Minor error Code (Open Message): Unknown (11) About stage 2) - peer (old junos) shouldn't generate such response due to === If a BGP speaker receives from its peer a capability that it does not itself support or recognize, it MUST ignore that capability. In particular, the Unsupported Capability NOTIFICATION message MUST NOT be generated and the BGP session MUST NOT be terminated in response to reception of a capability that is not supported by the local speaker. === At the same time, question to the stage 3) - why Bird gererate such message? + In the logs printed Error: Role mismatch (provider) Wbr, Mikhail.

4 5

[PATCH] BMP: Support for multiple protocol instances and bugfixes
by Zagorski, Michal 17 May '23

17 May '23

Hello, We've put some work in BMP to support multiple collectors and fix bugs found during testing. Please, review attached patch. As of now, known issue: * When BMP connects after BGP sessions established, the collector won't receive updates until peer down on BGP. -- Thanks, Michał Zagórski

1 0

unable to install leaked routes with krt_prefsrc set/how to unset an attribute?
by jo+bird＠swagspace.org 16 May '23

16 May '23

Hello. I am currently trying to get route leaking to work on Linux with bird. I have several VRFs and want to leak some of the routes from one VRF into an other. For this I have several routing tables in bird, one kernel protocol per table and pipe protocols to leak to routes between the tables. This works as intended. However I have a problem when exporting my leaked routes to the kernel. I get the log message May 16 15:28:24 host-1 bird[7349]: kernel4: 0.0.0.0/0: reinstalling May 16 15:28:24 host-1 bird[7349]: Netlink: Invalid argument May 16 15:28:24 host-1 bird[7349]: kernel4: 172.21.0.1/32: reinstalling May 16 15:28:24 host-1 bird[7349]: Netlink: Invalid argument Those 2 routes are not installed into the corresponding kernel routing table. These are exactly the routes that have the Kernel.prefsrc/krt_prefsrc attribute set. If I try to install these routes manually with all the attributes they have in the bird routing table I get the error > root@host-1:~# ip r add table 5 0.0.0.0/0 via 172.21.0.1 dev vlan-uplink-1 metric 1024 src 172.21.0.153 > Error: Invalid prefsrc address. This is because the IP address that is used here comes from an other VRF where it is available however it is not available in the VRF I am trying to install it. (I also don't need the prefsrc option to where the route is installed.) If I add the route to the Linux FIB without the prefsrc value or with an IP address that is available in the corresponding VRF, then it works out as intended. A workaround that I found is to set the krt_prefsrc attribute on export to something that is available in the target VRF. However it would be nicer to simply remove the attribute. So is it possible to remove an attribute from a route in bird? Greetings Jo

2 1

Re: Strange behaviour on filtering bgp_large_community ...
by Tim Weippert 15 May '23

15 May '23

Hi Maria, i think the confusion part is, that it works on CLI in a "symmetric" way but not in a function, that was my biggest questionmark :) regards, tim On Mon, May 15, 2023 at 01:21:46PM +0200, Maria Matejka wrote: > Hello! > > The ~ operator is not symmetric. We should probably better check its arguments or maybe even update the syntax. It basically means, when A ~ B, that A is in B. > > Sorry for that confusion. > Maria > > On 15 May 2023 12:59:11 CEST, Tim Weippert via Bird-users <bird-users(a)network.cz> wrote: > >Hi List, > > > >maybe i'm doing something wrong, but if i use some quick and dirty > >filter on the CLI all is working as expecting: > > > >show route where bgp_large_community ~ [(65000, 0, 1001)] > >show route where (65000, 0, 1001) ~ bgp_large_community > > > >both get the expected results, show all routes with the specific > >community attached. > > > >If i use it in a filter function to filter the routes out: > > > >function filter_large(int TestID) > >{ > > if ( bgp_large_community ~ [(65000, 0, TestID)] ) then { return false; } > > return true; > >} > > > >i get "all" routes, if clause doesn't get catched. > > > >function filter_large_V2(int TestID) > >{ > > if ( (65000, 0, TestID) ~ bgp_large_community ) then { return false; } > > return true; > >} > > > >with the V2 function i get what i want, filter out all routes with the > >community attached and show all the rest. > > > >I'm a little confused here, because the first version of the if clause is > >used for bgp_ext_community on several functions on my setup and working > >as expected, only for bgp_large_community i need to switch to if clause > >from version V2, and only in a function? > > > >Can someone confirm or explain this? > > > >regards, > >tim > > > >-- > >Tim Weippert > >http://weiti.org - weiti(a)weiti.org > >GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8 -- Tim Weippert http://weiti.org - weiti(a)weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8

2 1