Re: EBGP over unnumbered serial lines

Dennis Ferguson <dennis@mci.net> Thu, 28 September 1995 22:04 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19488; 28 Sep 95 18:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19484; 28 Sep 95 18:04 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa22415; 28 Sep 95 18:04 EDT
Received: by interlock.ans.net id AA32229 (InterLock SMTP Gateway 3.0 for iwg-out@ans.net); Thu, 28 Sep 1995 17:42:43 -0400
Message-Id: <199509282142.AA32229@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 28 Sep 1995 17:42:43 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 28 Sep 1995 17:42:43 -0400
To: Tony Li <tli@cisco.com>
Cc: rxg@proteon.com, bgp@ans.net
Subject: Re: EBGP over unnumbered serial lines
In-Reply-To: Your message of "Thu, 28 Sep 1995 13:55:10 PDT." <199509282055.AA24046@interlock.ans.net>
Date: Thu, 28 Sep 1995 17:41:38 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dennis Ferguson <dennis@mci.net>

>   > Wow, you can do that?  ;-)
>   > 
>   > The correct answer (that Dimitry alludes to obliquely) is that if you
>   > put your TCP peering address into the NEXT_HOP attribute that the
>   > neighbor should accept it.  Assuming the neighbor has a clue.
>
>   No, we can't do that.  I just wondered if you all experts out there
>   have a way to do that ;-).  Anyway, it did not even make sense to me
>   and it was more of a curiosity question.
>
> Yes, this is doable and not even too tough.  Well, at least for us it
> wasn't.  It _did_ take a few passes to consider all of the cases when
> verifying the next hop.

It works fine this way on unix boxes too, though the implementation
details are uglier.  Since you need an address for the remote end
of the serial line in any case to use as a tag for the brain-dead
forwarding table (unnumbered circuits still have numbers on unix
boxes, you just avoid telling anyone what the numbers are) the
technique there is to take the local and remote addresses used for
the TCP connection and actually configure the interface with them
(the configured addresses can be unrelated by a mask).  This even
makes the TCP-connection-addresses-as-next-hops look right to the
box and, lacking other routing information, the interface configuration
also provides the static host route needed to know where to send
packets to the neighbour.

Dennis Ferguson