Dummy Interface In OpenBGPd

[d***@thephinix.org]

Hi,

As I read the openbgpd documentation, there is not a single point wherein in the examples a dummy
interface is being used. Is a dummy interface supported in OpenBGP?

Regards,
Demuel

[Henning Brauer]

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point wherein in the examples a dummy
interface is being used. Is a dummy interface supported in OpenBGP?

-vvv :)

from bgpd's perspective, an interface is an interface, mostly.

[d***@thephinix.org]

Does that categorically mean there is no way, as of the moment, in openbgp to use a dummy
interface just like in Quagga?

Post by Henning Brauer

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point wherein in the examples a
dummy
interface is being used. Is a dummy interface supported in OpenBGP?

-vvv :)
from bgpd's perspective, an interface is an interface, mostly.
--
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Henning Brauer]

Post by d***@thephinix.org
Does that categorically mean there is no way, as of the moment, in openbgp to use a dummy
interface just like in Quagga?

well, you have to be more explicity.
pseudo-interfaces are just interfaces. there is no visible difference
for bgpd.

you still didn't say what you actually want.

[d***@thephinix.org]

I have 4 machines running OpenBSD-stable and it used some AS in the 64512-65535 range. Now, two of
these machines will be eventually connected to two different AS, say obsd1 to AS 64512 and obsd2
to 64513, while these four machines fall under one AS, say 64513.

From my readings in the published article of Claudio Jekker, it appears to me that this setup is

for a fully-redundant architecture wherein there could be no single point of failure.

I want to experiment with creating dummy interfaces under such topology just like in Quagga.

Post by d***@thephinix.org
Does that categorically mean there is no way, as of the moment, in openbgp to use a dummy
interface just like in Quagga?

well, you have to be more explicity.
pseudo-interfaces are just interfaces. there is no visible difference
for bgpd.
you still didn't say what you actually want.
--
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Henning Brauer]

Post by d***@thephinix.org
I want to experiment with creating dummy interfaces under such topology just like in Quagga.

this doesn't lead anywhere, really.
I don't know what "dummy interfaces .. just like in quagga" are, and,
moreover, it is completely unclear what you want to accomplish.

you probably just want a loopback interface, but that is a guess.

[d***@thephinix.org]

What i want to accomplish and wanted to do is to be able to use such an interface when all the NIC
on my machines are alloted for BGP.

Post by Henning Brauer

Post by d***@thephinix.org
I want to experiment with creating dummy interfaces under such topology just like in Quagga.

this doesn't lead anywhere, really.
I don't know what "dummy interfaces .. just like in quagga" are, and,
moreover, it is completely unclear what you want to accomplish.
you probably just want a loopback interface, but that is a guess.
--
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Henning Brauer]

Post by d***@thephinix.org
What i want to accomplish and wanted to do is to be able to use such an interface when all the NIC
on my machines are alloted for BGP.

that is not any clearer.
"such an interface"? get rid of that dummy interface terminology, that
doesn't exist.
"when all interfaces are alloted for BGP"? you probably mean allotted.
How are they allotted for BGP? you already have a BGP listener there?
Why are you haveing multiple listeners in teh first place?
the answer is probably still "create lo1" or similiar. But honestly, I
am tired of guessing what you actually want to accomplish. I asked 3
times now. Enough is enough.

[Claudio Jeker]

Post by d***@thephinix.org
Does that categorically mean there is no way, as of the moment, in
openbgp to use a dummy interface just like in Quagga?

There are no dummy interfaces. If you like to use a loopback interface
create one.

# cat > /etc/hostname.lo1
inet 10.83.66.128 255.255.255.255 NONE
# sh /etc/netstart lo1

That's it. You have a loopback address that can be used in bgpd.

neighbor 10.83.66.164 {
remote-as 65123
local-address 10.83.66.128
}

I guess that's what you are looking for. bgpd does not realy care about
interfaces. Interfaces and their link state are only used to figure out
the availability of nexthops.

