Routing

Good day all,

I am new to the forum. I am in a bit of problem with our internet connections with 2 providers, as i have recently joined and do not quite understand the configurations.

we use juniper srx series, below is the configuration with details ((note, i have used dummy ip's, asn etc).

 

ISP1-AS65333 (10.2.2.1 is its peer ip)

ISP2-AS65222 (10.5.5.1 is its peer ip)

192.168.241.0/24 &  192.168.242.0/24 &  192.168.100.0/24 - Additional IP ranges assigned to us.

(Sorry, but i am not sure it is assigned by which ISP)

Our main ip ranges (used for proxy internet, email services etc) are in  192.168.241.0/24 &  192.168.242.0/24 ranges,  192.168.100.0/24 is another range which is used for specific case based outbound traffic.

 

My main queries are:-

 

- With the two providers, is our internet outbound & inbound loadbalanced? (i say no)

- which provider link will be used to advertise 192.168.241.0/24 &  192.168.242.0/24? (i say its ISP2)

- basic understanding on how the 192.168.241.0/24 &  192.168.242.0/24 are advertised, so which link will the incoming traffic come from for these IP ranges & what in the config defines this?

 

=======================================================

set routing-options static route 0.0.0.0/0 next-hop 10.2.2.1
set routing-options static route 0.0.0.0/0 no-readvertise
set routing-options static route 0.0.0.0/0 preference 188

set routing-options static route 192.168.100.0/24 next-hop 192.168.241.122
set routing-options static route 192.168.100.0/24 preference 1

set policy-options policy-statement sendroute-isp1 term 1 from route-filter 192.168.100.0/24 exact
set policy-options policy-statement sendroute-isp2 term 1 from route-filter 192.168.100.0/24 exact
set policy-options policy-statement getroute-isp1 term 1 from route-filter 192.168.100.0/24 exact
set policy-options policy-statement getroute-isp2 term 1 from route-filter 192.168.100.0/24 exact

 

policy-statement sendroute-isp1 {           
        term 1 {                           
        from {                         
            protocol static;           
            route-filter 192.168.241.0/24 exact;
            route-filter 192.168.100.0/24 exact;
            route-filter 192.168.242.0/24 exact;
        }                             
        then accept;                   
    }                                 
    term 2 {                           
        then reject;             

 

policy-statement sendroute-isp2 {     
    term 1 {                           
        from {                         
            protocol static;           
            route-filter 192.168.100.0/24 exact;
            route-filter 192.168.241.0/24 orlonger;
            route-filter 192.168.242.0/24 orlonger;
                    }                             
        then accept;                   
    }                                 
    term 2 {                           
        then reject;

 

policy-statement getroute-isp1 {     
      term 1 {                           
        from {                         
            protocol bgp;             
            route-filter 192.168.241.0/24 orlonger;
            route-filter 192.168.242.0/24 orlonger;
            route-filter 192.168.100.0/24 exact;
        }                             
        then reject;                   
    }                                 
    term 2 {                           
        then accept;                   
    }                                 
}                                     
policy-statement getroute-isp2 {       
    term 1 {                           
        from {                         
            protocol bgp;             
            route-filter 192.168.241.0/24 orlonger;
            route-filter 192.168.242.0/24 orlonger;
            route-filter 192.168.100.0/24 exact;
        }                             
        then reject;                   
    }                                 
    term 2 {                           
        then accept; 

 

group BGP-65333 {
    type external;
    description "BGP with ISP1";
    import getroute-isp1;
    export sendroute-isp1;
    peer-as 65333;
    multipath multiple-as;
    neighbor 10.2.2.1;
}
group BGP-65222 {
    type external;
    description "eBGP with ISP2";
    import getroute-isp2;
    export sendroute-isp2;
    peer-as 65222;
    multipath multiple-as;
    neighbor 10.5.5.1; 

j.fw> show route 0.0.0.0 

inet.0: 61012 destinations, 60840 routes (60720 active, 0 holddown, 29 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0         *[BGP/170] 9w1d 09:01:29, MED 0, localpref 100, from 10.2.2.1
                      AS path: 65333 I, validation-state: unverified
                      to 10.2.2.1 via ge-5/0/1
                    > to 10.5.5.1 via ge-5/0/2
                    [BGP/170] 8w1d 03:05:27, localpref 100
                      AS path: 65222 I, validation-state: unverified
                    > to 10.5.5.1 via ge-5/0/2
                    [Static/188] 39w2d 06:05:18
                    > to 10.2.2.1 via ge-5/0/1

=====================================

Please do help on this for me to understand it. thank you all.

#junosrouting
#SRX

Hello Suthomas,

 

- With the two providers, is our internet outbound & inbound loadbalanced? (i say no)

 

A: Correct, there is no manual Local Preference, MED or as-path prepending setting. The ingress and egress traffic decision is based on the as-path length in this case. It is possible that some traffic is received by ISP1, and some by ISP2, but this depends only on the path from the source and their ISP uplinks.

 

 

- which provider link will be used to advertise 192.168.241.0/24 & 192.168.242.0/24? (i say its ISP2)

 

A: These prefixes will be advertised to BOTH ISPs at the same time, but only if you've configured a static route for these prefixes, as you can see at the "protocol static" statement. However, I cannot see any static route for these prefixes in your pasted configuration. As I suppose your Internet connection is working fine, I think that you didn't paste the complete static route config.

 

 

- basic understanding on how the 192.168.241.0/24 & 192.168.242.0/24 are advertised, so which link will the incoming traffic come from for these IP ranges & what in the config defines this?

 

A: In general, BGP traffic engineering is achieved by well-known BGP attributes, like local-preference (for egress traffic), as-path prepending or MED (both for ingress traffic). By default, without any manual traffic engineering setting, both prefixes will be advertised the same way, so the AS path itself is taken as the main attribute for route decisions.

 

You can find the Juniper BGP path selection criteria here:

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-overview.html#id-10119586

 

Please note that under normal circumstances, ISPs don't accept IPv4 more-specific prefixes than /24. With the statement "route-filter 192.168.241.0/24 orlonger" it is possible that you announce them smaller prefixes as well, which most ISPs don't like, and they are filtered anyway. For public ISP peerings, use "upto /24" or "exact" instead of "orlonger".

Thank you F1ght3r.

 

here are my static routes & bgp outputs.

---------------

set routing-options static route 192.168.241.0/24 discard
set routing-options static route 192.168.241.8/29 next-hop 192.168.241.254
set routing-options static route 192.168.241.8/29 preference 1
set routing-options static route 192.168.241.64/29 next-hop 192.168.241.254
set routing-options static route 192.168.241.64/29 preference 1

set routing-options static route 192.168.242.2/32 next-hop 192.168.241.42
set routing-options static route 192.168.242.6/32 next-hop 192.168.241.42

set routing-options static route 192.168.100.0/24 next-hop 192.168.241.254

set routing-options static route 192.168.241.224/27 next-hop 192.168.241.42
set routing-options static route 192.168.242.0/24 discard

set routing-options static route 172.16.48.0/21 next-hop 192.168.241.254
set routing-options static route 10.83.0.0/21 next-hop 192.168.241.254

set routing-options static route 192.168.241.56/29 next-hop 192.168.241.254

----------------------------

show route advertising-protocol bgp 10.5.5.1 (ISP2)

inet.0: 60210 destinations, 60100 routes (60190 active, 0 holddown, 76 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.168.100.0/24 Self I
* 192.168.241.0/24 Self I
* 192.168.241.8/29 Self I
* 192.168.241.224/27 Self I
* 192.168.242.0/24 Self I
* 192.168.242.8/32 Self I
* 192.168.242.32/29 Self I

------------------------

show route advertising-protocol bgp 10.2.2.1 (ISP1)
inet.0: 60210 destinations, 60100 routes (60190 active, 0 holddown, 76 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.168.100.0/24 Self I
* 192.168.241.0/24 Self I
* 192.168.242.0/24 Self I

 

a) 192.168.241/242.x are applications hosted with us, so those routes are clear and i understand they will be included in advertisements to outside world. Do comment if this is not right.

However, why does 192.168.241.x routes start with discard on top?

 

b) in the bgp outputs, it is seen ISP2 is used to route the traffic more , specifics as compared to ISP1.

  which configuration portion defines this?

 

Thank you again.

  

a) However, why does 192.168.241.x routes start with discard on top?

 

A: Every BGP announcement has to have the exact prefix in your Routing Table. For example, if you just have 192.168.241.8/29 configured, but want to announce 192.168.241.0/24, your Router will not announce the /24 because you do not have configured it anywhere. The "192.168.241.0/24 discard" is exactly for this use case, to put this route in your Routing Table, so that your SRX starts to announce it to the outside world. It is exactly the same with 192.168.242.0/24.

Please note that static route entries are not like firewall filters/ACLs, the entry on the top is not more important than the entry on the bottom. Every static route (without any "preference" set) has the same priority, independently if they are seen on the top or on the bottom.

 

 

b) in the bgp outputs, it is seen ISP2 is used to route the traffic more , specifics as compared to ISP1.

which configuration portion defines this?

 

A: It is this configuration:

 

policy-statement sendroute-isp2 {     
    term 1 {                           
        from {                         
            protocol static;           
            route-filter 192.168.100.0/24 exact;
            route-filter 192.168.241.0/24 orlonger;
            route-filter 192.168.242.0/24 orlonger;
                    }                             
        then accept;                   
    }                                 
    term 2 {                           
        then reject;

You have to replace the "orlonger" with the "exact" statement in this case, the same as for "policy-statement sendroute-isp1".

That helped me again, thanks for being patient.

Does my understanding on below ones seem correct? 

 

a) route-filter 192.168.241.0/24 orlonger - match & route 192.168.241.0/24 statics or anything that is greater in mask & more matching within the range . eg. 192.168.241.0/29 or 192.168.241.0/28 ?

b) route-filter 192.168.242.0/24 exact - match & route only 192.168.242.0/24. eg. will not route 192.168.242.0/27?

 

If under a scenario where ISP2 allocates another /27 (eg. 192.168.10.0/27) range , how should that be included within the current configurations & what will be the best way to add this (added out via both ISP links or just once etc.)

 

 

 

 

> a) route-filter 192.168.241.0/24 orlonger - match & route 192.168.241.0/24 statics or anything that is greater in mask & more matching within the range . eg. 192.168.241.0/29 or 192.168.241.0/28 ?

 

A: Correct, this means that /24 upto /32 can be announced to your ISP.

 

> b) route-filter 192.168.242.0/24 exact - match & route only 192.168.242.0/24. eg. will not route 192.168.242.0/27?

 

A: Correct as well.

 

 

> If under a scenario where ISP2 allocates another /27 (eg. 192.168.10.0/27) range ,

> how should that be included within the current configurations & what will be the best way to add this

> (added out via both ISP links or just once etc.)

 

A: ISPs never allocate a prefix more-specific than /24 for public ISP BGP connections. They can just allocate a prefix like 192.168.10.0/24 or bigger (= less specific).

 

In this case, just configure these three statements:

set policy-options policy-statement sendroute-isp1 term 1 from route-filter 192.168.10.0/24 exact
set policy-options policy-statement sendroute-isp2 term 1 from route-filter 192.168.10.0/24 exact

set routing-options static route 192.168.10.0/24 discard

 

This starts the announcement to your both upstreams.

Your response is much appreciated F1ght3r. apologies i should have been clearer.

1) 192.168.10.0/27 is an additional range that ISP2 has allocated to us. our organisation plans to use this for any new services that will host at our datacentre.

As its been given from ISP2, do i not advertise it via ISP1 or if it is advertised via ISP1 also will it cause any issues as its advertised via both ISP's?

2) for the configuration below that speaks about getting bgp route

a) what does this actually accomplish?
b) why and what is the reject statement indicate?

 

policy-statement getroute-isp1 {
term 1 {
from {
protocol bgp;
route-filter 192.168.241.0/24 orlonger;
route-filter 192.168.242.0/24 orlonger;
route-filter 192.168.100.0/24 exact;
}
then reject;
}
term 2 {
then accept;
}
}
policy-statement getroute-isp2 {
term 1 {
from {
protocol bgp;
route-filter 192.168.241.0/24 orlonger;
route-filter 192.168.242.0/24 orlonger;
route-filter 192.168.100.0/24 exact;
}
then reject;
}
term 2 {
then accept;

 

Hello Suthomas,

 

Answer 1)

If this is a public /27 prefix to be reachable by all Internet hosts, this will not be routed by BGP. Instead, this would be routed statically by ISP2 to your Router so that you can use this internally. Please note that this /27 prefix would not be redundant in this case, it can only be reachable by ISP2. If this ISP2 circuit breaks, this /27 prefix is not reachable any more.

This has to do that only prefixes >= /24 (e.g., /23, /22, ...) can by announced by BGP to the public Internet.

 

Answer 2a and b)

This policy tells the Router to accept all prefixes from your BGP peer EXCEPT for these 3 mentioned exact or orlonger prefixes. This makes sure that your Router does not send any traffic to these prefixes to your ISPs by accident.

 

1) Does that /27 need to be included in any or one of the getroute-isp or isp2 policy statements? in my view it should be in the getroute-isp2 bgp statements.

 

2) This makes sure that your Router does not send any traffic to these prefixes to your ISPs by accident

  I didn't grap this very well. Is it referring such that because those subnets belong to us, it need not be learnt     via bgp by us?

 

 

 

