Re: [vpp-dev] Building router plugin - Mroute

2017-04-03 Thread Jeff Shaw 
On Mon, Apr 03, 2017 at 08:37:46PM +0800, 倪红军 wrote:
> Hi Neale,
> 
> 
> The intent of this classification is to direct OSPF packet to the node  
> tap-inject-neighbor, 
> Then the OSPF packet can be redirected to BIRD in Hosting system.

You shouldn't need to use the classifier. A multicast route (and
all OSPF traffic) is automatically added to the fib when
tap-inject is enabled on an interface.

https://gerrit.fd.io/r/gitweb?p=vppsb.git;a=blob;f=router/router/tap_inject.c;h=8d6f5afde990feb0831f0182d7f904a86d041fb3;hb=fbaa56c33664c57083e6e96c7086e8afd95077b9#l106

In tap_inject.c:tap_inject_enable() you will see we register the
the router plugin's neighbor node for ARP and ICMP6, then we
register the router plugin's tx node for all ICMP, OSPF, TCP, and
UDP for both ipv4 and ipv6, as well as adding a multicast route
so we can handle OSPF.

No special commands are required, you can enable it in the config
file. This is new since the wiki was last updated.

  tap-inject {
enable
  }

Or from the command line use "enable tap-inject".

You probably do not want to add routes directly through vpp as
they will not be mirrored in the host. You only want to add
routes through netlink (i.e. "ip route add blah blah blah").

Same goes for interface addresses, "ip addr add ...", and link
state "ip link set up dev vpp5".

-Jeff