Btw. for ospfd you can use "interface lo1" to reliably redistribute the
loopback address.
--
:wq Claudio

Post by d***@thephinix.org

Post by Henning Brauer

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point wherein in the examples a
dummy
interface is being used. Is a dummy interface supported in OpenBGP?

-vvv :)
from bgpd's perspective, an interface is an interface, mostly.
--
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[d***@thephinix.org]

Can this looback interface be used as a sort of router-id just like in Quagga? Do I need to add
routes for this IP address reachable elsewhere in my network?

Post by Claudio Jeker

Post by d***@thephinix.org
Does that categorically mean there is no way, as of the moment, in
openbgp to use a dummy interface just like in Quagga?

There are no dummy interfaces. If you like to use a loopback interface
create one.
# cat > /etc/hostname.lo1
inet 10.83.66.128 255.255.255.255 NONE
# sh /etc/netstart lo1
That's it. You have a loopback address that can be used in bgpd.
neighbor 10.83.66.164 {
remote-as 65123
local-address 10.83.66.128
}
I guess that's what you are looking for. bgpd does not realy care about
interfaces. Interfaces and their link state are only used to figure out
the availability of nexthops.
Btw. for ospfd you can use "interface lo1" to reliably redistribute the
loopback address.
--
:wq Claudio

Post by d***@thephinix.org

Post by Henning Brauer

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point wherein in the examples a
dummy
interface is being used. Is a dummy interface supported in OpenBGP?

-vvv :)
from bgpd's perspective, an interface is an interface, mostly.
--
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Claudio Jeker]

Post by d***@thephinix.org
Can this looback interface be used as a sort of router-id just like in
Quagga? Do I need to add routes for this IP address reachable elsewhere
in my network?

Yes the IP needs to be reachable from elsewhere in your network -- unless
you don't want to use it and you can use the IP as your router-id --
that's what the router-id keyword is used for (actually you can use almost
anything as router-id).

[d***@thephinix.org]

The thing is, after I creatd /etc/hostname.lo1 as stated and I tring to ping it from other devices
within that network, it is not reachable. I put network 10.83.66.128/32 in my /etc/bgpd.conf but
still I can only ping this interface from that host it is put in but not from the other host.

Some hints? Should I manually add a route to it in the kernel routing table?

Post by Claudio Jeker

Post by d***@thephinix.org
Does that categorically mean there is no way, as of the moment, in
openbgp to use a dummy interface just like in Quagga?

There are no dummy interfaces. If you like to use a loopback interface
create one.
# cat > /etc/hostname.lo1
inet 10.83.66.128 255.255.255.255 NONE
# sh /etc/netstart lo1
That's it. You have a loopback address that can be used in bgpd.
neighbor 10.83.66.164 {
remote-as 65123
local-address 10.83.66.128
}
I guess that's what you are looking for. bgpd does not realy care about
interfaces. Interfaces and their link state are only used to figure out
the availability of nexthops.
Btw. for ospfd you can use "interface lo1" to reliably redistribute the
loopback address.
--
:wq Claudio

Post by d***@thephinix.org

Post by Henning Brauer

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point wherein in the examples a
dummy
interface is being used. Is a dummy interface supported in OpenBGP?

-vvv :)
from bgpd's perspective, an interface is an interface, mostly.
--
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Stuart Henderson]

Post by d***@thephinix.org
Some hints? Should I manually add a route to it in the kernel routing table?

If you're going to use static routes, you might as well use an address
on an normal interface... it's only worth configuring BGP on a loopback address
if you have an IGP to redistribute that address into.

(interesting. this prompted me to read lo(4) and learn it has a link1 flag,
well you learn something new every day..!)

[Dan Farrell]

- You likely want to use the lo0 interface for this (although I suppose
lo1 will suffice, but lo0 is the 'standard' loopback address (don't beat
me up about my use of the word 'standard'))

