Re: [j-nsp] EVPN on QFX5200

2019-09-19 Thread Liam Farr 
Hi,

I'm running VXLAN with ingress-node-replication in prod, can you
explain what you mean by havoc?

e.g.

show vlans

VLAN-NAME {

interface xe-0/0/2.2;

no-arp-suppression;

vxlan {

vni 561;

encapsulate-inner-vlan;

ingress-node-replication;

}

}

show interfaces xe-0/0/2

flexible-vlan-tagging;

mtu 9216;

encapsulation flexible-ethernet-services;

unit 2 {

encapsulation vlan-bridge;

vlan-id 2;

input-vlan-map pop;

output-vlan-map push;

}



Cheers

Liam

On Fri, 20 Sep 2019 at 08:49, Vincent Bernat  wrote:

>  ❦ 19 septembre 2019 16:25 -04, Andrey Kostin :
>
> > You can also try to use this scrips to generate configs for your
> > specific configuration:
> > https://github.com/JNPRAutomate/ansible-junos-evpn-vxlan/
>
> I would stay away from most of the random examples available on Internet
> (even ones from Juniper). For example, the above is using
> ingress-node-replication in the "vlan" directive. This will bring havoc
> in your network.
>
> Start with the following documentation which is correct:
>  <
> https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/sg-005-cloud-data-center.pdf
> >
>
> Also, be sure to read the following page to know the limitations:
>  <
> https://www.juniper.net/documentation/en_US/junos/topics/concept/vxlan-constraints-qfx-series.html
> >
>
> Notably, the QFX5200 is not able to route VXLANs.
> --
> Write clearly - don't sacrifice clarity for "efficiency".
> - The Elements of Programming Style (Kernighan & Plauger)
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


-- 
Kind Regards


Liam Farr

Maxum Data
+64-9-950-5302
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN on QFX5200

2019-09-19 Thread Vincent Bernat 
 ❦ 19 septembre 2019 16:25 -04, Andrey Kostin :

> You can also try to use this scrips to generate configs for your
> specific configuration:
> https://github.com/JNPRAutomate/ansible-junos-evpn-vxlan/

I would stay away from most of the random examples available on Internet
(even ones from Juniper). For example, the above is using
ingress-node-replication in the "vlan" directive. This will bring havoc
in your network.

Start with the following documentation which is correct:
 


Also, be sure to read the following page to know the limitations:
 


Notably, the QFX5200 is not able to route VXLANs.
-- 
Write clearly - don't sacrifice clarity for "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN on QFX5200

2019-09-19 Thread Andrey Kostin 

Hi Joe,

There are some documents on Junipers website describing principles and 
including configurations, like this:

https://www.juniper.net/us/en/training/jnbooks/day-one/data-center-technologies/data-center-deployment-evpn-vxlan/

Some parameters can vary, so it depends on what your requirements are.

You can also try to use this scrips to generate configs for your 
specific configuration:

https://github.com/JNPRAutomate/ansible-junos-evpn-vxlan/

Kind regards,
Andrey

Joe Freeman писал 2019-09-16 15:52:
Does anyone have a working example for EVPN configuration on the QFX 
5200's

that they'd be willing to share?

I've got four 5200's split between two DC's with 2x100G links between 
each

pair in a mesh. I'd like to run EVPN on them such that my network
infrastructure between the sites is transparent to the servers.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread john heasley 
Thu, Sep 19, 2019 at 06:42:58PM +0300, Saku Ytti:
> Quite, so I guess to be eligible for update group junos has two
> constraints and ios has one, junos constraints are same egress-policy
> and same peer-group, ios constraints same egress-policy. I can
> understand thne rationale to both, junos rationale makes sense in a
> context where you want to force update-group separation when you know
> the two sets are not guaranteed to have the same policy every time.

And, why wouldn't you want that control?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Saku Ytti 
On Thu, 19 Sep 2019 at 18:36,  wrote:

> In cisco these should be under common update group

This is a fair point. I've not tried to create unique peer-groups with
non-unique policies so this has escaped me.

> What is dynamic is that the peer 192.0.2.41 will be kicked out of group 11 if 
> configured with different export policy
> And reset in that process unfortunately

