dpss unable to copy or punt OSPF packets

Document created by cdnadmin on Jan 25, 2014
Version 1Show Document
  • View in full screen mode
This document was generated from CDN thread

Created by: Viktor S. Wold Eide on 08-10-2013 09:36:23 AM
Hi,

Copying and punting of for example ICMP, TCP, UDP, and GRE packets works just fine. Is it possible to copy or punt packets for protocols not listed as ONEP_PROTOCOL_* in acl.h ?

We have done some tests with the /tutorials/DatapathTutorial application included in the SDK v 1.0.0. When specifying protocol 89, OSPF, we can see that the filter is installed in the router and that the filter in the router matches the received OSPF hello messages:

#show ip access-lists dynamic
Extended IP access list onep-acl-118
    40 permit ospf any any (95 matches)
Extended IP access list udb_temp_acl72
    10 permit ospf any any (95 matches)
1#
 
However, the OSPF packets are not sent to the dpss process and hence not to the onepk DatapathTutorial application.

Using protocol ONEP_PROTOCOL_ALL = 256 does not help for the OSPF packets. The access-list on the router looks fine, but OSPF packets are still not sent to the dpss process and the application.

#show ip access-lists dynamic
Extended IP access list onep-acl-119
    40 permit ip any any (5 matches)
Extended IP access list udb_temp_acl73
    10 permit ip any any (5 matches)
#

Regards
Viktor

Subject: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troubleshooti
Replied by: Einar Nilsen-Nygaard on 08-10-2013 09:53:28 AM
Viktor,

What location are you capturing packets from? And are you trying this on the same router that is generating the OSPF packets?

Cheers,

Einar

On 8 Oct 2013, at 15:36, "Cisco Developer Community Forums" <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- Hi,

Copying and punting of for example ICMP, TCP, UDP, and GRE packets works just fine. Is it possible to copy or punt packets for protocols not listed as ONEP_PROTOCOL_* in acl.h ?

We have done some tests with the /tutorials/DatapathTutorial application included in the SDK v 1.0.0. When specifying protocol 89, OSPF, we can see that the filter is installed in the router and that the filter in the router matches the received OSPF hello messages:

#show ip access-lists dynamic
Extended IP access list onep-acl-118
    40 permit ospf any any (95 matches)
Extended IP access list udb_temp_acl72
    10 permit ospf any any (95 matches)
1#

However, the OSPF packets are not sent to the dpss process and hence not to the onepk DatapathTutorial application.

Using protocol ONEP_PROTOCOL_ALL = 256 does not help for the OSPF packets. The access-list on the router looks fine, but OSPF packets are still not sent to the dpss process and the application.

#show ip access-lists dynamic
Extended IP access list onep-acl-119
    40 permit ip any any (5 matches)
Extended IP access list udb_temp_acl73
    10 permit ip any any (5 matches)
#

Regards
Viktor
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/19980100 or simply reply to this email.

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 08-10-2013 10:10:28 AM
Hi Einar,

We have tried to both copy and punt OSPF packets on an ethernet interface
on a c2951 router, both for outgoing and incoming OSPF packets. So far we
have not been able to punt any of the OSPF packets (neither multicast nor
directly addressed packets). Please let us know if this should work.

Regards
Viktor


On Tue, Oct 8, 2013 at 4:53 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> What location are you capturing packets from? And are you trying this on
> the same router that is generating the OSPF packets?
>
> Cheers,
>
> Einar
>
> On 8 Oct 2013, at 15:36, "Cisco Developer Community Forums" <
> cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:
>
> Viktor S. Wold Eide has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Hi,
>
> Copying and punting of for example ICMP, TCP, UDP, and GRE packets works
> just fine. Is it possible to copy or punt packets for protocols not listed
> as ONEP_PROTOCOL_* in acl.h ?
>
> We have done some tests with the /tutorials/DatapathTutorial application
> included in the SDK v 1.0.0. When specifying protocol 89, OSPF, we can see
> that the filter is installed in the router and that the filter in the
> router matches the received OSPF hello messages:
>
> #show ip access-lists dynamic
> Extended IP access list onep-acl-118
> 40 permit ospf any any (95 matches)
> Extended IP access list udb_temp_acl72
> 10 permit ospf any any (95 matches)
> 1#
>
> However, the OSPF packets are not sent to the dpss process and hence not
> to the onepk DatapathTutorial application.
>
> Using protocol ONEP_PROTOCOL_ALL = 256 does not help for the OSPF packets.
> The access-list on the router looks fine, but OSPF packets are still not
> sent to the dpss process and the application.
>
> #show ip access-lists dynamic
> Extended IP access list onep-acl-119
> 40 permit ip any any (5 matches)
> Extended IP access list udb_temp_acl73
> 10 permit ip any any (5 matches)
> #
>
> Regards
> Viktor
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/19980100or simply reply to this email.
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/19980413or simply reply to this email.

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 08-10-2013 10:26:28 AM
OK, fine Einar.

