RARE user and assistance email list

["Ackermann, Michael via groups.io" <>]

This message was sent securely using Zix®

First sorry to hear about your flight.   Hope you are close to or even home now!     The airline better have bought you dinner and paid for a hotel!!!

 

I have many pcaps.   Trying to do as much as I can this weekend, as Monday and likely all of next week will likely be tough for me.     How dare I take a week off  😊. 

When we talk on Monday I will describe the various testing I have done and the traces I have.    You will likely not be interested in all of them.   And many are problems with setting up test environments and test scenarios,  that showed even more issues with IPV6.   But the bottom line continues to be that EHs are getting through. 

 

I would like to be involved in the FreeRTR testing.   You probably know what I say next ☹.     My issue is increasingly getting to be time.     So once again let’s talk about what I could possibly contribute,  in all the areas we have discussed the passed week or so,  and prioritize.    I hope you know I want to do it ALL,  but have to be realistic or I end up being a problem or slowing things down. 

 

In any event, a lot of great, positive and productive initiatives !       Very exciting!!!!

 

Thanks

 

Mike

 

 

 

From: Nalini J Elkins <>
Sent: Sunday, July 31, 2022 10:04 AM
To: ; Nalini J Elkins <>;
Cc: Ackermann, Michael <>; Tommaso Pecorella <>; Dhruv Dhody <>; Mohit P. Tahiliani <>
Subject: Re: [freertr] FreeRtr and Hop-By-Hop header

 

[External email]

Csaba,

 

(Adding Dhruv and Mohit.  They are our main contacts in India for our work.)

 

First, I am still not home yet.  My flight was cancelled so I had to spend the night at a stopover!  Hopefully, I get home today!  Then, I can work quietly.

 

We are setting up an email list.  Will invite you to join.  I think I will start an email thread / group to just test just router functions.  I will write up what I am thinking and then we can test the same thing on multiple platforms.  (FreeRtr, Cisco, Juniper, for example).

 

Please also send me pcaps of your testing / ping.  We can create a repository.   Also, let's create a "tools" section so we have PING (w/HBH), etc.   Procedures on how to do Telnet with HBH.     

 

Also, if we get Linux servers at various locations, can you guys help with setting up FreeRtr on them?  I think once we understand the configuration, we can easily clone (and modify routing table / etc as needed).   Mike, maybe you are best to coordinate this.  Do you have time?   Dhruv, is there someone in India who can help?

 

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

 

 

On Saturday, July 30, 2022 at 02:42:23 PM PDT, mc36 <> wrote:

 

 

and one explicit one:

mchome#lookup reverse  62.240.163.10
resolving ptr 10.163.240.62.IN-ADDR.ARPA
10.163.240.62.in-addr.arpa ptr internetcz.cust.net.upc.cz

mchome#ping 62.240.163.10 vrf inet2
pinging 62.240.163.10, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false, multi=false
!!!!!
result=100.0%, recv/sent/lost/err=5/5/0/0, took 71, min/avg/max/dev rtt=13/13.8/14/0.1, ttl 237/237/237/0.0, tos 0/0.0/0/0.0
mchome#ping 62.240.163.10 vrf inet2 alert 1
pinging 62.240.163.10, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=1, sweep=false, multi=false
.....
result=0.0%, recv/sent/lost/err=0/5/5/0, took 5002, min/avg/max/dev rtt=10000/0.0/0/0.0, ttl 256/0.0/0/0.0, tos 256/0.0/0/0.0
mchome#

