December 2024 - Bird-users

[PATCH] Babel: allow enabling link quality estimation manually
by Nick Cao 09 Apr '25

09 Apr '25

Link quality estimation is useful for link types other than wireless, especially when using babel with tunnels where packet losses do occur. --- doc/bird.sgml | 6 ++++++ proto/babel/babel.c | 19 ++++++------------- proto/babel/babel.h | 1 + proto/babel/config.Y | 5 ++++- 4 files changed, 17 insertions(+), 14 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 8041faa9..417ec030 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2032,6 +2032,12 @@ protocol babel [<name>] { hardware drivers or platforms do not implement this feature. Default: yes. + <tag><label id="babel-link-quality">link quality <m/switch/</tag> + If set, link quality estimation is performed on this interface. + Link quality is measured by packet loss and is used for computing + metrics of routes going through this interface. Default: yes for + wireless interfaces, otherwise no. + <tag><label id="babel-next-hop-ipv4">next hop ipv4 <m/address/</tag> Set the next hop address advertised for IPv4 routes advertised on this interface. Default: the preferred IPv4 address of the interface. diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 7f0cca73..6a238d75 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -593,21 +593,15 @@ babel_update_cost(struct babel_neighbor *nbr) if (!rcv || !nbr->ifa->up) goto done; - switch (cf->type) - { - case BABEL_IFACE_TYPE_WIRED: - case BABEL_IFACE_TYPE_TUNNEL: + if (!cf->link_quality) { /* k-out-of-j selection - Appendix 2.1 in the RFC. */ /* Link is bad if less than cf->limit/16 of expected hellos were received */ - if (rcv * 16 < cf->limit * max) - break; - - rxcost = cf->rxcost; - txcost = nbr->txcost; - break; - - case BABEL_IFACE_TYPE_WIRELESS: + if (!(rcv * 16 < cf->limit * max)) { + rxcost = cf->rxcost; + txcost = nbr->txcost; + } + } else { /* * ETX - Appendix 2.2 in the RFC. * @@ -622,7 +616,6 @@ babel_update_cost(struct babel_neighbor *nbr) */ rxcost = MIN( cf->rxcost * max / rcv, BABEL_INFINITY); txcost = MIN(nbr->txcost * max / rcv, BABEL_INFINITY); - break; } if (cf->rtt_cost && nbr->srtt > cf->rtt_min) diff --git a/proto/babel/babel.h b/proto/babel/babel.h index edde4cab..d152d099 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -145,6 +145,7 @@ struct babel_iface_config { u8 type; u8 limit; /* Minimum number of Hellos to keep link up */ u8 check_link; + u8 link_quality; uint port; uint hello_interval; /* Hello interval, in us */ uint ihu_interval; /* IHU interval, in us */ diff --git a/proto/babel/config.Y b/proto/babel/config.Y index b8af0267..cbf873c5 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -26,7 +26,7 @@ CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, - EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS) + EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS, QUALITY) CF_GRAMMAR @@ -72,6 +72,7 @@ babel_iface_start: BABEL_IFACE->rtt_decay = BABEL_RTT_DECAY; BABEL_IFACE->rtt_send = 1; BABEL_IFACE->check_link = 1; + BABEL_IFACE->link_quality = 0; BABEL_IFACE->ext_next_hop = 1; }; @@ -84,6 +85,7 @@ babel_iface_finish: BABEL_IFACE->hello_interval = BABEL_HELLO_INTERVAL_WIRELESS; if (!BABEL_IFACE->rxcost) BABEL_IFACE->rxcost = BABEL_RXCOST_WIRELESS; + BABEL_IFACE->link_quality = 1; } else { @@ -156,6 +158,7 @@ babel_iface_item: | TX tos { BABEL_IFACE->tx_tos = $2; } | TX PRIORITY expr { BABEL_IFACE->tx_priority = $3; } | CHECK LINK bool { BABEL_IFACE->check_link = $3; } + | LINK QUALITY bool { BABEL_IFACE->link_quality = $3; } | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4; } -- 2.41.0

