Re: [j-nsp] Regarding JUNOS SPACE
Dear Diogo, Service Now.. We have demo version without additional features. Honestly, i do not see any beneficial point inside of it. Am i missing something ? Thanks and regards, Gokhan 2011/11/28 Diogo Montagner diogo.montag...@gmail.com Hi Gokhan, Which application of Junos Space are you referring ? For example, the Service Now has a very good eLearning available on Juniper website. For Junos Space itself, I don't think there is. But you probably will find some eLearnings related to the Junos Space SDK. Thanks On 11/29/11, Gökhan Gümüş ggu...@gmail.com wrote: Dear Community, We have recently installed Junos Space with version 11.2. I have had a chance to have a look at Junos Space Web Gui to give some briefing to our NOC. But i could not find any documentation which explains Junos Space basicly and simply.( Power point presentation would be great ) Is there anybody who can provide a good document which explains Junos space basically? Thanks and regards, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Sent from my mobile device ./diogo -montagner ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Regarding JUNOS SPACE
Hi Gokhan, For me, one of the benefits I can see is that it will help you to collect most of the logs you need on the exact time that a problem happens. For example, in case some FPC has got problem. When that happens the JUNOS will raise one event and that event will trigger a junos script (installed in the router) to collect the logs specifically for that type of issue. If you have an auto policy configured on Service Now, it can automatically open a JTAC case for that issue and upload all the information there in few minutes. Thanks ./diogo -montagner On Tue, Nov 29, 2011 at 4:49 PM, Gökhan Gümüş ggu...@gmail.com wrote: Dear Diogo, Service Now.. We have demo version without additional features. Honestly, i do not see any beneficial point inside of it. Am i missing something ? Thanks and regards, Gokhan 2011/11/28 Diogo Montagner diogo.montag...@gmail.com Hi Gokhan, Which application of Junos Space are you referring ? For example, the Service Now has a very good eLearning available on Juniper website. For Junos Space itself, I don't think there is. But you probably will find some eLearnings related to the Junos Space SDK. Thanks On 11/29/11, Gökhan Gümüş ggu...@gmail.com wrote: Dear Community, We have recently installed Junos Space with version 11.2. I have had a chance to have a look at Junos Space Web Gui to give some briefing to our NOC. But i could not find any documentation which explains Junos Space basicly and simply.( Power point presentation would be great ) Is there anybody who can provide a good document which explains Junos space basically? Thanks and regards, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Sent from my mobile device ./diogo -montagner ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and 128.0.0.0 martian (JFYI)
On Wed, Oct 12, 2011 at 11:59:14AM +0400, Tima Maryin wrote: RIPE NCC was awared about this issue and now reallocate blocks to those who got addrs from 128.0.0.0/16 One more update on this topic: RIPE started debogonisation for 128.0.0.0/16, so it looks like this network will be allocated again in the future: route: 128.0.0.0/21 descr: RIPE-NCC-RIS debogon prefix origin: AS12654 pingable:128.0.0.1 I hope all networks will implement advice from PSN-2011-10-393 before this happens. -- In theory, there is no difference between theory and practice. But, in practice, there is. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Does a L3VPN RR require routing-instance for each VRF?
As per subject line: if we want to use a JunOS box (M7i, running 10.4) as a route-reflector, it seems to reject inet-vpn routes with: bgp_rcv_nlri: 129.x.x.0:4:193.x.x.0/92 rejected due to the lack of a valid target community I was hoping we could avoid the hassle of defining the VRF on the RRs if possible, but I guess that is required - am I missing some obvious / subtle point why that is the case, or some way of making it work? Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF?
Do you have family inet-VPN configured in the group stanza? All the routes are reflected from the bgp.l3vpn.0 table. You don't have to define each vrf. If you already configured the address family it sounds like it doesn't like your ext. communities for some reason. Sent from my iPhone On Nov 29, 2011, at 7:37 AM, Phil Mayers p.may...@imperial.ac.uk wrote: As per subject line: if we want to use a JunOS box (M7i, running 10.4) as a route-reflector, it seems to reject inet-vpn routes with: bgp_rcv_nlri: 129.x.x.0:4:193.x.x.0/92 rejected due to the lack of a valid target community I was hoping we could avoid the hassle of defining the VRF on the RRs if possible, but I guess that is required - am I missing some obvious / subtle point why that is the case, or some way of making it work? Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF?
On 29/11/11 12:55, Keegan Holley wrote: Do you have family inet-VPN configured in the group stanza? All the Yes. I also have routes in the inet.3 table matching the next-hops (to reply to the many people who unicasted me off-list). I have tried both a static and LDP. routes are reflected from the bgp.l3vpn.0 table. You don't have to This does not occur unless I define a routing-instance. In fact, with no routing-instance defined, the bgp.l3vpn.0 table is simply absent. define each vrf. If you already configured the address family it sounds like it doesn't like your ext. communities for some reason. Where would the ext. communities come from if I haven't defined a routing-instance? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF?
You don't need to define any VRFs. I'll post a config later. You don't need static routes for each PE either, you can just have a default route to discard in inet.3 and it'll work. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Phil Mayers p.may...@imperial.ac.uk To: Keegan Holley keegan.hol...@sungard.com Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tuesday, November 29, 2011 7:06 AM Subject: Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF? On 29/11/11 12:55, Keegan Holley wrote: Do you have family inet-VPN configured in the group stanza? All the Yes. I also have routes in the inet.3 table matching the next-hops (to reply to the many people who unicasted me off-list). I have tried both a static and LDP. routes are reflected from the bgp.l3vpn.0 table. You don't have to This does not occur unless I define a routing-instance. In fact, with no routing-instance defined, the bgp.l3vpn.0 table is simply absent. define each vrf. If you already configured the address family it sounds like it doesn't like your ext. communities for some reason. Where would the ext. communities come from if I haven't defined a routing-instance? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF?
If you are doing route target filtering (family route-target), then you may need to add the default target on the RRs: set ... protocols bgp ... family route-target advertise-default Cheers. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Observing error: device vlan not found
Hi,
we had this problem. We opened a ticket at Juniper and found our case here in
this list. We are not amused. Is this the default, that Juniper support
contacts an official mailing list??
However, I would like to ask the experts here for a continuing problem. Please
let me know, if it is better to open a new thread.
After configuring the irb interfaces, we can reach all IP addresses, that are
configured on the MX. However, I cannot reach a device, that is directly
connected to one of the MX's interfaces. I have tried the alternative
configurations that I found here:
https://puck.nether.net/pipermail/juniper-nsp/2010-July/017443.html
With the following configuration I can ping all IP addresses on the MX from
the devices that are directly connected. One is connected to ge-1/0/2. It's a
laptop with WinXP. The firewall service is not running. IP address is
111.222.33.1/24, default GW is 111.222.33.240.
I cannot ping the same devices from the MX and I cannot ping one device from
another. The second device is connected to ge-1/1/2. Config is basically the
same, IP addresses and vlan not, obviously.
I tried to find some documentation but I failed. Do _I_ have a problem or does
Juniper?
ge-1/0/2 {
flexible-vlan-tagging;
native-vlan-id 601;
encapsulation flexible-ethernet-services;
unit 601 {
encapsulation vlan-bridge;
vlan-id 601;
}
}
irb {
unit 601 {
family inet {
address 111.222.33.245/24 {
vrrp-group 0 {
virtual-address 111.222.33.240;
priority 98;
accept-data;
}
}
}
}
bridge-domains {
default {
description default;
domain-type bridge;
vlan-id 1;
}
vlan-601 {
domain-type bridge;
vlan-id 601;
interface ge-1/0/2.601;
routing-interface irb.601;
}
Any ideas?
Cheers,
Kerstin
--
Kerstin Ordnung
Betriebssysteme und Datennetze
Informationstechnologie
FIZ Karlsruhe - Leibniz-Institut für Informationsinfrastruktur
www.fiz-karlsruhe.de
---
Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische
Information mbH.
Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB
101892.
Geschäftsführerin: Sabine Brünger-Weilandt.
Vorsitzender des Aufsichtsrats: MinDirig Dr. Thomas Greiner.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF?
On 29/11/11 14:46, Per Granath wrote: If you are doing route target filtering (family route-target), then you may need to add the default target on the RRs: set ... protocols bgp ... family route-target advertise-default We are not doing route target filtering. I think I need to re-state my problem. I'm getting a lot of questions (unicast, off-list) which indicate I have not explained myself correctly. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF?
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Tuesday, November 29, 2011 7:38 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Does a L3VPN RR require routing-instance for each VRF? As per subject line: if we want to use a JunOS box (M7i, running 10.4) as a route-reflector, it seems to reject inet-vpn routes with: bgp_rcv_nlri: 129.x.x.0:4:193.x.x.0/92 rejected due to the lack of a valid target community I was hoping we could avoid the hassle of defining the VRF on the RRs if possible, but I guess that is required - am I missing some obvious / subtle point why that is the case, or some way of making it work? Basic question - I'm assuming that you have cluster x.x.x.x configured under the BGP group or individual BGP neighbor? This is the only reason I could see this occurring, is if you were missing the cluster statement, or it was being overridden by something else. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Solved - Does a L3VPN RR require routing-instance for each VRF?
On 29/11/11 14:37, Eric Van Tol wrote:
Basic question - I'm assuming that you have cluster x.x.x.x
configured under the BGP group or individual BGP neighbor? This is
the only reason I could see this occurring, is if you were missing
the cluster statement, or it was being overridden by something else.
Bingo, thanks. That's it.
I did not have a cluster statement.
The reason is that, as yet, this new RR does not *have* any clients, so
I had not created the group statement. The only BGP peers are the
existing route-reflectors, which of course go in a different group. i.e.
I only had:
protocols {
bgp {
group Core {
type internal;
local-address z.z.z.z;
family inet {
unicast;
multicast;
}
family inet-vpn {
unicast;
}
family inet6 {
unicast;
}
family inet6-vpn {
unicast;
}
family inet-mvpn {
signaling;
}
family inet-mdt {
signaling;
}
peer-as 64580;
neighbor x.x.x.x;
neighbor y.y.y.y;
}
}
}
When I added the group and set a cluster (even though there are no
neighbours in it...) the bgp.l3vpn.0 routing table suddenly magically
appeared.
Cheers,
Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] For info: NAT64 on M7i using adaptive services
All,
Some time ago, I asked whether this was possible. tl;dr - it is, and
mostly works with a few caveats.
The config I used was basically the same as that in the Configuring
Stateful NAT64 for Handling IPv4 Address Depletion document from
Juniper, but with one important change (that document assumes an MX 3D
router - maybe the unvarnished config works there).
In that document, they give an interface config like so:
ge-1/3/0 {
description IPv6 only domain;
unit 0 {
family inet;
family inet6 {
service {
input {
service-set nat64;
}
output {
service-set nat64;
}
}
address 2001:db8::x/112;
}
}
}
This did NOT work until I actually added an IPv4 address under family
inet i.e.
set interface ge-1/3/0 unit 0 family inet address
Without an actual IPv4 address, the M7i simply didn't work, and it very
much did NOT give any useful logging or diagnostics - it just failed in
weird ways, with weird log messages.
With this config, the NAT64 worked just fine. I then provisioned a 2nd
NAT64 prefix, out of our local /48, and used a firewall filter that
basically said this:
1. from local addresses - 64:FF9B::/96 permit
2. from ::/0 - 2001:db8:site::/96 permit
...and on IPv6 day we published a record for one of our IPv4-only
webservers of the form:
wwwX.imperial.ac.uk. IN 2001:db8:site::155.198.x.y
...and inbound IPv6 traffic to that address came via the NAT64 function
on the M7i.
This *mostly* worked, but we did have a few problems.
Firstly, we had problems with users whose IPv6 MTU was 1500. The NAT64
function on the M7i (at least for JunOS 10.4R1.9, the version we ran at
the time) does NOT appear to correctly translate the ICMPv6 messages
into ICMPv4 required for PMTUd to work. The reverse direction (ICMPv4
must-frag - ICMPv6 must-frag) did appear to work, but we didn't test
extensively.
We worked around this with TCP MSS clamping further into the network,
but it was not very satisfactory.
Secondly, we saw problems where source IP/port combinations were re-used
from the pool very quickly, and these re-used ports were then refused by
the webserver with a TCP RST.
We ameliorated this by moving to:
services {
nat {
pool POOL {
address y.y.y.0/24;
port {
automatic {
random-allocation;
}
}
}
}
}
...which seemed to reduce the problem to a very, very tiny level.
I am assuming this 2nd issue would not show up with a real NAT64
deployment where IPv6 clients talk to a very diverse set of IPv4 hosts
through the NAT64. But if your IPv6 clients are talking to a small
number of (or singular!) host(s) via the NAT64, the fact that ports are
recycled quicker than TIME_WAIT seems to cause problems for some IP stacks.
I did intend to investigate this further at some point, but it's looking
unlikely I'll find the time now.
Finally, a note on throughput - the built-in services thingy on the M7i
can do about 800Mbit/sec which is documented, but it's worth noting that
I benchmarked 2000 sessions/sec ramp rate, and IIRC at this point the
ASM CPU was not fully loaded. I also benchmarked 20k sessions, and
again RAM was not fully loaded. So it's a respectable (if not huge)
performance from such an old platform.
Hopefully this information is useful to someone.
Cheers,
Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP tracking of VirtualChassis status.
The 'show virtual-chassis' output on an EX4500 shows the following columns: show virtual-chassis Virtual Chassis ID: 0fff.78ff.dbffVirtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial NoModel prio Role Mode ID Interface0 (FPC 0) Prsnt ex4500-40f 198 Backup N 1 vcp-1 1 vcp-0 1 (FPC 1) Prsnt ex4500-40f 198 Master* N 0 vcp-1 0 vcp-0 Member ID for next new member: 2 (FPC 2) I can pretty much find all of those in the jnxVirtualChassisMemberTable/1.3.6.1.4.1.2636.3.40.1.4.1.1 except for the status. Has anyone had any luck tracking down some sort of SNMP monitoring for that particular one? Perhaps, since its based off the FPC in each member, I can query the corresponding jnxFruState/1.3.6.1.4.1.2636.3.1.15.1.8 table of each FPC? Jonathan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
