[quagga-dev 4801] Re: PtP not working in 0.99.7 on FreeBSD

Andrew J. Schorr aschorr at telemetry-investments.com
Tue May 15 14:10:17 BST 2007


On Mon, May 14, 2007 at 06:38:33PM -0400, Greg Troxel wrote:
> In BSD, p2p interfaces can be either configured with a /32 or a bigger
> mask.  One gives the local address/prefix length and the peer's address.
> e.g.:
> 
>   ifconfig gif0 10.0.255.1/30 10.0.255.2
> 
> I'm not sure if anything useful happens for addresses in the prefix but
> not the peer or us; they may get routed to the peer.  People with
> subnets typically use a /30; my reason was to make DVMRP happy (it being
> a protocol that doesn't really grok p2p links).
> 
> The RTM_NEWADDR is matched up with the interface flags and type from
> earlier, so it's clear it's a p2p interface.  I don't see how confusion
> would arise.

I'm not saying that a knowledgeable BSD user would be confused, I'm
just saying that I'm confused. :-)  According to the docs, the RTM_NEWADDR
message may have these fields:

     #define RTA_DST	   0x1	  /* destination sockaddr present */
     #define RTA_GATEWAY   0x2	  /* gateway sockaddr present */
     #define RTA_NETMASK   0x4	  /* netmask sockaddr present */
     #define RTA_GENMASK   0x8	  /* cloning mask sockaddr present */
     #define RTA_IFP	   0x10   /* interface name sockaddr present */
     #define RTA_IFA	   0x20   /* interface addr sockaddr present */
     #define RTA_AUTHOR    0x40   /* sockaddr for author of redirect */
     #define RTA_BRD	   0x80   /* for NEWADDR, broadcast or p-p dest addr */

In practice, at least in the FreeBSD examples that have been shared
with me, ifam_addrs has a value of 0xb4, which means that only 4 fields
are included in the message: RTA_NETMASK, RTA_IFP, RTA_IFA, and RTA_BRD.

So in your example above, where gif0 is configured with 10.0.255.1/30,
would RTA_BRD contain the peer address (10.0.255.2) or would
it contain the broadcast address (10.0.255.3)?  And how is this distinction
clearly communicated in the RTM_NEWADDR message?

> In a standards-based world, they are not actually orthogonal.  There is
> a spec for IP over Ethernet, and it's about subnets and arp.  What
> standards is your example case following?

I'm not aware of the standards issues here.  I am aware of the very
flexible addressing schemes supported by linux, and I think quagga now
has the capability to represent these various schemes properly.

> > The goal with my patch was to support the more flexible addressing
> > schemes where the addressing scheme is independent of the underlying
> > interface type.  But if FreeBSD has no notion of this, then we may
> > have to fall back to the old approach of assuming that PtP interfaces
> > are configured in one way, and broadcast interfaces configured in
> > another.
> 
> I really don't see a use case for this, other than supporting odd
> configs where there are only two hosts on an Ethernet and they have
> different prefixes.  Arguably if an ethernet is to be configured this
> way the POINTOPOINT flag should appear.  You're asking for an interface
> which is of type BROADCAST but behaves as POINTOPOINT, or at least
> that's how it sounds.
> 
> Are you saying that in Linux you can give a destination address to an
> ethernet?  How does it then behave?

Absolutely, linux can support this.  And this may in fact be a desirable
way to configure a metro ethernet WAN circuit (which are becoming very
common with telecomm carriers, at least in the U.S.).

Linux is very flexible.  Here are some examples of interface configurations
under linux:

1. Standard broadcast ethernet interface:
   bash-3.1$ ip -4 addr ls dev lan0.20
   4: lan0.20 at lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
       inet 192.168.20.93/24 brd 192.168.20.255 scope global lan0.20

2. Ethernet with PtP addressing style:
   bash-3.1$ ip -4 addr ls dev eth1
   3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
       inet 192.168.20.93 peer 172.17.1.1/32 scope global eth1

3. PtP (over a GRE tunnel) with shared local address (similar to #2 just above):
   bash-3.1$ ip -4 addr ls dev ptp0
   10: ptp0 at NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue 
       inet 192.168.20.93 peer 172.17.1.1/32 scope global ptp0

4. PtP with a /30 subnet assigned (and no peer specified):
   bash-3.1$ ip -4 addr ls dev ptp0
   10: ptp0 at NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue 
       inet 172.17.1.1/30 brd 172.17.1.3 scope global ptp0

5. PtP with /30 and peer specified:
   bash-3.1$ ip -4 addr ls dev ptp0
   10: ptp0 at NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue 
       inet 172.17.1.1 peer 172.17.1.2/30 brd 172.17.1.3 scope global ptp0

6. PtP with shared local address and a /24 peer address:
   bash-3.1$ ip -4 addr ls dev ptp0
   10: ptp0 at NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue 
       inet 192.168.20.93 peer 172.17.1.2/24 scope global ptp0

(note: I'm not exactly sure what #6 "means", but linux will now route
anything in the 172.17.1.2/24 prefix over the ptp0 link:

   bash-3.1$ ip route get 172.17.1.4
   172.17.1.4 dev ptp0  src 192.168.20.93 
       cache  mtu 1476 advmss 1436 hoplimit 64
.)

I have no idea which (if any) standards this flexibility complies with.
But I do know that linux supports it, and I also know that quagga
(as of release 0.99.7) can at least try to represent this in struct connected
(now that we have introduced the ZEBRA_IFA_PEER flag).

I'm not interested in the religious aspects -- I'm just trying to understand
which of these addressing modes are supported by BSD, and how they would
be communicated in the RTM_NEWADDR message so that quagga can represent
them accurately.  If you tell me that the way to understand the RTM_NEWADDR
message properly is to test the interface type and use that to
interpret RTA_BRD (as the peer address if it is a PtP interface, and
as the broadcast address otherwise), then so be it, that's a trivial
patch, let's commit it and move on.  But if you tell me that BSD has
more flexibility than that, then we need to figure out a more sophisticated
way of interpreting the RTM_NEWADDR message.  The latest patch I submitted
simply looks at the RTA_BRD value and sees whether it matches the broadcast
address that would normally be associated with the RTA_IFA and RTA_NETMASK
values.  If it doesn't match, then I assume that RTA_BRD contains a peer
address instead.  Is that a good approach?  It's up to you BSD folks
to decide...

> (I know, I'm extra cranky today....)

I'm always cranky, so I certainly understand. :-)

Regards,
Andy



More information about the Quagga-dev mailing list