As written in the initial message, it would be good to know if only the
ONEP_PROTOCOL_* in acl.h are supported or not.

In case copying or punting of OSPF is not possible in this way (using layer
3 filters) we would appreciate if you could check whether using any of the
layer 2 acl functions would make a difference or not, such as
onep_acl_create_l2_ace and onep_acl_create_l2_acl.

Best regards
Viktor

On Tue, Oct 8, 2013 at 5:15 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> Because of how some IOS components, such as routing protocols, interact
> with the underlying device OS infrastructure certain packets may not be
> available to the DPSS if you are on the same router as the OSPF instance
> generating the packets and you are capturing packets on the output path.
> However, I will have to do a little bit of research to fully answer your
> question.
>
> Let me get back to you.
>
> Cheers,
>
> Einar
>

Subject: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troubleshooti
Replied by: Einar Nilsen-Nygaard on 08-10-2013 10:15:38 AM
Viktor,

Because of how some IOS components, such as routing protocols, interact with the underlying device OS infrastructure certain packets may not be available to the DPSS if you are on the same router as the OSPF instance generating the packets and you are capturing packets on the output path. However, I will have to do a little bit of research to fully answer your question.

Let me get back to you.

Cheers,

Einar

On Oct 8, 2013, at 4:10 PM, Cisco Developer Community Forums <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- Hi Einar,

We have tried to both copy and punt OSPF packets on an ethernet interface
on a c2951 router, both for outgoing and incoming OSPF packets. So far we
have not been able to punt any of the OSPF packets (neither multicast nor
directly addressed packets). Please let us know if this should work.

Regards
Viktor


On Tue, Oct 8, 2013 at 4:53 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> What location are you capturing packets from? And are you trying this on
> the same router that is generating the OSPF packets?
>
> Cheers,
>
> Einar
>
> On 8 Oct 2013, at 15:36, "Cisco Developer Community Forums" <
> cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com><mailto:cdicuser@developer.cisco.com>> wrote:
>
> Viktor S. Wold Eide has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Hi,
>
> Copying and punting of for example ICMP, TCP, UDP, and GRE packets works
> just fine. Is it possible to copy or punt packets for protocols not listed
> as ONEP_PROTOCOL_* in acl.h ?
>
> We have done some tests with the /tutorials/DatapathTutorial application
> included in the SDK v 1.0.0. When specifying protocol 89, OSPF, we can see
> that the filter is installed in the router and that the filter in the
> router matches the received OSPF hello messages:
>
> #show ip access-lists dynamic
> Extended IP access list onep-acl-118
> 40 permit ospf any any (95 matches)
> Extended IP access list udb_temp_acl72
> 10 permit ospf any any (95 matches)
> 1#
>
> However, the OSPF packets are not sent to the dpss process and hence not
> to the onepk DatapathTutorial application.
>
> Using protocol ONEP_PROTOCOL_ALL = 256 does not help for the OSPF packets.
> The access-list on the router looks fine, but OSPF packets are still not
> sent to the dpss process and the application.
>
> #show ip access-lists dynamic
> Extended IP access list onep-acl-119
> 40 permit ip any any (5 matches)
> Extended IP access list udb_temp_acl73
> 10 permit ip any any (5 matches)
> #
>
> Regards
> Viktor
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/19980100or simply reply to this email.
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/19980413or simply reply to this email.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/19980939 or simply reply to this email.

Subject: RE: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troublesh
Replied by: Einar Nilsen-Nygaard on 09-10-2013 02:54:44 AM
Viktor,

Sorry, I missed the question about ONEP_PROTOCOL_*. You can specify numbers directly, so you are not limited to what is in the enum.

Cheers,

Einar

