❦ 17 février 2016 21:07 GMT, Alexander Arseniev :
> True, one cannot match on "next-hop" in "condition", only on exact
> prefix+table name.
> But this can be done using "route isolation" approach.
> So, the overall approach is:
> 1/ create a separate table and leak a 0/0 route there matching on
❦ 17 février 2016 22:56 GMT, Adam Vitkovsky :
>> Being a bit unsatisfied with a pair of MX104 turning themselves as a
>> blackhole
>> during BGP convergence, I am trying to reduce the size of the FIB.
>>
> You mentioned earlier that this is a new installation so why not use
> routing instance f
❦ 17 février 2016 21:07 GMT, Alexander Arseniev :
>> If the condition system would allow me to match a next-hop or an
>> interface in addition to a route, I could do:
>>
>> 3. Reject any route with upstream as next-hop if there is a default
>> route to upstream.
>>
>> 4. Reject any rout
❦ 17 février 2016 15:18 -0500, Chuck Anderson :
>> Being a bit unsatisfied with a pair of MX104 turning themselves as a
>> blackhole during BGP convergence, I am trying to reduce the size of the
>> FIB.
>>
>> I am in a simple situation: one upstream on each router, an iBGP session
>> between th
Hey!
Being a bit unsatisfied with a pair of MX104 turning themselves as a
blackhole during BGP convergence, I am trying to reduce the size of the
FIB.
I am in a simple situation: one upstream on each router, an iBGP session
between the two routers. I am also receiving a default route along the
fu
oblem but disabling damping made
this problem disappear entirely.
--
She is not refined. She is not unrefined. She keeps a parrot.
-- Mark Twain
――― Original Message ―――
From: Vincent Bernat
Sent: 3 février 2016 22:21 +0100
Subject: [j-nsp] Slow performance of th
❦ 5 février 2016 18:25 +0100, Raphael Mazelier :
> Hey vincent,
>
> Good to see you on the list :)
Hey Raphael!
Is there some way to not advertise the default route in OSPF during the
convergence time? Like a criteria: don't advertise this route when the
KRT queue has 1000+ ele
Hey!
I have a pair of MX104. Each one is receiving a full view and a default
through an external BGP session. They share an iBGP session. They
redistribute the default in OSPF (with a higher metric when the default
comes through the iBGP session). Nothing fancy.
If I shut the upstream port of one
❦ 26 janvier 2016 18:15 +0100, "Alexander Marhold" :
> We want to have an aggregate only announced when the VRRP vip route is
> active on the local BGP speaker
I had the exact same problem. I solved by using a conditional route instead.
policy-options {
policy-statement v4-PRIVATE-2-BGP {
❦ 25 janvier 2016 13:33 -0500, Chuck Anderson :
> There are two ways to do bridge-domains and vlan trunks on MX. The
> old way uses separate units for each VLAN. The new way uses a single
> unit 0 with all vlans in a family bridge. Try doing it the "old" way,
> pre-"family bridge interface-mo
❦ 25 janvier 2016 11:03 -0500, "Tim St. Pierre" :
> I'm pretty sure you have to add the interfaces to the bridge domains:
>
> vlan-200 {
> domain-type bridge;
> vlan-id 200;
> routing-interface irb.2;
> ++ interface xe-0/0/2.0;
> }
>
> We use a similar setup on MX, and it works wel
❦ 25 janvier 2016 16:34 +0100, Vincent Bernat :
> Now, I would like to be able to also use L3 subinterfaces on
> xe-2/0/2. So, I added "flexible-vlan-tagging" (but I think this is
> useless) and "encapsulation flexible-ethernet-services"
>
> #v+
> flexible-
Hey!
Currently, I am using an IRB interface on a MX104:
For example, on xe-2/0/2, I have:
#v+
vlan-tagging;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 200 300 ];
}
}
#v-
I have this bridge domain:
#v+
vlan-200 {
domain-type bridge;
vlan-id 200
101 - 113 of 113 matches
Mail list logo
