Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: refactor
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I3aad20b35d89fc541fdf185096d71ca12b09a6e2
|
|
Instead of all clients directly RR sourcing the entry they are tracking,
use a deidcated 'tracker' object. This tracker object is a entry
delegate and a child of the entry. The clients are then children of the
tracker.
The benefit of this aproach is that each time a new client tracks the
entry it doesn't RR source it. When an entry is sourced all its children
are updated. Thus, new clients tracking an entry is O(n^2). With the
tracker as indirection, the entry is sourced only once.
Type: feature
Change-Id: I5b80bdda6c02057152e5f721e580e786cd840a3b
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
if a tunnel's destination address is reachable through the tunnel
(see example config belwo) then search for and detect a recursion
loop and don't stack the adjacency. Otherwise this results in a
nasty surprise.
DBGvpp# loop cre
DBGvpp# set int state loop0 up
DBGvpp# set int ip addr loop0 10.0.0.1/24
DBGvpp# create gre tunnel src 10.0.0.1 dst 1.1.1.1
DBGvpp# set int state gre0 up
DBGvpp# set int unnum gre0 use loop0
DBGvpp# ip route 1.1.1.1/32 via gre0
DBGvpp# sh ip fib 1.1.1.1
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] locks:[src:plugin-hi:2, src:default-route:1, ]
1.1.1.1/32 fib:0 index:11 locks:4 <<< this is entry #11
src:CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,
path-list:[14] locks:2 flags:shared,looped, uPRF-list:12 len:1 itfs:[2, ]
path:[14] pl-index:14 ip4 weight=1 pref=0 attached-nexthop: oper-flags:recursive-loop,resolved, cfg-flags:attached,
1.1.1.1 gre0 (p2p)
[@0]: ipv4 via 0.0.0.0 gre0: mtu:9000 4500000000000000fe2fb0cc0a0000010101010100000800
stacked-on entry:11: <<<< and the midchain forwards via entry #11
[@2]: dpo-drop ip4
src:recursive-resolution refs:1 src-flags:added, cover:-1
forwarding: unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0]]
[0] [@6]: ipv4 via 0.0.0.0 gre0: mtu:9000 4500000000000000fe2fb0cc0a0000010101010100000800
stacked-on entry:11:
[@2]: dpo-drop ip4
DBGvpp# sh adj 1
[@1] ipv4 via 0.0.0.0 gre0: mtu:9000 4500000000000000fe2fb0cc0a0000010101010100000800
stacked-on entry:11:
[@2]: dpo-drop ip4
flags:midchain-ip-stack midchain-looped <<<<< this is a loop
counts:[0:0]
locks:4
delegates:
children:
{path:14}
Change-Id: I39b82bd1ea439be4611c88b130d40289fa0c1b59
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ifaef196a24fa9b6924f2b9692318f69763cee5e1
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
Change-Id: I9ce801e9b257eaa6be0cbe2ad3bfe630717f8c67
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
This patch separates setting of hardware interfaec and software
interface MTU. Software MTU is L2 payload MTU (i.e. not including L2
header). Per-protocol MTU for IPv4, IPv6 and MPLS can also be set.
Currently only IP4, IP6 are enabled in adjacency / rewrite code.
Documentation in src/vnet/MTU.md
Change-Id: Iee2fd6f0bbc8210748dd8e073ab9fab87d323690
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
interface)"
This reverts commit 70083ee74c3141bbefb185525315f1b34497dcaa.
Reverting as this patch is causing following crash:
0: /home/damarion/cisco/vpp3/build-data/../src/vnet/devices/devices.h:131 (vnet_get_device_input_thread_index) assertion `queue_id < vec_len (hw->input_node_thread_index_by_queue)' fails
Aborted
Change-Id: Ie2a365032110b1f67be7a9d832885b9899813d39
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I98bd454a761a1032738a21edeb0fe847e801f901
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
Change-Id: I994649761fe2e66e12ae0e49a84fb1d0a966ddfb
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I78a4176f98c2b4630a57ac5ddb7faf58ba0c4ee1
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ia2b3350bf8e2c72eee3f33936ba16dd817c75c72
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
Change-Id: I166301c9e2388bae5f70ec0179d663a2703e27f5
Signed-off-by: Ole Troan <ot@cisco.com>
|