> 
> 
> Thanks a lot,
> Hongjun
> 
> 
> 
> At 2017-04-01 17:42:28, "Neale Ranns (nranns)"  wrote:
> 
> 
>  
> 
> Hi Hongjun,
> 
>  
> 
> The new Multicast FIB in 17.04 removed the classify option for multicast 
> routes. May I ask the intent of the classification you want to achieve? Maybe 
> there is a way to get that behaviour with the new mechanisms.
> 
>  
> 
> Thanks,
> 
> neale
> 
>  
> 
> From:  on behalf of "Ni, Hongjun" 
> 
> Date: Saturday, 1 April 2017 at 07:11
> To: "Dave Barach (dbarach)" , Ed Warnicke 
> , Lukasz Chrustek 
> Cc: "Shaw, Jeffrey B" , "Damjan Marion (damarion)" 
> , "vpp-dev@lists.fd.io" , Lukasz 
> Chrustek 
> Subject: Re: [vpp-dev] Building router plugin
> 
>  
> 
> Hey Luk,
> 
>  
> 
> I have fixed some issues in netlink and router plugin in below patch: Now it 
> can work with VPP.
> 
> https://gerrit.fd.io/r/#/c/5881/Fix compile issue for netlink and router 
> plugin
> 
>  
> 
> Build script is:
> 
> cd /root/vpp
> 
> ln -sf /root/vpp/vppsb/netlink
> 
> ln -sf /root/vpp/vppsb/router
> 
> ln -sf /root/vpp/vppsb/netlink/netlink.mk build-data/packages/
> 
> ln -sf /root/vpp/vppsb/router/router.mk build-data/packages/
> 
>  
> 
> cd /root/vpp/build-root
> 
> make V=0 PLATFORM=vpp TAG=vpp_debug netlink-install router-install
> 
>  
> 
> ln -sf 
> /root/vpp/build-root/install-vpp_debug-native/router/lib64/router.so.0.0.0 \
> 
>  /usr/lib/vpp_plugins/router.so
> 
>  
> 
> I tested it with VPP master using  below script: and it works.
> 
> enable tap-inject
> 
>  
> 
> classify table mask l3 ip4 proto
> 
> ip route add 10.0.0.4/30 via classify 0
> 
> ip route add 10.0.0.22/32 via classify 0
> 
> classify session hit-next ip4-node tap-inject-neighbor table-index 0 match l3 
> ip4 proto 89
> 
> classify session hit-next ip4-node tap-inject-neighbor table-index 0 match l3 
> ip4 proto 2
> 
>  
> 
> But it seems that VPP master failed  to add multicast route via classify 
> table, because ip_mroute_command does not support this.
> 
> DBGvpp# ip mroute add 224.0.0.4/30 via classify 0
> 
> ip mroute: parse error `via classify 0'
> 
> I am not sure whether ip_mroute_command will add it later?
> 
>  
> 
> In VPP stable/1701, all multicast routes are added through “ip route add” 
> command, so below configuration works in stable/1701.
> 
> ip route add 224.0.0.4/30 via classify 0
> 
> I also have a patch that can work well in VPP stable/1701. If required, I can 
> send it to you.
> 
>  
> 
> Thanks Dave and Shaw, Jeffrey for your great help!
> 
>  
> 
> Regards,
> 
> Hongjun
> 
>  
> 
> From:vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Ni, Hongjun
> Sent: Wednesday, March 29, 2017 9:51 AM
> To: Dave Barach (dbarach) ; Ed Warnicke 
> ; Lukasz Chrustek 
> Cc: Shaw, Jeffrey B ; Damjan Marion (damarion) 
> ; vpp-dev@lists.fd.io; Lukasz Chrustek 
> 
> Subject: Re: [vpp-dev] Building router plugin
> 
>  
> 
> Thanks Dave.  Will look into it.
> 
>  
> 
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> Sent: Tuesday, March 28, 2017 7:52 PM
> To: Ni, Hongjun ; Ed Warnicke ; 
> Lukasz Chrustek 
> Cc: Shaw, Jeffrey B ; Damjan Marion (damarion) 
> ; vpp-dev@lists.fd.io; Lukasz Chrustek 
> 
> Subject: RE: [vpp-dev] Building router plugin
> 
>  
> 
> FWIW: I sent diffs to fix the build-system integration over the weekend, as 
> well as a fair fraction of the FIB 2.0 integration...
> 
>  
> 
> Thanks… Dave
> 
>  
> 
> From:vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Ni, Hongjun
> Sent: Monday, March 27, 2017 10:32 PM
> To: Ed Warnicke ; Lukasz Chrustek 
> Cc: Shaw, Jeffrey B ; Damjan Marion (damarion)

Re: [vpp-dev] Building router plugin

2017-04-03 Thread Jeff Shaw 
On Mon, Apr 03, 2017 at 08:51:09PM +0800, 倪红军 wrote:
> Hi Luk,
> 
> 
> The following is the diagram of router plugin:
> In order to insert routes from BIRD, the route will go through: BIRD -> tap 
> interface -> netlink plugin -> insert FIB.
> Not tested the performance yet. But I guess it is a tap interface limitation.
> 
> 
> I think a better way is just like Ed Warnicke suggested in bottom email:
> https://gerrit.fd.io/r/#/c/5004/ - which introduces memif interfaces... which 
> I think Damjan eventually wants a library for so that you could
> use them for things like taps for routing protocol packets...

If performance is of utmost importance, I recommend using the binary api or
building vpp into your application so you can program the fib directly. As
Hongjun noted, you are executing a lot of "extra" code to translate from
netlink to vpp so one should not expect optimal performance in this model.

-Jeff

> 
> 
> 
> 
> Thanks,
> Hongjun
> 
> At 2017-04-03 05:47:20, "Łukasz Chrustek"  wrote:
> Thank You very much Hongjun, I will test it.
> 
> I will test it - mean while, with our programmer, I run the plugin but 
> inserting routes (full BGP feed) thrugh tap interface take very long time. Is 
> it vpp limitation or tap interface ?
> 
> Regards
> Luk
> 
> 
> |
> | Hey Luk,
> 
> I have fixed some issues in netlink and router plugin in below patch: Now it 
> can work with VPP.
> https://gerrit.fd.io/r/#/c/5881/Fix compile issue for netlink and router 
> plugin
> 
> Build script is:
> cd /root/vpp
> ln -sf /root/vpp/vppsb/netlink
> ln -sf /root/vpp/vppsb/router
> ln -sf /root/vpp/vppsb/netlink/netlink.mk build-data/packages/
> ln -sf /root/vpp/vppsb/router/router.mk build-data/packages/
> 
> cd /root/vpp/build-root
> make V=0 PLATFORM=vpp TAG=vpp_debug netlink-install router-install
> 
> ln -sf 
> /root/vpp/build-root/install-vpp_debug-native/router/lib64/router.so.0.0.0 \
> /usr/lib/vpp_plugins/router.so
> 
> I tested it with VPP master using  below script: and it works.
> enable tap-inject
> 
> classify table mask l3 ip4 proto
> ip route add 10.0.0.4/30 via classify 0
> ip route add 10.0.0.22/32 via classify 0
> classify session hit-next ip4-node tap-inject-neighbor table-index 0 match l3 
> ip4 proto 89
> classify session hit-next ip4-node tap-inject-neighbor table-index 0 match l3 
> ip4 proto 2
> 
> But it seems that VPP master failed  to add multicast route via classify 
> table, because ip_mroute_command does not support this.
> DBGvpp# ip mroute add 224.0.0.4/30 via classify 0
> ip mroute: parse error `via classify 0'
> I am not sure whether ip_mroute_command will add it later?
> 
> In VPP stable/1701, all multicast routes are added through “ip route add” 
> command, so below configuration works in stable/1701.
> ip route add 224.0.0.4/30 via classify 0
> I also have a patch that can work well in VPP stable/1701. If required, I can 
> send it to you.
> 
> Thanks Dave and Shaw, Jeffrey for your great help!
> 
> Regards,
> Hongjun
> 
> From:vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Ni, Hongjun
> Sent: Wednesday, March 29, 2017 9:51 AM
> To: Dave Barach (dbarach) ; Ed Warnicke 
> ; Lukasz Chrustek 
> Cc: Shaw, Jeffrey B ; Damjan Marion (damarion) 
> ; vpp-dev@lists.fd.io; Lukasz Chrustek 
> 
> Subject: Re: [vpp-dev] Building router plugin
> 
> Thanks Dave.  Will look into it.
> 
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> Sent: Tuesday, March 28, 2017 7:52 PM
> To: Ni, Hongjun ; Ed Warnicke ; 
> Lukasz Chrustek 
> Cc: Shaw, Jeffrey B ; Damjan Marion (damarion) 
> ; vpp-dev@lists.fd.io; Lukasz Chrustek 
> 
> Subject: RE: [vpp-dev] Building router plugin
> 
> FWIW: I sent diffs to fix the build-system integration over the weekend, as 
> well as a fair fraction of the FIB 2.0 integration...
> 
> Thanks… Dave
> 
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Ni, Hongjun
> Sent: Monday, March 27, 2017 10:32 PM
> To: Ed Warnicke ; Lukasz Chrustek 
> Cc: Shaw, Jeffrey B ; Damjan Marion (damarion) 
> ; vpp-dev@lists.fd.io; Lukasz Chrustek 
> 
> Subject: Re: [vpp-dev] Building router plugin
> 
> Hi Luk,
> 
> We are using netlink and router plugin in VPP stable 17.01, and also met the 
> same issue.
> 
> I have submitted a patch to fix a compile issue in netlink for review, now 
> netlink could compile ok in VPP stable 17.01.
> https://gerrit.fd.io/r/#/c/5881/FIx compile issue for netlink
> 
> I am working on router plugin now, hope to address some issues and make it 
> work again in VPP stable 17.01.
> 
> For VPP 17.04, make file may need to be changed as per new building system.
> 
> Regards,
> Hongjun
> 
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Ed Warnicke
> Sent: Tuesday, March 28, 2017 6:10 AM
> To: Łukasz Chrustek 
> Cc: Damjan Marion (damarion) ; Lukasz Chrustek 
> ; vpp-dev@lists.fd.io; Shaw, Jeffrey B 
> 
> Subject: Re: [vpp-dev] Building router plugin
>