Quite, so I guess to be eligible for update group junos has two
constraints and ios has one, junos constraints are same egress-policy
and same peer-group, ios constraints same egress-policy. I can
understand thne rationale to both, junos rationale makes sense in a
context where you want to force update-group separation when you know
the two sets are not guaranteed to have the same policy every time.

Of course the ideal solution would be to never reset and use as few
update groups as theoretically possible. But for me as an operator,
both behaviour are good enough and don't really bite operationally, as
I can design configuration around it.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread adamv0025 
> From: Saku Ytti 
> Sent: Thursday, September 19, 2019 2:42 PM
> 
> On Thu, 19 Sep 2019 at 16:29,  wrote:
> 
> > The dynamic in Cisco implementation means that peers are automatically
> placed to update groups based on commonalities in export policies,
> regardless of the configuration.
> > In juniper case you can actually have two peers with exact same export
> policies be part of different update groups just because they have been
> configured that way -which is inefficient, but who cares throw more CPU at it
> and you're done -real operational problem is the meaningless peer reset.
> 
> I'm not sure I've seen this, but I'm ready to accept it to be true, but seems
> like something that could get PR and get fixed. Do you have a particular
> example where neighbours which will export the same set of routes and
> have same behaviour get separate update-groups?
> 
+group test-group1 {
+type external;
+family inet {
+unicast;
+}
+peer-as 65000;
+neighbor 192.0.2.10;
+}
+group test-group2 {
+type external;
+family inet {
+unicast;
+}
+peer-as 65000;
+neighbor 192.0.2.20;
+}
+group test-group3 {
+type internal;
+family inet {
+unicast;
+}
+neighbor 192.0.2.30;
+}
+group test-group4 {
+type internal;
+family inet {
+unicast;
+}
+neighbor 192.0.2.40
+neighbor 192.0.2.41;
+}

Group Type: External   Local AS: 31655
  Name: test-group1 Index: 8   Flags: <>
  Holdtime: 0
  Total peers: 1Established: 0
  192.0.2.10

Group Type: External   Local AS: 31655
  Name: test-group2 Index: 9   Flags: <>
  Holdtime: 0
  Total peers: 1Established: 0
  192.0.2.20

Group Type: InternalAS: 31655  Local AS: 31655
  Name: test-group3 Index: 10  Flags: <>
  Holdtime: 0
  Total peers: 1Established: 0
  192.0.2.30

Group Type: InternalAS: 31655  Local AS: 31655
  Name: test-group4 Index: 11  Flags: <>
  Holdtime: 0   
  Total peers: 2Established: 0  
  192.0.2.40
  192.0.2.41

In cisco these should be under common update group

What is dynamic is that the peer 192.0.2.41 will be kicked out of group 11 if 
configured with different export policy
And reset in that process unfortunately

set protocols bgp group test-group4 neighbor 192.0.2.41 export INTERNET_EX

Group Type: InternalAS: 31655  Local AS: 31655
  Name: test-group4 Index: 12  Flags: <>
  Export: [ INTERNET_EX ]   
  Holdtime: 0   
  Total peers: 1Established: 0  
  192.0.2.41



> > True but the argument can go both ways -in case of common memory
> space there's no protection so one needs to worry about leaking into
> different parts of memory.
> 
> Yes, the whole house of cards effect, which is very relevant in multitenant
> time-shared systems like Linux server, just because sshd crashes doesn't
> mean httpd should suffer. But I'm not sure if it's so important in router.
> 
> > Hmm, but we wouldn’t second guess this multi-process approach for
> desktop/mobile operating systems right?
> 
> They are much less controlled system, you install nillywilly random
> applications to your phone, and it's not good if phone crashes just because
> some background app I already forgot crashed. And servers have multiple
> tenants. I think in most cases routers have very different profile, vendor
> knows exactly what is running there and it's exactly one use-case.
> Note I'm not saying multiprocess is worse than monolithic, I'm just saying, 
> it's
> not obvious to me multiprocess is the superior in this use-case. Certainly C
> has exuberated the problem as it makes it too easy to write memory unsafe
> code, but considering how long lived NOS are, I think every NOS should be
> written in its own DSL which compiles to C++ or Rust. Then you have more
> choices where given problem is best solved.
> 
> Like forwarding code, should we write it in C or P4 which compiles to
> whatever language the NPU can consume? Less capable developers will be
> able to  write good code in P4 and can communicate to the smaller set of
> developers who write the P4 compiler about missing features. And if the P4
> compiler developer notices some nasty hacks the P4 coders need to write to
> solve some problem they can move the solution to the compiler and have
> the P4 coders write something less hacky.
> I think DSL as an abstraction is justified in any complex long lived project.
> 
Your point on all or nothing and single use-case nature of NOSes is certainly 
interesting. I'll

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Robert Raszuk 
>
> > Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups
> in Junos.
>
> They are dynamic, but once you make export change which affects subset
> of members in peer-group, that member gets reset while placed to new
> update-group.


