eBGP and iBGP configuration with 2 different IPS

[agibulhasan]

Hi,

I am in the process of deploying a new network scenario as per the design outlined in the attached design document (design.png).

Additionally, I have prepared a BGP configuration file (bgp configuration.docx) according to the diagram that I would like to request to review the BGP configuration file.

Could you please check the configuration and provide any feedback on its correctness?

Your expertise would be invaluable in ensuring that the deployment aligns with our design requirements.

Thank you in advance for your assistance!

[agibulhasan]

Interface Configuration:

"interface 0/0/0  ip address 10.10.10.1 255.255.255.252"                       !                                                               "interface 0/0/1  ip address 10.10.11.1 255.255.255.252"                       !                                               "interface 0/0/5  ip address 10.10.50.1 255.255.255.252"                       !                                                               "interface 0/0/4  ip address 10.10.100.3 255.255.255.0"

"interface 0/0/0  ip address 10.10.20.1 255.255.255.252"                       !                                                               "interface 0/0/1  ip address 10.10.21.1 255.255.255.252"                       !                                                               "interface 0/0/5  ip address 10.10.50.2 255.255.255.252"                       !                                                               "interface 0/0/5  ip address 10.10.100.4 255.255.255.0"

eBGP with iBGP:

router bgp 45532  bgp always-compare-med  bgp log-neighbor-changes  neighbor 10.10.50.2 remote-as 45532  neighbor 10.10.50.2 description iBGP WITH ROUTER2  neighbor 10.10.10.2 remote-as 23688  neighbor 10.10.10.2 description “eBGP with Primary ISP1”  neighbor 10.10.11.2 remote-as 17806  neighbor 10.10.11.2 description “eBGP with Primary ISP2”  !  address-family ipv4   network 10.10.100.0 mask 255.255.255.0   network 10.10.50.0 mask 255.255.255.252      neighbor 10.10.50.2 activate   neighbor 10.10.50.2 route-reflector-client   neighbor 10.10.50.2 next-hop-self   neighbor 10.10.50.2 prefix-list ROUTER1 out   neighbor 10.10.10.2 activate   neighbor 10.10.10.2 weight 4000   neighbor 10.10.10.2 soft-reconfiguration inbound   neighbor 10.10.10.2 prefix-list Primary_ISP1-in in   neighbor 10.10.10.2 route-map Primary_ISP1-out out   neighbor 10.10.11.2 activate   neighbor 10.10.11.2 weight 3000   neighbor 10.10.11.2 soft-reconfiguration inbound   neighbor 10.10.11.2 prefix-list Primary_ISP2-in in   neighbor 10.10.11.2 route-map Primary_ISP2-out out maximum-paths 2 exit-address-family

router bgp 45532  bgp always-compare-med  bgp log-neighbor-changes neighbor 10.10.50.1 remote-as 45532  neighbor 10.10.50.1 description iBGP WITH ROUTER1  neighbor 10.10.20.2 remote-as 23688  neighbor 10.10.10.2 description “eBGP with Secondary ISP1”  neighbor 10.10.21.2 remote-as 17806  neighbor 10.10.21.2 description “eBGP with Secondary ISP2” !  address-family ipv4   network 10.10.100.0 mask 255.255.255.0   network 10.10.50.0 mask 255.255.255.252      neighbor 10.10.50.1 activate   neighbor 10.10.50.1 next-hop-self   neighbor 10.10.50.1 prefix-list ROUTER2 out   neighbor 10.10.20.2 activate   neighbor 10.10.20.2 weight 2000   neighbor 10.10.20.2 soft-reconfiguration inbound   neighbor 10.10.20.2 prefix-list Secondary _ISP1-in in   neighbor 10.10.20.2 route-map Secondary _ISP1-in out   neighbor 10.10.21.2 activate   neighbor 10.10.21.2 weight 1000   neighbor 10.10.21.2 soft-reconfiguration inbound   neighbor 10.10.21.2 prefix-list Secondary _ISP2-in in   neighbor 10.10.21.2 route-map Secondary _ISP2-out out maximum-paths 2 exit-address-family