- Stop using the term 'dummy' in reference to any interface. There is no
such thing. You are referring to the loopback interface, the interface
that doesn't actually bind to a particular physical network interface on
your box. Take a hint- Henning is getting annoyed with you... that can't
help you in any way.

- Using the loopback interface for peering sessions has been prescribed
by many for many years now because it allows EBGP sessions assigned to
it to persist even if one or more physical interfaces drops. However, in
reality, I have found that this is usually disastrous. You normally
don't want the peer session to outlast the production circuit the routes
are intended to traverse, or you risk receiving routes that lead to
nowhere, and that's always bad. The most common use I can think of for
proper use of loopback interfaces for BGP peering is for IBGP sessions,
not EBGP sessions. I'll ask what are you intending to use it for,
because your previous statements are not clear ("What i want to
accomplish and wanted to do is to be able to use such an interface when
all the NIC on my machines are alloted for BGP").

If someone else here has a different philosophy regarding BGP peers
configured on loopbacks, share it.

Ducking,

danno

-----Original Message-----
From: owner-***@openbsd.org [mailto:owner-***@openbsd.org] On Behalf
Of ***@thephinix.org
Sent: Wednesday, February 07, 2007 5:54 PM
To: ***@openbsd.org
Subject: Re: Dummy Interface In OpenBGPd

The thing is, after I creatd /etc/hostname.lo1 as stated and I tring to
ping it from other devices
within that network, it is not reachable. I put network 10.83.66.128/32
in my /etc/bgpd.conf but
still I can only ping this interface from that host it is put in but not
from the other host.

Some hints? Should I manually add a route to it in the kernel routing
table?

Post by Claudio Jeker

Post by d***@thephinix.org
Does that categorically mean there is no way, as of the moment, in
openbgp to use a dummy interface just like in Quagga?

There are no dummy interfaces. If you like to use a loopback interface
create one.
# cat > /etc/hostname.lo1
inet 10.83.66.128 255.255.255.255 NONE
# sh /etc/netstart lo1
That's it. You have a loopback address that can be used in bgpd.
neighbor 10.83.66.164 {
remote-as 65123
local-address 10.83.66.128
}
I guess that's what you are looking for. bgpd does not realy care about
interfaces. Interfaces and their link state are only used to figure out
the availability of nexthops.
Btw. for ospfd you can use "interface lo1" to reliably redistribute the
loopback address.
--
:wq Claudio

Post by d***@thephinix.org

Post by Henning Brauer

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point

wherein in the examples a

Post by Claudio Jeker

Post by d***@thephinix.org

Post by Henning Brauer

Post by d***@thephinix.org
dummy
interface is being used. Is a dummy interface supported in

OpenBGP?

Post by Claudio Jeker

Post by d***@thephinix.org

Post by Henning Brauer
-vvv :)
from bgpd's perspective, an interface is an interface, mostly.
--
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Stuart Henderson]

Post by Dan Farrell
- You likely want to use the lo0 interface for this (although I suppose
lo1 will suffice, but lo0 is the 'standard' loopback address (don't beat
me up about my use of the word 'standard'))

lo1 makes redistributing into OSPF simpler, as per Claudio's example.
Use lo0 and you have to either filter out the 127.0.0.1 or explicitly
redistribute the /32; use a separate lo1 and it's just 'interface lo1'
(this also has an advantage if you change the address for some reason).

aiui, it isn't uncommon to have multiple loopbacks on routers, it's
just unusual on unix boxes.

Post by Dan Farrell
- Stop using the term 'dummy' in reference to any interface. There is
no such thing.

Looks like there is an interface type on some unix-clone called dummy,
which doesn't seem to be very much different to what everyone else calls
loopback. They have loopback too, though. I don't think there's much
point in trying to guess why...

[Stuart Henderson]

Post by Claudio Jeker
Btw. for ospfd you can use "interface lo1" to reliably redistribute the
loopback address.