And that is how dynamic update groups works by design. They automatically
group peers based on their export policy configuration.

To reset or not reset the peers really depends on the nature of the policy
change. In some cases clear soft out or in will do just fine without
bringing down the session. Of course if you enable soft reconfig in and
policy is just a new import filter no reset of the peer is required if OS
still does it they can fix it easily.

R.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Saku Ytti 
On Thu, 19 Sep 2019 at 16:29,  wrote:

> The dynamic in Cisco implementation means that peers are automatically placed 
> to update groups based on commonalities in export policies, regardless of the 
> configuration.
> In juniper case you can actually have two peers with exact same export 
> policies be part of different update groups just because they have been 
> configured that way -which is inefficient, but who cares throw more CPU at it 
> and you're done -real operational problem is the meaningless peer reset.

I'm not sure I've seen this, but I'm ready to accept it to be true,
but seems like something that could get PR and get fixed. Do you have
a particular example where neighbours which will export the same set
of routes and have same behaviour get separate update-groups?

> True but the argument can go both ways -in case of common memory space 
> there's no protection so one needs to worry about leaking into different 
> parts of memory.

Yes, the whole house of cards effect, which is very relevant in
multitenant time-shared systems like Linux server, just because sshd
crashes doesn't mean httpd should suffer. But I'm not sure if it's so
important in router.

> Hmm, but we wouldn’t second guess this multi-process approach for 
> desktop/mobile operating systems right?

They are much less controlled system, you install nillywilly random
applications to your phone, and it's not good if phone crashes just
because some background app I already forgot crashed. And servers have
multiple tenants. I think in most cases routers have very different
profile, vendor knows exactly what is running there and it's exactly
one use-case.
Note I'm not saying multiprocess is worse than monolithic, I'm just
saying, it's not obvious to me multiprocess is the superior in this
use-case. Certainly C has exuberated the problem as it makes it too
easy to write memory unsafe code, but considering how long lived NOS
are, I think every NOS should be written in its own DSL which compiles
to C++ or Rust. Then you have more choices where given problem is best
solved.

Like forwarding code, should we write it in C or P4 which compiles to
whatever language the NPU can consume? Less capable developers will be
able to  write good code in P4 and can communicate to the smaller set
of developers who write the P4 compiler about missing features. And if
the P4 compiler developer notices some nasty hacks the P4 coders need
to write to solve some problem they can move the solution to the
compiler and have the P4 coders write something less hacky.
I think DSL as an abstraction is justified in any complex long lived project.


-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread adamv0025 
> From: Saku Ytti 
> Sent: Thursday, September 19, 2019 1:32 PM
> 
> On Thu, 19 Sep 2019 at 15:11,  wrote:
> 
> > Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in
> Junos.
> 
> They are dynamic, but once you make export change which affects subset of
> members in peer-group, that member gets reset while placed to new
> update-group.
> 
The dynamic in Cisco implementation means that peers are automatically placed 
to update groups based on commonalities in export policies, regardless of the 
configuration.
In juniper case you can actually have two peers with exact same export policies 
be part of different update groups just because they have been configured that 
way -which is inefficient, but who cares throw more CPU at it and you're done 
-real operational problem is the meaningless peer reset.   

> > Right this inconsistency between configured and operational state in my
> opinion is THE biggest problem of XR, I'm afraid it has to be something
> fundamental since they haven't been able to consistently address these
> inconsistencies across the board for years now (or ASR9k HW? Not sure if
> these types of issues can be experienced on other platforms).
> 
> It is fundamental with non-monolithic design, because processA has no
> access to the memory of processB you need IPC, which for many things is too
> slow, so you replicate state and sync the state, which increases complexity
> and adds bugs.
True but the argument can go both ways -in case of common memory space there's 
no protection so one needs to worry about leaking into different parts of 
memory.
 