Answer 1) No, because you can't route a public used /27 by BGP, this has to be done statically, so there is no need to include this into the getroute or sendroute policy-statements. These statements are only necessary for BGP routing.

 

Answer 2) I meant that it is a best practice to filter prefixes that should not be learned from the outside. As you want to send all traffic to your /24 prefixes to your local LAN instead to your ISPs, you should block the learning of your locally used prefixes from your ISPs.

Advertising /24 routes to both the ISPs shouldn't be a problem instead its good for redundancy purpose. You can use AS-PREPEND knob to influence inbound traffic from a particular ISP (generally opted) -- follow the design requirements. 

If needed, you can also verify presence of routes on public route servers.

Thank you again.

I will take the liberty of asking about the additional 192.168.10.0/27 range again for advertisements.ISP2 has allocated to us & we have been told it is included in bgp on isp2 end. our organisation plans to use this for any new services that will host at our datacentre.

So in order to use this for hosting new services in our datacentre, where in my original configuration should the new segment be included so these services are reachable via internet using any of IP within that range?

Will it still be the below ones.

 

set policy-options policy-statement sendroute-isp1 term 1 from route-filter 192.168.10.0/24 exact
set policy-options policy-statement sendroute-isp2 term 1 from route-filter 192.168.10.0/24 exact