Subject: RE: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubles
Replied by: Einar Nilsen-Nygaard on 09-10-2013 03:14:33 AM
Ok, I've moved forward with the investigation. As a first step, and using a simple virtual router deployment rather than physical ISRs, I have been able to intercept a range of OSPF packets and copy them to my onePK application. I've attached a packet trace of two adjacencies being formed for reference, which was captured on a virtrual router with two OSPF neighbors. I was capturing packets both on input and output of the interfaces facing each neighbor, using an ACL-based class-map filtering on "ip any any" and my app only looking at OSPF packets (note that I also tried specifying the value 89 directly, rather than ONEP_PROTOCOL_ALL, and I obtained the same results).

So, in principal we can do this with the DPSS. However, as I mentioned before, a real ISR may behave differently, so the next step is to try this on a physical ISR, which I hope to be able to do today now that I have a test application.

Cheers,

Einar

Viktor S. Wold Eide:
OK, fine Einar.

As written in the initial message, it would be good to know if only the
ONEP_PROTOCOL_* in acl.h are supported or not.

In case copying or punting of OSPF is not possible in this way (using layer
3 filters) we would appreciate if you could check whether using any of the
layer 2 acl functions would make a difference or not, such as
onep_acl_create_l2_ace and onep_acl_create_l2_acl.

Best regards
Viktor

On Tue, Oct 8, 2013 at 5:15 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> Because of how some IOS components, such as routing protocols, interact
> with the underlying device OS infrastructure certain packets may not be
> available to the DPSS if you are on the same router as the OSPF instance
> generating the packets and you are capturing packets on the output path.
> However, I will have to do a little bit of research to fully answer your
> question.
>
> Let me get back to you.
>
> Cheers,
>
> Einar
>


Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 09-10-2013 04:01:38 AM
Just to avoid any misunderstanding, we do specify the protocol numbers
directly on the command line.

For OSPF only:
./bin/DatapathTutorial  -a 10.0.225.11 -u user -p xxx -i
GigabitEthernet0/0 -r 89 -t tcp

For all packets:
./bin/DatapathTutorial  -a 10.0.225.11 -u user -p xxx -i
GigabitEthernet0/0 -r 256 -t tcp

As mentioned the OSPF packets seem to be matched at the router, but not
copied to the dpss and application.

#show ip access-lists dynamic
Extended IP access list onep-acl-134
    40 permit ospf any any (12 matches)
Extended IP access list udb_temp_acl87
    10 permit ospf any any (12 matches)


#show policy-map target main-interface
GigabitEthernet0/0

  Service-policy packet-service input: __ONEP_5041_0

    Class-map: __ONEP_5041_0 (match-any)
      12 packets, 1128 bytes
      30 second offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name onep-acl-134
        12 packets, 1128 bytes
        30 second rate 0 bps
      PSP Copy
        src_vm  src_app 0
        dst_vm 1 dst_app 1
        dst_vm_user_data 0xBB53930
        local_id 1
        copy_size 0
        packets copied 0
        bytes copied 0

    Class-map: class-default (match-any)
      11 packets, 2024 bytes
      30 second offered rate 0000 bps, drop rate 0000 bps
      Match: any
#

Regards
Viktor

On Wed, Oct 9, 2013 at 9:54 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> Sorry, I missed the question about ONEP_PROTOCOL_*. You *can* specify
> numbers directly, so you are not limited to what is in the enum.
>
> Cheers,
>
> Einar
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/20007541or simply reply to this email.

Subject: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troubleshooti
Replied by: Einar Nilsen-Nygaard on 09-10-2013 04:43:38 AM
The run of the DatapathTutorial app I show below was after the adjacencies had been established, so it was only hello packets. Also, the app only looks at packets on one interface and going in one direction, so it's only going to show that traffic. That's all I meant :-)

We have a 2951 in our lab, which I'm going to use for a test, but currently someone else in my team is logged in to it and I need to talk with him before re-imaging it and setting up the test scenario. Unfortunately, he is asleep just now on the west coast of the US…

Cheers,

Einar

On Oct 9, 2013, at 10:27 AM, Cisco Developer Community Forums <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- Thanks a lot Einar.

You seem to indicate that there are some OSPF packets that are not being
copied? Do you see, e.g., with wireshark, OSPF packets that are not copied
to the onep application?

We are looking forward hearing whether this works or not for a physical
router, preferably a C2951.

Regards
Viktor

