All,
I was able to find what I was looking for using the below 3 links on Juniper's
site.
Thanks again for taking the time to read the email
https://kb.juniper.net/InfoCenter/index?page=content=KB11615=METADATA
Knowledge Search - Juniper
I personally have never heard of it.
Sounds very PRish to me, what code are you running and have you checked the
Problem Report Search
From: juniper-nsp on behalf of Aaron
Gould
Sent: Wednesday, May 30, 2018 11:48 AM
To: juniper-nsp@puck.nether.net
Subject:
Hello all,
I was wondering the benefit of this command and I guess I need a couple of
questions answered by the brains out there.
1. If a hard-disk fails on a Juniper router (Dual RE) does the RE
automatically fail-over or will it continue to function as master
2. If it doesn't
Using different cluster-ids you end up with multiple copies of all the
prefixes but done correctly it works just fine and provides better
redundancy at the cost of higher "path" count.
If you are running single cluster-id and pushing router memory limits it
would be a bad idea.
If you have the
Please tell me if it's normal that I have to reboot a EX4550 (pair of them,
virtual chassis) to get it to forward, after enabling a routing-instance of
type vrf (aka mpls l3vpn)
Strange, after enabling igp (ospf), mpls, ldp, mp-ibgp and vrf/l3vpn, the l3vpn
control plane looked fine locally
Hi Adam,
> Op 30 mei 2018, om 10:56 heeft adamv0...@netconsultings.com het volgende
> geschreven:
>
>> Of Sander Steffann
>> Sent: Wednesday, May 30, 2018 9:36 AM
>>
>> Hi,
>>
>>> But in this scenario, a client will send an update both to RR1 and
>>> RR2, and RR1 will reflect this update to
> Of Sander Steffann
> Sent: Wednesday, May 30, 2018 9:36 AM
>
> Hi,
>
> > But in this scenario, a client will send an update both to RR1 and
> > RR2, and RR1 will reflect this update to RR2, and RR2 will reflect it
> > to RR1, and voila! We have a routing loop.
>
> The moment it loops back to
On 30/May/18 09:18, Alexander Marhold wrote:
> should reject updates based on the cluster-id attribute).
>
> NO, NO, NO this is the old way of doing redundant RRs
> Never do this as it can lead to missing routing updates if a client A is
> connected to RR-1 only and Client B connected to RR-2
> From: Victor Sudakov [mailto:v...@mpeks.tomsk.su]
> Sent: Wednesday, May 30, 2018 8:57 AM
>
> adamv0...@netconsultings.com wrote:
> > > Of Victor Sudakov
> > > Sent: Wednesday, May 30, 2018 8:07 AM
> > >
> > > Alan Gravett wrote:
> > > > A RR can also be a client with hierarchical RR's...
> > >
> From: Alexander Marhold [mailto:alexander.marh...@gmx.at]
> Sent: Wednesday, May 30, 2018 8:42 AM
>
> >Instead you should not even connect RR1 and RR2 together And treat RR
> >infrastructure built from RR1s I their respective clusters as
> a
> >separate infrastructure to RR2s.
> >This is the
Alexander Marhold wrote:
> >Instead you should not even connect RR1 and RR2 together
> >And treat RR infrastructure built from RR1s I their respective clusters as
> a
> >separate infrastructure to RR2s.
> >This is the proper way
>
> NO,NO,NO
> This was the proper way in 1995, but not actual
adamv0...@netconsultings.com wrote:
> > Of Victor Sudakov
> > Sent: Wednesday, May 30, 2018 8:07 AM
> >
> > Alan Gravett wrote:
> > > A RR can also be a client with hierarchical RR's...
> >
> > A hierarchy is irrelevant for this discussion. We are talking about how a
> RR
> > should
>Instead you should not even connect RR1 and RR2 together
>And treat RR infrastructure built from RR1s I their respective clusters as
a
>separate infrastructure to RR2s.
>This is the proper way
NO,NO,NO
This was the proper way in 1995, but not actual as...
(Unfortunately most BGP books have been
Alexander Marhold wrote:
> To further evaluate on that topic:
>
> The rule for a IBGP community is:
> IBGP learned routes are not allowed to forward to other IBGP neighbors
>
> The IBGP rules for an RR are:
> IBGP learned routes from a nonclient are allowed to be forwarded to all
> clients only
> Of Victor Sudakov
> Sent: Wednesday, May 30, 2018 8:07 AM
>
> Alan Gravett wrote:
> > A RR can also be a client with hierarchical RR's...
>
> A hierarchy is irrelevant for this discussion. We are talking about how a
RR
> should differentiate between
>
> 1. Its clients
>
> 2. Non-clients
>
>
> > However the RR concept is quite flexible, a RR itself can be a client of
> > another RR ( hierarchically or at peer level)
>
> No, I'm not talking about hierarchy. Let's consider a setup with two
> redundant RRs in the same cluster. They are certainly not each other's
> clients, but they must
> Of Alexander Marhold
> Sent: Wednesday, May 30, 2018 8:19 AM
>
> >3. Non-clients which are also RRs in the same cluster (from which you
> should reject updates based on the cluster-id attribute).
>
> NO, NO, NO this is the old way of doing redundant RRs Never do this as it
can
> lead to
>3. Non-clients which are also RRs in the same cluster (from which you
should reject updates based on the cluster-id attribute).
NO, NO, NO this is the old way of doing redundant RRs
Never do this as it can lead to missing routing updates if a client A is
connected to RR-1 only and Client B
* Olivier Benghozi [2018-05-29 18:38]:
> I guess you have an explicit match for those routes in your VRF
> export policy for the downstream VRF instance ?
I don't know what you mean by "explicit match" exactly, but we have an
vrf-export policy that matches these routes.
Regards
Sebastian
--
Alexander Marhold wrote:
> If you set the cluster-id for a group all configured neighbors are
> RR-clients
Fine. But how do I tell the RR that if it receives an update with its
own cluster-id from another router (not member of the group, e.g.
another RR in the same cluster), it should reject the
Alan Gravett wrote:
> A RR can also be a client with hierarchical RR's...
A hierarchy is irrelevant for this discussion. We are talking about
how a RR should differentiate between
1. Its clients
2. Non-clients
3. Non-clients which are also RRs in the same cluster (from which you
should
sth...@nethelp.no wrote:
> > I'm reading
> > https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-reflectors.html
> > and it is completely mind-boggling.
> >
> > The example configuration of the Router Reflector (RR) places all neighbors
> > (both clients and non-clients)
To further evaluate on that topic:
The rule for a IBGP community is:
IBGP learned routes are not allowed to forward to other IBGP neighbors
The IBGP rules for an RR are:
IBGP learned routes from a nonclient are allowed to be forwarded to all
clients only
IBGP learned routes from a client are
If you set the cluster-id for a group all configured neighbors are
RR-clients
So in your example all 4 neighbors including D and E are clients.
However the RR concept is quite flexible, a RR itself can be a client of
another RR ( hierarchically or at peer level)
Which means A can be the RR of D
> I'm reading
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-reflectors.html
> and it is completely mind-boggling.
>
> The example configuration of the Router Reflector (RR) places all neighbors
> (both clients and non-clients) into one group "internal-peers." How
25 matches
Mail list logo