> The argument  against monolithic design is that single component failure will
> bring the whole house of cards down. I think this is debatable, if it's BGP or
> ISIS or LDP or oror which fails, my whole system is dead anyhow, router isn't
> multiservice multitenant in most cases, all pieces are needed and any piece
> failure is total failure.
> 
Touche, you're right in routers for control plane functions is mostly all or 
nothing.
Management plane is different, but that one is separate in both Junos and XR.

Then there's the flexibility aspect, for example being able to run multiple 
completely separate instances of BGP would be useful in some cases.  

> Hopefully Juniper avoids the pitfalls with Evolved, I'm not sure how.
> It seems like a complex problem to me. Having own DSL which compiles with
> many safety guarantees, to tune of rust, perhaps monolithic design is what
> you want, perhaps using the kernel facilities for multiprocess isn't the right
> solution, I don't think it's axiomatically true multiprocess is right 
> solution.
> 
Hmm, but we wouldn’t second guess this multi-process approach for 
desktop/mobile operating systems right?

adam 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Saku Ytti 
On Thu, 19 Sep 2019 at 15:11,  wrote:

> Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in 
> Junos.

They are dynamic, but once you make export change which affects subset
of members in peer-group, that member gets reset while placed to new
update-group.

> Right this inconsistency between configured and operational state in my 
> opinion is THE biggest problem of XR, I'm afraid it has to be something 
> fundamental since they haven't been able to consistently address these 
> inconsistencies across the board for years now (or ASR9k HW? Not sure if 
> these types of issues can be experienced on other platforms).

It is fundamental with non-monolithic design, because processA has no
access to the memory of processB you need IPC, which for many things
is too slow, so you replicate state and sync the state, which
increases complexity and adds bugs.
The argument  against monolithic design is that single component
failure will bring the whole house of cards down. I think this is
debatable, if it's BGP or ISIS or LDP or oror which fails, my whole
system is dead anyhow, router isn't multiservice multitenant in most
cases, all pieces are needed and any piece failure is total failure.

Hopefully Juniper avoids the pitfalls with Evolved, I'm not sure how.
It seems like a complex problem to me. Having own DSL which compiles
with many safety guarantees, to tune of rust, perhaps monolithic
design is what you want, perhaps using the kernel facilities for
multiprocess isn't the right solution, I don't think it's
axiomatically true multiprocess is right solution.



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread adamv0025 
> From: Saku Ytti 
> Sent: Thursday, September 19, 2019 12:33 PM
> 
> On Thu, 19 Sep 2019 at 14:22,  wrote:
> 
> > Just a few examples when you change export policy it resets the peer
> > or the cockup with RR clearing all sessions or the fact BGP is part of
> > very complex RDP monolith -to me that's not really "carrier grade"
> > implementation
> 
> This happens when export policy breaks update-group. It may sometimes be
> difficult for operator to understand if it will do that or not, so it's fair 
> concern.
> Perhaps system should not clear, but tell manual clear is needed for policy
> change to take effect.
> 
Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in 
Junos.

> If monolith is good or bad, I'm not sure. If you thread you have high
> performance with some risk. If you have process separation you have IPC
> problem, and you have low performance and many will solve this by
> duplicating state. Junos is moving towards multi process model with Junos
> Evolved, if this will be positive or negative direction remains to be seen.
>
I like where XR and Junos Evolved is heading, 
In future I'd like to have the option to install only stuff I need on a 
particular type of node/deployment and not worry about the rest all the way to 
being able to mix and match protocols of different vendors.  
Although cRPD is also interesting development pathway, but again cBGP would be 
even better :) 
 
> Operationally speaking, BGP in JunOS for us works great, on IOS-XR right now
> we have sessions where policy isn't what is configured and there is no way to
> verify which one, and we've propagated leaks because acting configuration
> isn't the one we've configured. We've not had similar problems in JunOS. This
> is anecdote, not data.
> 
Right this inconsistency between configured and operational state in my opinion 
is THE biggest problem of XR, I'm afraid it has to be something fundamental 
since they haven't been able to consistently address these inconsistencies 
across the board for years now (or ASR9k HW? Not sure if these types of issues 
can be experienced on other platforms).
Though usually it's CP state does not trickle down to DP correctly/completely 
where what you described seems to be CP only. 
 