On Wed, Oct 9, 2013 at 11:15 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Sure. If I
> use DataPathTutorial *against vIOS* I get this:
>
> cisco@onepk:~/onePK-sdk-1.0.0.84/c64/tutorials/DatapathTutorial$
> ./bin/DatapathTutorial -a 10.10.10.110 -u cisco -p cisco123 -i
> GigabitEthernet0/0 -r 89 -t tcp
>
> Network Element CONNECT SUCCESS
>
> Added ace to acl
> [0] Interface [GigabitEthernet0/0]
> [1] Interface [GigabitEthernet0/1]
> [2] Interface [GigabitEthernet0/2]
> [3] Interface [GigabitEthernet0/3]
> [4] Interface [GigabitEthernet0/4]
> [5] Interface [GigabitEthernet0/5]
> [6] Interface [GigabitEthernet0/6]
> [7] Interface [GigabitEthernet0/7]
> [8] Interface [GigabitEthernet0/8]
> [9] Interface [GigabitEthernet0/9]
> [10] Interface [Loopback99]
> [11] Interface [Tunnel0]
>
> Name of interface expecting packets: GigabitEthernet0/0
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
> This is obviously only part of the OSPF traffic, but you can see that with
> vIOS we are getting the packets. Hence the need to replicate with real
> hardware.
>
> Cheers,
>
> Einar
>
>
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/20012587 or simply reply to this email.

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 09-10-2013 04:14:28 AM
That's good to hear Einar.

Could you also verify that you are able to copy the packets using the
tutorials/DatapathTutorial application?

We do not have any IOS for Linux  VM image for onepk version 1.0.0.84. The
physical router has the following software:
Cisco IOS Software, C2951 Software (C2951-UNIVERSALK9-M), Version 15.3(3)M,
RELEASE SOFTWARE (fc2)

Regards
Viktor

On Wed, Oct 9, 2013 at 10:15 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Ok, I've
> moved forward with the investigation. As a first step, and using a simple
> virtual router deployment rather than physical ISRs, I have been able to
> intercept a range of OSPF packets and copy them to my onePK application.
> I've attached a packet trace of two adjacencies being formed for reference,
> which was captured on a virtrual router with two OSPF neighbors. I was
> capturing packets both on input and output of the interfaces facing each
> neighbor, using an ACL-based class-map filtering on "ip any any" and my app
> only looking at OSPF packets (note that I also tried specifying the value
> 89 directly, rather than ONEP_PROTOCOL_ALL, and I obtained the same
> results).
>
> So, in principal we can do this with the DPSS. However, as I mentioned
> before, a real ISR may behave differently, so the next step is to try this
> on a physical ISR, which I hope to be able to do today now that I have a
> test application.
>
> Cheers,
>
> Einar
>

Subject: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troubleshooti
Replied by: Einar Nilsen-Nygaard on 09-10-2013 04:15:28 AM
Sure. If I use DataPathTutorial *against vIOS* I get this:

cisco@onepk:~/onePK-sdk-1.0.0.84/c64/tutorials/DatapathTutorial$ ./bin/DatapathTutorial -a 10.10.10.110 -u cisco -p cisco123 -i GigabitEthernet0/0 -r 89 -t tcp

Network Element CONNECT SUCCESS

Added ace to acl
[0] Interface [GigabitEthernet0/0]
[1] Interface [GigabitEthernet0/1]
[2] Interface [GigabitEthernet0/2]
[3] Interface [GigabitEthernet0/3]
[4] Interface [GigabitEthernet0/4]
[5] Interface [GigabitEthernet0/5]
[6] Interface [GigabitEthernet0/6]
[7] Interface [GigabitEthernet0/7]
[8] Interface [GigabitEthernet0/8]
[9] Interface [GigabitEthernet0/9]
[10] Interface [Loopback99]
[11] Interface [Tunnel0]

Name of interface expecting packets: GigabitEthernet0/0

| FID | IPv | Source                  | Destination             | Prot | Pkt# | State                     |
| 100 |  4  | 10.10.20.120    : 0     | 224.0.0.5       : 0     | UNK! | CLOSED                    |


| FID | IPv | Source                  | Destination             | Prot | Pkt# | State                     |
| 100 |  4  | 10.10.20.120    : 0     | 224.0.0.5       : 0     | UNK! | CLOSED                    |


| FID | IPv | Source                  | Destination             | Prot | Pkt# | State                     |
| 100 |  4  | 10.10.20.120    : 0     | 224.0.0.5       : 0     | UNK! | CLOSED                    |