On 7/30/22 23:40, mc36 wrote:
> well, seemingly my local isp blocks all such my packets so i cannot do to much for now....
> but the stuff will be out by the tomorrow autoupgrade in some boxes in the local nren,
> where from i can test if further... interesting afterall... seemingly ipv4 is not better,
> some isps propagate the alert option, some dont... but in that case, at least my packets
> exceed my uplink isp border boxes... :)
>
>
> mchome#traceroute nop.hu vrf inet2 lookup ipv4
> resolving nop.hu for ipv4 ok!
> tracing 81.2.241.46, src="null," vrf=inet2, prt=0/33440, tim=1000, tos=0, flow=0, len=64
> via 0.0.0.0/0 0/2 dialer1 10.0.0.1 00:13:48
> 1 null time=1000
> 2 null time=1000
> 3 null time=1000
> 4 null time=1000
> 5 null time=1000
> 6 null time=1000
> 7 null time=1000
> 8 4.69.161.122 time=4, name=ae2.3204.ear1.Budapest1.level3.net
> 9 null time=1000
> 10 null time=1000
> 11 null time=1000
> 12 null time=1000
> 13 185.188.186.30 time=24, mpls=89, name=cz-prg01a-rc1-vla2121.net.vodafone.cz
> 14 185.188.187.88 time=12, mpls=982, name=cz-pra-pop115-rb1-vla2119.net.vodafone.cz
> 15 null time=1000
> 16 62.240.163.10 time=13, name=internetcz.cust.net.upc.cz
> 17 null time=1000
> 18 null time=1000
> 19 81.2.241.46 time=15, name=www.nop.hu
> mchome#
> mchome#ping 4.69.161.122 vrf inet2 alert 1234
> pinging 4.69.161.122, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=1234, sweep=false, multi=false
> !!!!!
> result=100.0%, recv/sent/lost/err=5/5/0/0, took 81, min/avg/max/dev rtt=12/16.2/23/14.9, ttl 55/55.0/55/0.0, tos 0/0.0/0/0.0
> mchome#ping 185.188.186.30 vrf inet2 alert 1234
> pinging 185.188.186.30, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=1234, sweep=false, multi=false
> .....
> result=0.0%, recv/sent/lost/err=0/5/5/0, took 5002, min/avg/max/dev rtt=10000/0.0/0/0.0, ttl 256/0.0/0/0.0, tos 256/0.0/0/0.0
> mchome#
>
>
>
> On 7/30/22 22:34, mc36 wrote:
>> and it works.... btw, these packets did not get out of my net, as expected... :)
>> but in wireshark, they look pretty, see attached.... :)
>> br,
>> cs
>>
>> resolving www for ipv6 ok!
>> pinging 2001:db8:1101::10, src="2001:db8:1101::227:227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
>> !!!!!
>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 7, min/avg/max/dev rtt=1/1.4/2/0.2, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
>> sid#ping www alert 123 ipv4
>> resolving www for ipv4 ok!
>> pinging 10.10.10.10, src="10.10.10.227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
>> !!!!!
>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 5, min/avg/max/dev rtt=0/0.8/1/0.1, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
>> sid#
>>
>>
>> sid#ping mp.ls
>> resolving mp.ls for ipv6 ok!
>> pinging 2001:15e8:110:92e::cc1e:c0de, src="2001:db8:1101::227:227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false,
>> multi=false
>> !!!!!
>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 89, min/avg/max/dev rtt=17/17.8/18/0.1, ttl 240/240/240/0.0, tos 0/0.0/0/0.0
>> sid#ping mp.ls alert 123
>> resolving mp.ls for ipv6 ok!
>> pinging 2001:15e8:110:92e::cc1e:c0de, src="2001:db8:1101::227:227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false,
>> multi=false
>> .....
>> result=0.0%, recv/sent/lost/err=0/5/5/0, took 5001, min/avg/max/dev rtt=10000/0.0/0/0.0, ttl 256/0.0/0/0.0, tos 256/0.0/0/0.0
>> sid#
>>
>>
>>
>>
>> On 7/30/22 22:13, mc36 wrote:
>>> well, imho all the vendors have the knobs to filter these out in acls, or globally...
>>> on fixed/programmable asics, it's on by default because of the limited onchip code space, but they'll tell....
>>> but if not, it's up to the operators if they do so... those who issues before with these,
>>> imho they've configured it already... but let's see... i'm extending my ping with
>>> the capability right now to ease the further testing, and we'll see...
>>>
>>> sid#ping 1.1.1.1 alert ?
>>>        <num> - payload data
>>>
>>> it'll set the packHolder.IPalrt from below patch i did with the tcp to emit the hbh frames...
>>> br,
>>> cs
>>>
>>>
>>> On 7/30/22 21:43, Nalini J Elkins wrote:
>>>> I am on board the flight home.        I will check your trace and results tomorrow.
>>>>
>>>> Btw, we can easily connect with juniper to check with them.        We are finding a Cisco contact.
>>>>
>>>> I am tentatively thinking of setting up freertrs near Mumbai, Seattle and Warsaw to start with as we have servers there.        Let me think a bit as to what exactly we want to do.
>>>>
>>>> Let        s see if they get through first and then think about performance next.
>>>>
>>>> Thanks so much!
>>>> Nalini
>>>>
>>>>
>>>> Sent from Smallbiz Yahoo Mail for iPhone <https://overview.mail.yahoo.com/?.src="iOS>
>>>>
>>>> On Saturday, July 30, 2022, 3:12 PM, mc36 <> wrote:
>>>>
>>>>              ohh, and i forgot the results... attaching a telnet session performed between two freerouters,
>>>>              the one ending with :227 patched with the below very simple things:
>>>>
>>>>              <mailto:>:~$ diff ~/Documents/src/net/freertr/prt/prtTcp.java /nfs/own/web/src/src/net/freertr/prt/prtTcp.java
>>>>              571c571
>>>>              <                                            pck.IPalrt = 123;
>>>>              ---
>>>>                  >                                            pck.IPalrt = -1;
>>>>              626c626
>>>>              <                                                                    pck.IPalrt = 123;
>>>>              ---
>>>>                  >                                                                    pck.IPalrt = -1;
>>>>              <mailto:>:~$
>>>>
>>>>              you can see, that it's a healthy session, nothing strange, wireshark decodes it cleanly...
>>>>              and, they were several mpls hops away from each other, all the intermediate boxes running
>>>>              the below mentioned dpdk dataplane... if it was pure ip, the i dont say it would suffer,
>>>>              because it's a low volume traffic, but be would get rate limited, and forwarded in the
>>>>              java code instead of the dpdk code....
>>>>
>>>>              br,
>>>>              cs
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>              On 7/30/22 20:39, mc36 wrote:
>>>>                  > hi,
>>>>                  > interesting plans... well, i just performed some experiments and seemingly freerouter passes packets correctly with hbh option,
>>>>                  > regardless of it's contents... there is an exception, if, after finding the real layer4 protocol id, if that protocol is
>>>>                  > registered for the receiving interface, then it can do further processing on the packet, if it wants... right now, only the
>>>>                  > below mentioned rsvp and mdl are who do such things, everything else (tcp, udp, etc) passes does not cares at all:
>>>>                  > https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/prt/prtTcp.java#L1195
>>>>              <https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/prt/prtTcp.java#L1195>
>>>>                  > https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/prt/prtUdp.java#L307
>>>>              <https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/prt/prtUdp.java#L307>
>>>>                  > https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/ip/ipFwd.java#L1490
>>>>              <https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/ip/ipFwd.java#L1490>
>>>>                  > https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/ip/ipFwd.java#L2269
>>>>              <https://github.com/rare-freertr/freeRtr/blob/54c1194d70998433dc4d50e1f2394e1b139d4967/src/net/freertr/ip/ipFwd.java#L2269>
>>>>                  > but, there is a catch: right now we have some dataplanes, a dpdk based ones, an xdp/ebpf based, and the a based for for tofino asic..
>>>>                  > right now, all the dataplane handles these packets as exception packets, that is, after rate limiting, freerouter code will finally
>>>>                  > forward the packets... it have some consequences, most notably the real flow characteristics will significantly differ from the measured
>>>>                  > characteristics... even i can imagine that the real flow could be broken whereas the measured one goes through: for example if the dataplane
>>>>                  > programming fails somehow and an entry missing in one of the tables, but, if playing with the hbh option, it's an early catch and obviously
>>>>                  > does not use most of the output tables... imho the other already, deployed boxes will show similar or worse behaviors...
>>>>                  > regarding your plans to bring up a freerouter network and see it yourself, surely we're more than happy to help you if you have any questions...
>>>>                  > br,
>>>>                  > cs
>>>>                  >
>>>>                  >
>>>>                  >
>>>>                  >
>>>>                  >
>>>>                  > On 7/30/22 15:07, Nalini J Elkins wrote:
>>>>                  >> <https://datatracker.ietf.org/doc/html/draft-fear-ippm-mpdm-02 <https://datatracker.ietf.org/doc/html/draft-fear-ippm-mpdm-02>>Csaba,
>>>>                  >>
>>>>                  >> We are doing a        deep dive investigation into IPv6 Extension Headers.                    You may wish to watch our presentation at the IEPG on Sunday at:
>>>> IETF114-IEPG-20220724-1400
>>>>                  >> <https://www.youtube.com/watch?v=Pz6wIu1gaXE <https://www.youtube.com/watch?v=Pz6wIu1gaXE>>                                            Basically, our investigation shows that some of
>>>> the previous work may
>>>>              have drawn some inaccurate assumptions as to if extension
>>>>                  >> headers can be used on the public internet.                    This functionality is critical to the Internet at large.
>>>>                  >>
>>>>                  >> The draft we are currently working on is on an Encrypted Destination Option <https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/
>>>>              <https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/>>.                                            But, what we want to do is
>>>>                  >> to have FreeRtr support a HBH header.                                            Please see draft HERE < >.                                                        It is an expired draft and I want to make some
>>>> changes.                    But, you will get the idea.
>>>>                  >>
>>>>                  >> What I want to do is to set up a FreeRtr network across the public internet.                    We have servers already.                                            Is this work that you would be
>>>> interested to participate
>>>>              in?                                            If
>>>>                  >> so, we would love for you to be co-author on the draft / participant in presentations.
>>>>                  >>
>>>>                  >> Please let me know your thoughts.
>>>>                  >>
>>>>                  >> Thanks,
>>  >>                  >>
>>>>                  >> Nalini Elkins
>>>>                  >> CEO and Founder
>>>>                  >> Inside Products, Inc.
>>>>                  >> www.insidethestack.com
>>>>                  >> (831) 659-8360
>>>>                  >>
>>>>                  >>
>>>>                  >> On Friday, July 29, 2022 at 12:44:31 PM PDT, mc36 < <mailto:>> wrote:
>>>>                  >>
>>>>                  >>
>>>>                  >> hihi,
>>>>                  >> you're welcome, and i thank you for reaching out...
>>>>                  >> i bet you have some specific idea... could you please drop me the draft you're planning for?
>>>>                  >> thanks,
>>>>                  >> cs
>>>>                  >>
>>>>                  >>
>>>>                  >> On 7/29/22 20:23, Nalini J Elkins wrote:
>>>>                  >>        > Thanks!
>>>>                  >>        >
>>>>                  >>        > Let me look and I will be back to you on what we may need.
>>>>                  >>        >
>>>>                  >>        > I am at ietf and just going home.                    So it will take me a few days.
>>>>                  >>        >
>>>>                  >>        >
>>>>                  >>        > Sent from Smallbiz Yahoo Mail for iPhone <https://overview.mail.yahoo.com/?.src="iOS" <https://overview.mail.yahoo.com/?.src="iOS
>>>>                  ><https://overview.mail.yahoo.com/?.src="iOS" <https://overview.mail.yahoo.com/?.src="iOS>>>
>>>>                  >>        >
>>>>                  >>        > On Friday, July 29, 2022, 1:49 PM, mc36 < <mailto:> <mailto: <mailto:>>> wrote:
>>>>                  >>        >
>>>>                  >>        >                                                        hihi,
>>>>                  >>        >                                                        nice to meet you again!
>>>>                  >>        >                                                        well, something is there, but it depends what you need exactly...
>>>>                  >>        >                                                        on receiving, this happens:
>>>>                  >>        > https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120 >
>>>>                  >> <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120>>
>>>>                  >>        >                                                        <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120 >
>>>>                  >> <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L120>>>
>>>>                  >>        >                                                        on the sending side, this:
>>>>                  >>        > https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160 >
>>>>                  >> <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160>>
>>>>                  >>        >                                                        <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160 >
>>>>                  >> <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160
>>>>              <https://github.com/rare-freertr/freeRtr/blob/cb31f8a1671f0119082e174331bbdd83fb782963/src/net/freertr/ip/ipCor6.java#L160>>>
>>>>                  >>        >                                                        this is, as is for now, fine for igmp, rsvp over ipv6, and maybe other protocols to do the trick...
>>>>                  >>        >                                                        br,
>>>>                  >>        >                                                        cs
>>>>                  >>        >
>>>>                  >>        >
>>>>                  >>        >                                                        On 7/29/22 18:45, <mailto:> <mailto:
>>>>              <mailto:>> <mailto: <mailto:>
>>>>                  >> <mailto: <mailto:>>> wrote:
>>>>                  >>        >                                                                                            > Csaba,
>>>>                  >>        >                                                                                            >
>>>>                  >>        >                                                                                            > I believe we met at the IETF hackathon in Vienna.                                                                                            We are working
>>>> on IPv6 extension header testing.
>>>>                  >>        >                                                                                            >
>>>>                  >>        >                                                                                            > I would like to understand the support of IPv6 extension headers in
>>>> FreeRtr.                                                                                            Do you have it?
>>>>                  >>        >                                                                                            >
>>>>                  >>        >                                                                                            > If not, we would like to work with you to add it.
>>>>                  >>        >                                                                                            >
>>>>                  >>        >                                                                                            > Thanks,
>>>>                  >>        >                                                                                            >
>>>>                  >>        >                                                                                            > Nalini Elkins
>>>>                  >>        >                                                                                            > CEO and Founder
>>>>                  >>        >                                                                                            > Inside Products, Inc.
>>>>                  >>        >                                                                                            > www.insidethestack.com
>>>>                  >>        >                                                                                            > (831) 659-8360
>>>>                  >>        >
>>>>                  >
>>>>                  >
>>>>                  >                  >
>>>>                  >
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

 This message was secured by Zix&#174.

_._,_._,_

---

   Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#461) | | | Mute This Topic | New Topic
Your Subscription | | Unsubscribe []

_._,_._,_