SRX

is it possible to adverise static routes into these? 

we have some SOHO routers that come back to and SRX 240 ( about 30 of them 

each SOHO bring up OSPF when the tunnle comes up this is so i dont have to put a bunch of static pointing to the ST0.x interfaces for all the /29s 

I have a requirement to for some internet adds to come back here and go out a private connection to a vender, the SOHO boxes are trying to use the internet for this, makes sense. 

I know i can fix this if i add the statics to the SOHO routers so that traffic goes of the tunnle, but it would be much cleaner and easier to update the list if I could put them on the 240 and use the OSPF that is already in place to do this 

I have a tried a policy to redistrubte static but i have little expeance with stub networks, every place i have work in the past was always full mesh back bone. 

Thanks for the help 

240 (st0.0 to st0.36)

ospf {
export [ direct-opsf exportstatic1 ];
area 0.0.0.50 {
stub default-metric 1 no-summaries;
interface st0.1 {
interface-type p2p;
authentication {

area 0.0.0.0 {
interface vlan.0;

policy-statement direct-opsf {
term T1 {
from protocol [ direct static ];
}
}
policy-statement exportstatic1 {
term exportstatic1 {
from protocol static;
then accept;

SOHO 

ospf {
area 0.0.0.50 {
stub;
interface st0.0 {
interface-type p2p;
authentication {

}
interface vlan.1;
interface lo0.0;

Hello,

---

@Andrewmiller wrote:

is it possible to adverise static routes into these? 

 

 

 

---

No. See RFC 2328 section 3.6

https://www.ietf.org/rfc/rfc2328.txt

---

@Andrewmiller wrote:

 

 

240 (st0.0 to st0.36)

ospf {
export [ direct-opsf exportstatic1 ];
area 0.0.0.50 {
stub default-metric 1 no-summaries;
interface st0.1 {
interface-type p2p;
authentication {

 

 

area 0.0.0.0 {
interface vlan.0;

 

policy-statement direct-opsf {
term T1 {
from protocol [ direct static ];
}
}
policy-statement exportstatic1 {
term exportstatic1 {
from protocol static;
then accept;

 

 

---

The config above will inject external LSA into area 0 only. Area 50 will have only internal and 0/0 route which begs a question -why do You need to redistribute statics into Area 50 in 1st place?

HTH

Thx

Alex

i need a set of routes (that are internet IPs) to get advertised to all the SOHO via OSFP 

that way I do not need to put the static routes on the each SOHO device 

these are a new project and it seems weelky they are adding routes   So it would be easier just to do it on the on headend SRX 240 then having to update each SOHO 

please i hate static routes so only having in one place makes it cleaner 

from the SOHO boxes 

traceroute 199.38..x.x 

this tries to trace out hte internet, but i need it to go over the IPSEC tunnle bock to our HQ 

once it hit the HQ the routes in our core send to to a FW that the vender has circuit off of. 

there is a range of pulic IP that get sent ot this vendor, and not over the internet

Hello,

Your options at this point:

1/ convert area 50 stub into normal area->visit each SOHO box to change config

2/ use BGP overlay -> visit each SOHO box to change config

3/ on SRX 240 only, delete "no summaries" and inject the statics into area 50 as LSA-3 which is non-trivial/tricky but should be possible with another area+direct routes matching Your statics+FBF. Other people would call it horrible kludge 

My personal choice would be (2) as it would give a greater flexibility in the future.

HTH

Thx

Alex

I think BGP would be the least invasive, since i will not need to bring down the OSPF to do it. 

also # 3 would work im sure I'm assuming i would have to write a policy for it to work ? 

like this ? 

set policy-options policy-statement exportstatic1 term exportstatic1 from protocol static
set policy-options policy-statement exportstatic1 term exportstatic1 then external type 1
set policy-options policy-statement exportstatic1 term exportstatic1 then accept

Hello,

---

@Andrewmiller wrote:

 

also # 3 would work im sure I'm assuming i would have to write a policy for it to work ? 

 

 

like this ? 

set policy-options policy-statement exportstatic1 term exportstatic1 from protocol static
set policy-options policy-statement exportstatic1 term exportstatic1 then external type 1
set policy-options policy-statement exportstatic1 term exportstatic1 then accept

---

No. For my option #3 You have to:

1/ duplicate Your statics as connected. I.e. if You have static 203.0.113.0/24 then pick an intreface that is always up, like lo0 and assign 203.0.113.254/24 to it. Repeat for every static route.

2/ add this interface into OSPF. Use a separate area and filter these connecteds from going into area 0 with "area-range" or "network-summary-import" 

3/ Add anotther routing instance and import area 0 OSPF routes into it.

4/ Add FBF to from-SOHO-ingress interface to send all traffic from SOHO into that routing instance.

HTH

Thx
Alex

i ened up going the BGP route, it was easier.

then i realized it should work without the routes do to my FW config on the other side...... and it does

so didn't really need it, but I got some good hands on with OSPF for BGP lol

was fun

thanks for the help !