Re: [vpp-dev] Building router plugin - Mroute

2017-04-03 Thread Jeff Shaw 
On Mon, Apr 03, 2017 at 01:10:40PM +, Neale Ranns (nranns) wrote:
> Hi Hongjun,
> 
> Is there a general mechanism to steer all ‘for-us’ traffic to 
> tap-inject-neighbor? i.e. given this:
>   set int ip address GigE0/0/0 10.10.10.10/24
> how do packets to 10.10.10.10 get sent to tap-inject-neighbor?

For the router plugin, you would want IP interface addresses
to be added by the control side, not from vpp, as they would
not be mirrored to the host. The mirroring only happens from
the control to data plane side, not the other way around. I
guess it is more like a one-way mirror used in interrogation
rooms on tv.

If you did,

  ip addr add 10.10.10.10/24 dev vpp0

where vpp0 is the interface associated with GigE0/0/0, then
the router plugin (via the netlink plugin) would hear the
netlink message and apply the address in vpp by calling the
ip4_add_del_interface_address() function.

When the tap-inject mode was originally enabled on the
interface, the router plugin registered the tap-inject-neighbor
node for ICMP6 and ARP traffic, and tap-inject-tx for ICMP, UDP,
TCP, and OSPF. Neighbor nodes do extra processing (i.e. snooping
the neighbor addresses) while the tap-inject-tx node just copies
packets directly into the tap associated with the interface on
which the packet ingressed. See tap_inject.c:tap_inject_enable().

