rVRRPd - A new open source VRRPv2 daemon

[Nicolas Chabbey]

Hello,

I released the first major version of rVRRPd, an open source and
RFC3768-compliant VRRPv2 daemon. It actually only supports Linux but I
will soon be adding support for additional operating systems and platforms.

rVRRPd was born from my desire to develop skills in system development.
I also wanted to provide another open and secure implementation of a
FHRP to the network community.

Here's a summary of what rVRRPd (v0.1.0) is:
 - Implemented almost entirely in Rust
 - Interoperable with RFC3768 compliant devices
 - Support for RFC2338 simple password authentication
 - Support for additional proprietary authentication methods
 - Easily configurable using TOML
 - Multithreaded operations
 - Fast, secure and scalable

This implementation is aimed to be fast and secure, however please keep
in mind, it is still in its infancy. It is not yet ready for production
use but should be fairly stable.

I'm the only developer at this time, and my resources are limited.
However, I took the time to fuzz the latest version, and to do some
interoperability testing. So far, the results have been great.

Of course, I'm open to any suggestions and feedback. Anything that can
improve the project constructively is more than welcome. I am also open
to contributors.

You can find the latest development version of rVRRPd at
https://github.com/e3prom/rVRRPd

Regards



signature.asc
Description: OpenPGP digital signature

Re: Reddit down

[Nicolas Chabbey]

Maybe backend related?

I've a 503 here:
$ wget -X GET http://www.reddit.com/r/FedEx/
--2019-07-11 16:34:03--  http://www.reddit.com/r/FedEx/
Resolving www.reddit.com (www.reddit.com)... 151.101.121.140
Connecting to www.reddit.com (www.reddit.com)|151.101.121.140|:80...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.reddit.com/r/FedEx/ [following]
--2019-07-11 16:34:04--  https://www.reddit.com/r/FedEx/
Connecting to www.reddit.com (www.reddit.com)|151.101.121.140|:443...
connected.
HTTP request sent, awaiting response... 503 Service Unavailable:
Back-end server is at capacity
2019-07-11 16:34:04 ERROR 503: Service Unavailable: Back-end server is
at capacity.

Regards

On 11/07/2019 16:25, Mike Bolitho wrote:
> Working fine in Phoenix on Cox and CenturyLink.
> 
> -Mike Bolitho
> 
> On Thu, Jul 11, 2019, 7:16 AM Mark Tinka  > wrote:
> 
> Good for me at my house right now - Johannesburg.
> 
> Fastly are delivering...
> 
> MacBook-Pro-7:~ tinka$ traceroute -I www.reddit.com
> 
> traceroute to reddit.map.fastly.net 
> (151.101.173.140), 64 hops max, 72 byte packets
>  1  10.0.32.1 (10.0.32.1)  6.238 ms  5.571 ms  5.425 ms
>  2  ae-1-4.pr-01-jnb.za.seacomnet.com
>  (105.16.165.253)  6.902
> ms  3.966 ms  5.166 ms
>  3  ae-4-0.pp-01-jnb.za.seacomnet.com
>  (105.16.29.8)  5.466 ms 
> 6.375 ms  5.811 ms
>  4  fastly.ixp.joburg (196.60.8.13)  4.556 ms  5.220 ms  5.085 ms
>  5  151.101.173.140 (151.101.173.140)  4.846 ms  4.562 ms  5.395 ms
> MacBook-Pro-7:~ tinka$
> 
> Mark.
> 
> On 11/Jul/19 15:57, Robert Webb wrote:
>> I am getting, "Our CDN was unable to reach our servers".
>>
>> Looking at down detector, there are lots of folks reporting issues
>> and the Reddit status page has a high error rate...
>>
>> On Thu, Jul 11, 2019 at 9:55 AM Michael Morrison
>> mailto:michael.d.morri...@me.com>> wrote:
>>
>> Reddit main page loads for me in Columbus Ohio on a Level 3 loop.
>>
>> > On Jul 11, 2019, at 9:51 AM, Robert Webb
>> mailto:rwfireg...@gmail.com>> wrote:
>> >
>> > Are we having yet another CDN meltdown or is it isolated to
>> just reddit?
>>
> 

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Nicolas Chabbey]

Are there any good reasons of using proprietary FHRPs like HSRP and GLBP
over VRRP ?

I know that one reason may be interoperability with some vendors
equipment and old gears, but VRRPv3 is now widely used, in particular
for IPv6.

Also VRRP can be easily extended with proprietary extensions and looks
very similar to HSRP in its operation.

Regards.

