Task 5.1 BGP

In order to achieve stable and reachable routes to all BGP learnt prefixes I had to add the following configuration to the solution:

1) R5. Filter EIGRP external (AD 170) learnt routes within RIP process on R5. These routes (112.0.0.0/9 through 119.0.0.0/8 and 28.119.16.0/24 and 28.119.17.0/24) were redistributed into EIGRP from BGP on R6. The routes were being redistributed into OSPF on R5 and then redistributed by R4 in RIP and hence learnt by R5 through RIP (AD 120). I increased AD on R5 for these routes in RIP to 171.

router rip
distance 171 0.0.0.0 255.255.255.255 EIGRP-EXTERNAL

ip access-list standard EIGRP-EXTERNAL
permit 112.0.0.0
permit 113.0.0.0
permit 114.0.0.0
permit 115.0.0.0
permit 116.0.0.0
permit 117.0.0.0
permit 118.0.0.0
permit 119.0.0.0
permit 28.119.17.0
permit 28.119.16.0

2) R6. Filter advertisement of EIGRP external routes (via BGP -> EIGRP) to BB1. Otherwise 28.119.16.0/24 and 28.119.17.0/24 router are advertised to BB1; BB1 then prefers R6 for these prefixes over the same (iBGP) prefixes from BB3 (and hence no connectivity to these prefixes)!

router eigrp 10
distribute-list EIGRP-EXTERNAL out Serial0/0/0.101

ip access-list standard EIGRP-EXTERNAL
deny 112.0.0.0
deny 113.0.0.0
deny 114.0.0.0
deny 115.0.0.0
deny 116.0.0.0
deny 117.0.0.0
deny 118.0.0.0
deny 119.0.0.0
deny 28.119.17.0
deny 28.119.16.0
permit any

Any thoughts anyone? Hope this helps someone.

Comments

  • Hello ,

    Sorry for my question, I did not test the lab yet by my hand, but while I'm reading it I can't understand why we need redistribution between the BGP and the IGP , I may missed something here , but I can see that there is IGP between the BB routers and the Internal network , and full IGP redistribtion , so all the IGP routes should be advertised already to the BB routs

    and the BGP routes is advertised via the BGP to the internal network !!!!

    where is the exact point that weneed redistribution from the BGP to the IGP ??

    Thanks
  • I think in this Lab some not all BB routes are advertised via IGP to the Network.
    So if we do not want to disable synchronization we will need to redistribute BGP->IGP
    However I faced some problems with R1 not able to synchronize the BGP networks even when it has an internal IGP route learned via OSPF ???
  • As per below on R1 BGP shows this as not synchronized even when there is an OSPF IGP route to same destination.
    R2 however does not have this issue
    For me this is really strange and I might need to read more about BGP synchronization

    Rack1R1#sh ip bgp 28.119.16.0/24
    BGP routing table entry for 28.119.16.0/24, version 0
    Paths: (1 available, no best path)
    Not advertised to any peer
    54
    54.1.1.254 (metric 20) from 150.1.6.6 (150.1.6.6)
    Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
    Rack1R1#sh ip route 28.119.16.0
    Routing entry for 28.119.16.0/24
    Known via "ospf 1", distance 110, metric 20
    Tag 54, type extern 2, forward metric 64
    Last update from 190.1.135.5 on Serial1/0, 00:01:50 ago
    Routing Descriptor Blocks:
    * 190.1.135.5, from 150.1.5.5, 00:01:50 ago, via Serial1/0
    Route metric is 20, traffic share count is 1

    Rack1R2#sh ip bgp 28.119.16.0/24
    BGP routing table entry for 28.119.16.0/24, version 12
    Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
    Not advertised to any peer
    54
    54.1.1.254 (metric 2172416) from 150.1.6.6 (150.1.6.6)
    Origin IGP, metric 0, localpref 100, valid, internal, synchronized, best
  • In the solution guide of section 5.1
    At first i did not understand the need of the following lines

    network 190.1.0.0 mask 255.255.255.0
    aggregate-address 190.1.0.0 255.255.0.0 summary-only

    Later i figured out it is needed so that BB routers can find route back to the Network

    My question: Is it required that BB routers have routes to loopback IPs too in the range of 150.1.0.0/16 ??
  • Another question regarding advertising the network 190.1.0.0/16
    Why don't we need to advertise the same on R3 to BB2
    In our scenario we do not need it because there is no routers behind BB2 but I shouldn't really know that in the lab exam

    In case of BB1 it learned some BGP networks from BB3 and hence BB3 needs to have routes to 190.1.0.0/16 if I want to ping these networks

    Network Next Hop
    *>i28.119.16.0/24 172.16.4.3
    *>i28.119.17.0/24 172.16.4.3
  • Hi John

    Really useful post - i have been scratching my head a little. Were you able to tell this had happened without looking on the BB routers? If so, what info were you looking at?

    Cheers
    Andy
  • Hi,

    The BB routers are already running IGP with the core routers. so all the BB routers know about the network 190.1.0.0 by IGP. Do the network will be already in the routing table, so do we again advertise them in BGP. Please correct me if i am missing anything.

    Thanks,
    Vignesh
  • The problem in case was the redistribution of bgp into eigrp on R6. Required to stop R5 (no bgp running) from black-hole-ing connectivity to BB1 bgp routes from R3.
    Because we had igp connectivity to BB1 it received the redistributed routes back through eigrp with an AD of 170. This was no problem for routes 112 - 119 as they were directly connected interfaces BB1 and so had a lower AD. However 28.119 prefixes were learned by BB1 via ibgp from another BB router before they were propagated to R6 and as such they had an AD of 200. When BB1 recieved the eigrp routes with a lower AD it installed them via R6. A simple distribute list on R6 denying these routes fixes it up.

    hope this helps
    cheers
    Andy
  • Andy,

    Could you please tell me what is the need for the following command network 190.1.0.0 mask 255.255.255.0 under BGP.This network is already known to the Backbone routers via IGP like Eigrp in BB1, RIP in BB2 and BB3. And why again we are advertising the network 190.1.0.0 in BGP.
  • The igp was running between BB1 and R6 so BB1 has a route back to 190.1.0.0.

    However the 28.119 routes were learnt by BB1 from BB3. When we ping these addresses the packets are forwarded by BB1 to BB3. BB3 and BB1 only share routes via BGP so we have to get the source addresses of our pings into BGP. In this case the 190.1.0.0 summary covers that.
  • Hi Guys, I made the following to solve the problem related to black holing in R5:

    **************************************************
    R1 configuration:

    router ospf 1
    redistribute bgp 100 metric 201 subnets

    router bgp 100
    bgp redistribute-internal
    **************************************************

    So, all bgp enabled routers will not install bgp redistributed routes via IGP.

    What do you think about it ?

    Diogo.
Sign In or Register to comment.