[j-nsp] Update on 10.4R9 stability for MX?
It has been a couple of months since the JTAC recommended Junos software versions has been updated for the MX. As of February, the recommendation was to use 10.4R8.5 for the MX, except that there is an issue related to BFD configurations on the DPC line cards. Supposedly, the fix is in 10.4R9. In looking at the release notes, there are some issues that have been resolved in the 11.x series but nothing noted yet for any future 10.4.x releases. Perhaps there are future 10.4.x versions planned to carry forward these fixes? I am curious to know about anyone's experience with 10.4R9 over the past few months. I have DPC only currently; i.e. no MPC hardware -- and no MultiServices. Thanks. Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Controlling routes between OSPF areas
Hi everyone, I have a two network segments, OSPF area 0 and 1. I have a firewall cluster with interfaces in both areas. I need to stop say a default route from area 0 making its way into area 1. I've tried import and export policies but nothing seems to really work. Can anybody please give me an example? Is this against how OSPF works? Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Help Needed for Bonjour Routing/OSX Clients
Hello All, I am a complete noobie when it comes to Juniper so please don't bash me to bad :-) Hardware: Juniper SRX240 Problem : We have moved our client PCs from being all in 1 large subnet into 8 VLANs to better segment the various departments. All windows PCs/Servers are working fine, no problems. The Apple OSX PCs are another story. They can only see the Bonjour type services, printers, etc. in their own VLAN and none from the other VLANs. How can I get this Bonjour traffic to be passed/seen by all devices in all VLANs? Current Setup: The SRX240 is the main (Only) router in the network. I is configured with 8 VLANs, each with a different /24 subnet. 2 Interfaces are Aggregated and connected to a Managed/VLAN Capable Switch (VPN Trunk) where the clients/servers have been placed in the various VLANs. Everything works as expected except the aforementioned Apple Bonjour. All VLANs are in the same security Zone (Trusted) and permissions have been setup for all Trusted Interfaces to communicate with each other and pass any/all traffic (No filters/security blocks between VLANs). Whats needed: What are the commands to get the Bonjour traffic to be seen/sent to all VLAN members? I have found a few posts online, but they all seem to mention multiple routers or large Corp setups, thus not the right settings.. Any/All help would be appreciated. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Help Needed for Bonjour Routing/OSX Clients
To get Bonjour to work across LANs, you would need to enable multicast routing so that clients on the various LANs can join the same group. Bonjour is just Apple's name for mDNS (multicast DNS). Provided that everyone can solicit queries and hear announcements, hosts should be able to resolve the addresses of the other stations and will then attempt to route to it. I've gotten this to work in the past, but it ended up being a LOT more work than just using DNS names and routing (which I've subsequently done each time). Bonjour / mDNS is really only great at service discovery and small-scale name resolution, IMO. DNS and distributing names at scale; not so much. Cheers, jof ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Help Needed for Bonjour Routing/OSX Clients
How big is the network? Will O'Brien On May 9, 2012, at 4:59 PM, Jonathan Lassoff j...@thejof.com wrote: To get Bonjour to work across LANs, you would need to enable multicast routing so that clients on the various LANs can join the same group. Bonjour is just Apple's name for mDNS (multicast DNS). Provided that everyone can solicit queries and hear announcements, hosts should be able to resolve the addresses of the other stations and will then attempt to route to it. I've gotten this to work in the past, but it ended up being a LOT more work than just using DNS names and routing (which I've subsequently done each time). Bonjour / mDNS is really only great at service discovery and small-scale name resolution, IMO. DNS and distributing names at scale; not so much. Cheers, jof ___ 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] Controlling routes between OSPF areas
On Wed, 9 May 2012 14:29:57 -0700 Morgan Mclean wrx...@gmail.com wrote: Hi everyone, I have a two network segments, OSPF area 0 and 1. I have a firewall cluster with interfaces in both areas. I need to stop say a default route from area 0 making its way into area 1. I've tried import and export policies but nothing seems to really work. Can anybody please give me an example? Is this against how OSPF works? Thanks, Morgan An OSFP filter map should do the job you want. You basically define which routes are allowed to export/import. -- Burkhard Ott System Administrator Revenuewire Inc. 1205 - 4464 Markham Street Victoria, BC V8Z 7X8 250-984-1132 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Controlling routes between OSPF areas
Your export policy must be applied at the announcement router. For example, my area 0 router only announces a default route and nothing else. Set a match and don't forget the reject. Will On May 9, 2012, at 4:30 PM, Morgan Mclean wrx...@gmail.com wrote: Hi everyone, I have a two network segments, OSPF area 0 and 1. I have a firewall cluster with interfaces in both areas. I need to stop say a default route from area 0 making its way into area 1. I've tried import and export policies but nothing seems to really work. Can anybody please give me an example? Is this against how OSPF works? Thanks, Morgan ___ 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] Controlling routes between OSPF areas
I tried the restrict statement under area 1 for another route as a test:
[edit protocols ospf area 0.0.0.1]
+ area-range 192.168.30.156/30 {
+ restrict;
+ exact;
+ }
And I still see it on the other end:
192.168.30.156/30 *[OSPF/10] 22:22:03, metric 2
to 192.168.30.110 via ge-7/0/0.0
Morgan
On Wed, May 9, 2012 at 3:18 PM, OBrien, Will obri...@missouri.edu wrote:
Your export policy must be applied at the announcement router. For
example, my area 0 router only announces a default route and nothing else.
Set a match and don't forget the reject.
Will
On May 9, 2012, at 4:30 PM, Morgan Mclean wrx...@gmail.com wrote:
Hi everyone,
I have a two network segments, OSPF area 0 and 1. I have a firewall
cluster with interfaces in both areas. I need to stop say a default route
from area 0 making its way into area 1.
I've tried import and export policies but nothing seems to really work.
Can anybody please give me an example? Is this against how OSPF works?
Thanks,
Morgan
___
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] Controlling routes between OSPF areas
Will,
You mean the export policy restricting 0/0 from area 0 to area 1 must be on
the srx that has an interface from area 0, and an interface from area 1.
Correct?
I've tried this with no luck on my ospf export policy:
+term deny-test {
+from {
+area 0.0.0.0;
+route-filter 192.168.30.156/30 exact;
+}
+to area 0.0.0.1;
+then reject;
+}
On Wed, May 9, 2012 at 3:50 PM, Morgan McLean wrx...@gmail.com wrote:
I tried the restrict statement under area 1 for another route as a test:
[edit protocols ospf area 0.0.0.1]
+ area-range 192.168.30.156/30 {
+ restrict;
+ exact;
+ }
And I still see it on the other end:
192.168.30.156/30 *[OSPF/10] 22:22:03, metric 2
to 192.168.30.110 via ge-7/0/0.0
Morgan
On Wed, May 9, 2012 at 3:18 PM, OBrien, Will obri...@missouri.edu wrote:
Your export policy must be applied at the announcement router. For
example, my area 0 router only announces a default route and nothing else.
Set a match and don't forget the reject.
Will
On May 9, 2012, at 4:30 PM, Morgan Mclean wrx...@gmail.com wrote:
Hi everyone,
I have a two network segments, OSPF area 0 and 1. I have a firewall
cluster with interfaces in both areas. I need to stop say a default route
from area 0 making its way into area 1.
I've tried import and export policies but nothing seems to really work.
Can anybody please give me an example? Is this against how OSPF works?
Thanks,
Morgan
___
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] Update on 10.4R9 stability for MX?
On Wed, May 09, 2012 at 03:13:26PM -0400, Clarke Morledge wrote: It has been a couple of months since the JTAC recommended Junos software versions has been updated for the MX. As of February, the recommendation was to use 10.4R8.5 for the MX, except that there is an issue related to BFD configurations on the DPC line cards. Supposedly, the fix is in 10.4R9. In looking at the release notes, there are some issues that have been resolved in the 11.x series but nothing noted yet for any future 10.4.x releases. Perhaps there are future 10.4.x versions planned to carry forward these fixes? I am curious to know about anyone's experience with 10.4R9 over the past few months. I have DPC only currently; i.e. no MPC hardware -- and no MultiServices. There is a serious issue with MPLS RSVP auto-bandwidth in 10.4R9, which can cause the reservation calculations to be off by quite a bit. The least broken code we've found so far is 10.4S9, I'm surprised they haven't done an R10 yet. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
