Hello,
I have 2 routers that have the same issue, LOG-1 from the first router and LOG-2 from the second router.
Please have a view
Thank you
Ernest
↧
Re: DCHP on VRF doesnt work properly
↧
Re: DCHP on VRF doesnt work properly
Hi Ernest,
Only DHCP logs were enabled.
Client is failing due to license issue. Please find the below error log.
Nov 27 20:39:16.719056 DH_SVC_AUTHENTICATE_LICENSE: Authentication failed due to license error. Total license failures 6153
Nov 27 20:41:13.982914 DH_SVC_AUTHENTICATE_LICENSE: Authentication failed due to license error. Total license failures 6163
Regards,
Rahul
↧
↧
Re: DCHP on VRF doesnt work properly
nestiern wrote:_______________________________________________________________
-->show system license
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
subscriber-address-assignment 1 0 1 invalid
subscriber-address-assignment license in invalid state , this means that trial period is expired , so now you should buy license
↧
Gre tunnel max throughput MX Series
Hi everyone,
Does anyone happen to know what the max throughput would be on gre tunnels for an MX series device?
Thanks!
↧
Re: Gre tunnel max throughput MX Series
It is line rate. Only limitation is to number of tunnels, but you can use filter to de/encapsulate traffic
↧
↧
Routing through MPLS Network - VRF?
Hi,
After a user has entered a network via L2TP and PPP, am I right in thinking that the best method of getting that user across an MPLS backbone ISP is via VRF's? If it is then could someone please show me an example of this?
Thanks
↧
Re: Routing through MPLS Network - VRF?
Hi Clive,
All you need is to create the loopback and address-assignment under the VRF.
You can use radius-attribute “ERX-Virtual-Router-Name := "TEST" or you can use predefined variable.
LNS# show dynamic-profiles TEST
predefined-variable-defaults {
routing-instances TEST;
}
LNS# dynamic-profiles TEST
routing-instances {
"$junos-routing-instance" {
interface "$junos-interface-name";
}
}
LNS# show routing-instances TEST
instance-type vrf;
interface lo0.4;
vrf-target target:X:X;
access {
address-assignment {
pool LAB {
family inet {
network 10.0.0.0/22;
}
}
}
}
Regards,
Rahul
↧
Re: Routing through MPLS Network - VRF?
Hi Rahul,
Thank you.... much appreciated
Thanks
Clive
↧
Policy Statement
Hello,
I am new to using Junos!
I am trying to learn how to use the policy to send routes into routing protocols.
root> show configuration policy-options
policy-statement Test {
term 1 {
from {
route-filter 2.2.2.2/32 address-mask 255.255.255.0;
}
then accept;
}
}
---------------------------------------------------------
root> show configuration protocols bgp
export Test;
group test {
neighbor 1.1.1.1 {
peer-as 100;
}
}
I expected this policy to match just the IP 2.2.2.2 with a mask /24. But this one matches other IP as well. I am wondering how this is working.
root> show interfaces terse | match lo0.0 lo0.0 up up inet 2.2.2.3/24
Peer device:
root> show route protocol bgp
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2.2.2.3/32 *[BGP/170] 00:06:49, localpref 100
AS path: 200 I> to 1.1.1.2 via em0.0
root>
↧
↧
Re: Policy Statement
which route exactly u want to export?
if u just want to export 2.2.2.2/32 then write following statement..
route-filter 2.2.2.2/32 exact;
If you want to export route with 2.2.2.2/24 then you may use following statement in policy options.
route-filter 2.2 2.0/24 exact;
↧
Re: Policy Statement
Hello Milind,
Thanks for the reply.
Can you please tell me what does this match 'route-filter 2.2.2.2/32 address-mask 255.255.255.0'? I was under the impression that it would match the host 2.2.2.2 with a /24 mask.
Thanks for the reply.
Can you please tell me what does this match 'route-filter 2.2.2.2/32 address-mask 255.255.255.0'? I was under the impression that it would match the host 2.2.2.2 with a /24 mask.
↧
How to Filtering the syslog flooding ?
HI all,
Can someone guide me how to filter the log messages as per below that flooding the firewall. I'm try do config as per below but cannot work. Appreciate some advise.
{primary:node1}
FW02> show configuration system syslog
archive size 1m files 10;
user * {
any emergency;
}
host x.x.x.x {
any any;
change-log any;
interactive-commands any;
inactive: match RT_FLOW_SESSION;
port 516;
structured-data;
}
host x.x.x.x {
any any;
change-log any;
interactive-commands any;
inactive: match RT_FLOW_SESSION;
port 516;
structured-data;
}
file messages {
any notice;
authorization info;
explicit-priority;
}
file filter-log {
any notice;
match "!(.*Mosquitto.*)";
explicit-priority;
}
GKD-re[4608]: %DAEMON-5: 2017-12-01 08:45:00.321485 ERROR Failed to connect to message broker: No route to host.
Dec 1 08:45:00.321 2017 FW01 GKD-re[4608]: %DAEMON-5: 2017-12-01 08:45:00.321525 INFO Mosquitto error The client is not currently connected. (errno=65). Reconnecting to MQTT in 2s.
Dec 1 08:45:01.725 2017 FW01 GKD-lchassis[5395]: %DAEMON-5: 2017-12-01 08:45:01.725512 ERROR Failed to connect to message broker: No route to host.
Dec 1 08:45:01.725 2017 FW01 GKD-lchassis[5395]: %DAEMON-5: 2017-12-01 08:45:01.725543 INFO Mosquitto error The client is not currently connected. (errno=65). Reconnecting to MQTT in 2s.
Dec 1 08:45:02.026 2017 FW01 GKD-chassis[4742]: %DAEMON-5: 2017-12-01 08:45:02.026516 ERROR Failed to connect to message broker: No route to host.
Dec 1 08:45:02.026 2017 FW01 GKD-chassis[4742]: %DAEMON-5: 2017-12-01 08:45:02.026546 INFO Mosquitto error The client is not currently connected. (errno=6
Thanks
↧
Re: How to Filtering the syslog flooding ?
Hi all,
it's ok. i already get it.
↧
↧
How to match one of community and trigger action ?
Hi All
I have a question for policy .
If I hope to match one of community strings and trigger action , how do I do ?
As follow is right way ?
set policy-options community TW members " 9527:1|9527:2|9527:3"
set policy-options policy-statement GOTW term 1 from community TW
set policy-options policy-statement GOTW term 1 then local-preference 120
set policy-options policy-statement GOTW term 1 then accept
↧
Re: Policy Statement
Hi,
Please read the below document which has a very good explanation about your query.
Example
Accept incoming IPv4 routes with a destination prefix of 10.1.0/24 and the third byte an even number from 0 to 14, inclusive:
[edit]
policy-options {policy-statement from_customer_a {term term_1 {from {route-filter 10.1.0.0/24 address-mask 255.255.241.0;}then {...reject;}}}}
The route filter in routing policy term term_1 matches the following incoming IPv4 route addresses:
- 10.1.0.0/24
- 10.1.2.0/24
- 10.1.4.0/24
- 10.1.6.0/24
- 10.1.8.0/24
- 10.1.10.0/24
- 10.1.12.0/24
- 10.1.14.0/24
The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise logical AND of the netmask value and the match prefix address. That is, where the netmask bit pattern 255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value of the corresponding bit in the destination prefix address 10.1.0.0/24.
Regards,
Rahul N
↧
Re: Policy Statement
Accepting Incoming IPv4 Routes by Applying an Address Mask to the Route Address and the Destination Match Prefix
Accept incoming IPv4 routes with a destination prefix of 10.1.0/24 and the third byte an even number from 0 to 14, inclusive:
[edit]
policy-options {policy-statement from_customer_a {term term_1 {from {route-filter 10.1.0.0/24 address-mask 255.255.241.0;}then {...reject;}}}}
The route filter in routing policy term term_1 matches the following incoming IPv4 route addresses:
- 10.1.0.0/24
- 10.1.2.0/24
- 10.1.4.0/24
- 10.1.6.0/24
- 10.1.8.0/24
- 10.1.10.0/24
- 10.1.12.0/24
- 10.1.14.0/24
The bit-wise logical AND of the netmask value and the candidate route address must match the bit-wise logical AND of the netmask value and the match prefix address. That is, where the netmask bit pattern 255.255.241.0 contains a set bit, the incoming IPv4 route address being evaluated must match the value of the corresponding bit in the destination prefix address 10.1.0.0/24.
- The first two bytes of the netmask value are binary 1111 1111 1111 1111, which means that a candidate route address will fail the match if the first two bytes are not 10.1.
- The third byte of the netmask value is binary 1111 0001, which means that a candidate route address will fail the match if the third byte is greater than 15 (decimal), an odd number, or both.
- The prefix length of the match prefix address is 24 (decimal), which means that a candidate route address will fail the match if its prefix length is not exactly 24.
As an example, suppose that the candidate route address being tested in the policy is 10.1.8.0/24 (binary 0000 1010 0000 0001 0000 1000).
- When the netmask value is applied to this candidate route address, the result is binary 0000 1010 0000 0001 0000 0000.
- When the netmask value is applied to the configured destination prefix address, the result is also binary 0000 1010 0000 0001 0000 0000.
- Because the results of both AND operations are the same, the match continues to the second match criteria.
- Because the prefix lengths of the candidate address and the configured destination prefix address are the same (24 bits), the match succeeds.
As another example, suppose that the candidate route address being tested in the policy is 10.1.3.0/24 (binary 0000 1010 0000 0001 0000 0011).
- When the netmask value is applied to this candidate route address, the result is binary 0000 1010 0000 0001 0000 0001.
- However, when the netmask value is applied to the configured destination prefix address, the result is binary 0000 1010 0000 0001 0000 0000.
- Because the results of the two AND operations are different (in the third byte), the match fails.
Accepting Incoming IPv4 Routes with Similar Patterns But Different Prefix Lengths
Accept incoming IPv4 route addresses of the form 10.*.1/24 or 10.*.1.*/32:
[edit]
policy-options {policy-statement from_customer_b {term term_2 {from {route-filter 10.0.1.0/24 address-mask 255.0.255.0;route-filter 10.0.1.0/32 address-mask 255.0.255.0;}then {...reject;}}}}
The route filter match criteria 10.0.1.0/24 address-mask 255.0.255.0 matches an incoming IPv4 route address of the form 10.*.1/24. The route’s prefix length must be exactly 24 bits long, and any value is acceptable in the second byte.
The route filter match criteria 10.0.1.0/32 address-mask 255.0.255.0 matches an incoming IPv4 route address of the form 10.*.1.*/32. The route’s prefix length must be exactly 32 bits long, and any value is acceptable in the second byte and the fourth byte.
Evaluation of an Address Mask Match Type with Longest-Match Lookup
This example illustrates how a longest-match lookup evaluates a route filter that contains two address-mask match types. Consider the route filter configured in the routing policy term term_3 below:
[edit]
policy-options {policy-statement from_customer_c {term term_3 {from {route-filter 10.0.1.0/24 address-mask 255.0.255.0;route-filter 10.0.2.0/24 address-mask 255.240.255.0;}then {...}}}}
Suppose that the incoming IPv4 route source address 10.1.1.0/24 is tested against the route filter configured in the policy term term_3:
The longest-match lookup tree for routing policy term term_3 contains two match prefixes: one prefix for 10.0.1.0/24 address-mask 255.0.255.0 and one prefix for 10.0.2.0/24 address-mask 255.240.255.0. When searching the tree for the longest-prefix match for a candidate, the longest-match lookup considers the number of contiguous high-order bits in the configured netmask-value instead of the length of the configured destination-prefix:
- For the first route filter match criteria, the longest-match lookup entry is 10.0.0.0/8 because the netmask value contains 8 contiguous high-order bits.
- For second route filter match criteria, the longest-match lookup entry is 10.0.0.0/12 because the netmask value contains 12 contiguous high-order bits.
Now that the longest-match prefix in term_3 has been identified for the candidate route address, the candidate route address is evaluated against the route filter match criteria 10.0.2.0/24 address-mask 255.240.255.0:
- To test the incoming IPv4 route address 10.1.1.0/24, the netmask value 255.240.255.0 is applied to 10.1.1.0/24. The result is 10.0.1.0.
- To test the configured destination prefix address 10.0.2.0/24, the netmask value 255.240.255.0 is applied to 10.0.2.0/24. The result is 10.0.2.0.
- Because the results are different, the route filter match fails. No actions, whether specified with the match criteria or with the then statement, are taken. The incoming IPv4 route address is not evaluated against any other match criteria.
↧
Re: Policy Statement
Unlike firewall filters, the default action on policy-statement is accept .
So when you dont specify a default term to reject/deny everything else other than your match condition, everything else will be accepted.
root> show configuration policy-options
policy-statement Test {
term 1 {
from {
route-filter 2.2.2.2/32 address-mask 255.255.255.0;
}
then accept;
}
}
you need to add term 2 with action reject . If you have multiple policies use action as next-policy and configure reject on the last policy.
Ref: https://kb.juniper.net/KB27448
↧
↧
Re: How to match one of community and trigger action ?
You policy looks ok to me..
However, i have not tried 3 communities using regular expressions in BGP community.
Refer above, it does say not specifically that you can match 3 expressions in a go..
You can try following to simplify..
set policy-options community TW members " 9527:*"
or
set policy-options community TW1 members " 9527:1"
set policy-options community TW2 members " 9527:2"
set policy-options community TW3 members " 9527:3"
and match this 3 communities in your policy like..
set policy-options policy-statement GOTW term 1 from community [TW1 TW2 TW3]
↧
Is possible to ECMP on vrf using only source-ip address hashing
Hi All
Is possible to ECMP on vrf using only source-ip address hashing if I have route multipath to 2 device like a
0/0 next-hop PE1
0/0 next-hop PE2
↧
Re: Policy Statement
Hello Suraj,
Will this config work?
root@R2> show configuration policy-options policy-statement Test
term 1 {
from {
route-filter 2.2.2.2/32 address-mask 255.255.255.0;
}
then accept;
}term 2 {
then reject;
}
root@R2>
↧