| FID | IPv | Source                  | Destination             | Prot | Pkt# | State                     |
| 100 |  4  | 10.10.20.120    : 0     | 224.0.0.5       : 0     | UNK! | CLOSED                    |


| FID | IPv | Source                  | Destination             | Prot | Pkt# | State                     |
| 100 |  4  | 10.10.20.120    : 0     | 224.0.0.5       : 0     | UNK! | CLOSED                    |

This is obviously only part of the OSPF traffic, but you can see that with vIOS we are getting the packets. Hence the need to replicate with real hardware.

Cheers,

Einar

On Oct 9, 2013, at 10:01 AM, Cisco Developer Community Forums <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- Just to avoid any misunderstanding, we do specify the protocol numbers
directly on the command line.

For OSPF only:
./bin/DatapathTutorial -a 10.0.225.11 -u user -p xxx -i
GigabitEthernet0/0 -r 89 -t tcp

For all packets:
./bin/DatapathTutorial -a 10.0.225.11 -u user -p xxx -i
GigabitEthernet0/0 -r 256 -t tcp

As mentioned the OSPF packets seem to be matched at the router, but not
copied to the dpss and application.

#show ip access-lists dynamic
Extended IP access list onep-acl-134
40 permit ospf any any (12 matches)
Extended IP access list udb_temp_acl87
10 permit ospf any any (12 matches)


#show policy-map target main-interface
GigabitEthernet0/0

Service-policy packet-service input: __ONEP_5041_0

Class-map: __ONEP_5041_0 (match-any)
12 packets, 1128 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: access-group name onep-acl-134
12 packets, 1128 bytes
30 second rate 0 bps
PSP Copy
src_vm src_app 0
dst_vm 1 dst_app 1
dst_vm_user_data 0xBB53930
local_id 1
copy_size 0
packets copied 0
bytes copied 0

Class-map: class-default (match-any)
11 packets, 2024 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any
#

Regards
Viktor

On Wed, Oct 9, 2013 at 9:54 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> Sorry, I missed the question about ONEP_PROTOCOL_*. You *can* specify
> numbers directly, so you are not limited to what is in the enum.
>
> Cheers,
>
> Einar
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/20007541or simply reply to this email.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/20010589 or simply reply to this email.

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 09-10-2013 04:27:28 AM
Thanks a lot Einar.

You seem to indicate that there are some OSPF packets that are not being
copied? Do you see, e.g., with wireshark, OSPF packets that are not copied
to the onep application?

We are looking forward hearing whether this works or not for a physical
router, preferably a C2951.

Regards
Viktor

On Wed, Oct 9, 2013 at 11:15 AM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Sure. If I
> use DataPathTutorial *against vIOS* I get this:
>
> cisco@onepk:~/onePK-sdk-1.0.0.84/c64/tutorials/DatapathTutorial$
> ./bin/DatapathTutorial -a 10.10.10.110 -u cisco -p cisco123 -i
> GigabitEthernet0/0 -r 89 -t tcp
>
> Network Element CONNECT SUCCESS
>
> Added ace to acl
> [0] Interface [GigabitEthernet0/0]
> [1] Interface [GigabitEthernet0/1]
> [2] Interface [GigabitEthernet0/2]
> [3] Interface [GigabitEthernet0/3]
> [4] Interface [GigabitEthernet0/4]
> [5] Interface [GigabitEthernet0/5]
> [6] Interface [GigabitEthernet0/6]
> [7] Interface [GigabitEthernet0/7]
> [8] Interface [GigabitEthernet0/8]
> [9] Interface [GigabitEthernet0/9]
> [10] Interface [Loopback99]
> [11] Interface [Tunnel0]
>
> Name of interface expecting packets: GigabitEthernet0/0
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
>
> | FID | IPv | Source | Destination | Prot | Pkt# | State |
> | 100 | 4 | 10.10.20.120 : 0 | 224.0.0.5 : 0 | UNK! | CLOSED |
>
> This is obviously only part of the OSPF traffic, but you can see that with
> vIOS we are getting the packets. Hence the need to replicate with real
> hardware.
>
> Cheers,
>
> Einar
>
>

Subject: RE: dpss unable to copy or punt OSPF packets
Replied by: Einar Nilsen-Nygaard on 09-10-2013 12:53:37 PM
Viktor,

