Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: fix
Using the adjacency to modify the interface's feature arc doesn't work, since there are potentially more than one adj per-interface.
Instead have the interface, when it is created, register what the end node of the feature arc is. This end node is then also used as the interface's tx node (i.e. it is used as the adjacency's next-node).
rename adj-midhcain-tx as 'tunnel-output', that's a bit more intuitive.
There's also a fix in config string handling to:
1- prevent false sharing of strings when the end node of the arc is different.
2- call registered listeners when the end node is changed
For IPSec the consequences are that one cannot provide per-adjacency behaviour using different end-nodes - this was previously done for the no-SA and an SA with no protection. These cases are no handled in the esp-encrypt node.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: If3a83d03a3000f28820d9a9cb4101d244803d084
|
|
Type: refactor
It's only the nodes that require compiling for each arch,
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Ibb2bfc756001735cc10ef0fd8db7e8b8358cf8e2
|
|
Type: feature
Support setting the MTU for a peer on an interface. The minimum value of
the path and interface MTU is used at forwarding time.
the path MTU is specified for a given peer, by address and table-ID.
In the forwarding plane the MTU is enfored either:
1 - if the peer is attached, then the MTU is set on the peer's
adjacency
2 - if the peer is not attached, it is remote, then a DPO is added to
the peer's FIB entry to perform the necessary fragmentation.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I8b9ea6a07868b50e97e2561f18d9335407dea7ae
|
|
Type: fix
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: Id7b27edf3712aaa3c277e752b9ca78bb91d184a1
|
|
Type: feature
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Change-Id: I964afd9266645de5c87d49c58ce6b48c2c18f97f
|
|
Type: refactor
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Change-Id: Id1801519638a9b97175847d7ed58824fb83433d6
|
|
Type: fix
Signed-off-by: Dave Barach <dave@barachs.net>
Change-Id: Ibad744788e200ce012ad88ff59c2c34920742454
|
|
Type: fix
it is possible for a user to change the end node of a feature arc, but
this change should only apply to that 'instnace' of the arc, not all
arcs. for example, if a tunnel has its ipx-output end node changed to
adj-midchain-tx, this shouldn't affect all ipx-output arcs. obviously...
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I41daea7ba6907963e42140307d065c8bcfdcb585
|
|
Type: improvement
- inline some common encap fixup functions into the midchain
rewrite node so we don't incur the cost of the virtual function call
- change the copy 'guess' from ethernet_header (which will never happen) to an ip4 header
- add adj-midchain-tx to multiarch sources
- don't run adj-midchain-tx as a feature, instead put this node as the
adj's next and at the end of the feature arc.
- cache the feature arc config index (to save the cache miss going to fetch it)
- don't check if features are enabled when taking the arc (since we know they are)
the last two changes will also benefit normal adjacencies taking the arc (i.e. for NAT, ACLs, etc)
for IPSec:
- don't run esp_encrypt as a feature, instead when required insert this
node into the adj's next and into the end of the feature arc. this
implies that encrypt is always 'the last feature' run, which is
symmetric with decrypt always being the first.
- esp_encrpyt for tunnels has adj-midchain-tx as next node
Change-Id: Ida0af56a704302cf2d7797ded5f118a781e8acb7
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Change-Id: I57f8bfbce4feed9d2775875cb8b1b729a47900a4
Signed-off-by: Neale Ranns <nranns@cisco.com>
(cherry picked from commit 24064d02aa9810ebc64c16dc778a179bb0ef5483)
|
|
Type: fix
coverity found invalid logic.
Change-Id: Ic9144ac805a4e5a18aa299794fedda044dcb65fe
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: feature
plus fixes for gre
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I0eca5f94b8b8ea0fcfb058162cafea4491708db6
|
|
Type: feature
Change-Id: I1632ff23b1bf6d91aa3406c95ebd6ef0aa595f35
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I6527e3fd8bbbca2d5f728621fc66b3856b39d505
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I53ab8d17914e6563110354e4052109ac02bf8f3b
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.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: I9ce801e9b257eaa6be0cbe2ad3bfe630717f8c67
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
and update glean address on local interface MAC change
Change-Id: I530826d60c7e9db2b0fa2d45754139d82c5ea807
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|
|
This reverts commit 8b30e471df4d42214619e1d6c50cc8298426b45f.
Change-Id: I99edb236eb0a7f8ba3fba333c3481a710ebcb59c
Signed-off-by: Ole Troan <ot@cisco.com>
|
|
update the glean adj on a local interface MAC change
Change-Id: Ia5c5cde424ed0fea3431532cc5abf22b364bbab5
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
returned in the fixup function
Change-Id: I458e6e03b03e27775df33a2fd302743126d6ac44
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I4164c4c19c8dbfd73e6ddf94a12056325cc093b9
Signed-off-by: Neale Ranns <nranns@cisco.com>
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
1) introduce an interface-tx DPO. This is a simple wrapper around a sw_if_index. enhance DPO stacking functions to allow per-instance next-nodes and hence allow children to stack onto the interface per-instance tx node and not on 'interface-output'.
2) update PPPoE code to use ta midchain stack on a interface-tx DPO of the encap-interface. This remove the need for pppoe_encap node (which is replaced by the adj-midchain-tx) and interface-output node is no longer used (see above). Since PPPoE encap node is no longer needed, the PPPoE seesion does not need to be retrieved in the data-path, hence the cahce misses are removed.
Change-Id: Id8b40f53daa14889a9c51d802e14fed7fba4399a
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
1 - interface-DPO
Used in the Data-plane to change a packet's input interface
2 - MPLS multicast FIB entry
Same as a unicast entry but it links to a replicate not a load-balance DPO
3 - Multicast MPLS tunnel
Update MPLS tunnels to use a FIB path-list to describe the endpoint[s]. Use the path-list to generate the forwarding chain (DPOs) to link to .
4 - Resolve a path via a local label (of an mLDP LSP)
For IP multicast entries to use an LSP in the replication list, we need to decribe the 'resolve-via-label' where the label is that of a multicast LSP.
5 - MPLS disposition path sets RPF-ID
For a interface-less LSP (i.e. mLDP not RSVP-TE) at the tail of the LSP we still need to perform an RPF check. An MPLS disposition DPO performs the MPLS pop validation checks and sets the RPF-ID in the packet.
6 - RPF check with per-entry RPF-ID
An RPF-ID is used instead of a real interface SW if index in the case the IP traffic arrives from an LSP that does not have an associated interface.
Change-Id: Ib92e177be919147bafeb599729abf3d1abc2f4b3
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
This patch deprecates stack-based thread identification,
Also removes requirement that thread stacks are adjacent.
Finally, possibly annoying for some folks, it renames
all occurences of cpu_index and cpu_number with thread
index. Using word "cpu" is misleading here as thread can
be migrated ti different CPU, and also it is not related
to linux cpu index.
Change-Id: I68cdaf661e701d2336fc953dcb9978d10a70f7c1
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I03195a86c69f84a301051c6b3ab64456bbf28645
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
node_index memeber from the rewrite for space - this is only used for formtting
before:
ip4-rewrite * * * * 2.66e1 256.00
after:
ip4-rewrite * * * * 2.40e1 256.00
Change-Id: Ic397150727cad38811564777419ad6bd26b8a3a6
Signed-off-by: Neale Ranns <nranns@wasa-ucs-11.cisco.com>
|
|
Also adds missing gpe nsh address type functions.
Change-Id: I3353a23c0518da9ce3b221ddf8c5bd0364930154
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I97fedb0f70dd18ed9bbe985407cc5fe714e8a2e2
Signed-off-by: Florin Coras <fcoras@cisco.com>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|