I was making my own topology for BGP Confederation, I had divided one AS 2 into two sub AS, 100 and 200 and in each sub AS I had configured route -reflector, the router which is connected to the EBGP on both the Sub As is having an error for
This failure is due to the fact that there seems to be routing information about this route that is coming from another source that has a lower administrative distance (BGP has the higher AD so it fails or loses, and the route is not added). Can you check to see the source of that higher AD and see where it is coming from? If you find that out, then you can adjust ADs to result in the BGP routes that you want installed.
88.1.1.2 is the interface of R8 from where I had configured BGP on this router which has interface add 88.1.1.1, I need to increase AD on R8 as it is on different AS 3 and R7 is on A2.
Can you please upload any videos on it so which can help why it occur where we use iBGP internally and what is the best solution to fix this issue.
Forgive me, but Iâm still trying to understand the nature of the problem. Why are you changing the AD on R8, and if so, I donât see it in your configuration. And if youâre getting an issue with AD, this means that the router is learning of the route from a different source, which we donât see in what you provided. Can you clarify further so that we can aid in troubleshooting?
R1 is in AS 1, R2, R3, R4, R5, R6, R7 are in AS 2, R3 is in AS 3.
All the neighborship between AS are done via loopback address and in AS2 I am using OSPF to advertise the connectivity, in iBGP I had configured two RR servers that is R3 and R6, I am able to ping from AS 3 to AS 1, but internally in AS 2 i am not able to ping R8 or R1 and the router R2 and R7 are showing
The RIB failure is not necessarily a problem. It seems here that R7 sees that it has a directly connected route of 88.1.1.0/24 in its routing table, which automatically outranks the AD of the route learned via BGP, which is as it should be.
My question is, why does R7 receive routing information to a network that is directly connected? Is 88.1.1.0/24 being advertised via OSPF as well? Can you clarify this information so we can further troubleshoot?
Yes, 88.1.1.0/24 is directly connected between R7 and R8, EBGP is configured via R7 and R8 on the interface which has ip add 88.1.1.0/24. I had advertised 88.1.1.0/24 on R8 via BGP, there is no OSPF advertisement of this network.
The RIB-failure statement you are getting states that the router is learning of the 88.1.1.0/24 network from BGP. This however is a directly connected network, and should be in your routing table as such. The conflict comes from the fact that the AD of the directly connected route outranks the AD of the route being learned via BGP. However, my question is WHY is BGP advertising this route to a router that is directly connected to it? Can you investigate in this direction?
Then it is natural that you will have such a message from BGP. This is not necessarily incorrect, and based on the design, is to be expected. The problem you are facing is independent of the specific BGP message that you are sharing. You will have to look elsewhere for the specific problem.
Our goal here is to help you pinpoint the problem by giving some guidelines, or information concerning the next steps to take. I hop this helps you in your troubleshooting procedures.
Hi Navraj,
As Laz said this is independent of the RIB failure likely as its a connected network for R7. You need to break it down to see where is the connectivity getting lost ? Have you tried some basic checks? May be a traceroute from your internal AS2 router to R8 ? See where is it getting broken. Look at the routing table of it and see if it has a route ? Also it is very important to understand that unless you advertise your internal prefixes in AS2 , there wont be return route in R8 or R1. So this is something to troubleshoot step by step. Hope this helps.
Thanks,
M
Infact I set up a similar lab and I donât see any problem. I am able to ping between R1<<>>R8
R8#ping 1.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 8.8.8.8
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/102/132 ms
R8#
R1#ping 8.8.8.8 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/137/220 ms
R1#
And if I ping from the AS2 I am not able to ping.
R4#ping 8.8.8.8 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
.....
Success rate is 0 percent (0/5)
R4#
Its because R8 or R1 donât have any return routes to R4.
R8#show ip route 4.4.4.4
% Network not in table
R8#
As soon as I advertize 4.4.4.4 in my IBGP , I am able to ping it.
R4#sh run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 2
bgp confederation peers 200
**network 4.4.4.4 mask 255.255.255.255 >>>>>>> Advertizing 4.4.4.4**
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback0
neighbor 5.5.5.5 remote-as 200
neighbor 5.5.5.5 ebgp-multihop 2
neighbor 5.5.5.5 update-source Loopback0
no auto-summary
R4#
R4#ping 8.8.8.8 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
So it has no relation to RIB failure or Confedaration or Route-reflector within Sub-AS. I assume you are not advertising the internal subnet of AS 2 in your BGP.
Suppose we a have topology in which R2-R3-R6 and R4-R5-R7 ( As per topology using by you in confederation topic only difference is that I connected R6&R7 next to R3&R5) are connected to each other in same AS then can we perform confederation if yes then how we divide these routers in sub-ASes to get minimun IBGP peering ?
Based on your description, I wasnât able to find the lesson about which you are speaking. The lesson on confederations uses five routers, R1 through R5. However, I can respond to your question more generally.
As long as all the routers in a particular AS can communicate with each other (that is, they are able to achieve full mesh iBGP peerings) it is possible to subdivide such a topology into two or more confederations. You can simply follow the logic in the lesson to configure such a topology.
In general, it is a good idea to strike a balance between the number of confederations and the number of routers per confederation. There is no point in having too few, or too many routers within each confederation, or too few or too many confederations within an AS. Configuration complexity is lowest when the number of confederations within an AS is about the same as the number of routers within each confederation.
Hi Laz,
I am speaking about the 5-Routers topology we used in confederation topic, Only added two more routers R6 connected next to R3 and R7 connected next to R5( R6 and R7 are also connected to each other) so if now you understand my query then please teach me how can we use confederation concept here and in how many ways ?
In brief connectivity like that ::
When configuring confederations within a single AS, the rules you have to follow are these:
Routers within the sub-ASâes must have full mesh iBGP peerings.
Interconnection between sub-ASâes donât need to be full mesh, you simply need at least one peering between routers in different sub-ASâes.
So essentially, either router R6 or R7, which both belong to AS 67 simply need a single peering to either R2, R3, R4, or R5 in order to be successfully added as a sub-AS to AS2.
You can choose whatever peerings you want between routers in different sub-ASâes, as long as there is one peering for each sub-AS.
RIB failures occur when a route (with the same prefix and prefix length) is learned via BGP, but already exists in the routing table with a lower AD. I suggest you do the following:
take a look at the routing table of the routers and see if the routes that have the RIB failure are also being learned via OSPF or even via a static route. iBGP has an AD of 200, while OSPF has an AD of 110 and static routes an AD of 1.
Make sure that OSPF is being used to advertise only the subnets between the routers, and the loopbacks used for the router IDs. BGP should be used to advertise only the 55.55.55.55 network on R5, and the 11.11.11.11 network on R1.