Dear Neale,
Thanks for taking time and answer in details.
Answer comments inline.
On Thu, Jul 25, 2019 at 12:38 PM Neale Ranns (nranns) <nra...@cisco.com>
wrote:
>
>
> Hi Brayan,
>
>
>
> First let’s discuss a bit your config and your objectives:
>
>
>
> acl ID 0 permit { any }
>
> set int ip addr GigabitEthernetb/0/0 30.30.30.1/24
>
> set int ip addr GigabitEthernet3/0/0 20.20.20.1/24
>
>
>
> abf policy add id 9001 acl 0 via 0.0.0.0 GigabitEthernetb/0/0
>
> abf attach ip4 policy 9001 priority 1 GigabitEthernet3/0/0
>
>
>
> I’m sure you know that you can achieve the same by replacing the ABF route
> with a default route, so no doubt this is a test for you and you intend to
> make the ACL more expressive.
>
Exactly. as well as that you said, my approach is check of abf flexibility
and its integrity and compatibility with some other features, especially
static routing and nat.
> So let’s consider some more scenarios. First we’ll correct policy rule to
> include the nexthop, since any packets not going to 30.30.30.0/24 need to
> be sent to a next-hop on the LAN (we’ll discount proxy ARP as a solution
> because it does scale to add an ARP entry for every host on the internet).
>
>
>
> Acl ID 0 permit (tcp port 80 }
>
> abf policy add id 9001 acl 0 via 30.30.30.2 GigabitEthernetb/0/0
>
>
>
> so if a packet now arrives for 30.30.30.3 to TCP port 80, where wold you
> like it to go? Do you want it to follow a routing decision and go to
> 30.30.30.3, or follow the abf decision to 30.30.30.2?
>
I would like to follow a routing decision for 30.30.30.0/24.
>
>
> now let’s add another connected subnet.
>
>
>
> set int ip addr GigabitEthernet9/0/0 40.40.40.1/24
>
>
>
> packets destined to this subnet will also match the ABF rule. Again
> consider a packet to 40.40.40.2 do you want these packets to follow a
> routing decision and be forwarded to 40.40.40.2 on GigabitEthernet9/0/0 or
> to 30.30.30.2 on GigabitEthernetb/0/0?
>
same as former, it is needed to follow a routing decision.
>
>
> In general, when does a routing decision override the ABF result?
>
> In VPP’s ABF implementation the answer is never. The ABF feature runs
> first and it is the only decision that is made. If you want to change this
> behaviour you can ‘insert’ a routing decision by using it as the result of
> ABF. For example:
>
>
>
> # create a table in which the post ABF routing decision will be made
>
> ip table add 42
>
> # add routes for prefixes that we want to override the ABF decision
>
> # these routes will then perform a lookup in default table
>
> ip route add table 42 30.30.30.0/24 via ip4-lookup-in-table 0
>
> ip route add table 42 40.40.40.0/24 via ip4-lookup-in-table 0
>
> # all the rest of the packets do the same as the ABF policy
>
> ip route add table 42 0.0.0.0/24 via 30.30.30.2 GigabitEthernetb/0/0
>
>
>
> # the ABF policy result in a lookup in our override table
>
> abf policy add id 9001 acl 0 via ip4-lookup-in-table 42
>
>
>
Ok.Good job!. It seems resolve all of the Proposed Scenarios here. Thanks
for your example and sample configuration. I will check the abf plugin more
and share with you if I find other anomaly or ambiguity. Thanks in advance.
Best Regards,
>
>
> hope this helps,
>
> neale
>
>
>
>
>
>
>
> *De : *brayan ortega <brayan.ortega6...@gmail.com>
> *Date : *mercredi 24 juillet 2019 à 16:13
> *À : *"Neale Ranns (nranns)" <nra...@cisco.com>
> *Cc : *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> *Objet : *Re: [vpp-dev] abf problem with arp
>
>
>
> Dear Neale,
>
> Thanks for your prompt response.
> Answer comments inline.
>
>
>
> On Wed, Jul 24, 2019 at 5:16 PM Neale Ranns (nranns) <nra...@cisco.com>
> wrote:
>
>
>
> Dear Brayan,
>
>
>
> You should always add a next-hop to a path when IP routing.
>
> Answers comments inline.
>
>
>
> /neale
>
>
>
> *De : *<vpp-dev@lists.fd.io> au nom de brayan ortega <
> brayan.ortega6...@gmail.com>
> *Date : *mercredi 24 juillet 2019 à 11:25
> *À : *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> *Objet : *[vpp-dev] abf problem with arp
>
>
>
> Dear VPP Folks,
>
> I'm using vpp v19.08-rc0~698-g1f50bf8fc (master branch) and It seems there
> is a bug when the abf plugin is enabled and configured in my scenario.
>
> abf policy is defined as follows:
> 1- permit packets
> 2- route to output interface without gateway definition ( via 0.0.0.0 )
> 3- attaching it to input interfaces
> When the abf policy is defined as described, the connected networks to
> output interfaces will be unreachable. I checked the trace of packets and
> saw the following. First, an icmp packet is received on input interface.
> Then arp packet is sent and arp reply is received. But in next icmp packet
> again this scenario happens while we have an entry for destination ip in
> arp table. however, arp reply is dropped and "arp-disabled: ARP Disabled
> on this interface" log is seen in trace output. My vppctl trace output is
> available here: https://paste.ubuntu.com/p/pB2sh3GxrD/
>
> The following is the ping result from my client:
>
> Client 1: ping 30.30.30.2 ( 30.30.30.30 is my router ip address) isn't
> established.
>
>
>
> My topology and vpp configuration are attached to this email.
>
> If it is needed to set a gateway for abf,
>
>
>
> Yes.
>
>
>
> then we can not reach to connected network devices. So I had to set my
> abf gateway to 0.0.0.0 for connected networks when there is an abf policy
> for networks which are not connected directly.
>
>
>
> Are you saying that the ACL you are using in the ABF policy also matches
> connected devices and so the ABF policy is also used to forward to attached
> devices? This won’t work for ABF, since ABF runs before the normal IP
> lookup. So either don’t include connected subnets in the ACL definition, or
> add a higher priority policy for each of the connected devices with a
> nexthop of that connected device.
>
>
>
> Suppose we have a lot of connected devices, It is not reasonable to write
> a lot of higher priorities policies for them. On the other hands, for
> unconnected network, it is needed to write a general abf policy ( any ) and
> then exclude connected network devices. what's your opinion about bringing
> your idea in code level. Instead of writing a lot of abf policies for
> connected network devices with higher priority than general abf policy, we
> write abf policies for connected networks with next-hop 0.0.0.0 and then in
> abf plugin, check if the next-hop is 0.0.0.0 then change next-hop to packet
> destination ip!
> I would like to know your advice and opinion.
>
>
>
>
>
> The reason this:
>
> Ip route 2.0.0.0/8 via 0.0.0.0 Eth0
>
> Kinda (because a router connected to eth0 must have proxy ARP configured
> for 2/8) works for IP routing, Is that the first packet to say 2.0.0.1
> generates an ARP request and the proxying router replies. The ARP response
> creates an ARP entry for 2.0.0.1 and a FIB entry 2.0.0.01/32 via the
> proxying router. The next packet through does an LPM and hits the /32, so
> is forwarded successfully.
>
>
>
>
> There’s no such LPM for ABF, so all packets generate ARP requests.
>
>
>
> Do you think this is bug? It seems it is not a normal functionality. I
> checked this scenario ( write route policy without next-hop definition) on
> Cisco router and there aren't this problem ( my client1 icmp connection was
> established ).
>
> Warm Regards,
>
> Brayan
>
>
>
>
>
> Hth,
>
> /neale
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13595): https://lists.fd.io/g/vpp-dev/message/13595
Mute This Topic: https://lists.fd.io/mt/32582274/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
