Change the definition of vl_api_mac_address_t to an aliased type.
Change-Id: I1434f316d0fad6a099592f39bceeb8faeaf1d134
Signed-off-by: Ole Troan <ot@cisco.com>
Add 2/3 support to binarytomac and mactobinary and move to vpp_mac.py
Change-Id: I3dc7e4a24486aee22140c781aae7e44e58935877
Signed-off-by: Ole Troan <ot@cisco.com>
- negative test with wrong XID in OFFER not implemented as issue
reported in Jira ticket VPP-99 still not fixed
Jira: CSIT-1147
Change-Id: I4ebc622bd81fed421919bc0397a12e32cb26fa1d
Signed-off-by: Jan Gelety <jgelety@cisco.com>
- use types on the DHCP API so that the same data is sent in comfing messages and in dumps
- add the DHCP client dump API
- update VOM to refelct API changes
- rename VOM class dhcp_config* dhcp_client*
- the VOM dhcp_client class maintains the lease data (which it reads on a dump) for clients to read
Change-Id: I2a43463937cbd80c01d45798e74b21288d8b8ead
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Add a few dhcp client rx packet/state counters
Temporarily disable the dhcp client unit test, since it trips over the
newly-added hardware address check.
Change-Id: I7f68607e6ed3d738cba357c3fe76664a99b71cd8
Signed-off-by: Dave Barach <dave@barachs.net>
- many of the patches fd.io applies in test/patches/2.3.3 are now upstreamed in 2.4
- 2.4 adds support for IGMPv3 which is my main motivation for the upgrade
Change-Id: If2c0a524e3cba320b4a5d8cd07817c6ea2bf0c5a
Signed-off-by: Neale Ranns <nranns@cisco.com>
DISCOVER message sent.
According to RFC2131:
In the case of a client using DHCP for initial configuration (before
the client's TCP/IP software has been completely configured), DHCP
requires creative use of the client's TCP/IP software and liberal
interpretation of RFC 1122. The TCP/IP software SHOULD accept and
forward to the IP layer any IP packets delivered to the client's
hardware address before the IP address is configured; DHCP servers
and BOOTP relay agents may not be able to deliver DHCP messages to
clients that cannot accept hardware unicast datagrams before the
TCP/IP software is configured.
To work around some clients that cannot accept IP unicast datagrams
before the TCP/IP software is configured as discussed in the previous
paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
defined as the BROADCAST (B) flag. The semantics of this flag are
discussed in section 4.1 of this document. The remaining bits of the
flags field are reserved for future use. They MUST be set to zero by
clients and ignored by servers and relay agents. Figure 2 gives the
format of the 'flags' field.
this changes means VPP conforms to the:
"SHOULD accept and forward to the IP layer any IP packets delivered
to the client's hardware address before the IP address is configured"
with the caveat that VPP allows DHCP packets destined to the stanard client
DHCP port to be delivered. With this enhancement the control-plane is now
able to choose the setting of the broadcast flag.
Change-Id: Ia4eb2c9bb1e30c29f9192facc645e9533641955a
Signed-off-by: Neale Ranns <nranns@cisco.com>
Enhence support of DHCP VSS (Virtual Subnet Selection) to include
VSS type 0 where VSS info is a NVT (Network Virtual Terminal)
ASCII VPN ID where the ASCII string MUST NOT be terminated with a
zero byte. Existing code already support VSS type 1, where VSS
information is a RFC 2685 VPN-ID of 7 bytes with 3 bytes OUI
and 4 bytes VPN index, and VSS type 255 indicating global VPN.
Change-Id: I54edbc447c89a2aacd1cc9fc72bd5ba386037608
Signed-off-by: John Lo <loj@cisco.com>
Dynamically calculate the required buffer size to pack into based on
message definition. Also add input parameter length checking.
Change-Id: I7633bec596e4833bb328fbf63a65b866c7985de5
Signed-off-by: Ole Troan <ot@cisco.com>
part 2;
- this adds the code to create an IP and MPLS table via the API.
- but the enforcement that the table must be created before it is used is still missing, this is so that CSIT can pass.
Change-Id: Id124d884ade6cb7da947225200e3bb193454c555
Signed-off-by: Neale Ranns <nranns@cisco.com>
despite VPP DHCP client setting neither ciaddr nor giaddr and setting the broadcast bit (see RFC 2131 section 4.1) some DHCP servers will still send a unicast DCHPACK. So as not to drop this VPP must have both 1) a receive FIB entry for the OFFERED IP adress and 2) a 'don't drop me because of uRPF' FIB entry for the DHCP server's address.
Change-Id: I167d858deb45629318cbdccf5bf67d971730a42f
Signed-off-by: Neale Ranns <nranns@cisco.com>
the existing seeting of client_id to a VPP version number was unused and so overridden
Change-Id: If9ebea936336f1fcca8d07e67186c95f8f8f0ccd
Signed-off-by: Neale Ranns <nranns@cisco.com>
Multiple DHCP (4 and/or 6) servers can be added and removed through multiple calls to the 'set dhcp server' API.
All 4/6/ discover/solicit messages will then be replicated to all servers in the list. The expectation is that the servers/system is configured in such a way that this is viable.
If VSS information is providied for the clinet VRF which also has multiple servers configured, then the same VSS information is sent to each server. Likewise the source address of packets sent to from VPP to each server is the same.
Change-Id: I3287cb084c84b3f612b78bc69cfcb5b9c1f8934d
Signed-off-by: Neale Ranns <nranns@cisco.com>
The DHCP proxy and VSS information maintained by VPP is the same for v4 and v6, so we can manage this state using the same code.
Packet handling is cleary different, so this is kept separate.
Change-Id: I10f10cc1f7f19debcd4c4b099c6de64e56bb0c69
Signed-off-by: Neale Ranns <nranns@cisco.com>
DHCP additions:
1) DHCPv4 will only relay a message back to the client, if the Option82 information is present. So make this the default.
2) It is no longer possible to select via the API to "insert circuit ID" - since this is now default
3) Remove the version 2 API since it's now the same as version 1.
4) Adding the VSS option is now conditional only on the presence of VSS config (not the 'insert' option in the set API)
5) DHCP proxy dump via API
Change-Id: Ia7271ba8c1d4dbf34a02c401d268ccfbb1b74f17
Signed-off-by: Neale Ranns <nranns@cisco.com>
- IPv[46] mfib tables with support for (*,G/m), (*,G) and (S,G) exact and longest prefix match
- Replication represented via a new replicate DPO.
- RPF configuration and data-plane checking
- data-plane signals sent to listening control planes.
The functions of multicast forwarding entries differ from their unicast conterparts, so we introduce a new mfib_table_t and mfib_entry_t objects. However, we re-use the fib_path_list to resolve and build the entry's output list. the fib_path_list provides the service to construct a replicate DPO for multicast.
'make tests' is added to with two new suites; TEST=mfib, this is invocation of the CLI command 'test mfib' which deals with many path add/remove, flag set/unset scenarios, TEST=ip-mcast, data-plane forwarding tests.
Updated applications to use the new MIFB functions;
- IPv6 NS/RA.
- DHCPv6
unit tests for these are undated accordingly.
Change-Id: I49ec37b01f1b170335a5697541c8fd30e6d3a961
Signed-off-by: Neale Ranns <nranns@cisco.com>
