Hi,
problem solved, It was caused by my attempt to redistribuite the bgp into ospf process…
1 Like
No i have another question.
I’m tryng to trace 11.11.11.11 from R5.
R5#traceroute 11.11.11.11 source loopback 0
Type escape sequence to abort.
Tracing the route to 11.11.11.11
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.35.3 17 msec
192.168.45.4 13 msec
192.168.35.3 6 msec
2 192.168.24.2 12 msec
192.168.23.2 7 msec
192.168.24.2 8 msec
3 192.168.12.1 [AS 24] 13 msec 9 msec 8 msec
R5#
Can you help me to interpret this output?
Thanks
Hello Giovanni
Traceroute will always send three packets for each TTL. In other words, it will begin by sending three packets with a TTL of 1, and then another three with a TTL of 2, another three with a TTL of 3 and so on until it gets to the destination. For each iteration, it gets a response back from whatever router it reaches with that TTL value.
Now keeping that in mind, let’s take a look at the routing table of R5:
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/3] via 192.168.45.4, 00:04:26, GigabitEthernet0/1
[110/3] via 192.168.35.3, 00:04:26, GigabitEthernet0/2
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 192.168.35.3, 00:04:26, GigabitEthernet0/2
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/2] via 192.168.45.4, 00:04:26, GigabitEthernet0/1
5.0.0.0/32 is subnetted, 1 subnets
C 5.5.5.5 is directly connected, Loopback0
11.0.0.0/32 is subnetted, 1 subnets
B 11.11.11.11 [200/0] via 192.168.12.1, 00:03:22
55.0.0.0/32 is subnetted, 1 subnets
C 55.55.55.55 is directly connected, Loopback5
B 192.168.12.0/24 [200/0] via 2.2.2.2, 00:03:27
O 192.168.23.0/24 [110/2] via 192.168.35.3, 00:04:26, GigabitEthernet0/2
O 192.168.24.0/24 [110/2] via 192.168.45.4, 00:04:26, GigabitEthernet0/1
192.168.35.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.35.0/24 is directly connected, GigabitEthernet0/2
L 192.168.35.5/32 is directly connected, GigabitEthernet0/2
192.168.45.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.45.0/24 is directly connected, GigabitEthernet0/1
L 192.168.45.5/32 is directly connected, GigabitEthernet0/1
Now remember, that OSPF is being run within AS2, and by default, equal cost load balancing is enabled. So when R5 pings 11.11.11.11, we can see what happens when we look at the routing table:
- There is an entry for 11.11.11.11 which is learned via BGP. It can be reached via 192.168.12.1 which is the next hop eBGP router
- How do we reach 192.168.12.1? There is another BGP route that tells us we can reach it via 2.2.2.2.
- How do we reach 2.2.2.2? There are two OSPF equal cost routes that get us there, via 192.168.35.3 and 192.168.45.4.
Equal cost load balancing, when using something like traceroute (which uses UDP) will take place on a per packet basis. So, packets are alternated between the two routes. This is why you see responses alternating between the two possible paths you can take.
In the last entry, all three responses came from Fa0/0 on R1, so they weren’t explicitly stated. But you can see this from the three response times that are indicated.
I hope this has been helpful!
Laz
Hi Guys,
Great lesson. I just want to confirm something for myself.
To quote: “R3 is in a different sub-AS than R2, you can see that it says confed-external. Something important to note is that the next hop IP address didn’t change. When you use regular EBGP, a router changes the next hop IP address of a route to its own IP address when it sends the route to another EBGP router.”
Are you saying that in typical eBGP circumstances, R2 would advertise the route to R3 and change the next hop to the interface it advertised the route out of e.g. “192.168.23.2” ?
Hello Joseph
Yes, that’s exactly correct. The next-hop IP for a prefix found outside of your local AS is always the IP address of the eBGP router that advertised it into your local AS. For example, take a look at this topology:
The next-hop IP address that R1 has in its BGP table for the 3.3.3.0/24 subnet is 192.168.23.3, which is the address of R3, which is the eBGP router that advertised the network into AS12 in the first place.
The difference that Rene is emphasizing in the statements you mentioned is that even though R2 and R3 are using eBGP (different sub-AS’es), the next-hop IP that R3 sees is that of R1, and not that of R2. This is because the R2-R3 BGP peering is not regular eBGP, but an eBGP peering between sub-AS’es.
I hope this has been helpful!
Laz
1 Like
Spot on, thanks man.
1 Like
I must be missing something. So you have to have two BGP processes running on your router, but if you try to configure a second process is says BGP is already running. What am I not understanding?
Hello Chad
Actually, you are only running a single BGP process in each router using the AS number of the sub-AS to which the router belongs. You can then configure the confederation AS containing the sub-AS’es as the confederation identifier.
In other words
- Routers in the same sub-AS and the same confederation AS will have the same BGP number and the same confederation identifier in their configurations.
- Routers in different sub-AS’es but in the same confederation AS will have different BGP numbers but the same confederation identifier in their configurations.
In both cases, however, there is only a single BGP process running under which both confederation and sub-AS’es are configured.
I hope this has been helpful!
Laz
Hello Rene,
Could you please explain why the internal route is preferred over the external.
R5#show ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.11/32, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
2
(24) 1
192.168.12.1 (metric 3) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, confed-external
(24) 1
192.168.12.1 (metric 3) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
As per my knowledge the confed-external should be preferred.
Thanks
Hello Luis
When confederations are involved, this Cisco Documentation states that some things are calculated differently, depending upon the configuration. By default, any confederation sub-AS does not actually participate in the best path selection process. All routers within a confederation AS are dealt with as if they were in a normal AS, and sub-AS’es are ignored.
Specifically, the document states that for AS_PATH, any confederation AS’es are not included in the AS path length. Also for MED, unless the bgp bestpath med-confed command is enabled, MEDs are not compared for any sub-AS. Also, for eBGP and iBGP comparison, it states explicitly that:
There is no distinction between Confederation External and Confederation Internal.
Therefore, if you go through all of the attributes you will find that they are all the same until you come to router ID. 3.3.3.3 is a lower router ID than 4.4.4.4, so that one is chosen.
I hope this has been helpful!
Laz
Hello Laz,
Thanks a lot.
1 Like
Hi,
why I cannot arrive to 11.11.11.11 from none router but R2?
R5#ping 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5#traceroute 11.11.11.11
Type escape sequence to abort.
Tracing the route to 11.11.11.11
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.35.3 44 msec
192.168.45.4 32 msec
192.168.35.3 20 msec
2 192.168.24.2 60 msec
192.168.23.2 64 msec
192.168.24.2 48 msec
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
Hello Fran
This is expected behaviour. You will notice that the 11.11.11.11 prefix in all four of the routers in AS2 shows a next-hop IP address of 192.168.12.1. This is the IP address of R1. Now only R2 knows this next-hop IP address, because it is directly connected, and because it is an eBGP neighbor with R1. The 192.168.12.1 IP address does not appear in the routing table of any other router (R3, R4 and R5) so no other router can actually get there!
Now in order to resolve this issue, you must use BGP’s next-hop-self feature. This will cause R2 to advertise the 11.11.11.11 prefix with itself as the next hop, rather than the eBGP neighbor as the next hop. You can find out more about this feature at the following lesson:
Now the purpose of the BGP Confederation lesson was to see how prefixes are shared by BGP routers, and how they appear in the BGP tables. This is the reason why Rene didn’t go into the details of the next-hop-self feature and only focused on how the distribution of the prefixes is achieved.
I hope this has been helpful!
Laz
1 Like
Understood! thanks so much for explanation
regards
fran
1 Like
Hey Rene,
Great lesson! I am a bit confused by R2’s configuration in section “1.2 BGP Confederation Configuration”. For the command below:
R2(config-router)#neighbor 3.3.3.3 ebgp-multihop 2
I thought that we only need to use the multihop command if you are peering (using eBGP) with a router that is not directly connected. But in this case, R3 is directly connected to R2. I’m trying to understand why we increase the TTL to 2. Is it because we are peering using loopbacks? If that’s the case, would it be better to use the neighbor x.x.x.x disable-connected-check command instead of neighbor x.x.x.x ebgp multihop 2 ? I labbed both scenarios and the neighborship comes up using either command when peering with loopbacks on directly connected eBGP routers. Thanks for your time Rene.
Hello Leroy
Yes, that is exactly the reason why. To resolve the issue, you can use either one of the two solutions you have indicated, either multihop or disable-connected-check. Both will work as you have confirmed in this particular case.
There is a difference however between the two commands. The disable-connected-check command will disable the check an eBGP router will make to see if the neighbor’s IP address is on the same subnet as one of the local router’s interfaces. This command will not change the TTL count. So this command will enable you to create an eBGP peer with the loopback address of a directly connected router. It will not allow you to create a peering with an eBGP router that may be two or more hops away.
Alternatively, the multihop command will allow you to create a peering between eBGP routers that are two or more hops away simply because it increases the TTL.
More info about these two commands can be found here:
I hope this has been helpful!
Laz
1 Like
Awesome, this is exactly what I needed to see if I was missing something. Thanks for confirming Laz and great write up!
1 Like
Hi Rene,
May I know the confederation design for R21 and R22?
attached diagram and configuration(unfinished). Thank you!
RRweBGP_Confederation.rar (3.6 KB)
)
Chan
Hello Pui Lai
Hmm, I’m not sure what you’re asking. Are you asking for the configurations of R21 and R22? you can take a look at the lesson and see how R2 and R4 have been configured to create a sub-AS. If you follow the same logic, you can create the appropriate configurations on your topology here as well.
Let us know how you get along!
I hope this has been helpful!
Laz
Hi Laz,
Thanks for your reply. But there is a little bit different from the BGP Confederation topology in the example because R1 and R3 in my topology don’t have a connection between them. It is different from the R2 and R4 in the example.
So, should I assign R1 and R3 in my topology a sub-AS in standard configuration?
Chan