I have configured a router with yyy.yy.yyy.247/32 on lo1 and yyy.yy.yyy.247/28
on vlan2244. This seems attractive since BGP sessions can be bound to an address
which is available (at least over one of my metro links) whether or not OSPF
is running - (not to mention because I am working in a fairly small PI block
and would really like to avoid burning another /28 ;-)

The vlan already has a router acting as DR.

If I configure vlan2244 before lo1, all is well, associations are formed,
prefixes are seen.

If I configure lo1 before vlan2244 (default order for /etc/netstart), ospfd
doesn't act on any packets coming from the DR, it believes that it should be
DR itself, but no outbound packets are seen by tcpdump -i vlan2244 (or -i lo1).

I can work-around this at startup by altering netstart as follows,
but I wondered:-

1) is this an acceptable work-around?
2) should ospfd handle this any differently?
3) is it bloody stupid to be doing this?

--- netstart.orig Wed Nov 22 20:21:41 2006
+++ netstart Sat Feb 10 13:32:09 2007
@@ -289,7 +289,7 @@
# Configure all the non-loopback interfaces which we know about, but
# do not start interfaces which must be delayed.
# Refer to hostname.if(5) and bridgename.if(5)
-ifmstart "" "trunk vlan carp gif gre pfsync pppoe"
+ifmstart "" "trunk vlan carp gif gre pfsync pppoe lo"

if [ "$ip6kernel" = "YES" -a "x$rtsolif" != "x" ]; then
fw=`sysctl -n net.inet6.ip6.forwarding`
@@ -311,7 +311,7 @@
# The pfsync interfaces need to come up before carp.
# Configure all the carp interfaces which we know about.
# They must come up after pfsync but before default route.
-ifmstart "trunk vlan pfsync carp"
+ifmstart "trunk vlan pfsync carp lo"

# /etc/mygate, if it exists, contains the name of my gateway host
# that name must be in /etc/hosts.

-- -- -- -- -- -- -- --
# ls -l `which ospfd`
-r-xr-xr-x 1 root bin 108900 Feb 7 00:47 /usr/sbin/ospfd
# cat /etc/ospfd.conf

router-id yyy.yy.yyy.247

auth-type crypt
auth-md 1 YlqnfuTjFhs7v6
auth-md-keyid 1

hello-interval 2
router-dead-time 10

area 0.0.0.0 {
interface lo1
interface vlan2244 { metric 20 }
}

# sh /etc/netstart lo1 vlan2244
# ospfd -d
startup
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vlan2244
if_fsm: event UP resulted in action START and changing state for interface vlan2244 from DOWN to WAIT
start_spf_timer: IDLE -> DELAY
spf_calc: calculation started, area ID 0.0.0.0
spf_calc: calculation ended, area ID 0.0.0.0
spf_start_holdtimer: DELAY -> HOLD
spf_timer: state HOLD -> IDLE
if_act_elect: interface vlan2244 old dr none new dr yyy.yy.yyy.247, old bdr none new bdr none
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vlan2244
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vlan2244
if_fsm: event WAITTIMER resulted in action ELECT and changing state for interface vlan2244 from WAIT to DR
^Z[1] + Suspended ospfd -d
# bg
[1] ospfd -d
# tcpdump -nilo1
tcpdump: listening on lo1, link-type LOOP
^C
0 packets received by filter
0 packets dropped by kernel
# tcpdump -nivlan2244
tcpdump: listening on vlan2244, link-type EN10MB
14:23:12.018878 SSTP STP config root=88c4.0:c:31:64:f7:0 rootcost=0 bridge=88c4.0:c:31:64:f7:0 port=11 ifcost=128 age=0/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=2244
14:23:12.357744 yyy.yy.yyy.243 > 224.0.0.5: OSPFv2-hello 44: rtrid yyy.yy.yyy.3 backbone dr yyy.yy.yyy.243 [tos 0xc0] [ttl 1]
14:23:14.018983 SSTP STP config root=88c4.0:c:31:64:f7:0 rootcost=0 bridge=88c4.0:c:31:64:f7:0 port=11 ifcost=128 age=0/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=2244
14:23:14.367676 yyy.yy.yyy.243 > 224.0.0.5: OSPFv2-hello 44: rtrid yyy.yy.yyy.3 backbone dr yyy.yy.yyy.243 [tos 0xc0] [ttl 1]
14:23:16.019399 SSTP STP config root=88c4.0:c:31:64:f7:0 rootcost=0 bridge=88c4.0:c:31:64:f7:0 port=11 ifcost=128 age=0/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=2244
14:23:16.377767 yyy.yy.yyy.243 > 224.0.0.5: OSPFv2-hello 44: rtrid yyy.yy.yyy.3 backbone dr yyy.yy.yyy.243 [tos 0xc0] [ttl 1]
^C
-- -- -- -- -- -- -- --

