[j-nsp] IPv6 static default route in routing instance?
Hi,
Just wondering if anybody's come across this before - default IPv6
static not appearing in the routing instance inet6 table...
Instance is a VRF:
instance-type vrf;
interface ge-1/1/0.503;
interface ge-1/1/0.504;
route-distinguisher 56263:101;
vrf-import [ reject-all ];
vrf-export [ reject-all ];
vrf-table-label;
routing-options {
graceful-restart;
rib dmz.inet6.0 {
static {
route ::/0 next-hop :a500:0:2::1;
}
}
static {
route 0.0.0.0/0 {
next-hop xxx.x.216.54;
no-readvertise;
}
}
}
Looking at the dmz.inet6.0 table shows directly connected routes, but
not the default.
In contrast, dmz.inet.0 has a v4 default as expected.
I must be doing something wrong here
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Firewall best practices
I have a question regarding managing policies among multiple sets of firewalls. I don't know what industry standard / best practice is for managing rules among multiple devices. My two cents. When there is really no such a standard, things to keep in mind do exist. Here are some mistakes people tend to make (and I managed to recall): 1. Too many firewalls. The old-school (and, let's be honest, promoted by vendors and their partners) security design style recommends to put a separate firewall for everything. Dedicated internal firewall, dedicated external firewall, dedicated VPN aggregator, dedicated this, dedicated that. Just open any shmeeseeaee-security book, and you'll find lots of the figures like that. Sometimes they looks attractive in PowerPoint but it is unmanageable. Rule of thumb: the fewer statefull devices you have in the network (including virtual ones), the more secure you are. Modern firewalls have enough horse-power for almost everything. 2. Putting each VLAN into a dedicated zone. I believe it's the habit of attaching acl/filters to interfaces, that makes people do this. This mistake implies a lot of zones and complete mess in the policies, which is not what security zones were invented for. The lower number of security zones you pack your interfaces into, the closer you are to the 'Can you mother read it?' rule of thumb for policies. Some logic is required though. Don't get me wrong, I don't mean to put everything into a single zone (as well as I don't mean to have no firewall at all). Normally you put something into a separate zone because you want to isolate it _by default_ (!) from the other zones. 3. But not otherwise! Putting few interfaces into a zone does not mean all traffic is permitted between these interfaces. On SRX you even have to write explicit policies to allow intra-zone traffic. So it's usually OK to put all your DMZ vlans into a single zone and allow only, say, any to dns/ntp/kerberos using application dns/ntp/kerberos inside it. 4. Putting all IPSec VPNs into a single zone. This makes the VPNs indistinguishable from security point of view. If the remote side is a branch with users of just same trustiness as your local LAN users, it's probably better to put the tunnel interface into the Trust/LAN/however-you-wish-to-call-it zone. if you have a few tunnel to partners (very often mixed with leased channels), put this all into a special zone 'Partners', but don't put there your tunnels to branches. So on. 5. Items 1 and 4 also mean that dedicated device for IPsec is a particularly bad idea. 6. Complicated routing schemes, especially with FBF/PBR, static /32s and other trash. This is hard to scale in the plain routing sense, but when it comes to security, all the design beauty can be broken with a single clumsy step. Add here the fact that security teams are often not experts in complex routing.However business needs sometimes require this anyway. But when your boss asks to extract particular flow and forward it via Paris when it should normally go through Tokyo together with the rest of traffic, tell him the real cost of the solution and ask to seriously think of the benefits and losses. If the trick is really needed, try to use only routing with no additional security constructions. 7. Particularizing policies with very-specific address-objects. Also very effective way to turn your policies into a real nightmare. To have a well-designed network security, first you need well-designed network. Well-organized VLANs, addressing, 802.1X --- all this makes your firewall config much smoother. In the ideal case you should be able to use 'any'or subnet-based address objects for source in all policies, and /32-objects only as destinations in policies permitting connections to your servers. P. S. And yes, security zone names are not worth much. Trust/untrust/dmz or lan/wan/man/internet/DC/server-farm --- all the same. Better pay more attention to your address-book entry names and interface descriptions. -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 static default route in routing instance?
Please provide the output of
show route table dmz.inet6.0 :a500:0:2::1
Thanks,
--Stacy
On Jun 12, 2012, at 11:48 PM, Gordon Smith wrote:
Hi,
Just wondering if anybody's come across this before - default IPv6 static not
appearing in the routing instance inet6 table...
Instance is a VRF:
instance-type vrf;
interface ge-1/1/0.503;
interface ge-1/1/0.504;
route-distinguisher 56263:101;
vrf-import [ reject-all ];
vrf-export [ reject-all ];
vrf-table-label;
routing-options {
graceful-restart;
rib dmz.inet6.0 {
static {
route ::/0 next-hop :a500:0:2::1;
}
}
static {
route 0.0.0.0/0 {
next-hop xxx.x.216.54;
no-readvertise;
}
}
}
Looking at the dmz.inet6.0 table shows directly connected routes, but not the
default.
In contrast, dmz.inet.0 has a v4 default as expected.
I must be doing something wrong here
___
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] IPv6 static default route in routing instance?
My guess is that the direct route to your next-hop :a500:0:2::1 is
not in this instance. Check the interface address config for
ge-1/1/0.503 and ge-1/1/0.504.
13.06.2012 09:48, Gordon Smith wrote:
Hi,
Just wondering if anybody's come across this before - default IPv6
static not appearing in the routing instance inet6 table...
Instance is a VRF:
instance-type vrf;
interface ge-1/1/0.503;
interface ge-1/1/0.504;
route-distinguisher 56263:101;
vrf-import [ reject-all ];
vrf-export [ reject-all ];
vrf-table-label;
routing-options {
graceful-restart;
rib dmz.inet6.0 {
static {
route ::/0 next-hop :a500:0:2::1;
}
}
static {
route 0.0.0.0/0 {
next-hop xxx.x.216.54;
no-readvertise;
}
}
}
Looking at the dmz.inet6.0 table shows directly connected routes, but
not the default.
In contrast, dmz.inet.0 has a v4 default as expected.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 static default route in routing instance?
A downgrade from 11.4R2.14 to 11.2R7.4 fixed the problem.
I now see a v6 default route in the vrf...
G... Thats a pretty big bug to be in the second code revision of
that train
On Wed, 13 Jun 2012 08:33:26 -0600, Stacy W. Smith wrote:
Please provide the output of
show route table dmz.inet6.0 :a500:0:2::1
Thanks,
--Stacy
On Jun 12, 2012, at 11:48 PM, Gordon Smith wrote:
Hi,
Just wondering if anybody's come across this before - default IPv6
static not appearing in the routing instance inet6 table...
Instance is a VRF:
instance-type vrf;
interface ge-1/1/0.503;
interface ge-1/1/0.504;
route-distinguisher 56263:101;
vrf-import [ reject-all ];
vrf-export [ reject-all ];
vrf-table-label;
routing-options {
graceful-restart;
rib dmz.inet6.0 {
static {
route ::/0 next-hop :a500:0:2::1;
}
}
static {
route 0.0.0.0/0 {
next-hop xxx.x.216.54;
no-readvertise;
}
}
}
Looking at the dmz.inet6.0 table shows directly connected routes,
but not the default.
In contrast, dmz.inet.0 has a v4 default as expected.
I must be doing something wrong here
___
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
[j-nsp] JUNOS/EX-series gripe - mirror/analyse before rewrite
Hi, whine mode: on Why oh why, in the name of the gods of Junos, is mirror/analyse done before DSCP rewrite? (aka why oh why is DSCP rewrite done on egress?) ..there's probably a really good architectural reason but jeez, it doesn't help when you have some brain-dead endpoints that can't make their own traffic and your network performance probe (attached to the same switch) reports on packet marking/QoS. whine mode: off cheers :) Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