I did a presentation on this topic at the FD.io mini-summit last
year. The slides are somewhat informative. I am not sure if the
video was posted anywhere.

  https://wiki.fd.io/view/File:Dynamic_Routing_on_a_Fast_Data_Plane.pptx


-Jeff

> 
> /neale
> 
> From: 倪红军 
> Date: Monday, 3 April 2017 at 13:53
> To: "Neale Ranns (nranns)" 
> Cc: "Ni, Hongjun" , "Dave Barach (dbarach)" 
> , Ed Warnicke , Lukasz Chrustek 
> , "Shaw, Jeffrey B" , "Damjan 
> Marion (damarion)" , "vpp-dev@lists.fd.io" 
> , Lukasz Chrustek 
> Subject: Re:Re: [vpp-dev] Building router plugin - Mroute
> 
> Hi Neale,
> 
> The intent of this classification is to direct OSPF packet to the node  
> tap-inject-neighbor,
> Then the OSPF packet can be redirected to BIRD in Hosting system.
> 
> Thanks a lot,
> Hongjun
> 
> 
> At 2017-04-01 17:42:28, "Neale Ranns (nranns)" 
> mailto:nra...@cisco.com>> wrote:
> 
> 
> Hi Hongjun,
> 
> The new Multicast FIB in 17.04 removed the classify option for multicast 
> routes. May I ask the intent of the classification you want to achieve? Maybe 
> there is a way to get that behaviour with the new mechanisms.
> 
> Thanks,
> neale
> 
> From: mailto:vpp-dev-boun...@lists.fd.io>> on 
> behalf of "Ni, Hongjun" mailto:hongjun...@intel.com>>
> Date: Saturday, 1 April 2017 at 07:11
> To: "Dave Barach (dbarach)" mailto:dbar...@cisco.com>>, Ed 
> Warnicke mailto:hagb...@gmail.com>>, Lukasz Chrustek 
> mailto:ski...@tlen.pl>>
> Cc: "Shaw, Jeffrey B" 
> mailto:jeffrey.b.s...@intel.com>>, "Damjan Marion 
> (damarion)" mailto:damar...@cisco.com>>, 
> "vpp-dev@lists.fd.io" 
> mailto:vpp-dev@lists.fd.io>>, Lukasz Chrustek 
> mailto:luk...@chrustek.net>>
> Subject: Re: [vpp-dev] Building router plugin
> 
> Hey Luk,
> 
> I have fixed some issues in netlink and router plugin in below patch: Now it 
> can work with VPP.
> https://gerrit.fd.io/r/#/c/5881/ Fix compile issue for netlink and router 
> plugin
> 
> Build script is:
> cd /root/vpp
> ln -sf /root/vpp/vppsb/netlink
> ln -sf /root/vpp/vppsb/router
> ln -sf /root/vpp/vppsb/netlink/netlink.mk build-data/packages/
> ln -sf /root/vpp/vppsb/router/router.mk build-data/packages/
> 
> cd /root/vpp/build-root
> make V=0 PLATFORM=vpp TAG=vpp_debug netlink-install router-install
> 
> ln -sf 
> /root/vpp/build-root/install-vpp_debug-native/router/lib64/router.so.0.0.0 \
>  /usr/lib/vpp_plugins/router.so
> 
> I tested it with VPP master using  below script: and it works.
> enable tap-inject
> 
> classify table mask l3 ip4 proto
> ip route add 10.0.0.4/30 via classify 0
> ip route add 10.0.0.22/32 via classify 0
> classify session hit-next ip4-node tap-inject-neighbor table-index 0 match l3 
> ip4 proto 89
> classify session hit-next ip4-node tap-inject-neighbor table-index 0 match l3 
> ip4 proto 2
> 
> But it seems that VPP master failed  to add multicast route via classify 
> table, because ip_mroute_command does not support this.
> DBGvpp# ip mroute add 224.0.0.4/30 via classify 0
> ip mroute: parse error `via classify 0'
> I am not sure whether ip_mroute_command will add it later?
> 
> In VPP stable/1701, all multicast routes are added through “ip route add” 
> command, so below configuration works in stable/1701.
> ip route add 224.0.0.4/30 via classify 0
> I also have a patch that can work well in VPP stable/1701. If required, I can 
> send it to you.
> 
> Thanks Dave and Shaw, Jeffrey for your great help!
> 
> Regards,
> Hongjun
> 
> From: vpp-dev-boun...@lists.fd.io 
> [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Ni, Hongjun
> Sent: Wednesday, M

Re: [vpp-dev] Building router plugin - Mroute

2017-04-03 Thread Jeff Shaw 
On Mon, Apr 03, 2017 at 04:55:20PM +, Neale Ranns (nranns) wrote:
> Hi Jeff,
> 
> Thanks for the explanation.
> 
> If we registered the tap-inject-tx node as a local/for-us feature then it 
> would be get all traffic sent to one of the router’s addresses, regardless of 
> the L4 protocol. That might be a more robust solution. Local features are a 
> relatively new concept and presently only for IPv4. But I’ll add them for 
> IPv6 if you think this is the right approach.

Yeah, that would be more robust. Though, it isn't too bad only
needing to register a handful of protocols to get OSPF, RIP,
and BGP to work. What you are describing would have been easier
initially, but would have taken all the fun out of debugging
each protocol one-by-one!

> One can then also add unicast/multicast routes as local – which would be how 
> you might install 224.0.0.0/24 (grep vnet/mfib/mfib_test.c for path_for_us 
> for an example)

It looks like it takes less code to add a multicast route with
than the ip4_add_del_route() method, which I appreciate. I must
admit it looks slightly less intuitive. However, I understand the
new fib is much improved and much more flexible so it expect it
would take some getting used to.

I think the only reason to change the router plugin would be if
the old interfaces went away, which appears to be the case as the
fib matures.

Other users should comment as I don't actually use it. I only
developed the plugin in hopes it would be useful for those in the
community by making it very easy to port over existing netlink
based control planes.

-Jeff

> 
> Regards,
> neale
> 
> -Original Message-
> From: Jeff Shaw 
> Date: Monday, 3 April 2017 at 23:12
> To: "Neale Ranns (nranns)" 
> Cc: 倪红军 , "Ni, Hongjun" , "Dave 
> Barach (dbarach)" , Ed Warnicke , 
> Lukasz Chrustek , "Shaw, Jeffrey B" 
> , "Damjan Marion (damarion)" , 
> "vpp-dev@lists.fd.io" , Lukasz Chrustek 
> 
> Subject: Re: [vpp-dev] Building router plugin - Mroute
> 
> On Mon, Apr 03, 2017 at 01:10:40PM +, Neale Ranns (nranns) wrote:
> > Hi Hongjun,
> > 
> > Is there a general mechanism to steer all ‘for-us’ traffic to 
> tap-inject-neighbor? i.e. given this:
> >   set int ip address GigE0/0/0 10.10.10.10/24
> > how do packets to 10.10.10.10 get sent to tap-inject-neighbor?
> 
> For the router plugin, you would want IP interface addresses
> to be added by the control side, not from vpp, as they would
> not be mirrored to the host. The mirroring only happens from
> the control to data plane side, not the other way around. I
> guess it is more like a one-way mirror used in interrogation
> rooms on tv.
> 
> If you did,
> 
>   ip addr add 10.10.10.10/24 dev vpp0
> 
> where vpp0 is the interface associated with GigE0/0/0, then
> the router plugin (via the netlink plugin) would hear the
> netlink message and apply the address in vpp by calling the
> ip4_add_del_interface_address() function.
> 
> When the tap-inject mode was originally enabled on the
> interface, the router plugin registered the tap-inject-neighbor
> node for ICMP6 and ARP traffic, and tap-inject-tx for ICMP, UDP,
> TCP, and OSPF. Neighbor nodes do extra processing (i.e. snooping
> the neighbor addresses) while the tap-inject-tx node just copies
> packets directly into the tap associated with the interface on
> which the packet ingressed. See tap_inject.c:tap_inject_enable().
> 
> I did a presentation on this topic at the FD.io mini-summit last
> year. The slides are somewhat informative. I am not sure if the
> video was posted anywhere.
> 
>   https://wiki.fd.io/view/File:Dynamic_Routing_on_a_Fast_Data_Plane.pptx
> 
> 
> -Jeff
> 
> > 
> > /neale
> > 
> > From: 倪红军 
> > Date: Monday, 3 April 2017 at 13:53
> > To: "Neale Ranns (nranns)" 
> > Cc: "Ni, Hongjun" , "Dave Barach (dbarach)" 
> , Ed Warnicke , Lukasz Chrustek 
> , "Shaw, Jeffrey B" , "Damjan 
> Marion (damarion)" , "vpp-dev@lists.fd.io" 
> , Lukasz Chrustek 
> > Subject: Re:Re: [vpp-dev] Building router plugin - Mroute
> > 
> > Hi Neale,
> > 
> > The intent of this classification is to direct OSPF packet to the node  
> tap-inject-neighbor,
> > Then the OSPF packet can be redirected to BIRD in Hosting system.
> > 
> > Thanks a lot,
> > Hongjun
> > 
> > 
> > At 2017-04-01 17:42:28, "Ne

[vpp-dev] VPP Zoom meeting requires login

2022-10-11 Thread Jeff Shaw 
Hello, I tried to join the VPP meeting this morning on Zoom but it 
required login. I tried creating an account using my company email, but 
this was somehow restricted.


Can the Zoom meeting be updated to not require login?


Thanks,
Jeff

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21999): https://lists.fd.io/g/vpp-dev/message/21999
Mute This Topic: https://lists.fd.io/mt/94261804/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-