Billy,
Thanks for pointing out that this particular case is documented in
doxygen. I didn't follow up on this specific example but was
highlighting the general issue. It would be nice to have specific tag
in Doxygen which identifies configuration constraint definitions.
Thanks,
-daw-
On 1/17/17 10:13 AM, Billy McFall wrote:
Dave, I agree with your statements about VPP probably needs to add the
verification. I wanted to add that this constraint was added to the
Doxygen documentation. But there are a lot of constraints that are not
documented, and if they are, I'm not sure how to better propagate the
information to masses.
From the Doxygen documentation for "set interface ip table":
*Note*
IP addresses added after setting the interface IP table end up
in the indicated FIB table. If the IP address is added prior
to adding the interface to the FIB table, it will NOT be part
of the FIB table. Predictable but potentially
counter-intuitive results occur if you provision interface
addresses in multiple FIBs. Upon RX, packets will be processed
in the last IP table ID provisioned. It might be marginally
useful to evade source RPF drops to put an interface address
into multiple FIBs.
Billy McFall
On Tue, Jan 17, 2017 at 9:45 AM, Dave Wallace <dwallac...@gmail.com
<mailto:dwallac...@gmail.com>> wrote:
Neale,
Given this constraint, IMO it should be verified prior to enacting
the change of the interface table and the request should be
rejected if the constraint is not met. The $64,000 question is
whether this constraint should be verified by VPP itself or the
management agent.
Prior to open sourcing VPP, when there was a dedicated management
agent, Dave and I agreed that constraint verification was the
responsibility of the management agent.
Now that VPP is open source and there are potentially numerous
management agents, it seems to me that including configuration
constraint verification in the VPP might make more sense as a
defensive mechanism.
In either case, there is a general lack of documentation on
feature constraints that needs to be addressed. In the past, I
have worked on a system where the entire set of system
configuration constraints was documented in the bug tracking
system. Needless to say, this was a less than optimal means of
communicating the set of requirements.
Thanks,
-daw-
On 1/17/2017 2:20 AM, Neale Ranns (nranns) wrote:
Hi Choonho,
An interface can only reside in (a.k.a be bound to) a single
table. So each time you do;
Set int ip table loop0 X
You are changing the table it is bound to, not adding tables. So
the output you see at the end of the sequence is correct, the
loopback has two addresses and is bound to table 5.
However, this is not a supported sequence of events. You MUST
remove all configured IP address on an interface before you
change the interface’s table.
Regards,
neale
*From: *<vpp-dev-boun...@lists.fd.io>
<mailto:vpp-dev-boun...@lists.fd.io> on behalf of Choonho Son
<choonho....@gmail.com> <mailto:choonho....@gmail.com>
*Date: *Tuesday, 17 January 2017 at 00:17
*To: *"vpp-dev@lists.fd.io" <mailto:vpp-dev@lists.fd.io>
<vpp-dev@lists.fd.io> <mailto:vpp-dev@lists.fd.io>
*Subject: *[vpp-dev] show interface address with multiple tables
With multiple tables(VRF), show interface addr display wrong
table ID.
DBGvpp# create loopback interface
loop0
DBGvpp# set interface ip table loop0 1
DBGvpp# set interface ip address loop0 1.0.0.250/16
<http://1.0.0.250/16>
DBGvpp# sh int addr
local0 (dn):
loop0 (dn):
1.0.0.250/16 <http://1.0.0.250/16> table 1
DBGvpp# set interface ip table loop0 5
DBGvpp# set interface ip address loop0 5.0.0.250/16
<http://5.0.0.250/16>
DBGvpp# sh int addr
local0 (dn):
loop0 (dn):
1.0.0.250/16 <http://1.0.0.250/16> table 5
5.0.0.250/16 <http://5.0.0.250/16> table 5
DBGvpp#
The reason looks like
ip4_main_t has single fib_index_by_sw_if_index.
Even though sw_if_index has two table ID(fib_index) 1 and 5.
Last updated fib_index(Table 5) is updated at ip4_main_t.
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
https://lists.fd.io/mailman/listinfo/vpp-dev
<https://lists.fd.io/mailman/listinfo/vpp-dev>
_______________________________________________ vpp-dev mailing
list vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
https://lists.fd.io/mailman/listinfo/vpp-dev
<https://lists.fd.io/mailman/listinfo/vpp-dev>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
