Scenario:
You are the senior network engineer working for the federation of planets. BGP was developed on earth but is heavily used between planets as well. The network is expected to grow and to make you don’t go crazy over configuring full mesh IBGP peerings you want to use a solution that is scalable for the future. You already know how to configure route reflectors and clusters but you haven’t seen BGP confederations yet. Let’s see if you can configure this.
Goal:
- All IP addresses have been preconfigured for you. I’m not showing them in the topology picture or it will be a big mess.
- Each router has a loopback0 interface.
- Configure OSPF within AS 2345 so the routers know how to reach each others loopback interfaces.
- Configure IBGP within AS 2345 but create confederations, use AS2, AS3, AS4 and AS 5.
- Configure EBGP between AS 1 and AS 2345.
- Configure EBGP between AS 2 and AS 2345.
- Advertise all loopback0 interfaces in BGP.
- Ensure all loopback0 interfaces are reachable throughout the BGP network.
IOS:
c3640-jk9s-mz.124-16.bin
Topology:
Video Solution:
Configuration Files
You need to register to download the GNS3 topology file. (Registration is free!)Once you are logged in you will find the configuration files right here.
Do you want your CCNA or CCNP Certificate?
The How to Master series helps you to understand complex topics like spanning-tree, VLANs, trunks, OSPF, EIGRP, BGP and more.
Written by René Molenaar - CCIE #41726
Is it possible for a router to have an internal confederation peer with an AS of 2 and then also have an external peer with an AS of 2?
That’s not how it is supposed to be. You are in an AS or in a SUB-AS (confederation). If your router is within the SUB-AS it can talk with other external BGP routers from another AS but not from the same AS. If you configure the confederation you have to specify the AS and SUB-AS number.
I’m not surprised if you would get an error when you try to configure an external BGP router with the same AS number as your SUB-AS.
That is what I ran into with this lab. Take router Worf for example, it has to talk to laForge which is AS 2 and then also Riker which is an external AS of 2. To make it work, I had to change Riker to AS 6 instead.
I was just making sure there wasn’t a different way of doing this that I was unaware of…
Thanks
Oh crap…I see I made a mistake on this one ;D router Riker should be in AS6…sorry I didn’t see this one before.
As i read the requirements i figured as mutch too. BGP is a cool protocol, lots of stuff!!
You might want to also consider putting router Data in AS 3 instead of 4 and put Worf in AS 4 so their AS numbers match their loopback addresses.
That sounds like a good idea. I’ll fix it when i’m recording the video for this one.
I figured it out I had everything correct I was forgetting to source my ping..
I can’t figure out a way to delete my post.
I was able to set this up and fix some interfaces IP issues… once I have it all setup I can ping from AS1 to the loopback on AS6 so I know everything is routing fine and I see BGP updates on all my routers. My only problem is I cannot ping 6.6.6.6 from LaForge or Data, and I cannot ping 1.1.1.1 from Worf or Crusher.
LaForge and Data both can ping 1.1.1.1.
Worf and Crusher can both ping 6.6.6.6.
I’ve did show ip routes and there is a route to go the correct way to get to the network. When I do a trace though it goes to the adjacent routers 192 IP and then stops there.
For example if I ping 6.6.6.6 from LaForge it goes to 192.168.24.4 (worfs connected network) and then stops.
I’m not sure why it’s doing this… I have made sure I had full OSPF connectivity first also so I don’t think it’s an IGP issue.
Here is my bgp from LaForge:
router bgp 2
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 2345
bgp confederation peers 3 4 5
network 2.2.2.0 mask 255.255.255.0
network 192.168.12.0
neighbor 3.3.3.3 remote-as 4
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 3.3.3.3 next-hop-self
neighbor 4.4.4.4 remote-as 3
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
neighbor 4.4.4.4 next-hop-self
neighbor 192.168.12.1 remote-as 1
no auto-summary
Worf:
router bgp 3
no synchronization
bgp log-neighbor-changes
bgp confederation identifier 2345
bgp confederation peers 2 4 5
network 4.4.4.0 mask 255.255.255.0
network 192.168.46.0
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 next-hop-self
neighbor 5.5.5.5 remote-as 5
neighbor 5.5.5.5 ebgp-multihop 2
neighbor 5.5.5.5 update-source Loopback0
neighbor 5.5.5.5 next-hop-self
neighbor 192.168.46.6 remote-as 6
no auto-summary
Also do you need to identify all confederation peers in the global AS or just the connected ones? I’ve tried both ways and still had the same issue, but I had connectivity across the network.
Thanks
Myles
Hi Myles,
Good to see you figured it out. Want me to leave or delete your post?
Rene
Hi Myles,
I forgot to answer your question. When you configure your BGP Confederation Peers you only have to configure the “directly connected” Sub-ASes. It doesn’t hurt to configure all of them but it’s not necessary.
Rene
So I completed this lab and was able to ping end to end without using the neighboring looback address’s for peers. I’m just curious if that is required, or if peering with the 192.168 address’s is fine as well?
You can use the IP address on the loopback interface or the IP address on the directly connected interfaces. It doesn’t matter much as long as your routers become BGP neighbors.
The advantage of using a loopback interface is that it can never go "down" unless your router crashes or you type the "shutdown" command on it. Physical interfaces can go down and if the IP address on the physical interface is no longer reachable your BGP neighbor adjacency will drop.
If you use loopback interfaces you normally use an IGP (OSPF/EIGRP) to advertise them. In case of a physical link failure our IGP can search for another path to the loopback interface. This is good because it means your BGP neighbor adjacency will stay up as long as the loopback interface is reachable…
Hi Rene
I assume that IP address on FastEthernet2/0 Data router should be
FastEthernet2/0 192.168.35.3
not
FastEthernet2/0 192.168.24.2
Yes you are right. Just changed this in the startup configs. Thanks for letting me know!
Hi Rene
Thanks for such a wonderful lab. In order to complete the lab very fist time do, i assume that directly connected neighbor and loop back interface should be advertise in BGP. because router can take any physical interface ip address to reach to the destination that’s why need to advertise directly connected neighbor into BGP.
Hi,
It totally depends on what you "want". If this were a real life scenario then maybe you don’t want the networks in between the routers to be reachable so you don’t have to advertise them. If you don’t advertise them then you need to keep in mind to specify the source IP address when you are doing a ping or you’ll have trouble with the return traffic. In a lab it’s ok to advertise all these directly connected networks 🙂
Rene
Great lab. Thanks!!
thanks 🙂
Commander Data rocks. This is what real star Trek is all about not like that new rubbish starring that idiot Chris Pine.
lol you bet.
Why the peering between picard -> laforge and data has to be with the physical interface and not with picard’s loopback?
Hi Rene
Thanks for all your labs. Looking at the diagrams you are creating 4 separate confederation between 4 public AS’s. I was wondering why we need to do that? Surely EBGP neighbors would exchange routing information between each other with any confed config.
Additionally, config identifier 2345 is a public AS as well. I was under the impression that confed identifier need to be private AS’s?
Appreciate your help.
Imran
Imran i think your missing the point regarding the confederation, each SUB AS would have more routers than just the single router depicted. The point of the Lab was to show how it works. You could have hundreds of routers within each SUB AS, even route reflector clusters etc etc…… ultimately reducing the amount of meshed peers in a IBGP environment.
i added BGP peer-session templates to this.
also costed out the OSPF link between LaForge and Worf in order to force traffic from Picard to Riker over the Data/AS4 to Crusher/AS5 path instead of the LaForge/AS2 to Worf/AS3 path.
excellent lab 🙂
Hi Rene, This a a great lab, Please create a video on it as it will be much appreciated by all your followers !!! Cheers Mate .