IP ROUTE:

ip route 10.10.10.0 255.255.255.252 10.10.100.2 name Primary­_ISP1 To DMZ_Fw ip route 10.10.11.0 255.255.255.252 10.10.100.2 name Primary­_ISP2 To DMZ_Fw

ip route 10.10.20.0 255.255.255.252 10.10.100.2 name Secondary­_ISP1 To DMZ_Fw ip route 10.10.21.0 255.255.255.252 10.10.100.2 name Secondary­_ISP2 To DMZ_Fw

IP PREFIX LIST:

ip prefix-list Primary _ISP1-in seq 10 permit 0.0.0.0/0 ip prefix-list Primary _ISP1-in seq 20 deny 0.0.0.0/0 le 32 ! ip prefix-list Primary _ISP1-out seq 30 permit 10.10.100.0 /24 ! ip prefix-list Primary _ISP2-in seq 10 permit 0.0.0.0/0 ip prefix-list Primary _ISP2-in seq 20 deny 0.0.0.0/0 le 32 ! ip prefix-list Primary_ISP2-out seq 30 permit 10.10.100.0 /24 ! ip prefix-list ROUTER1 -in seq 10 permit 0.0.0.0/0 ip prefix-list ROUTER1 -in seq 20 deny 0.0.0.0/0 le 32

ip prefix-list Secondary _ISP1-in seq 10 permit 0.0.0.0/0 ip prefix-list Secondary _ISP1-in seq 20 deny 0.0.0.0/0 le 32 ! ip prefix-list Secondary _ISP1-out seq 30 permit 10.10.100.0 /24 ! ip prefix-list Secondary _ISP2-in seq 10 permit 0.0.0.0/0 ip prefix-list Secondary _ISP2-in seq 20 deny 0.0.0.0/0 le 32 ! ip prefix-list Secondary _ISP2-out seq 30 permit 10.10.100.0 /24 ! ip prefix-list ROUTER2 -in seq 10 permit 0.0.0.0/0 ip prefix-list ROUTER2 -in seq 20 deny 0.0.0.0/0 le 32 !

ROUTE MAP:

route-map Primary _ISP1-out permit 10  match ip address prefix-list Primary _ISP1-out ! route-map Primary _ISP2-out permit 10  match ip address prefix-list Primary _ISP2-out !

route-map Secondary _ISP1-out permit 10  match ip address prefix-list Secondary _ISP1-out ! route-map Secondary _ISP2-out permit 10  match ip address prefix-list Secondary _ISP2-out

[MHM Cisco World]

neighbor 10.10.50.2 route-reflector-client <<- why route reflect between two ibgp routers???

MHM

[Giuseppe Larosa]

Hello @agibulhasan ,

your proposed configuration can be improved in several ways and some of the points of attention have been already described by @MHM Cisco World and by @paul driver .

a) you don't need to make the second border router a BGP route reflector client of first router to receive the eBGP routes that R2 learns from its own eBGP neighbors from ISP1 CP202 and ISP2 CPE02.

b) it is important to avoid to become a transit AS between ISP1 and ISP2 Paul has described how you can implement a route-map that does not depends on an IP prefix-list but just checks for AS path attribute to be empty ^$ this happens only  local routes within your AS. ( your AS number is added to the prefix when preparing the updates, ISP1 and ISP2 sees an AS path equal to your ASNumber followed by the origin code ( i if you use network command)

c) the most important one IMHO is you have two border routers and not one with an iBGP session between them.

Cisco weight is NOT a BGP attribute and it does not travel inside BGP advertisements you need to use local-prefence instead.

So I would suggest you to remove all neighbors x.x..x.x weight commands.

You can use instead:

on R1:

neighbor x.x.x.x local-preference    <value>

the default local preference is 100. Highest value is preferred.

Example

neighbor 10.10.10.2 local-preference 4000

