Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I36ad1ef2a53af3d3f3a6348bc189b17e9e4e21bd
Signed-off-by: jackiechen1985 <xiaobo.chen@tieto.com>
|
|
Change-Id: I53ab8d17914e6563110354e4052109ac02bf8f3b
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I682a47d6cf9975aca6136188d28ee93eaadf4fe3
Signed-off-by: Juraj Sloboda <jsloboda@cisco.com>
|
|
- Generate client DUID only when DHCPv6 PD feature is enabled
- Change client DUID type from DUID-LLT to DUID-LL
- Fix coverity warnings
Change-Id: I20e518fc9a1c5f3f7ea9add7e7e03a487c99e978
Signed-off-by: Juraj Sloboda <jsloboda@cisco.com>
|
|
Change-Id: I72a1ccdfdd5573335ef78fc01d5268934c73bd31
Signed-off-by: Juraj Sloboda <jsloboda@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>
|
|
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>
|
|
This does not update api client code. In other words, if the client
assumes the transport is shmem based, this patch does not change that.
Furthermore, code that checks queue size, for tail dropping, is not
updated.
Done for the following apis:
Plugins
- acl
- gtpu
- memif
- nat
- pppoe
VNET
- bfd
- bier
- tapv2
- vhost user
- dhcp
- flow
- geneve
- ip
- punt
- ipsec/ipsec-gre
- l2
- l2tp
- lisp-cp/one-cp
- lisp-gpe
- map
- mpls
- policer
- session
- span
- udp
- tap
- vxlan/vxlan-gpe
- interface
VPP
- api/api.c
OAM
- oam_api.c
Stats
- stats.c
Change-Id: I0e33ecefb2bdab0295698c0add948068a5a83345
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
- separate client/server code for both memory and socket apis
- separate memory api code from generic vlib api code
- move unix_shared_memory_fifo to svm and rename to svm_fifo_t
- overall declutter
Change-Id: I90cdd98ff74d0787d58825b914b0f1eafcfa4dc2
Signed-off-by: Florin Coras <fcoras@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>
|
|
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>
|
|
Change-Id: I4a529dfab5d0ce6b0bbc0ccbbd89c6b109dbf917
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Hostnames are limited to 63 characters and a NUL terminator.
Change-Id: Ie1724d83675cca5e8cdfcd99d8e56e530a044d5d
Signed-off-by: Jon Loeliger <jdl@netgate.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>
|
|
Removed a fair number of "BUG" message handlers, due to conflicts with
actual message handlers in api_format.c. Vpp itself had no business
receiving certain messages, up to the point where we started building
in relevant code from vpp_api_test.
Eliminated all but one duplicate registration complaint. That one
needs attention from the vxlan team since the duplicated handlers have
diverged.
Change-Id: Iafce5429d2f906270643b4ea5f0130e20beb4d1d
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
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>
|
|
Change-Id: I3829835ed2126e51e96690c907deac623dc77151
Signed-off-by: Pavel Kotucek <pkotucek@cisco.com>
|