diff options
Diffstat (limited to 'src/vnet/srv6')
| -rw-r--r-- | src/vnet/srv6/sr_doc.md | 63 | ||||
| -rw-r--r-- | src/vnet/srv6/sr_doc.rst | 123 | ||||
| -rw-r--r-- | src/vnet/srv6/sr_localsid.md | 58 | ||||
| -rw-r--r-- | src/vnet/srv6/sr_localsid.rst | 90 | ||||
| -rw-r--r-- | src/vnet/srv6/sr_policy.md | 60 | ||||
| -rw-r--r-- | src/vnet/srv6/sr_policy.rst | 96 | ||||
| -rw-r--r-- | src/vnet/srv6/sr_steering.md | 35 | ||||
| -rw-r--r-- | src/vnet/srv6/sr_steering.rst | 50 |
8 files changed, 359 insertions, 216 deletions
diff --git a/src/vnet/srv6/sr_doc.md b/src/vnet/srv6/sr_doc.md deleted file mode 100644 index c80a0fc18f7..00000000000 --- a/src/vnet/srv6/sr_doc.md +++ /dev/null @@ -1,63 +0,0 @@ -# SRv6: Segment Routing for IPv6 {#srv6_doc} - -This is a memo intended to contain documentation of the VPP SRv6 implementation. -Everything that is not directly obvious should come here. -For any feedback on content that should be explained please mailto:pcamaril@cisco.com - -## Segment Routing - -Segment routing is a network technology focused on addressing the limitations of existing IP and Multiprotocol Label Switching (MPLS) networks in terms of simplicity, scale, and ease of operation. It is a foundation for application engineered routing as it prepares the networks for new business models where applications can control the network behavior. - -Segment routing seeks the right balance between distributed intelligence and centralized optimization and programming. It was built for the software-defined networking (SDN) era. - -Segment routing enhances packet forwarding behavior by enabling a network to transport unicast packets through a specific forwarding path, different from the normal path that a packet usually takes (IGP shortest path or BGP best path). This capability benefits many use cases, and one can build those specific paths based on application requirements. - -Segment routing uses the source routing paradigm. A node, usually a router but also a switch, a trusted server, or a virtual forwarder running on a hypervisor, steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to a segment-routing node or global within a segment-routing network. Segment routing allows an operator to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the segment-routing network. Segment routing also supports equal-cost multipath (ECMP) by design. - -Segment routing can operate with either an MPLS or an IPv6 data plane. All the currently available MPLS services, such as Layer 3 VPN (L3VPN), L2VPN (Virtual Private Wire Service [VPWS], Virtual Private LAN Services [VPLS], Ethernet VPN [E-VPN], and Provider Backbone Bridging Ethernet VPN [PBB-EVPN]), can run on top of a segment-routing transport network. - -**The implementation of Segment Routing in VPP covers both the IPv6 data plane (SRv6) as well as the MPLS data plane (SR-MPLS). This page contains the SRv6 documentation.** - -## Segment Routing terminology - -* Segment Routing Header (SRH): IPv6 routing extension header of type 'Segment Routing'. (draft-ietf-6man-segment-routing-header-05) -* SegmentID (SID): is an IPv6 address. -* Segment List (SL) (SID List): is the sequence of SIDs that the packet will traverse. -* SR Policy: defines the SRH that will be applied to a packet. A packet steered into an SR policy may either receive the SRH by IPv6 header encapsulation (as recommended in draft-ietf-6man-rfc2460bis) or it could be inserted within an existing IPv6 header. An SR policy is uniquely identified by its Binding SID and associated with a weighted set of Segment Lists. In case several SID lists are defined, traffic steered into the policy is unevenly load-balanced among them according to their respective weights. -* Local SID: is a SID associated with a processing function on the local node, which may go from advancing to the next SID in the SRH, to complex user-defined behaviors. When a FIB lookup, either in the main FIB or in a specific VRF, returns a match on a local SID, the associated function is performed. -* BindingSID: a BindingSID is a SID (only one) associated one-one with an SR Policy. If a packet arrives with an IPv6 DA corresponding to a BindingSID, then the SR policy will be applied to such packet. - -## SRv6 Features in VPP - -The <a href="https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/">SRv6 Network Programming (*draft-filsfils-spring-srv6-network-programming*)</a> defines the SRv6 architecture. - -VPP supports the following SRv6 LocalSID functions: End, End.X, End.DX6, End.DT6, End.DX4, End.DT4, End.DX2, End.B6, End.B6.Encaps. - -For further information and how to configure each specific function: @subpage srv6_localsid_doc - - -The <a href="https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-policy/">Segment Routing Policy (*draft-filsfils-spring-segment-routing-policy*)</a> defines SR Policies. - -VPP supports SRv6 Policies with T.Insert and T.Encaps behaviors. - -For further information on how to create SR Policies: @subpage srv6_policy_doc - -For further information on how to steer traffic into SR Policies: @subpage srv6_steering_doc - -## SRv6 LocalSID development framework - -One of the *'key'* concepts about SRv6 is network programmability. This is why an SRv6 LocalSID is associated with an specific function. - -However, the trully way to enable network programmability is allowing any developer **easily** create his own SRv6 LocalSID function. That is the reason why we have added some API calls such that any developer can code his own SRv6 LocalSID behaviors as plugins an add them to the running SRv6 code. - -The principle is that the developer only codes the behavior -the graph node-. However all the FIB handling, SR LocalSID instantiation and so on are done by the VPP SRv6 code. - -For more information please refer to: @subpage srv6_plugin_doc - -Available SRv6 plugins include: - -- @subpage srv6_as_plugin_doc -- @subpage srv6_ad_plugin_doc -- @subpage srv6_am_plugin_doc -- @subpage srv6_mobile_plugin_doc - diff --git a/src/vnet/srv6/sr_doc.rst b/src/vnet/srv6/sr_doc.rst new file mode 100644 index 00000000000..24501832b85 --- /dev/null +++ b/src/vnet/srv6/sr_doc.rst @@ -0,0 +1,123 @@ +.. _srv6_doc: + +SRv6: Segment Routing for IPv6 +============================== + +This is a memo intended to contain documentation of the VPP SRv6 +implementation. Everything that is not directly obvious should come +here. For any feedback on content that should be explained please +mailto:pcamaril@cisco.com + +Segment Routing +--------------- + +Segment routing is a network technology focused on addressing the +limitations of existing IP and Multiprotocol Label Switching (MPLS) +networks in terms of simplicity, scale, and ease of operation. It is a +foundation for application engineered routing as it prepares the +networks for new business models where applications can control the +network behavior. + +Segment routing seeks the right balance between distributed intelligence +and centralized optimization and programming. It was built for the +software-defined networking (SDN) era. + +Segment routing enhances packet forwarding behavior by enabling a +network to transport unicast packets through a specific forwarding path, +different from the normal path that a packet usually takes (IGP shortest +path or BGP best path). This capability benefits many use cases, and one +can build those specific paths based on application requirements. + +Segment routing uses the source routing paradigm. A node, usually a +router but also a switch, a trusted server, or a virtual forwarder +running on a hypervisor, steers a packet through an ordered list of +instructions, called segments. A segment can represent any instruction, +topological or service-based. A segment can have a local semantic to a +segment-routing node or global within a segment-routing network. Segment +routing allows an operator to enforce a flow through any topological +path and service chain while maintaining per-flow state only at the +ingress node to the segment-routing network. Segment routing also +supports equal-cost multipath (ECMP) by design. + +Segment routing can operate with either an MPLS or an IPv6 data plane. +All the currently available MPLS services, such as Layer 3 VPN (L3VPN), +L2VPN (Virtual Private Wire Service [VPWS], Virtual Private LAN Services +[VPLS], Ethernet VPN [E-VPN], and Provider Backbone Bridging Ethernet +VPN [PBB-EVPN]), can run on top of a segment-routing transport network. + +**The implementation of Segment Routing in VPP covers both the IPv6 data +plane (SRv6) as well as the MPLS data plane (SR-MPLS). This page +contains the SRv6 documentation.** + +Segment Routing terminology +--------------------------- + +- Segment Routing Header (SRH): IPv6 routing extension header of type + ‘Segment Routing’. (draft-ietf-6man-segment-routing-header-05) +- SegmentID (SID): is an IPv6 address. +- Segment List (SL) (SID List): is the sequence of SIDs that the packet + will traverse. +- SR Policy: defines the SRH that will be applied to a packet. A packet + steered into an SR policy may either receive the SRH by IPv6 header + encapsulation (as recommended in draft-ietf-6man-rfc2460bis) or it + could be inserted within an existing IPv6 header. An SR policy is + uniquely identified by its Binding SID and associated with a weighted + set of Segment Lists. In case several SID lists are defined, traffic + steered into the policy is unevenly load-balanced among them + according to their respective weights. +- Local SID: is a SID associated with a processing function on the + local node, which may go from advancing to the next SID in the SRH, + to complex user-defined behaviors. When a FIB lookup, either in the + main FIB or in a specific VRF, returns a match on a local SID, the + associated function is performed. +- BindingSID: a BindingSID is a SID (only one) associated one-one with + an SR Policy. If a packet arrives with an IPv6 DA corresponding to a + BindingSID, then the SR policy will be applied to such packet. + +SRv6 Features in VPP +-------------------- + +The SRv6 Network Programming +(*draft-filsfils-spring-srv6-network-programming*) defines the SRv6 +architecture. + +VPP supports the following SRv6 LocalSID functions: End, End.X, End.DX6, +End.DT6, End.DX4, End.DT4, End.DX2, End.B6, End.B6.Encaps. + +For further information and how to configure each specific function: +:ref:`srv6_localsid_doc` + +The Segment Routing Policy +(*draft-filsfils-spring-segment-routing-policy*) defines SR Policies. + +VPP supports SRv6 Policies with T.Insert and T.Encaps behaviors. + +For further information on how to create SR Policies: :ref:`srv6_policy_doc` + +For further information on how to steer traffic into SR Policies: +:ref:`srv6_steering_doc` + +SRv6 LocalSID development framework +----------------------------------- + +One of the *‘key’* concepts about SRv6 is network programmability. This +is why an SRv6 LocalSID is associated with an specific function. + +However, the true way to enable network programmability is allowing +any developer **easily** create his own SRv6 LocalSID function. That is +the reason why we have added some API calls such that any developer can +code his own SRv6 LocalSID behaviors as plugins an add them to the +running SRv6 code. + +The principle is that the developer only codes the behavior -the graph +node-. However all the FIB handling, SR LocalSID instantiation and so on +are done by the VPP SRv6 code. + +For more information please refer to: :ref:`srv6_plugin_doc` + +Available SRv6 plugins include: + +- :ref:`srv6_as_plugin_doc` +- :ref:`srv6_ad_plugin_doc` +- :ref:`srv6_am_plugin_doc` +- :ref:`srv6_mobile_plugin_doc` diff --git a/src/vnet/srv6/sr_localsid.md b/src/vnet/srv6/sr_localsid.md deleted file mode 100644 index fbc7ef827e6..00000000000 --- a/src/vnet/srv6/sr_localsid.md +++ /dev/null @@ -1,58 +0,0 @@ -# SR LocalSIDs {#srv6_localsid_doc} - -A local SID is associated to a Segment Routing behavior -or function- on the current node. - -The most basic behavior is called END. It simply activates the next SID in the current packet, by decrementing the Segments Left value and updating the IPv6 DA. - -A local END SID is instantiated using the following CLI: - - sr localsid (del) address XX::YY behavior end - -This creates a new entry in the main FIB for IPv6 address XX::YY. All packets whose IPv6 DA matches this FIB entry are redirected to the sr-localsid node, where they are processed as described above. - -Other examples of local SIDs are the following: - - sr localsid (del) address XX::YY behavior end - sr localsid (del) address XX::YY behavior end.x GE0/1/0 2001::a - sr localsid (del) address XX::YY behavior end.dx6 GE0/1/0 2001::a - sr localsid (del) address XX::YY behavior end.dx4 GE0/1/0 10.0.0.1 - sr localsid (del) address XX::YY behavior end.dx2 GigabitE0/11/0 - sr localsid (del) address XX::YY behavior end.dt6 5 - sr localsid (del) address XX::YY behavior end.dt6 5 - -Note that all of these behaviors match the definitions of the SRv6 architecture (*draft-filsfils-spring-srv6-network-programming*). Please refer to this document for a detailed description of each behavior. - -Note also that you can configure the PSP flavor of the End and End.X behaviors by typing: - - sr localsid (del) address XX::YY behavior end psp - sr localsid (del) address XX::YY behavior end.x GE0/1/0 2001::a psp - -Help on the available local SID behaviors and their usage can be obtained with: - - help sr localsid - -Alternatively they can be obtained using. - - show sr localsids behavior - -The difference in between those two commands is that the first one will only display the SR LocalSID behaviors that are built-in VPP, while the latter will display those behaviors plus the ones added with the SR LocalSID Development Framework. - - -VPP keeps a 'My LocalSID Table' where it stores all the SR local SIDs instantiated as well as their parameters. Every time a new local SID is instantiated, a new entry is added to this table. In addition, counters for correctly and incorrectly processed traffic are maintained for each local SID. The counters store both the number of packets and bytes. - -The contents of the 'My LocalSID Table' is shown with: - - vpp# show sr localsid - SRv6 - My LocalSID Table: - ========================= - Address: c3::1 - Behavior: DX6 (Endpoint with decapsulation and IPv6 cross-connect) - Iface: GigabitEthernet0/5/0 - Next hop: b:c3::b - Good traffic: [51277 packets : 5332808 bytes] - Bad traffic: [0 packets : 0 bytes] - -------------------- - -The traffic counters can be reset with: - - vpp# clear sr localsid-counters diff --git a/src/vnet/srv6/sr_localsid.rst b/src/vnet/srv6/sr_localsid.rst new file mode 100644 index 00000000000..cf042a847b4 --- /dev/null +++ b/src/vnet/srv6/sr_localsid.rst @@ -0,0 +1,90 @@ +.. _srv6_localsid_doc: + +SR LocalSIDs +============ + +A local SID is associated to a Segment Routing behavior -or function- on +the current node. + +The most basic behavior is called END. It simply activates the next SID +in the current packet, by decrementing the Segments Left value and +updating the IPv6 DA. + +A local END SID is instantiated using the following CLI: + +:: + + sr localsid (del) address XX::YY behavior end + +This creates a new entry in the main FIB for IPv6 address XX::YY. All +packets whose IPv6 DA matches this FIB entry are redirected to the +sr-localsid node, where they are processed as described above. + +Other examples of local SIDs are the following: + +:: + + sr localsid (del) address XX::YY behavior end + sr localsid (del) address XX::YY behavior end.x GE0/1/0 2001::a + sr localsid (del) address XX::YY behavior end.dx6 GE0/1/0 2001::a + sr localsid (del) address XX::YY behavior end.dx4 GE0/1/0 10.0.0.1 + sr localsid (del) address XX::YY behavior end.dx2 GigabitE0/11/0 + sr localsid (del) address XX::YY behavior end.dt6 5 + sr localsid (del) address XX::YY behavior end.dt6 5 + +Note that all of these behaviors match the definitions of the SRv6 +architecture (*draft-filsfils-spring-srv6-network-programming*). Please +refer to this document for a detailed description of each behavior. + +Note also that you can configure the PSP flavor of the End and End.X +behaviors by typing: + +:: + + sr localsid (del) address XX::YY behavior end psp + sr localsid (del) address XX::YY behavior end.x GE0/1/0 2001::a psp + +Help on the available local SID behaviors and their usage can be +obtained with: + +:: + + help sr localsid + +Alternatively they can be obtained using. + +:: + + show sr localsids behavior + +The difference in between those two commands is that the first one will +only display the SR LocalSID behaviors that are built-in VPP, while the +latter will display those behaviors plus the ones added with the SR +LocalSID Development Framework. + +VPP keeps a ‘My LocalSID Table’ where it stores all the SR local SIDs +instantiated as well as their parameters. Every time a new local SID is +instantiated, a new entry is added to this table. In addition, counters +for correctly and incorrectly processed traffic are maintained for each +local SID. The counters store both the number of packets and bytes. + +The contents of the ‘My LocalSID Table’ is shown with: + +:: + + vpp# show sr localsid + SRv6 - My LocalSID Table: + ========================= + Address: c3::1 + Behavior: DX6 (Endpoint with decapsulation and IPv6 cross-connect) + Iface: GigabitEthernet0/5/0 + Next hop: b:c3::b + Good traffic: [51277 packets : 5332808 bytes] + Bad traffic: [0 packets : 0 bytes] + -------------------- + +The traffic counters can be reset with: + +:: + + vpp# clear sr localsid-counters diff --git a/src/vnet/srv6/sr_policy.md b/src/vnet/srv6/sr_policy.md deleted file mode 100644 index 2a7eb4c9870..00000000000 --- a/src/vnet/srv6/sr_policy.md +++ /dev/null @@ -1,60 +0,0 @@ -# Creating a SR Policy {#srv6_policy_doc} - -An SR Policy is defined by a Binding SID and a weighted set of Segment Lists. - -A new SR policy is created with a first SID list using: - - sr policy add bsid 2001::1 next A1:: next B1:: next C1:: (weight 5) (fib-table 3) - -* The weight parameter is only used if more than one SID list is associated with the policy. -* The fib-table parameter specifies in which table (VRF) the Binding SID is to be installed. - -An SR policy is deleted with: - - sr policy del bsid 2001::1 - sr policy del index 1 - -The existing SR policies are listed with: - - show sr policies - -## Adding/Removing SID Lists from an SR policy - -An additional SID list is associated with an existing SR policy with: - - sr policy mod bsid 2001::1 add sl next A2:: next B2:: next C2:: (weight 3) - sr policy mod index 3 add sl next A2:: next B2:: next C2:: (weight 3) - -Conversely, a SID list can be removed from an SR policy with: - - sr policy mod bsid 2001::1 del sl index 1 - sr policy mod index 3 del sl index 1 - -Note that this cannot be used to remove the last SID list of a policy. - -The weight of a SID list can also be modified with: - - sr policy mod bsid 2001::1 mod sl index 1 weight 4 - sr policy mod index 3 mod sl index 1 weight 4 - -## SR Policies: Spray policies - -Spray policies are a specific type of SR policies where the packet is replicated on all the SID lists, rather than load-balanced among them. - -SID list weights are ignored with this type of policies. - -A Spray policy is instantiated by appending the keyword **spray** to a regular SR policy command, as in: - - sr policy add bsid 2001::1 next A1:: next B1:: next C1:: spray - -Spray policies are used for removing multicast state from a network core domain, and instead send a linear unicast copy to every access node. The last SID in each list accesses the multicast tree within the access node. - -## Encapsulation SR policies - -In case the user decides to create an SR policy an IPv6 Source Address must be specified for the encapsulated traffic. In order to do so the user might use the following command: - - set sr encaps source addr XXXX::YYYY - -Default hop-limit for the encapsulating IPv6 header is 64. It is possible to specify custom hop-limit value from 1 to 255 using this command: - - set sr encaps hop-limit N diff --git a/src/vnet/srv6/sr_policy.rst b/src/vnet/srv6/sr_policy.rst new file mode 100644 index 00000000000..50cc19bfb14 --- /dev/null +++ b/src/vnet/srv6/sr_policy.rst @@ -0,0 +1,96 @@ +.. _srv6_policy_doc: + +Creating a SR Policy +==================== + +An SR Policy is defined by a Binding SID and a weighted set of Segment +Lists. + +A new SR policy is created with a first SID list using: + +:: + + sr policy add bsid 2001::1 next A1:: next B1:: next C1:: (weight 5) (fib-table 3) + +- The weight parameter is only used if more than one SID list is + associated with the policy. +- The fib-table parameter specifies in which table (VRF) the Binding + SID is to be installed. + +An SR policy is deleted with: + +:: + + sr policy del bsid 2001::1 + sr policy del index 1 + +The existing SR policies are listed with: + +:: + + show sr policies + +Adding/Removing SID Lists from an SR policy +------------------------------------------- + +An additional SID list is associated with an existing SR policy with: + +:: + + sr policy mod bsid 2001::1 add sl next A2:: next B2:: next C2:: (weight 3) + sr policy mod index 3 add sl next A2:: next B2:: next C2:: (weight 3) + +Conversely, a SID list can be removed from an SR policy with: + +:: + + sr policy mod bsid 2001::1 del sl index 1 + sr policy mod index 3 del sl index 1 + +Note that this cannot be used to remove the last SID list of a policy. + +The weight of a SID list can also be modified with: + +:: + + sr policy mod bsid 2001::1 mod sl index 1 weight 4 + sr policy mod index 3 mod sl index 1 weight 4 + +SR Policies: Spray policies +--------------------------- + +Spray policies are a specific type of SR policies where the packet is +replicated on all the SID lists, rather than load-balanced among them. + +SID list weights are ignored with this type of policies. + +A Spray policy is instantiated by appending the keyword **spray** to a +regular SR policy command, as in: + +:: + + sr policy add bsid 2001::1 next A1:: next B1:: next C1:: spray + +Spray policies are used for removing multicast state from a network core +domain, and instead send a linear unicast copy to every access node. The +last SID in each list accesses the multicast tree within the access +node. + +Encapsulation SR policies +------------------------- + +In case the user decides to create an SR policy an IPv6 Source Address +must be specified for the encapsulated traffic. In order to do so the +user might use the following command: + +:: + + set sr encaps source addr XXXX::YYYY + +Default hop-limit for the encapsulating IPv6 header is 64. It is +possible to specify custom hop-limit value from 1 to 255 using this +command: + +:: + + set sr encaps hop-limit N diff --git a/src/vnet/srv6/sr_steering.md b/src/vnet/srv6/sr_steering.md deleted file mode 100644 index ca5cc7b6c7a..00000000000 --- a/src/vnet/srv6/sr_steering.md +++ /dev/null @@ -1,35 +0,0 @@ -# Steering packets into a SR Policy {#srv6_steering_doc} - -## steer packets uging the sr steering policy - -To steer packets in Transit into an SR policy (T.Insert, T.Encaps and T.Encaps.L2 behaviors), the user needs to create an 'sr steering policy'. - - sr steer l3 2001::/64 via index 1 - sr steer l3 2001::/64 via bsid cafe::1 - sr steer l3 2001::/64 via bsid cafe::1 fib-table 3 - sr steer l3 10.0.0.0/16 via bsid cafe::1 - sr steer l2 TenGE0/1/0 via bsid cafe::1 - -Disclaimer: The T.Encaps.L2 will steer L2 frames into an SR Policy. Notice that creating an SR steering policy for L2 frames will actually automatically *put the interface into promiscous mode*. - -## steer packets using the classifier - -Another way to steer packet is to use the classifier. - -First the user need to manually add the source routing node to the list of the -ip6-inacl next nodes. -Using the python api this can be donne with: - - # jsonfiles = get list of json api files - vpp = VPP(jsonfiles) - vpp.add_node_next(node_name='ip6-inacl', next_name='sr-pl-rewrite-insert') - -Below is a classifier mask filtering all the packets from the interface -TenGigabitEthernet5/0/0 on ip version and moving all ipv6 packets to the -sr-pl-rewrite-insert node (dropping the others) and applying the source routing -index 2. -In essence, this means "apply this sr policy to all the packets from this interface) - - vpp# classify table miss-next 0 current-data-flag 1 mask hex f000000000000000 skip 0 - vpp# classify session acl-hit-next 1 table-index 0 match hex 6000000000000000 action set-sr-policy-index 2 - vpp# set interface input acl intfc TenGigabitEthernet5/0/0 ip6-table 0 diff --git a/src/vnet/srv6/sr_steering.rst b/src/vnet/srv6/sr_steering.rst new file mode 100644 index 00000000000..b8a82e57550 --- /dev/null +++ b/src/vnet/srv6/sr_steering.rst @@ -0,0 +1,50 @@ +.. _srv6_steering_doc: + +Steering packets into a SR Policy +================================= + +steer packets using the sr steering policy +------------------------------------------ + +To steer packets in Transit into an SR policy (T.Insert, T.Encaps and +T.Encaps.L2 behaviors), the user needs to create an ‘sr steering +policy’. + +:: + + sr steer l3 2001::/64 via index 1 + sr steer l3 2001::/64 via bsid cafe::1 + sr steer l3 2001::/64 via bsid cafe::1 fib-table 3 + sr steer l3 10.0.0.0/16 via bsid cafe::1 + sr steer l2 TenGE0/1/0 via bsid cafe::1 + +Disclaimer: The T.Encaps.L2 will steer L2 frames into an SR Policy. +Notice that creating an SR steering policy for L2 frames will actually +automatically *put the interface into promiscous mode*. + +steer packets using the classifier +---------------------------------- + +Another way to steer packet is to use the classifier. + +First the user need to manually add the source routing node to the list +of the ip6-inacl next nodes. Using the python api this can be done +with: + +:: + + # jsonfiles = get list of json api files + vpp = VPP(jsonfiles) + vpp.add_node_next(node_name='ip6-inacl', next_name='sr-pl-rewrite-insert') + +Below is a classifier mask filtering all the packets from the interface +TenGigabitEthernet5/0/0 on ip version and moving all ipv6 packets to the +sr-pl-rewrite-insert node (dropping the others) and applying the source +routing index 2. In essence, this means “apply this sr policy to all the +packets from this interface) + +:: + + vpp# classify table miss-next 0 current-data-flag 1 mask hex f000000000000000 skip 0 + vpp# classify session acl-hit-next 1 table-index 0 match hex 6000000000000000 action set-sr-policy-index 2 + vpp# set interface input acl intfc TenGigabitEthernet5/0/0 ip6-table 0 |