adam

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Saku Ytti 
On Thu, 19 Sep 2019 at 14:22,  wrote:

> Just a few examples when you change export policy it resets the peer or the 
> cockup with RR clearing all sessions or the fact BGP is part of very complex 
> RDP monolith -to me that's not really "carrier grade" implementation

This happens when export policy breaks update-group. It may sometimes
be difficult for operator to understand if it will do that or not, so
it's fair concern. Perhaps system should not clear, but tell manual
clear is needed for policy change to take effect.

If monolith is good or bad, I'm not sure. If you thread you have high
performance with some risk. If you have process separation you have
IPC problem, and you have low performance and many will solve this by
duplicating state. Junos is moving towards multi process model with
Junos Evolved, if this will be positive or negative direction remains
to be seen.

Operationally speaking, BGP in JunOS for us works great, on IOS-XR
right now we have sessions where policy isn't what is configured and
there is no way to verify which one, and we've propagated leaks
because acting configuration isn't the one we've configured. We've not
had similar problems in JunOS. This is anecdote, not data.



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread adamv0025 
> Phil Reilly
> Sent: Thursday, September 19, 2019 6:05 AM
> 
> the BGP functionality and extensions are well
> developed in JUNOS. 
Ha... :)
Just a few examples when you change export policy it resets the peer or the 
cockup with RR clearing all sessions or the fact BGP is part of very complex 
RDP monolith -to me that's not really "carrier grade" implementation 

adam

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Elmar K. Bins 
g...@greenie.muc.de (Gert Doering) wrote:

> And given the price point of the MX204, if the amount of interfaces is
> sufficient, just get two of them :-)

Alternatively, just add QFXn as satellites.

El El
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Saku Ytti 
On Thu, 19 Sep 2019 at 01:52, Jason Lixfeld  wrote:

> Don’t get me wrong, Cisco definitely owns their share of BS, but they seem to 
> be predictable in how they are going to screw you.  Juniper will screw you, 
> but how they are going to screw you seems to be predictably unpredictable.

I have to say this is entirely subjective and my subjective experience
is rather different. But it is to be expected, if we would have very
homogenous view on which vendor is superior, competing vendors would
disappear.

My subjective views where JNPR shines compared to market

a) model driven configuration since day1, this is a big thing, much
bigger than YANG or Netconf or whatever other automation hype is going
on. Junos doesn't actively resist automation.
b) Trio is the only platform I know how to protect control-plane so
that I don't know how to break it
c) very debuggable (CSCO is good too here, this is more complaint to
Other Options).
d) I will echo your sentiment about complexity and agree to it, junos
gives a lot of power to the operator, where CSCO might have some
specific feature they support, have a name for, and have single line
config, JNPR doesn't have anything, because the feature has always
been possible due to the inherent flexibility and expressiveness of
the system. Some particular examples, BGP GTSM, VRF source selection,
egress-acl-at-ingress, there are plenty of examples in this, but can
be very involved to get right.

I don't have any dislike for CSCO, I'm sure you can support your
business case with both vendors, or Nokia or Huawei. Subjectively for
SP role, I think Nokia and Huawei have best port/chassis options. I
think Juniper has best NPU and best NOS on the market. For SP role
particularly, from the big names, today I think CSCO has least
attractive portfolio, but this is normal timing related thing, at some
point any vendor is behind, once they release some new generation
stuff they'll move ahead and start regressing. I believe ANET has best
practices in developing software and considering how young they are on
SP market, it's quite impressive where they are.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

2019-09-19 Thread Gert Doering 
Hi,

On Thu, Sep 19, 2019 at 05:04:54PM +1200, Phil Reilly wrote:
> MX104's are the dual brain unit of the 204. Though a 204 has 40/100G 
> capabilities. If I read your original request correctly about ip 
> routing. Not sure the 104/204 is grunty enough to deal with multiple 
> internet tables. Thats a demanding task these days best left to the 
> larger chassis.

You can't really compare MX104 to MX204.  

The MX104 is ppc based and *slow*, and should have never ever shipped.

The MX204 is a really really nice box, with a fast intel RE and 40/100G
ports (though some - documented - restrictions on how they can be combined),
and from a RE/BGP point of view, en par with the larger MXes.

And given the price point of the MX204, if the amount of interfaces is
sufficient, just get two of them :-)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp