Hi In MX960, regarding command: set policy-options policy-statement ABC term EXPLICIT_DENY then reject, do you think the EXPLICIT_DENY need to define? why? I do not think it need to define. It could be any letters. Do you think so? Thank you
↧
Command--set policy-options policy-statement ABC term EXPLICIT_DENY then reject
↧
Re: Command--set policy-options policy-statement ABC term EXPLICIT_DENY then reject
In your policy statement EXPLICIT_DENY is simply the variable name for the term. you are correct that this could be any letters or a number. This is simply a name for that particular term.
See the complete syntax example here:
↧
↧
Re: NAT problem on MX
Did you reslove this issue? I am having the same problem on a mx80. Can you please share the solution?
↧
Anyone can explain command show route receive-protocol bgp ?
In MX960, bgp peer have not been configured yet. I got the output after typing command show route receive-protocol bgp. Please see the below
My question is as it does not show any routes there, why it shows 31 routes, 3035 routes and 5 routes? Thank you
JUNIPER> show route receive-protocol bgp 2021:4878:f0f:4002:f0:19:0:2
inet.0: 30 destinations, 31 routes (30 active, 0 holddown, 0 hidden)
WN.inet.0: 1517 destinations, 3035 routes (1516 active, 0 holddown, 12 hidden)
inet6.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
WN.inet6.0: 3007 destinations, 6497 routes (3097 active, 0 holddown, 0 hidden)
↧
Re: Anyone can explain command show route receive-protocol bgp ?
Hi,
"show route receive-protocol bgp" is normally the prefixes received from a BGP peer before any policies are processed and the routes are imported in the routing-table.
The figures displayed are the actual routes in the corresponding routing-tables.
"show route summary" would display the same figures.
Cheers,
Ashvin
↧
↧
Re: Anyone can explain command show route receive-protocol bgp ?
This output is saying that you are not receiving any routes from this peer.
As Ashvin notes, the numbers are just the total number of each type of route in that particular table as a whole. And the output shows that none of those routes are from this peer. This we would expect on the inet.0 tables as they are ipv4 and only inet6.0 tables would what routes from an ipv6 peer.
↧
Re: output error drop on Juniper M10i
Hi All,
I am having the same issue. These drops appear in a specific time and leave.
Any clue please ?
↧
Re: output error drop on Juniper M10i
Hi,
Can you check "show interfaces x/x/x extensive", looking at the queue counters for any dropped packets.
Drops could be due to CoS.
Cheers,
Ashvin
↧
Re: Command--set policy-options policy-statement ABC term EXPLICIT_DENY then reject
So, do you think what traffic the EXPLICIT_DENY represent ? Thank you
↧
↧
Different routing-instance interface in same router can communicate ?
Hi, Here is a question. Anyone can help to answer?
Here is a topology R1(ge-1/0) ------ (ge-1/1)R2(ge-1/2) ----- (ge-1/3)R3
R3 advertise bgp routes to R2. The interface ge-1/2 in R2 is routing-instance ABC, while ge-1/1 in R2 is routing-instance xyz. Do you think if it is possible for R2 to advertise the bgp routes to R1 through R2' ge-1/1? Thank you
↧
Re: Layer 2 VPN (VPLS) versus Layer 3 VPN (VPRN) -- packet content difference question
Hi,
You could probably look at some sample packet captures:
https://www.cloudshark.org/captures/001bc9d05587
https://www.cloudshark.org/captures/00f374aa6770?filter=arp
Those are for EoMPLS / L2VPN:
In L3VPN there would be no inner L2 headers [PW Ethernet control / Ethernet / VLAN etc]:
Cheers,
Ashvin
↧
Re: Different routing-instance interface in same router can communicate ?
Hi,
This can be possible by sharing the routes between ABC and xyz RI. rib-groups can be used for this.
To advertise a route to a BGP neighbor, that route needs to be present in that routing-table.
However, in doing so I don't really see the purpose of having 2 RIs, unless I missed something.
Cheers,
Ashvin
↧
Re: Community add
Hi,
The community add statement looks ok.
What issues were you facing? Were you seeing the expected route announced to the upstream?
Cheers,
Ashvin
↧
↧
Re: Command--set policy-options policy-statement ABC term EXPLICIT_DENY then reject
Can you paste the full config of the policy statement along with the config ,where you export this policy.
something like :
set protocols x export ABC
If explicity deny is the only term in the policy statement and if this is the only policy you apply under the protocol ,
it rejects all the routes.
What will be rejected depends on the placement of this particular policy statement.
↧
Re: Different routing-instance interface in same router can communicate ?
The current configuration in R2' ge-1/1 is routing-instance xyz. If we change it into routing-instance ABC, that would be easy for us to advertise that routes to R1. but we do not like to change so because it already has some traffic going there.
So how can can we share the routes between ABC and xyz RI? Can you send a link here? Thanks
↧
Re: Community add
Two corrections needed here
First if the traffic has to be blackholed from community x, why do you put then community add x as the routes are already coming with community x, it should be "from community x" instead of "then community add"
Second if you want to blackhole / RTBH, you shd be doing "from community x then reject" not accept
↧
Re: Different routing-instance interface in same router can communicate ?
There are two options to leak routes between VRF's:
1) auto export
2) Rib groups
Easiest one is auto export
Here is the link for the same:
http://www.juniper.net/techpubs/en_US/junos12.3/information-products/topic-collections/nce/auto-export-understanding/auto-export-understanding.pdf
Basically you have to add auto-export knob in both vrf under vrf x routing-options and also have a common route target
between both VPN's in addition to their own/native unique route targets.
You can export/import route targets via policy something like
VPNA {
instance-type vrf;
interface ge-4/0/1.35;
interface ge-2/1/1.70;
route-distinguisher 7777:1111;
vrf-import import-vpn-a
vrf-export export-vpn-a
routing-options {
auto-export
}
VPNB {
instance-type vrf;
interface ge-1/1/1.40;
interface ge-3/2/2.50;
route-distinguisher 7777:2222;
vrf-import import-vpn-b
vrf-import export-vpn-b
routing-options {
auto-export
}
VPN A route-target policy :
vrf import:
policy-options{
policy-statement import-vpn-a {
term 1 {
from {
protocol bgp ;
community vpn-a;
}
then {
accept;
}
}
}
community vpn-a member target:7777:1111;>>>>vpn-a native rt
community vpn-a member target:4:4;>>common rt for both vpn
vrf-export:
policy-options{
policy-statement export-vpn-a {
term 1 {
from {
protocol [bgp direct];
}
then
{
community add vpn-a;
}
}
}
VPN B route-target policy :
vrf import:
policy-options{
policy-statement import-vpn-b {
term 1 {
from {
protocol bgp ;
community vpn-b;
}
then {
accept;
}
}
}
community vpn-a member target:8888:2222;>>>>vpn-B native rt
community vpn-a member target:4:4;>>common rt for both vpn
vrf-export:
policy-options{
policy-statement export-vpn-b {
term 1 {
from {
protocol [bgp direct];
}
then
{
community add vpn-b;
}
}
}
↧
↧
Re: Different routing-instance interface in same router can communicate ?
Hi,
Both auto-export and rib-groups are possible if the instance-type is vrf.
If instance-type is virtual-router, I belive rib-group would be the only option.
Can you advise what is the instance-type of the RIs?
Cheers,
Ashvin
↧
Re: Community add
Hi,
For customer-triggerred RTBF, the prefix needs to be accepted, next-hop changed so that this destination address gets null routed / discarded. As per RFC5635 NO_EXPORT community should also be appended so that the prefix does not get announced to other neighbors.
However, in this scenario the intention is to specifically announce the RTBF prefix to the upstream as well with an RTBF community [provided by upstream] such that the upstream will also blackhole this destination address. This is quite effective in mitigating DoS/DDoS attacks. So, NO_EXPORT should not be applied.
Perhaps if we have some context we can understand better. Is AS123 the customer or the upstream?
Cheers,
Ashvin
↧
Re: Command--set policy-options policy-statement ABC term EXPLICIT_DENY then reject
set policy-options policy-statement ABC term EXPLICIT_DENY then reject
If this is only one term in a longer policy, (likely the last term) then all other routes not accepted by previous terms are rejected for either import or export depending on where the policy is applied.
If this is the ONLY line in the policy, then the system is probably using policy chains where you assign multiple policies in order for the peer import or export and each is simply executed in order. Then this policy is put as the last one in the chain to reject all routes not covered by a previous policy.
↧