set routing-options static route 192.168.10.0/24 discard

 

You can try advertising the /27 towards the ISP2(one who allocated the pool to you) just to be sure but they should be doing static routing for the /27 towards you and advertising the related lower subnet prefix(/24 or lower) towards further in internet.

The reason that you can’t /27 towards another provider is providers filters more specific routes before advertising to internet and hence it’s unlikely that you’ll find higher than /24 prefixes on public Route servers.

You’ll have single point failure in this case, as in if the link with ISP2 goes down then the connectivity with those hosted on the /27 will be lost from internet.

Thanks, I missed to change the statements. Does the configuration for advertising 192.168.10.0/27 fit correctly in sending it to isp2. Does the "exact" statement with 192.168.10.0/27 make sense?

 

Apart from this, if this extra /27 is divided into two /29's, will advertising the whole as 192.168.10.0/27 exact be fine & work.

 

policy-statement sendroute-isp2 {
term 1 {
from {
protocol static;
route-filter 192.168.100.0/24 exact;
route-filter 192.168.241.0/24 orlonger;
route-filter 192.168.242.0/24 orlonger;
route-filter 192.168.10.0/27 exact;
}
then accept;
}
term 2 {
then reject;

Firstly, you need to check with provider if they’ll be accepting the /27 you advertise. Moreover, You can divide /27 in your network however you want and advertise the whole /27 to them (if they agree for BGP advertisement)

The configuration looks perfect, but instead of using “orlonger” with /24’s use “exact” because anyways the specific prefixes will be dropped even if you advertise them.

The tool you can use to see what routes junos is sending to your peers is

 

show route advertising-protocol bgp 10.2.2.1

show route advertising-protocol bgp 10.5.5.1