An update. I have been testing on a 3925 (2951 not available yet) and can report that there is an issue of some kind which I have been investigating this afternoon with the CEF team, but with no conclusion. What we can see while monitoring a specific interface for input OSPF packets is that the packets are matched by the ACL (as you observed) but that only occasional packets are copied to the onep application. This last point seems to be different from what you have observed, but there is no regular pattern to the packets that make it to the onep app that I have noted so far.

So, we have narrowed down where the problem might be, but we have not found the issue yet.

Cheers,

Einar

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 10-10-2013 02:12:28 AM
OK Einar. Thanks a lot for the update.

Regards
Viktor

Subject: RE: dpss unable to copy or punt OSPF packets
Replied by: Einar Nilsen-Nygaard on 10-10-2013 08:35:29 AM
Viktor,

Testing on a 2951 has yielded the same results now as you experienced. Not sure how interested you are in the details, but as you may or may not be aware, OSPF packets have a TTL of 1, and initial investigations seem to suggest that this may be causing us some issues. This will require a bit more work to nail down. I probably won't have any more news this week.

Cheers,

Einar

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 11-10-2013 05:24:28 AM
Thanks for the update Einar, it's appreciated.

Are there any documents describing in detail exactly where, in relation to
processing steps, a packet is copied, punted, or (re)injected for the
different defined target_locations? More specifically, details regarding
which processing steps take place before copy/punt and after (re)inject.

Regards
Viktor

On Thu, Oct 10, 2013 at 3:35 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> Testing on a 2951 has yielded the same results now as you experienced. Not
> sure how interested you are in the details, but as you may or may not be
> aware, OSPF packets have a TTL of 1, and initial investigations seem to
> suggest that this may be causing us some issues. This will require a bit
> more work to nail down. I probably won't have any more news this week.
>
> Cheers,
>
> Einar
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/20058824or simply reply to this email.

Subject: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troubleshooti
Replied by: Einar Nilsen-Nygaard on 11-10-2013 05:55:28 AM
We don't have that level of document yet, I'm afraid.

Cheers,

Einar

On Oct 11, 2013, at 11:24 AM, Cisco Developer Community Forums <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": -------------------------------------------------------------- Thanks for the update Einar, it's appreciated.

Are there any documents describing in detail exactly where, in relation to
processing steps, a packet is copied, punted, or (re)injected for the
different defined target_locations? More specifically, details regarding
which processing steps take place before copy/punt and after (re)inject.

Regards
Viktor

On Thu, Oct 10, 2013 at 3:35 PM, Cisco Developer Community Forums <
cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

> Einar Nilsen-Nygaard has created a new message in the forum
> "Troubleshooting":
> -------------------------------------------------------------- Viktor,
>
> Testing on a 2951 has yielded the same results now as you experienced. Not
> sure how interested you are in the details, but as you may or may not be
> aware, OSPF packets have a TTL of 1, and initial investigations seem to
> suggest that this may be causing us some issues. This will require a bit
> more work to nail down. I probably won't have any more news this week.
>
> Cheers,
>
> Einar
> --
> To respond to this post, please click the following link:
> http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/20058824or simply reply to this email.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/20101012 or simply reply to this email.

Subject: RE: dpss unable to copy or punt OSPF packets
Replied by: Viktor S. Wold Eide on 26-11-2013 09:58:07 AM
Einar Nilsen-Nygaard:
Viktor,

Testing on a 2951 has yielded the same results now as you experienced. Not sure how interested you are in the details, but as you may or may not be aware, OSPF packets have a TTL of 1, and initial investigations seem to suggest that this may be causing us some issues. This will require a bit more work to nail down. I probably won't have any more news this week.

Cheers,

Einar
Hi again Einar,

Have you looked more into this issue?

As we understand it, this is a bug, meaning that it will be possible to punt any packet which is sent out on any interface?

Is this something that is likely to be fixed in the upcoming version 1.1 and then also for the 2951?

Best regards
Viktor

Subject: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troubleshooti
Replied by: Einar Nilsen-Nygaard on 02-12-2013 07:39:51 AM
Viktor,

We have a partial fix today which I have verified has addressed the OSPF packet issue, but which has caused problems with other packet types when the action is a COPY, the net result of which is that an application would receive multiple copies of a packet it is interested in under certain circumstances. This obviously needs addressed, so we're not quite done yet.