On 04/08/2019 21:40, cyrus ramirez via NANOG wrote:
> If you're looking for vendor neutral FHRP, VRRP has RFC documentation.
> GLBP and HSRP are Cisco proprietary protocols and are protected
> information other than the study material and how too out there.
> 
> Cyrus
> 
> Sent from Yahoo Mail on Android
> 
> 
> On Sat, Aug 3, 2019 at 10:19 AM, Chriztoffer Hansen
>  wrote:
> 
> Saku Ytti wrote on 03/08/2019 15:49:
> > I don't think any work for GLBP exists in IETF.
> 
> A shot in the dark. Correct.
> 
> 
> https://www.google.com/#q=%28"GLBP"%7C"Gateway+Load+Balancing"+Protocol%7C"Global+Load+Balancing"+Protocol%29+AND+inurl%3Adatatracker+AND+inurl%3Aietf
> 
> (My IETF history is short. =I won't know any older history.)
> 
> ... I doubt any current or previous Cisco folks on the list would want
> to chirm in about history from inside Cisco on the GLBP topic...(?)
> 
> 
> -- 
> Best regards,
> Chriztoffer
> 

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Nicolas Chabbey]

Good point. I forgot about this one.

Apparently, you can have four active forwarders per group. The load is
balanced across them via the virtual MAC addresses.

I could implement something similar to my open VRRP implementation (I
wrote about it on the ML recently), but only if it's a wanted features.
I don't think it's overly complex to do, but of course it won't be
covered by any current RFCs.

Regards.

On 05/08/2019 19:55, Grant Taylor via NANOG wrote:
> On 8/5/19 9:19 AM, Nicolas Chabbey wrote:
>> Are there any good reasons of using proprietary FHRPs like HSRP and
>> GLBP over VRRP ?
> 
> I thought that GLBP had functionality that allowed both participants to
> be active/active.  I.e. you could cause ⅔ of traffic to go to one GLBP
> peer and the remaining ⅓ go to the other GLBP peer.
> 
> It's my understanding that neither HSRP nor VRRP support this
> active/active operation and that they are purely active/passive.
> 
> Sure, you can have multiple HSRP / VRRP IPs and spread the load via
> client configuration.  But that's outside of the scope of the protocols
> themselves.
> 
> Please correct me if I'm wrong.
> 
> 
> 

Re: [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)

[Nicolas Chabbey]

You can certainly add 'security' to the list.

I don't mean 'network security' here but 'information security' as a whole.

A lot of vendors (notably AV) uses of a lot of marketing terms and they
also play with the fears of people to sell their (insert revolutionary)
products/solutions.

Some of them could be rather useless in a security standpoint,
especially if not properly tuned and configured. It can bring a false
sense of security which is sometimes worst than a sense of security at all.

My two cent..

On 07/07/18 16:57, Marcus Leske wrote:
> open APIs tops that funny abuse list IMHO :
> https://github.com/OAI/OpenAPI-Specification/issues/568
> 
> can we change the topic of the thread to an informative one, instead
> of a leaked video or not, to why exactly do network engineers are
> often confused by the abusive marketing all over the place of what is
> open and what is not and other computing terms.
> 
> I guess this is happening in networking more often than other domains
> because networking people didnt get a chance in their career to learn
> about the world of computing, their heads were somewhere else,
> learning about  complex networking protocols and not the common
> computing interfaces, the open source world, existing  frameworks and
> paradigms, this video helps a bit on how did this happen:
> https://vimeo.com/262190505https://vimeo.com/262190505
> 
> has anyone here seen list of topics that network engineers usually
> miss on their journey ?  i know they never get exposed to software
> development and engineering in general, databases, web technologies,
> operating system fundamentals.
> 
> opinions ?
> 
> danke,
> markus
> 
> On Mon, Jul 2, 2018 at 12:25 PM, Matt Erculiani  wrote:
>> Unfortunately, like many other industry terms, "open" is becoming a
>> meaningless marketing buzzword much like "cloud", "converged", even
>> "redundancy" or any other technical term that has had its definition
>> diluted as time goes on. We're all well aware on the ISP side that it
>> only takes one Fortune 500 to start using a buzzword incorrectly, then
>> the rest of the big guys all the way to mom and pop shops around the
>> world start using it in the same context. Unfortunately I don't see
>> any end to this trend in sight.
>>
>>"...fingerprints is took, days is lost, bail is made, court
>> dates are ignored, cycle is repeated."
>> - Early Cuyler
>>
>> -Matt
>>
>> On Thu, Jun 28, 2018 at 11:29 AM, Tails Pipes  wrote:
>>> No, things changed there as well. Lookup merchant sillicon, and revise this
>>> post every 6 months. have you heard of Barefoot networks? The days of ASICs
>>> from Cisco are gone and we are glad, we tested the P4 DSL (cisco never got
>>> that right with mantel) on Nexus and its wonderful.
>>>
>>> The asics you speak of are no longer important or valuable because people
>>> realized that in many networking planets and galaxies, the asic is reflects
>>> the network design, they are related, and specifically for the data center,
>>> the clos fabric design won, and that does not require fancy asics.
>>> I guess your knowledge is out dated a bit. Cisco itself is using those
>>> merchant sillicon ASICs happily. (lookup Chuck's comments on nexus9000,
>>> best selling cisco switch ever)...guess it is a good switch, because bright
>>> box pushed cisco to do that, and if any one on this list can disagree with
>>> me here, i'm up to that challenge.
>>>
>>> What i have discovered recently is that things happen in following way.
>>>
>>> Your boss or his boss picks a work culture (no one gets fired for buying
>>> IBM/Cisco), that culture (buying the shiny suits) impacts how you do work,
>>> it makes you select vendors (the ones that sends me to vegas every year)
>>> and not the right network design, you select cisco and you are stuck there
>>> for life, because once they tell you how things should work (aka :
>>> certificates), things are worse, now every time you make a new network
>>> purchase (afraid of new CLI ), you will not be able to look the other way
>>> because you just dont know any thing else (and loosing your certificate
>>> value).
>>>
>>> I wish the culture would change to, no one got fired for buying closed but
>>> didnt get promoted either. change requires boldness.
>>>
>>> https://toolr.io/2018/06/18/stop-abusing-the-word-open/
>>>
>>>
>>>
>>> On Wed, Jun 27, 2018 at 9:41 AM,  wrote:
>>>
> Tails Pipes
> Sent: Friday, June 22, 2018 3:00 PM
>
> can you easily answer this question ? why packets are not pushed in
 linux ?
