Dear Rehan
To complement Morgan's response.
It seems you are based in Saudi. Here IGW allows ISPs to advertise a /25.
Assuming you already have your own /24 from RIPE, you can divide this into
two /25 and achieve reasonable 'load-sharing' in the inbound direction. To
keep the traffic uniform
You should have remote loopbacks also redistributed into LDP (if your
transport label is from LDP).
In JUNOS, this does not happen by default, you must have LDP egress-policy
for this to occur. By default, LDP announces only primary lo0.0 IP@.
Absent this, your L2circuits would show OL error
Thanks Alex,
I had already redistibuted all my loopback into my IGP and all were reachable
| Kind Regards, |
| Peter Nyamukusa|
| MCSE-2000/2003, CCNP, CCIP,
This is not enough.
You must have LDP egress-policy and include these loopbacks there too
https://www.juniper.net/techpubs/software/junos/junos93/swconfig-mpls-apps/configuring-the-ldp-egress-policy.html
HTH
Thanks
Alex
- Original Message -
From: Peter Nyamukusa
To: Alex Arseniev
Hey Folks,
I have a somewhat typical duel PE and duel CE scenario. However, the two PE and
two CE routers are all in the same subnet and the two PE routers routing
instances can see eachother over OSPF.
I'm not sure if this is wise.
Should routing instances belonging to the same MPLS VPN be
Hello,
we're just setting up inline-jflow on MX Trio chipsets and I'm seeing
a few odd things:
1) Why is inline-jflow sending so many packets instead of putting more
then one flow in one udp packet? Every ~5 seconds I get a LOT of UDP
packets at the same time, many of them only containing
On (2012-11-20 16:54 +0100), Sebastian Wiesinger wrote:
Just started with IPFIX export on two nodes this monday.
2) In Douglas Hanks Juniper MX Series book it is noted that the
sampling rate for inline jflow must always be 1 (other rates are
not valid). Still it seems to work with rate
Hi,
Can you share the output of:
show route table inet.3 5.1.1.2(ASN1234)
show route table inet.3 5.1.1.1 (ASN 4321)
show ldp database l2circuit -- on both PEs
Alex, imho redistributing ldp through egress-policy wouldn't stitch mpls
transport (assume LDP) b/w remote
Can anyone tell me the maximum number of routing instances supported on the
MX and EX platforms??
I am working on a technical review of vendors and am looking for that
information.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
Chris,
On Junos I believe there is a limit of about 15 logical instances but I am
not aware of a limit of routing instances on the platforms. I would check
with a pre-sales team if they have those details as these figures depend on
hardware configuration/platform/junos versions.
Darius
On Tue,
On (2012-11-20 13:28 -0500), Chris Evans wrote:
Can anyone tell me the maximum number of routing instances supported on the
MX and EX platforms??
I am working on a technical review of vendors and am looking for that
information.
I noticed same question in c-nsp. Any straight answer you're
hey,
Just for future reference, this is not true for SRX running in flow mode.
On SRX, number of zones is software limited and interfaces for single
zone have to be in the same routing-instance. So in essence you are
limited to 127 routing instances (128 - global) on a box with 128 zones.
- Load balancing all traffic between 2 ISP connections, not sure if its
possible or not?
- Send/Receive traffic of some subnets through one ISP and for others
through other ISP to maximum utilize both ISP links
First thing I must say, in 100% of cases (I am assuming it's an enterprise
13 matches
Mail list logo