The issue will be addressed in the upcoming 1.1 release, but probably in the first rebuild for the 2951 (and other ISR-G2 platforms).

Cheers,

Einar


On Nov 26, 2013, at 3:58 PM, Cisco Developer Community Forums <cdicuser@developer.cisco.com<mailto:cdicuser@developer.cisco.com>> wrote:

Viktor S. Wold Eide has created a new message in the forum "Troubleshooting": --------------------------------------------------------------
Einar Nilsen-Nygaard:
Viktor,

Testing on a 2951 has yielded the same results now as you experienced. Not sure how interested you are in the details, but as you may or may not be aware, OSPF packets have a TTL of 1, and initial investigations seem to suggest that this may be causing us some issues. This will require a bit more work to nail down. I probably won't have any more news this week.

Cheers,

Einar
Hi again Einar,

Have you looked more into this issue?

As we understand it, this is a bug, meaning that it will be possible to punt any packet which is sent out on any interface?

Is this something that is likely to be fixed in the upcoming version 1.1 and then also for the 2951?

Best regards
Viktor
--
To respond to this post, please click the following link: http://developer.cisco.com/web/onepk-developer/forum/-/message_boards/view_message/21742255 or simply reply to this email.

Subject: Re: New Message from Einar Nilsen-Nygaard in onePK Developer - Troubleshoot
Replied by: Viktor S. Wold Eide on 02-12-2013 10:08:51 AM
OK Einar. Thanks for the update. Could you clarify somewhat what you mean
by the first rebuild? I assume this means that an update to the SDK 1.1
itself is not sufficient, and hence both SDK 1.1 and an updated version of
the image for the 2951 are needed?

Best regards
Viktor

Subject: RE: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troublesh
Replied by: Viktor S. Wold Eide on 10-12-2013 11:07:08 AM
Hi again,

We have done some testing using the all_in_one_VM sdk-c64-1.0.0.84 and vIOS.

With the VM, OSPF packets are punted for some onepk sessions. We sometimes experience onepk sessions where OSPF packets are not punted. Injecting OSPF packets on input does not seem to work at all, as far as we have seen.

We experience these issues when trying to tunnel any packet/frame, including OSPF, from one router to another within a custom container packet. For tunneling, punting on both output and input, as well as inject_raw on both output and input are needed.

Briefly, this looks like:

output:
- punt packet (works for OSPF for some onepk sessions, but not always)
- drop packet
- inject new packet on output

input:
- punt packet
- drop packet
- inject new packet on input  (does not work for OSPF)

For the other protocols we have tested this seems to work.

Best regards
Viktor

Einar Nilsen-Nygaard:
Viktor,

We have a
partial fix today which I have verified has addressed the OSPF packet
issue, but which has caused problems with other packet types when the
action is a COPY, the net result of which is that an application would
receive multiple copies of a packet it is interested in under certain
circumstances. This obviously needs addressed, so we're not quite done
yet.

The issue will be addressed in the upcoming 1.1 release, but
probably in the first rebuild for the 2951 (and other ISR-G2
platforms).

Cheers,

Einar


Subject: RE: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troublesh
Replied by: Viktor S. Wold Eide on 10-12-2013 11:26:39 AM
I should have added that divert gives this behavior (we have tried both divert and punt) - OSPF packets injected at input are not properly received by the OSPF process on the router.

Best regards
Viktor

Subject: RE: Re: New Message from Viktor S. Wold Eide in onePK Developer - Troublesh
Replied by: Viktor S. Wold Eide on 23-01-2014 04:55:45 AM
Einar Nilsen-Nygaard:
Viktor,

We have a partial fix today which I have verified has addressed the OSPF packet issue, but which has caused problems with other packet types when the action is a COPY, the net result of which is that an application would receive multiple copies of a packet it is interested in under certain circumstances. This obviously needs addressed, so we're not quite done yet.

The issue will be addressed in the upcoming 1.1 release, but probably in the first rebuild for the 2951 (and other ISR-G2 platforms).

Cheers,

Einar

Hi again Einar,

Could you please provide a short status regarding this issue? Should this be OK now?

We are using the latest onepk version available from Cisco DevNet, that is, sdk-c64-1.1.0.99 together with the latest router images also available from Cisco DevNet. Regarding physical routers, we are using c2951 and c2911. For c2911 no working image is available from DevNet so far.

Best regards
Viktor

Attachments

Outcomes