> is it because of big switch, cumulus, pica8 ?
>
> can you push packets in linux without writing code to do that ? who is
 writing
> that code ?
>
> this is supposedly a community effort, something that older generations
> dont understand.
>
 If pure linux as NOS has some legs it'll fly regardless of cisco blessing,
 don't worry no single company owns the whole industry.
 A

Re: 7206 VXR NPE-G1 throughput

[Nicolas Chabbey]

On 02/10/2014 04:30 PM, Remco Bressers wrote:

On 02/10/2014 04:17 PM, Vlade Ristevski wrote:

We are looking to double the bandwidth on one of our circuits from 300Mbps to 
600Mbps. We currently use a Cisco 7206VXR with an NPE-G1 card. These seem like 
very popular routers so I'm hoping a few
people on this list have them deployed. If you or a customer have these 
deployed, how much bandwidth have you seen them handle? This will be handling 
dorm traffic at a college so it's mostly download.
The 7206 handles our 300 Mbps circuit just fine, but we are moving it to our 
600Mbps circuit. At peak we've seen the following numbers for that circuit:


   30 second input rate 559982000 bits/sec, 55809 packets/sec
   30 second output rate 55429000 bits/sec, 32598 packets/sec
  267756984712 packets input, 25152556755 bytes, 0 no buffer

This is the interface that connects to our provider. As you can see its almost 
all download traffic. Our ASR1002 handles it without a sweat but I'm a little 
skeptical of whether the 7206 will hold up.


This depends on multiple variables. The 7200 is a single-CPU platform where CPU 
can go sky-high when using features like ACL's, QoS, IPv6 and you name it.. 
Also, changing from IOS 12.4 to 15 increased
our CPU usage with another 10%+. Stick to the bare minimum of features you 
really need and you will be fine.



I do share the same thoughts as Remco. We've actually several NPE-G1 in 
production environments with full BGP feed. We saw a decrease in 
forwarding performance since 12.4T and up. We also recently disabled 
some features like netflow and ip inspection, which seemed relatively 
CPU intensive.


I do remember we were able to forward around ~700Mbps of 1500 bytes 
traffic with old IOS images and no ACLs.

Re: Hurricane Electric packet loss

[Nicolas Chabbey]

Hello,

Did you notice the average RTT delay from the 5th hop and beyond? I'm 
not sure if you can trust the values according to the high packet loss, 
but it may indicate an additional problem (or MAY confirm your 
assumption about congestion).


On 07/22/2014 11:48 AM, Wolfgang Nagele (AusRegistry) wrote:

Hi,

We’ve been customers of Hurricane Electric for a number of years now and always 
been happy with their service.

In recent months packet loss on some of their major routes has become a very 
common (every few days) occurrence. Without knowledge of their network I am 
unsure what’s the cause of it but we’ve seen it on the Tokyo - US routes as 
well as the London - US routes. It reminds me of the Cogent expansion which was 
carried out by unsustainable oversubscription which eventually resulted in 
unusable service for a number of years. Having seen some of the rates that HE 
has been selling for I can’t help but wonder if they made the same mistake ...