4 14

[PATCH v2] Babel: Allow v6 next hop on interfaces with v4 addresses
by Chris Webb 28 Mar '25

28 Mar '25

By default, the Babel protocol will advertise an IPv6 extended next hop address on interfaces which don't have an IPv4 address. This is controlled by the 'extended next hop' option. Add support for 'extended next hop force' which advertises an extended next hop even when IPv4 addresses are present. (They may be temporary, for debugging or otherwise unsuitable for including in an advertisement.) --- v2: use an explicit enum for possible values of ext_next_hop doc/bird.sgml | 9 ++++++--- proto/babel/babel.c | 17 +++++++++++++---- proto/babel/babel.h | 6 ++++++ proto/babel/config.Y | 5 +++-- 4 files changed, 28 insertions(+), 9 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 0d1e6f49..cb5fa572 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2266,7 +2266,7 @@ protocol babel [<name>] { check link <switch>; next hop ipv4 <address>; next hop ipv6 <address>; - extended next hop <switch>; + extended next hop <switch>|force; rtt cost <number>; rtt min <time>; rtt max <time>; @@ -2377,10 +2377,13 @@ protocol babel [<name>] { source for Babel packets will be used. In normal operation, it should not be necessary to set this option. - <tag><label id="babel-extended-next-hop">extended next hop <m/switch/</tag> + <tag><label id="babel-extended-next-hop">extended next hop + <m/switch/|force</tag> If enabled, BIRD will accept and emit IPv4 routes with an IPv6 next hop when IPv4 addresses are absent from the interface as described in - <rfc id="9229">. Default: yes. + <rfc id="9229">. Use <cf/extended next hop force/ to emit IPv4 routes + with an IPv6 next hop even when IPv4 addresses are present on the + interface. Default: yes. <tag><label id="babel-rtt-cost">rtt cost <m/number/</tag> The RTT-based cost that will be applied to all routes from each neighbour diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4187d258..4db6bd04 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1836,8 +1836,12 @@ babel_iface_update_addr4(struct babel_iface *ifa) { struct babel_proto *p = ifa->proto; - ip_addr addr4 = ifa->iface->addr4 ? ifa->iface->addr4->ip : IPA_NONE; - ifa->next_hop_ip4 = ipa_nonzero(ifa->cf->next_hop_ip4) ? ifa->cf->next_hop_ip4 : addr4; + if (ipa_nonzero(ifa->cf->next_hop_ip4)) + ifa->next_hop_ip4 = ifa->cf->next_hop_ip4; + else if (ifa->cf->ext_next_hop != BABEL_EXT_NEXT_HOP_FORCE && ifa->iface->addr4) + ifa->next_hop_ip4 = ifa->iface->addr4->ip; + else + ifa->next_hop_ip4 = IPA_NONE; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ifa->cf->ext_next_hop) log(L_WARN "%s: Missing IPv4 next hop address for %s", p->p.name, ifa->ifname); @@ -1912,8 +1916,13 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con add_tail(&p->interfaces, NODE ifa); - ip_addr addr4 = new->addr4 ? new->addr4->ip : IPA_NONE; - ifa->next_hop_ip4 = ipa_nonzero(ic->next_hop_ip4) ? ic->next_hop_ip4 : addr4; + if (ipa_nonzero(ic->next_hop_ip4)) + ifa->next_hop_ip4 = ic->next_hop_ip4; + else if (ic->ext_next_hop != BABEL_EXT_NEXT_HOP_FORCE && new->addr4) + ifa->next_hop_ip4 = new->addr4->ip; + else + ifa->next_hop_ip4 = IPA_NONE; + ifa->next_hop_ip6 = ipa_nonzero(ic->next_hop_ip6) ? ic->next_hop_ip6 : ifa->addr; if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ic->ext_next_hop) diff --git a/proto/babel/babel.h b/proto/babel/babel.h index edde4cab..5b397b45 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -127,6 +127,12 @@ enum babel_ae_type { BABEL_AE_MAX }; +enum babel_ext_next_hop { + BABEL_EXT_NEXT_HOP_OFF = 0, + BABEL_EXT_NEXT_HOP_ON = 1, + BABEL_EXT_NEXT_HOP_FORCE = 2 +}; + struct babel_config { struct proto_config c; diff --git a/proto/babel/config.Y b/proto/babel/config.Y index d412a54b..bdfff203 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -24,7 +24,7 @@ CF_DECLS CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, - NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, + NEXT, HOP, FORCE, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, EXTENDED, TUNNEL, RTT, MIN, MAX, DECAY, SEND, TIMESTAMPS, COST, DELAY) @@ -158,7 +158,8 @@ babel_iface_item: | CHECK LINK bool { BABEL_IFACE->check_link = $3; } | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } - | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4; } + | EXTENDED NEXT HOP bool { BABEL_IFACE->ext_next_hop = $4 ? BABEL_EXT_NEXT_HOP_ON : BABEL_EXT_NEXT_HOP_OFF; } + | EXTENDED NEXT HOP FORCE { BABEL_IFACE->ext_next_hop = BABEL_EXT_NEXT_HOP_FORCE; } | AUTHENTICATION NONE { BABEL_IFACE->auth_type = BABEL_AUTH_NONE; } | AUTHENTICATION MAC { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 0; } | AUTHENTICATION MAC PERMISSIVE { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 1; }