neighbor 10.10.11.2 local-preference 3000

on R2:

neighbor 10.10.20.2 local-preference 2000

neighbor 10.10.21.2 local-preference 1000

Let me explain why it is better to use local-preference instead of weight:

you can take advantage of the iBGP session to use hierarchy like the following

ISP 1 CPE 01 first

ISP1 CPE 02 second

ISP2 CPE 01 third

ISP2 CPE 02 fourth.

this cannot be achieved using weight.

When the first link fails or the eBGP session fails, R1 can use CPE02 of ISP1 .

This provides the advantage of keeping the same provider and  it provides benefits if NAT is involved.

With local-preference is still possible to implement a different hierarchy like the one proposed above.

edit:

you can add an action

set local-preference <value> within each of route-maps to achieve setting of local preference to different values.

it looks like the command suggested above at neighbor level has vanished or my memory failed.

the following describes a command to rise local preference at router bgp process level

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-a1.html#wp9538078130

bgp default local-preference 200

this under R1 can be enough if you want to implement a hierarchy like the one you have provided-

Hope to help

Giuseppe

[paul driver]

Hello @Giuseppe Larosa 
your absolutely correct, TBH i didn't proof read my post correctly, apologies to the OP @agibulhasan 

[agibulhasan]

Thanks

[paul driver]

Hello
I noticed you are wanting to utilise med between ISP for load-balancing, comparing from either ISP, As-path is more preferred in bgp best path selection and you could use if you relax its default behaviour as needing to have the same as-path in it as-sequence, so it just looks as the as-path length instead.

However based on your topology and given that you are only receiving a default route and advertising a single subnet implementing load balancing multipath can be achieved egress but ingress from the ISP you really would have no control regards the return path a such you’d probably experienced asymmetric routing.

load sharing between the ISPs is more applicable, egress you could use local preference and not weight on each multihomed router and as-path prepending to the less preferred ISP, that will still leave the return from either ISP choosing its own dual path back towards your site, possibly asymmetrically.

You would defiantly need to make sure you do not become  transit path for either ISP which you could accomplished with a simple regular expression filter.

I envisaged bgp soft-reconfiguration inbound would not be applicable either due to the routers most probably being route-refresh capable.

bgp soft-reconfiguration inbound is used save all unchanged routing updates information from it bgp peers so that information can be called upon when a reconfiguration of a bgp policy is required and a soft reset is performed to that peer so to activate those changed policy , However this comes at a cost to the memory resource of the routers storing this information, especially if you are receiving a full routing table, on the other hand route-refresh resets ingress route policies dynamically requesting these changes to its bgp peers so it doesn’t have to store bgp updates locally so its less resource intensive for the local routers.

Lastly route-reflector isn’t applicable also. edited- I would envisage also you probably require to run an igp (ospf) on your internal interfaces for transit reachabilty between the local rts and the lan

Attached is a possible basic example based on the above.

[MHM Cisco World]

[paul driver]

Hello
B- I would say yes there is, the local rtrs need to understand and beware of each other bgp rib tables additionally its used for LP to incase either local rtr losing its primary connection to the specified ISP.
it is also used to specify that primary ISP connection otherwise the local rtr would choose either of its own ebgp connection too either ISP as primary (hot patato) 

[MHM Cisco World]

""B- I would say yes there is, the local rtrs need to understand and beware of each other bgp rib tables additionally its used for LP to incase either local rtr losing its primary connection to the specified ISP.
it is also used to specify that primary ISP connection otherwise the local rtr would choose either of its own ebgp connection too either ISP as primary (hot patato)""

Friend regarding point B and C 

B no need ibgp since as I mention each Rtr have direct connect to both ISP' but to and to correct point C each Rtr need weight to prefer one ISP than other that are directly connected.

Or you can use both ISP load balance (without need for weight).

MHM

[paul driver]

Hello @MHM Cisco World 
Possibly suggest if applicable you make one of your labs and test it, you should then see the requirement