[Stuart Henderson]

fwiw, one piece of fallout from listing the same address on a loopback
interface as a real iface is that ntpd 'listen on *' tries to listen to
the same address twice and fails, so you need to list the addresses
individually in ntpd.conf.

(other than that, I haven't seen any major problems, but I'd put it in
the category of "if you do this you'd better be ready to work out what's
breaking and how to fix it" and my third question definitely still
stands :)

Post by Stuart Henderson

Post by Claudio Jeker
Btw. for ospfd you can use "interface lo1" to reliably redistribute the
loopback address.

I have configured a router with yyy.yy.yyy.247/32 on lo1 and yyy.yy.yyy.247/28
on vlan2244. This seems attractive since BGP sessions can be bound to an address
which is available (at least over one of my metro links) whether or not OSPF
is running - (not to mention because I am working in a fairly small PI block
and would really like to avoid burning another /28 ;-)
The vlan already has a router acting as DR.
If I configure vlan2244 before lo1, all is well, associations are formed,
prefixes are seen.
If I configure lo1 before vlan2244 (default order for /etc/netstart), ospfd
doesn't act on any packets coming from the DR, it believes that it should be
DR itself, but no outbound packets are seen by tcpdump -i vlan2244 (or -i lo1).
I can work-around this at startup by altering netstart as follows,
but I wondered:-
1) is this an acceptable work-around?
2) should ospfd handle this any differently?
3) is it bloody stupid to be doing this?
--- netstart.orig Wed Nov 22 20:21:41 2006
+++ netstart Sat Feb 10 13:32:09 2007
@@ -289,7 +289,7 @@
# Configure all the non-loopback interfaces which we know about, but
# do not start interfaces which must be delayed.
# Refer to hostname.if(5) and bridgename.if(5)
-ifmstart "" "trunk vlan carp gif gre pfsync pppoe"
+ifmstart "" "trunk vlan carp gif gre pfsync pppoe lo"
if [ "$ip6kernel" = "YES" -a "x$rtsolif" != "x" ]; then
fw=`sysctl -n net.inet6.ip6.forwarding`
@@ -311,7 +311,7 @@
# The pfsync interfaces need to come up before carp.
# Configure all the carp interfaces which we know about.
# They must come up after pfsync but before default route.
-ifmstart "trunk vlan pfsync carp"
+ifmstart "trunk vlan pfsync carp lo"
# /etc/mygate, if it exists, contains the name of my gateway host
# that name must be in /etc/hosts.
-- -- -- -- -- -- -- --
# ls -l `which ospfd`
-r-xr-xr-x 1 root bin 108900 Feb 7 00:47 /usr/sbin/ospfd
# cat /etc/ospfd.conf
router-id yyy.yy.yyy.247
auth-type crypt
auth-md 1 YlqnfuTjFhs7v6
auth-md-keyid 1
hello-interval 2
router-dead-time 10
area 0.0.0.0 {
interface lo1
interface vlan2244 { metric 20 }
}
# sh /etc/netstart lo1 vlan2244
# ospfd -d
startup
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vlan2244
if_fsm: event UP resulted in action START and changing state for interface vlan2244 from DOWN to WAIT
start_spf_timer: IDLE -> DELAY
spf_calc: calculation started, area ID 0.0.0.0
spf_calc: calculation ended, area ID 0.0.0.0
spf_start_holdtimer: DELAY -> HOLD
spf_timer: state HOLD -> IDLE
if_act_elect: interface vlan2244 old dr none new dr yyy.yy.yyy.247, old bdr none new bdr none
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vlan2244
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface vlan2244
if_fsm: event WAITTIMER resulted in action ELECT and changing state for interface vlan2244 from WAIT to DR
^Z[1] + Suspended ospfd -d
# bg
[1] ospfd -d
# tcpdump -nilo1
tcpdump: listening on lo1, link-type LOOP
^C
0 packets received by filter
0 packets dropped by kernel
# tcpdump -nivlan2244
tcpdump: listening on vlan2244, link-type EN10MB
14:23:12.018878 SSTP STP config root=88c4.0:c:31:64:f7:0 rootcost=0 bridge=88c4.0:c:31:64:f7:0 port=11 ifcost=128 age=0/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=2244
14:23:12.357744 yyy.yy.yyy.243 > 224.0.0.5: OSPFv2-hello 44: rtrid yyy.yy.yyy.3 backbone dr yyy.yy.yyy.243 [tos 0xc0] [ttl 1]
14:23:14.018983 SSTP STP config root=88c4.0:c:31:64:f7:0 rootcost=0 bridge=88c4.0:c:31:64:f7:0 port=11 ifcost=128 age=0/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=2244
14:23:14.367676 yyy.yy.yyy.243 > 224.0.0.5: OSPFv2-hello 44: rtrid yyy.yy.yyy.3 backbone dr yyy.yy.yyy.243 [tos 0xc0] [ttl 1]
14:23:16.019399 SSTP STP config root=88c4.0:c:31:64:f7:0 rootcost=0 bridge=88c4.0:c:31:64:f7:0 port=11 ifcost=128 age=0/0 max=20/0 hello=2/0 fwdelay=15/0 pvid=2244
14:23:16.377767 yyy.yy.yyy.243 > 224.0.0.5: OSPFv2-hello 44: rtrid yyy.yy.yyy.3 backbone dr yyy.yy.yyy.243 [tos 0xc0] [ttl 1]
^C
-- -- -- -- -- -- -- --