3 5

How to upgrade version Bird to 2.15.1
by Nguyen Van Nhan 02 Feb '25

02 Feb '25

Dear Bird Community, I have installed BIRD and tested the configurations related to the operation of this application. I have some questions during the BIRD deployment process, I hope you will give me specific instructions for editing and optimizing in operation. I am installing the default Bird version 2.0.8 on Ubuntu LTS 22.04 operating system 1. Can you provide me with detailed instructions to upgrade Bird to the latest version 2.15.1? I have tried to upgrade but when performing the operation in birdc, it still shows that it is at version 2.0.8. 2. Does Bird support BMP protocol in the latest version? We are researching to use BMP on Bird to get monitoring data via OpenBMP. Is it possible? Thanks and best regards, Nhan Nguyen Email: nhannv(a)vnnic.vn<mailto:nhannv@vnnic.vn> Mobile: +84 905 674 854

2 1

radvd lifetime question
by Nico Schottelius 23 Jan '25

23 Jan '25

Hello, we got a network in which clients using dhcpcd withdraw the router advertisements sent by bird too early: -------------------------------------------------------------------------------- Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired Dec 19 06:33:15 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe48:3bb8: router expired Dec 19 06:38:22 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: fe80::20d:b9ff:fe46:3bd4: router expired Dec 19 06:39:30 bibimbap daemon.warn dhcpcd[18464]: wlan0: part of a Router Advertisement expired -------------------------------------------------------------------------------- The config in bird is: -------------------------------------------------------------------------------- protocol radv { # Pods / bridge interface "eth0" { max ra interval 10; prefix 2a0a:5480::/64 { preferred lifetime 86400; }; prefix 2a0a:e5c0:13::/64 { skip; }; default preference high; }; rdnss { ns 2a0a:5480:0:a::a; ns 2a0a:5480:0:a::b; lifetime 86400; }; } -------------------------------------------------------------------------------- This causes RAs to be sent that look like this: -------------------------------------------------------------------------------- interface wlan0 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag off; AdvOtherConfigFlag off; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 30; AdvHomeAgentFlag off; AdvDefaultPreference low; prefix 2a0a:5480::/64 { AdvValidLifetime 86400; AdvPreferredLifetime 86400; AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; # End of prefix definition RDNSS 2a0a:5480:0:a::a 2a0a:5480:0:a::b { AdvRDNSSLifetime 86400; }; # End of RDNSS definition }; # End of interface definition -------------------------------------------------------------------------------- It seems that the "AdvDefaultLifetime 30;" is wrong. Trying to fix it using -------------------------------------------------------------------------------- interface "eth0" { default lifetime 86400; -------------------------------------------------------------------------------- fails as bird reports: -------------------------------------------------------------------------------- /bird/bird.conf:897:31 Default lifetime must be in range 0-9000 -------------------------------------------------------------------------------- I read in the manpage of radvd that indeed 9000 is the max (not sure why that limit is at 9k though...), but what I am wondering is what is the right approach to this? Or is this a bug in dhcpcd? BR, Nico p.s.: A low "max ra interval" allows us to run multiple, active routers in the same network and clients will quickly fall over to the second router, if one is not functioning correctly. -- Sustainable and modern Infrastructures by ungleich.ch

2 1

third (?) bug in 3.0.0
by Marek Zarychta 14 Jan '25

14 Jan '25

I tried BIRD 3 on FreeBSD, seems to build fine including both flavors: netlink and rtsock. Only the netlink flavor was tested in runtime. In small, testing scenario with OSPF and BGP it seems to run fine. When deployed in production setup with dual-stack and 2x full-view the daemon crashes almost immediately with SIGSEGV. It was non-debug built, so cores will not be much useful, though I can share them. Cheers -- Marek Zarychta

2 3

Concerning the structure of ASPA tables and AS0
by Ralph Covelli 09 Jan '25

09 Jan '25

Hello Bird Team! My name is Ralph. I'm a network engineer and C programmer for Hurricane Electric. I am a long time fan of the Bird project! Keep up the great work!! Earlier this year I was tasked with implementing reactive ASPA in our network. My code was based off your older implementation of static ASPA tables here: https://gitlab.nic.cz/labs/bird/-/tree/aspa This older implementation is based off of customer-provider pairs: typedef struct net_addr_aspa { u8 type; u8 padding; u16 length; u32 customer_asn; u32 provider_asn; } net_addr_aspa; I've attached the patch as "bird-2.15.1-aspa-asn-pairs.patch". I took a look at 2.16 and ran into 2 problems. Respectfully, I would like to report two issues with the ASPA code in 2.16. Issue #1) There is no way to tell the difference between a transit entry and an "AS0" entry. $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56; route aspa 43970 provider 0; } --- $ ./sbin/birdc BIRD 2.16 ready. bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 43 56 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> --- The treatment of AS0 providers is mentioned in section 5 of draft-ietf-sidrops-aspa-verification-19. It is a mechanism for people to announce that "no one should announce this AS". I've attached a snapshot of the global ASPA table as "bird-aspa-v2.16.conf". There is one AS0 announcement as of today. Issue #2) Changes in static ASPA tables are not reflected until entries are removed and re-added. $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56; route aspa 43970 provider 0; } bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 43 56 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56, 78; <---- added AS78 route aspa 43970 provider 0; } $ ./sbin/birdc BIRD 2.16 ready. bird> configure Reading configuration from /home/rpki/bird/etc/bird.conf Reconfigured bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 43 56 <-------- changes not reflected *** 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; #route aspa 970 provider 43, 56, 78; <----- remove entries altogether route aspa 43970 provider 0; } $ ./sbin/birdc BIRD 2.16 ready. bird> configure Reading configuration from /home/rpki/bird/etc/bird.conf Reconfigured bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> $ cat bird-aspa.conf aspa table at; protocol static { aspa; route aspa 12345 transit; route aspa 970 provider 43, 56, 78; <------- add entry again route aspa 43970 provider 0; } $ ./sbin/birdc BIRD 2.16 ready. bird> configure Reading configuration from /home/rpki/bird/etc/bird.conf Reconfigured bird> show route table at all Table at: 43970 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 970 [static1 20:17:30.142] * (200) Type: static univ aspa_providers: 43 56 78 <--------- changes reflected correctly 12345 [static1 19:38:32.125] * (200) Type: static univ aspa_providers: 0 bird> --- This problem does not occur when the ASPA elements are customer-provider pairs. I believe this is an overall design issue, not a simple bug. I will be bringing this issue up with ietf-sidrops. Thanks! -- Ralph Covelli Hurricane Electric / AS6939 Network Engineer

2 8

first (?) bird 3.0.0 bug report
by Radu Anghel 08 Jan '25

08 Jan '25

Hi, Using a slightly modified version of the config from the 2.15.1 (just some {} inside case structures), but probably unrelated. If bird gets killed/not shut down properly and routes remain in the kernel then bird 3.0.0 is unable to restart and just segfaults when trying to refresh kernel routes. I can reproduce it by just kill -9 bird && restarting bird. daemon.debug bird: KERNEL6.ipv6: route refresh begin: rr 1 set 1 valid 0 pruning 0 pruned 0 kern.info kernel: [75645.964935] bird[4162]: segfault at 0 ip 000000000045d47b sp 00007ffcb9f9f2c0 error 4 in bird[403000+a8000] likely on CPU 1 (core 0, socket 1) kern.info kernel: [75645.970115] Code: 5d 41 5c 41 5d 41 5e 41 5f c3 55 53 48 89 fb 48 83 ec 38 80 bb 79 02 00 00 04 48 8b 7f 30 75 46 48 89 d5 31 d2 e8 63 a4 ff ff <83> 38 00 49 89 c0 75 07 31 c0 e9 9d 00 00 00 48 8b 40 10 48 8d 7b The kernel protocol config is: protocol kernel KERNEL6 { debug { events, states }; scan time 3600; merge paths on; metric 0; ipv6 { import filter KERNEL_IN; export filter KERNEL_OUT; }; } Cheers, R

4 11

doc: flow6 label should be numeric op, not bitmask
by Eric Long 31 Dec '24

31 Dec '24

Hi, In User's Guide Section 6.6 (Protocol :: Static) [0], IPv6 flowspec's flow label component is documented as: > label bitmask-match > > Set a 20-bit bitmask for matching Flow Label field in packets (e.g. > label 0x8e5/0x8e5). However in RFC 8956 (Dissemination of Flow Specification Rules for IPv6) as well as earlier drafts it should be followed by numeric operators instead of bitmasks. Source code seems to be correct [2], though. p.s. Could BGP's "supported standards" replace RFC 5575 with 8955/8956? Cheers, Eric [0]: https://bird.network.cz/?get_doc&v=30&f=bird-6.html#ss6.16 [1]: https://www.rfc-editor.org/rfc/rfc8956.html#name-type-13-flow-label-new [2]: https://gitlab.nic.cz/labs/bird/-/blob/96dc63d602016c38f43677b2f95705aee9dc…

1 0

second (?) bug in 3.0.0
by Job Snijders 30 Dec '24

30 Dec '24

Second bug? :-) bird: 2024-12-18 15:01:29.251 [0001] <INFO> Started bird: 2024-12-18 15:01:34.615 [0001] <BUG> Trying to lock in a bad order: 00007fff17afd6e0 000079af687be298 seems to trigger when peers connect config: router id 10.10.255.254; protocol device { } protocol direct { disabled; } protocol kernel { ipv4 { import none; export none; }; } log stderr all; protocol bgp everything { local as 1000; neighbor range 10.0.0.0/8 external; connect delay time 1; ipv4 {import all; export all; next hop self; import table on;}; }

2 3

freebsd : how to allow loopback nexthop in OSPFv3-IPv4 ?
by benoitc＠enki-multimedia.eu 26 Dec '24

26 Dec '24

Hi all, I would like te to use the new feature "allow loopback nexthop in OSPFv3-IPv4 " on freebsd but I am not sure about the configuration. Let say 2 machines are linked to each others via a vlan. Should I pass the vlan as ptp or stub on freebsd ? Or is there any other way to have unnumbered interfaces on freebsd? Eg for the interface vlan330: protocol ospf v3 ospfv4 { ipv4 { import filter ospf_import; export filter ospf_export; }; area 0 { interface "lo1" { stub yes; }; interface "vlan330" { type ptp; cost 25; }; }; } Is this configuration correct? Benoît

2 2