It depends on which XRv image you use. The “free” image has a very limited
forwarding plane - it was really only meant for DevOps work
The licensed XRv9000 images work, I’m told, but as we’re only using them as RRs
I haven’t tested this myself
Regards,
Chris Jones
> On 9 May 2020, at 05:13, A
Using csr1000v in EVE-NG, yesterday I was able to do mp2mp vpls (rfc4761 bgp
ad, bgp sig) using (3) csr1000v routers and it all worked, control plane
*and* data plane, all CE's behind the csr1000v pe's could ping each other.
(i test rfc4762 bgp ad, ldp sig, but only with 2 csr1000v and it worked...
Hi,
On Fri, May 08, 2020 at 05:28:04PM +, Drew Weaver wrote:
> Plan right now is to create the port-channel interface on both ends,
> duplicate the configuration from the existing interface and then plug in the
> 2nd cable.
>
> I expect that spanning tree will block the port-channel and not
Hello,
Have an old C3560E that is uplinked to another switch using a single 10G
interface.
The existing uplink interface is a trunk port and it carries 40 VLANs.
I want to migrate it to use a port channel while avoiding downtime.
Plan right now is to create the port-channel interface on both e
On 8/May/20 12:48, Gert Doering wrote:
> If a broker doesn't know about that, I wouldn't use them.
>
> (I'm a bit picky anyway, because I tend to only trust people I've met
> and worked with for a while, and since there are two brokers among
> them that well understand RIR policies and all that
Hi,
On Fri, May 08, 2020 at 12:44:14PM +0200, Mark Tinka wrote:
> On 8/May/20 12:24, Gert Doering wrote:
>
> > This is why you use a broker who understands their trade to facilitate
> > the transfer. Ensure that such details are not overlooked.
>
> What are the chances these brokers know about
On 8/May/20 12:24, Gert Doering wrote:
>
> This is why you use a broker who understands their trade to facilitate
> the transfer. Ensure that such details are not overlooked.
What are the chances these brokers know about IPv6? And that's just the
basic requirement to graduate to RPKI, and DNSS
Hi,
On Fri, May 08, 2020 at 11:42:51AM +0200, Robert Raszuk wrote:
> See when you sign a block then sell this block without removing your RPKI
> signature, then the block gets cutted into chunks and sold further - and no
> one in this process of transaction chain cares about RPKI - this entire
> s
On 8/May/20 12:06, Alarig Le Lay wrote:
> Well… if your LIR isn’t careful enough to take care of RPKI, then change
> your LIR. And if the customer isn’t careful enough to verify the RPKI
> state of its prefixes, some bad things will happen, one day or an other.
> And this may not necessary invol
Lukas,
True. But I am actually not sure why RPKI state could not just expire by
itself say every 12 months unless renewed by the owner ? Just like DNS name
fee :)
Thx,
R.
On Fri, May 8, 2020 at 12:02 PM Lukas Tribus wrote:
> Hello Robert,
>
> On Fri, 8 May 2020 at 11:42, Robert Raszuk wrote
On 8/May/20 12:05, Mark Tinka wrote:
>
> One of the reasons you should now enable automatic ROA certification of
> longer prefixes, if you only really meant to sign the parent.
*not enable, I meant to say.
Mark.
___
cisco-nsp mailing list cisco-nsp
On Fri 08 May 2020 11:42:51 GMT, Robert Raszuk wrote:
> See when you sign a block then sell this block without removing your RPKI
> signature, then the block gets cutted into chunks and sold further - and no
> one in this process of transaction chain cares about RPKI - this entire
> story of using
On 8/May/20 11:42, Robert Raszuk wrote:
> Frankly this was ugly as quite unexpected - but relatively easy to see
> what is going on. In this space I am much more worried about RPKI db
> accuracy then any of the implementation issues. I found number of
> cases so far where what is in RPKI is just
Hello Robert,
On Fri, 8 May 2020 at 11:42, Robert Raszuk wrote:
> See when you sign a block then sell this block without removing your RPKI
> signature, then the block gets cutted into chunks and sold further - and no
> one in this process of transaction chain cares about RPKI - this entire
> sto
Yes your story how you found it is exactly as mine - with just one
exception that I was looking at my upstream ISPs across two ASBRs and
debugging what is going on :) But the core of the issue was precisely
identical !
Well I am still running it .. just enabled ext comms.
Frankly this was ugly as
On 8/May/20 11:23, Robert Raszuk wrote:
>
> But in what you pasted in I do not see statement that paths received
> over IBGP with no state information should be considered VALID. I
> think they just thought North - South then if you validate on ingress
> rest of the domain should assume the IBGP
Hi,
On Thu 07 May 2020 23:29:03 GMT, Pierre Emeriaud wrote:
> Yes, my fellow netadmin Alarig at as204092 just asked on bird's
> mailing list why didn't bird sent the extcommunity.
> https://bird.network.cz/pipermail/bird-users/2020-May/014559.html for
> the interested.
I had a patch to test and i
On 8/May/20 01:25, Robert Raszuk wrote:
> Well this is not a feature (even in Cisco land - it is a design bug).
> Just a few days ago I had a phone chat with a person who implemented
> origin validation in Cisco and he actually confirmed.
It's all mangled, but specifically, the part that Cisco
18 matches
Mail list logo