[Stuart Henderson]

Post by d***@thephinix.org
Does that categorically mean there is no way, as of the moment, in openbgp to use a dummy
interface just like in Quagga?

there categorically *is* a way, set up /32 address on a lo interface,
and use that as local-address in bgpd.conf, making sure the other hosts
have a way to reach it (e.g. announce the /32 into OSPF). quite useful
for i-bgp sessions and it's pretty much the same way you'd do this
elsewhere.

there is nothing particularly special about the lo* interfaces,
just configure them as normal (hostname.lo0, hostname.lo1, etc).

[Stuart Henderson]

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point wherein
in the examples a dummy interface is being used. Is a dummy interface
supported in OpenBGP?

Do you mean 'loopback interface'? Works just fine (certainly to an alias
on lo0, I assume a single address on lo1, lo2 etc would likewise not be a
problem).

[d***@thephinix.org]

Yeah a loopback just like in Quagga or in Cisco.

Post by Stuart Henderson

Post by d***@thephinix.org
As I read the openbgpd documentation, there is not a single point wherein
in the examples a dummy interface is being used. Is a dummy interface
supported in OpenBGP?

Do you mean 'loopback interface'? Works just fine (certainly to an alias
on lo0, I assume a single address on lo1, lo2 etc would likewise not be a
problem).

[Henning Brauer]

Post by d***@thephinix.org
Yeah a loopback just like in Quagga or in Cisco.

loopback interfaces are pseudo-interfaces.
and as I said, interfaces are just interfaces for bgpd. pseudo or real,
there is no real difference.