Here is an example of what’s going on again atm.
HOST: prolocation01.ring.nlnog.ne Loss%   Snt   Last   Avg  Best  Wrst StDev
   1.|-- 2a00:d00:ff:136::253   0.0%110.3   0.3   0.3   0.4   0.0
   2.|-- 2a00:d00:1:12::1   0.0%100.7   0.8   0.7   1.1   0.1
   3.|-- hurricane-electric.nikhef  0.0%100.7   3.1   0.7   8.3   2.9
   4.|-- 100ge9-1.core1.lon2.he.ne  0.0%109.8  12.6   8.0  19.2   4.1
   5.|-- 100ge1-1.core1.nyc4.he.ne 10.0%10   74.7  74.6  73.7  80.8   2.3
   6.|-- 10ge10-3.core1.lax1.he.ne 30.0%10  133.4 138.0 133.4 145.1   4.8
   7.|-- 10ge1-3.core1.lax2.he.net 20.0%10  135.7 139.1 133.4 145.1   4.5
   8.|-- 2001:504:13::3b   40.0%10  143.2 143.1 142.1 144.4   0.8
   9.|-- 2402:7800:100:1::55   50.0%10  144.4 144.1 143.8 144.4   0.2
  10.|-- 2402:7800:0:1::f6 60.0%10  298.7 298.4 298.2 298.7   0.2
  11.|-- ge-0-1-4.cor02.syd03.nsw. 10.0%10  299.3 298.9 298.3 299.5   0.5
  12.|-- 2402:7800:0:2::18a20.0%10  299.7 299.4 298.9 300.1   0.4
  13.|-- 2001:dcd:12::10   30.0%10  299.8 299.5 298.8 300.0   0.5

Is anybody else observing this as well?

Cheers,
Wolfgang

Re: Hurricane Electric packet loss

[Nicolas Chabbey]

Forget about it. The delay are correct, my mistake. I should look more 
carefully.


I also been a regular customer of HE, and always been satisfied with 
their service, especially regarding the IPv6 transit.


On 07/22/2014 02:13 PM, Nicolas Chabbey wrote:

Hello,

Did you notice the average RTT delay from the 5th hop and beyond? I'm 
not sure if you can trust the values according to the high packet 
loss, but it may indicate an additional problem (or MAY confirm your 
assumption about congestion).


On 07/22/2014 11:48 AM, Wolfgang Nagele (AusRegistry) wrote:

Hi,

We’ve been customers of Hurricane Electric for a number of years now 
and always been happy with their service.


In recent months packet loss on some of their major routes has become 
a very common (every few days) occurrence. Without knowledge of their 
network I am unsure what’s the cause of it but we’ve seen it on the 
Tokyo - US routes as well as the London - US routes. It reminds me of 
the Cogent expansion which was carried out by unsustainable 
oversubscription which eventually resulted in unusable service for a 
number of years. Having seen some of the rates that HE has been 
selling for I can’t help but wonder if they made the same mistake ...


Here is an example of what’s going on again atm.
HOST: prolocation01.ring.nlnog.ne Loss%   Snt   Last   Avg Best  Wrst 
StDev
   1.|-- 2a00:d00:ff:136::253   0.0%110.3   0.3 0.3   
0.4   0.0
   2.|-- 2a00:d00:1:12::1   0.0%100.7   0.8 0.7   
1.1   0.1
   3.|-- hurricane-electric.nikhef  0.0%100.7   3.1 0.7   
8.3   2.9
   4.|-- 100ge9-1.core1.lon2.he.ne  0.0%109.8  12.6 8.0  
19.2   4.1
   5.|-- 100ge1-1.core1.nyc4.he.ne 10.0%10   74.7  74.6 73.7  
80.8   2.3
   6.|-- 10ge10-3.core1.lax1.he.ne 30.0%10  133.4 138.0 133.4 
145.1   4.8
   7.|-- 10ge1-3.core1.lax2.he.net 20.0%10  135.7 139.1 133.4 
145.1   4.5
   8.|-- 2001:504:13::3b   40.0%10  143.2 143.1 142.1 
144.4   0.8
   9.|-- 2402:7800:100:1::55   50.0%10  144.4 144.1 143.8 
144.4   0.2
  10.|-- 2402:7800:0:1::f6 60.0%10  298.7 298.4 298.2 
298.7   0.2
  11.|-- ge-0-1-4.cor02.syd03.nsw. 10.0%10  299.3 298.9 298.3 
299.5   0.5
  12.|-- 2402:7800:0:2::18a20.0%10  299.7 299.4 298.9 
300.1   0.4
  13.|-- 2001:dcd:12::10   30.0%10  299.8 299.5 298.8 
300.0   0.5


Is anybody else observing this as well?

Cheers,
Wolfgang