Rule #1 – Just because Host 1 can get to Host 2, does NOT mean that Host 2 can get back to Host 1!
I can’t tell you how many times I’ve seen this out in the field. Here is a prime example.
This is quite a simply common topology. OfficeA and OfficeB have a WAN connection running between them. RouterA and RouterB are under control of the ISP and are running OSPF. RouterC is a customer-owned router, and so doesn’t run any OSPF with RouterA or RouterB.
OfficeB has an internet connection, and RouterB is injecting a default route to OfficeA via OSPF.
RouterB has a default route to RouterC. So let’s think about traffic flow now. A host connected to RouterA needs to send traffic to the internet. It will send it’s traffic to it’s default gateway, RouterA. RouterA has a default route injected into OSPF from RouterB and so sends traffic to RouterB.
RouterB has a default route and hence sends that traffic out to RouterC. Which then goes out to the internet.
Traffic then flows back from the internet to RouterC. The return address will be an IP that belongs in RouterA and RouterB’s routing table, however RouterC has no knowledge of that subnet (as it’s not participating in OSPF). RouterC will just use it’s default route and send that packet back out to the internet. Eventually the TTL will kill that packet.
This can be fixed by putting a static route on RouterC to let it know that RouterA’s ip range needs to be sent off to RouterB instead.
A similar thing will happen if we add a server to SwitchA. That server’s default gateway will most likely be RouterC. If a host in OfficeA send a PING to that server, that server will then send traffic off to RouterC. If RouterC does not have the static route added above, it’ll send it out to the internet.
I’m well aware that the design in the picture is pretty bad, but I used it to illustrate a point. That point being that just because router’s know how to get from A to B, it does NOT mean they know how to route that traffic back. Make sure you understand this!
As promised, I’ll now start writing up solutions to my previously posted labs. I hope this will spur up some conversation. I still stress that you should always try to do the lab without my help first. This will ensure you learn how to do it properly. Also remember that there are always multiple ways to do certain labs, so don’t take my solution as gospel.
I’ll be walking through my first MPLS lab which was originally posted over here: http://mellowd.co.uk/ccie/?p=518
- Use RIP as the routing protocol on CPE devices
- CPE1 and CPE5 belong to Company_A
- CPE2 and CPE6 belong to Company_B
- Each site has a /24 that is advertised via the loopback
- CPE1 should be able to ping CPE5’s loopback and vice-versa
- CPE2 should be able to ping CPE6’s loopback and vice-versa
- Different companies should NOT be able to ping each other. They must stay completely separate
- Now remove RIP and configure it so that both companies are using OSPF
- Once complete, remove the OSPF config and use EIGRP
The first part is very easy. As far as the config on the CPE goes, it’s standard. The CPE devices don’t know, or care, that the ISP is running MPLS. As an example, I’ve posted the relevent config from CPE6:
interface Loopback0 ip address 172.16.2.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.1.4.1 255.255.255.0 duplex auto speed auto ! router rip version 2 network 10.0.0.0 network 172.16.0.0 no auto-summary
The actual core routers also have a very simple configuration. This has already been setup in my provided configuration files. All thats needed is a IGP running correctly; CEF to be enabled; and then MPLS IP to be enabled on all links going to MPLS routers. As an example, I’ll show a bit of the configuration on CR1:
ip cef ! interface FastEthernet0/0 ip address 10.0.0.5 255.255.255.252 duplex auto speed auto mpls ip ! interface Serial1/0 ip address 10.3.0.1 255.255.255.252 mpls ip serial restart-delay 0 ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.0.0.3 area 0 network 10.0.0.4 0.0.0.3 area 0 network 10.2.0.0 0.0.0.3 area 0 network 10.3.0.0 0.0.0.3 area 0 network 10.255.255.2 0.0.0.0 area 0
The real meat of the configuration comes in on the AR routers. i.e. the edge MPLS routers that the CPE devices connect to. These are the routers which needs to hold the customer routing tables, as well as keeping customer networks separate from each other.
The first thing that needs to be done is to configure the VRF’s on each AR router that will connect. I’ll use the vrf name of CUS1 for the first customer and CUS2 for the second.
For the first customer:
AR1#(config)ip vrf CUS1 AR1#(config)rd 400:1 AR1#(config)route-target both 400:1
And now the second:
AR1#(config)ip vrf CUS2 AR1#(config)rd 400:2 AR1#(config)route-target both 400:2
We now need to setup the interfaces that the CPE devices will connect to:
AR1#interface FastEthernet0/0 AR1#ip vrf forwarding CUS1 AR1#ip address 10.1.1.2 255.255.255.0 AR1#interface FastEthernet2/0 AR1#ip vrf forwarding CUS2 AR1#ip address 10.1.2.2 255.255.255.0
Now it’s time to set up the routing protocol between the ISP vrf and the customer device. We are using RIP for this lab, so the configuration will be as follows for both customers:
AR1#router rip AR1#version 2 AR1#no auto-summary AR1#address-family ipv4 vrf CUS2 AR1#redistribute bgp 400 metric 10 AR1#network 10.0.0.0 AR1#no auto-summary AR1#version 2 AR1#address-family ipv4 vrf CUS1 AR1#redistribute bgp 400 metric 10 AR1#network 10.0.0.0 AR1#no auto-summary AR1#version 2
You can see in the above commands that we are redistributing BGP even though we haven’t configured BGP yet. Don’t worry, that step is next.
MPLS used MP-BGP for the MPLS VPN feature. i.e. it uses MP-BGP to distribute routes via each customers VRF, through the core, and then out the other side.
The first part of the MP-BGP configuration is a simple iBGP config. AR1′s configuration is below:
AR1#router bgp 400 AR1#neighbor 10.255.255.7 remote-as 400 AR1#neighbor 10.255.255.7 update-source Loopback0 AR1#no auto-summary
The second part of the MP-BGP configuration is to enable the vpnv4 part of BGP:
AR1#address-family vpnv4 AR1#neighbor 10.255.255.7 activate AR1#neighbor 10.255.255.7 send-community extended
The final part is to set up the actual VRF part for each customer, and enable redistribution of RIP routes learned earlier:
AR1#address-family ipv4 vrf CUS2 AR1#redistribute rip metric 10 ! AR1#address-family ipv4 vrf CUS1 AR1#redistribute rip metric 10
To have a quick recap, this is the MPLS specific configuration now on AR1:
ip cef ! ip vrf CUS1 rd 400:1 route-target export 400:1 route-target import 400:1 ! ip vrf CUS2 rd 400:2 route-target export 400:2 route-target import 400:2 ! ! interface FastEthernet0/0 ip vrf forwarding CUS1 ip address 10.1.1.2 255.255.255.0 duplex auto speed auto ! interface FastEthernet2/0 ip vrf forwarding CUS2 ip address 10.1.2.2 255.255.255.0 duplex auto speed auto ! router rip version 2 no auto-summary ! address-family ipv4 vrf CUS2 redistribute bgp 400 metric 10 network 10.0.0.0 no auto-summary version 2 exit-address-family ! address-family ipv4 vrf CUS1 redistribute bgp 400 metric 10 network 10.0.0.0 no auto-summary version 2 exit-address-family ! router bgp 400 no synchronization bgp log-neighbor-changes neighbor 10.255.255.7 remote-as 400 neighbor 10.255.255.7 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.255.255.7 activate neighbor 10.255.255.7 send-community extended exit-address-family ! address-family ipv4 vrf CUS2 redistribute rip metric 10 no synchronization exit-address-family ! address-family ipv4 vrf CUS1 redistribute rip metric 10 no synchronization exit-address-family
A similar configuration will of course need to be done on AR3.
Once done, we should be able to log onto CPE6 and ensure that it has CPE2′s networks. We should also see that it has NO access to CPE1 and CPE5′s networks. This is exactly what we see:
CPE6#sh ip route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 2 subnets
R 172.16.1.0 [120/10] via 10.1.4.2, 00:00:19, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 2 subnets
R 10.1.2.0 [120/10] via 10.1.4.2, 00:00:19, FastEthernet0/0
C 10.1.4.0 is directly connected, FastEthernet0/0
Can we ping CPE2′s loopback? We sure can:
CPE6#ping 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/60/92 ms
Can we ping CPE1′s loopback? No we cannot!
CPE6#ping 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
If we run a traceroute to CPE2′s loopback, we can see it going through the MPLS core:
CPE6#trace 172.16.1.1 Type escape sequence to abort. Tracing the route to 172.16.1.1 1 10.1.4.2 8 msec 0 msec 20 msec 2 10.8.0.1 [MPLS: Labels 28/38 Exp 0] 44 msec 68 msec 84 msec 3 10.1.2.2 [MPLS: Label 38 Exp 0] 60 msec 48 msec 28 msec 4 10.1.2.1 112 msec * 44 msec CPE6#
Lab done. If there are any questions, please let me know! :)
The diagram is the same as my last VPN Lab. Also it uses my MPLs topology found over here: http://mellowd.co.uk/ccie/?p=522
This is the topology for this lab (click for a bigger image):
- Customer1 and Customer 2 both have MPLS vpn’s through the ISP core.
- Customer1 is using OSPF and Customer2 is using EIGRP
- Customers should have no access to each others networks
- Customers should be able to reach all their sites from all their sites
- The ISP wants to monitor the CPE routers via their monitoring server. Create another loopback on each CPE router and give them all a /32 loopback in the 172.16.1.1/24 range – i.e. 172.16.1.1/32 for CPE1, 172.16.1.2/32 for CPE2 and so on
- Ensure the monitoring router can get to all these /32 routes (and ONLY these /32 routes) – It should not know about any customer routes – CPE routers should only see their OWN loopbacks in the routing table
- Now enable CPE3 and CPE6 to see each others subnets. All other CPE routers should see no change in their routing tables
This lab will test a Central Services MPLS VPN.
The diagram is the same as my last VPN Lab. Also it uses my MPLs topology found over here: http://mellowd.co.uk/ccie/?p=522
This is the topology for this lab (click for a bigger image):
- Customer1 and Customer 2 both have MPLS vpn’s through the ISP core.
- Customer1 is using OSPF and Customer2 is using EIGRP
- Customers should have no access to each others networks
- Customers should be able to reach all their sites from all their sites
- The ISP is now providing a mail relay for it’s customers to use. Ensure that all customers can get to the 10.200.1.1/24 subnet through their vpn’s, but they must still be seperated from each other.
This VPN lab will test intranet and extranet MPLS VPN’s.
The diagram is the same as my last VPN Lab. Also it uses my MPLs topology found over here: http://mellowd.co.uk/ccie/?p=522
This is the lab topology again:
- CPE1 and CPE5 belong to Customer1
- CPE2 and CPE6 belong to Customer2
- Both customers are running OSPF as their IGP’s
- The loopbacks as shown in the topology must be advertised into OSPF. Cutomer1 should be able to ping all loopbacks in their networks and Customer2 should be able to ping everything in theirs.
- Both customers are now running a project together, and need 2 of their offices connected. CPE1 from Customer1 should be able to communicate with CPE6 from Customer2 and vice-versa
- It’s essential that CPE2 and CPE5 are NOT able to get to all loopbacks. ONLY CPE1 and CPE6 should be able to communicate with each other. This new configuration should not break the previous VPN’s in place
- Do this without using any ACL’s, Prefix-lists, Route-maps or the like
Hopefully this will be my final tweak. This time I’ve added base configs to the CPE devices. It just gives them a hostname and ensures there is no timeout. This prevents you from having to keep logging back in.
Image-wise, it’s the same. Click for the larger image:
This is the .net file contents:
#MPLS 1.0 Topology created by Darren O'Connor 22/02/10 #MPLS 1.1 created 23/02/10 #MPLS 1.2 created 24/02/10 #www.mellowd.co.uk/ccie #Feel free to use and change as you see fit. However if you do use please leave my details here at the top [localhost:7200] workingdir = /data/dynamips/working [[3640]] image = /data/dynamips/IOS_Images/3640/c3640-js-mz.124-25c.UNCOMPRESSED.bin ram = 128 disk0 = 0 disk1 = 0 mmap = true ghostios = true ########################### # # # Mpls Topology 1.2 # # # ########################### [[Router CR1]] model = 3640 console = 2001 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX s1/0 = AR1 s1/0 s1/2 = AR3 s1/2 Fa0/0 = CR3 Fa0/0 Fa2/0 = CR2 Fa2/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR1.cfg [[Router CR2]] model = 3640 console = 2002 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX s1/0 = AR2 s1/0 s1/2 = AR1 s1/2 Fa0/0 = CR4 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR2.cfg [[Router CR3]] model = 3640 console = 2003 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa2/0 = CR4 Fa2/0 s1/0 = AR3 s1/0 s1/1 = GR1 s1/1 s1/2 = AR4 s1/2 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR3.cfg [[Router CR4]] model = 3640 console = 2004 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX s1/0 = AR4 s1/0 s1/2 = AR2 s1/2 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR4.cfg [[Router AR1]] model = 3640 console = 2005 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE1 Fa0/0 Fa2/0 = CPE2 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR1.cfg [[Router AR2]] model = 3640 console = 2006 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE4 Fa0/0 Fa2/0 = CPE3 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR2.cfg [[Router AR3]] model = 3640 console = 2007 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE5 Fa0/0 Fa2/0 = CPE6 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR3.cfg [[Router AR4]] model = 3640 console = 2008 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE8 Fa0/0 Fa2/0 = CPE7 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR4.cfg [[Router CPE1]] model = 3640 console = 2009 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE1.cfg [[Router CPE2]] model = 3640 console = 2010 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE2.cfg [[Router CPE3]] model = 3640 console = 2011 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE3.cfg [[Router CPE4]] model = 3640 console = 2012 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE4.cfg [[Router CPE5]] model = 3640 console = 2013 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE5.cfg [[Router CPE6]] model = 3640 console = 2014 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE6.cfg [[Router CPE7]] model = 3640 console = 2021 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE7.cfg [[Router CPE8]] model = 3640 console = 2022 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE8.cfg [[Router GR1]] model = 3640 console = 2023 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T Fa0/0 = ISP2 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/GR1.cfg [[Router ISP2]] model = 3640 console = 2024 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/ISP2.cfg
And here are the updated config files: http://mellowd.co.uk/ccie/wp-content/uploads/2010/02/mpls.tar2.gz
During your BGP studies, you’ll come across BGP confederations a couple of times. There are a few things that are easy to miss, and I’d like to clear it up here.
This will be both theory and practical, and I’ll be using this topology to explain things (click image for full size topology):
The routers are the same that are in my topology that I normally use. The only thing that will change will be the IP addressing so it’ll be easier to see what’s going on. The topology can be found here: http://mellowd.co.uk/ccie/?p=243
Our company, AS 65535 has a multitude of routers running BGP in our core. N.B: R2 and R4 will NOT be running BGP at all. We are connected to 2 ISP’s – AS100 and AS200. We are also running OSPF internally inside the organisation.
BGP confederations allow your BGP deployment to scale quite nicely internally. Remember the rule of BGP split horizon – i.e. a BGP router learning a route from an iBGP peer will not advertise that to another iBGP peer. Confederations can help with this, as each intra-confederation connection is actually a special eBGP peering and not a regular iBGP peer.
BGP confederations can also help with splitting up your IGP domains. IGP’s like EIGRP or OSPF cannot scale to gigantic routing table sizes. IGP’s also put more emphasis on convergence speed as opposed to stability like BGP. I know the topology I have is no-where near big enough, but it does allow me to show you how it splits these IGP domains. I am going to run OSPF in both Sub-AS 10 and 30, as well as EIGRP in 10, 20 and 30 so I can seperate the OSPF portion out completely. I am going to be running OSPF in area 0 in Sub-AS 10 as well as in 30, but these will be completely independent of each other.
Each router has a loopback which will be advertised. R1 is 1.1.1.1, R4 is 4.4.4.4 and so on. All iBGP and intra-confederation peers will be peered using the loopback IP addresses.
Configuring:
The ISP itself will have a normal BGP config, nothing special needs to be done. You do need to ensure you are configuring a peer with AS 65535. ISP1 and ISP2 do not know anything about the fact that we are running a confederation.
R1 config:
R1# router bgp 100 no synchronization bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 neighbor 192.168.1.8 remote-as 65535 no auto-summary
R8′s config is like so. The BGP process must be configured under the Sub-AS number. In this case AS 10. The peer connectino between ISP1 and our company will NOT come up until I tell R8 that it should identify itself to ISP1 as being in AS 65535. As soon as the confederation identifier is in place, the peer connection will come up. BGP confederation peers just tells the router itself which AS’s are intra-confederation peers. If you do not add this then the router will assume any AS different to the one it’s using itself will be a full eBGP peer.
R1# router bgp 10 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 20 30 network 8.8.8.8 mask 255.255.255.255 neighbor 9.9.9.9 remote-as 10 neighbor 9.9.9.9 update-source Loopback0 neighbor 192.168.1.1 remote-as 100 no auto-summary ! router ospf 1 log-adjacency-changes network 8.8.8.8 0.0.0.0 area 0 network 10.1.1.16 0.0.0.3 area 0 network 192.168.1.0 0.0.0.255 area 0
I’ve also added the next hop addresses into OSPF so I don’t need to use next-hop-self.
To do a quick check on the peer connection, have a look here:
R1#sh ip bgp sum Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.1.8 4 65535 17 17 4 0 0 00:10:06 1
The peer is up, and as far as R1 is concerned, R8 is in AS 65535
R2 is simply running OSPF and nothing else:
R2# router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 10.1.1.16 0.0.0.3 area 0 network 10.1.1.20 0.0.0.3 area 0
Router 9 is running BGP, OSPF and EIGRP – I wouldn’t do this in the real world. It’s simply to prove a point later. It’s also peered with AS20, a Sub-AS. There is an important thing to note here. Basically iBGP sessions do not need the ‘ebgp-multihop’ command. iBGP peers do NOT have to be directly connected. When Sub-AS’s connect to each other they DO need it though otherwise the peer will simply not come up. You can see that the peer config to R8 does not have it while the peer config to R10 does have it. This is the config:
R9# router bgp 10 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 20 30 network 9.9.9.9 mask 255.255.255.255 neighbor 8.8.8.8 remote-as 10 neighbor 8.8.8.8 update-source Loopback0 neighbor 10.10.10.10 remote-as 20 neighbor 10.10.10.10 ebgp-multihop 2 neighbor 10.10.10.10 update-source Loopback0 no auto-summary ! router ospf 1 log-adjacency-changes network 9.9.9.9 0.0.0.0 area 0 network 10.1.1.20 0.0.0.3 area 0 network 10.1.1.96 0.0.0.3 area 0 ! router eigrp 1 network 9.9.9.9 0.0.0.0 network 10.1.1.96 0.0.0.3 no auto-summary
Router10 is peered with 2 other Sub-AS’s. It’s also running EIGRP:
#R10 router bgp 20 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 10 30 network 10.10.10.10 mask 255.255.255.255 neighbor 3.3.3.3 remote-as 30 neighbor 3.3.3.3 ebgp-multihop 2 neighbor 3.3.3.3 update-source Loopback0 neighbor 9.9.9.9 remote-as 10 neighbor 9.9.9.9 ebgp-multihop 2 neighbor 9.9.9.9 update-source Loopback0 no auto-summary ! router eigrp 1 network 10.1.1.36 0.0.0.3 network 10.1.1.96 0.0.0.3 network 10.10.10.10 0.0.0.0 no auto-summary
R3, R4, R11 and R12 are more of the same of what’s just been done. I’ll post just the configs here.
#R3 R3#sh run | begin eigrp router eigrp 1 network 3.3.3.3 0.0.0.0 network 10.1.1.36 0.0.0.3 auto-summary ! router ospf 1 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 10.1.1.36 0.0.0.3 area 0 network 10.1.1.44 0.0.0.3 area 0 ! router bgp 30 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 10 20 neighbor 10.10.10.10 remote-as 20 neighbor 10.10.10.10 ebgp-multihop 2 neighbor 10.10.10.10 update-source Loopback0 neighbor 11.11.11.11 remote-as 30 neighbor 11.11.11.11 update-source Loopback0 no auto-summary
R4# router ospf 1 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 10.1.1.44 0.0.0.3 area 0 network 10.1.1.52 0.0.0.3 area 0
#R11 router ospf 1 log-adjacency-changes network 10.1.1.52 0.0.0.3 area 0 network 11.11.11.11 0.0.0.0 area 0 network 172.20.1.0 0.0.0.255 area 0 ! router bgp 30 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 10 20 network 11.11.11.11 mask 255.255.255.255 neighbor 3.3.3.3 remote-as 30 neighbor 3.3.3.3 update-source Loopback0 neighbor 172.20.1.12 remote-as 200 no auto-summary
#R12 router bgp 200 no synchronization bgp log-neighbor-changes network 12.12.12.12 mask 255.255.255.255 neighbor 172.20.1.11 remote-as 65535 no auto-summary
Now there are a couple things we need to note about these special BGP peerings. Usually, the next-hop address will change when an update is given to an eBGP peer. If we check R10′s BGP table though, we can see that the next-hop addresses have NOT changed: (192.168.1.1 is R1′s IP address; 172.20.1.12 is R12′s)
R10#sh ip bgp
BGP table version is 8, local router ID is 10.10.10.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.1.1.1/32 192.168.1.1 0 100 0 (10) 100 i
* 8.8.8.8/32 8.8.8.8 0 100 0 (10) i
r> 9.9.9.9/32 9.9.9.9 0 100 0 (10) i
*> 10.10.10.10/32 0.0.0.0 0 32768 i
* 11.11.11.11/32 11.11.11.11 0 100 0 (30) i
* 12.12.12.12/32 172.20.1.12 0 100 0 (30) 200 i
That means updates to confederation peers will have the next-hop stay the same. You need to ensure that those next hop addresses are known by all confederation peers otherwise you’ll get what I have above, most have no valid route.
If we check the BGP table on R3, we see the following:
R3#sh ip bgp
BGP table version is 20, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 9.9.9.9/32 9.9.9.9 0 100 0 (20 10) i
r> 10.10.10.10/32 10.10.10.10 0 100 0 (20) i
r>i11.11.11.11/32 11.11.11.11 0 100 0 i
*>i12.12.12.12/32 172.20.1.12 0 100 0 200 i
R3 can see that the IP 9.9.9.9 came through AS 20 and 10, even though all routers are in the same major AS.
The last thing I’d like to point out is the split of the IGP (OSPF in this case) Both Sub-AS 10 and 30 are running OSPF area 0. We can see how many times the SPF algorithm has run in each:
R9#sh ip ospf Routing Process "ospf 1" with ID 9.9.9.9SPF algorithm executed 3 times
R3#sh ip ospf Routing Process "ospf 1" with ID 3.3.3.3SPF algorithm executed 7 times
Let’s force the algorithm to run again by adding another loopback on Router9 and advertising it into OSPF:
R9#conf t Enter configuration commands, one per line. End with CNTL/Z. R9(config)#int lo2 R9(config-if)#ip address 99.99.99.99 255.255.255.255 R9(config-if)#router ospf 1 R9(config-router)#network 99.99.99.99 0.0.0.0 area 0
If we now check the SPF algorithm again in Both Sub-AS’s:
R9#sh ip ospf Routing Process "ospf 1" with ID 9.9.9.9SPF algorithm last executed 00:00:56.144 ago SPF algorithm executed 4 times
R3#sh ip ospf Routing Process "ospf 1" with ID 3.3.3.3SPF algorithm last executed 00:27:18.572 ago SPF algorithm executed 7 times
We can see in Sub-AS 10 the SPF algorithm ran 56 seconds ago. In Sub-AS 30 however, it has not forced the algorithm to run again, proving that these IGP domains are completely separate from each other.
So that’s the basics of Confederations. They can be very useful for a number of reasons. Just be sure to remember how exactly they operate. Any questions, feel free to ask
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 12:
- AS7, AS9 and AS11 are all customers of ISP1
- AS7 has it’s own address space – 77.48.16.0/24 advertised via a loopback
- ISP1 owns the address space 180.16.0.0/16
- AS9 has been assigned 180.16.9.0/24 from ISP1 – insert via loopback
- AS11 has been assigned 180.16.11.0/24 from ISP1 – insert via loopback
- Ensure that AS7′s address space is advertised to AS9 and AS11
- ISP1 needs to advertise the entire 180.16.0.0/16 range and not the more specific routes. Ensure AS7 sees only 180.16.0.0/16 HOWEVER it must still know that some routes have come from AS9 and AS11
- On AS9, configure an attribute so that ISP1 does not advertise the more specific 180.16.9.0/24 address to anyone.
- You should notice that ISP1 is now not advertising the aggregate because it has inherited the no-export community from above
- Now on ISP1, ensure that the community is changed so that the aggregate can be advertised again
Click on the thumbnail for the full size topology:
Sometimes when configuring BGP you’ll come accross routes that show rib-failure. What exactly does this mean?
Have a look at this output:
R3#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
r> 172.16.220.0/24 172.16.220.1 0 0 3 i
*> 192.68.0.0/16 172.16.220.1 0 0 3 {2,1} i
*> 192.68.10.0 172.16.220.1 0 3 2 i
172.16.220.0/24 is showing up as r> – but what exactly is going on? There is a command you can use to see what’s happened: show ip bgp rib-failure
R3#sh ip bgp rib-failure Network Next Hop RIB-failure RIB-NH Matches 172.16.220.0/24 172.16.220.1 Higher admin distance n/a
Here it’s telling me that the BGP could not be injected into the routing table as there is already a route with a higher administrative distance there. This is proved with the ip routing table:
R3#sh ip route 172.16.220.0
Routing entry for 172.16.220.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/1
Route metric is 0, traffic share count is 1
Essentially a RIB-failure is a note letting you know that the route is in BGP, but it has not been injected into the IP routing table even though it is a valid and best route
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 11:
- All routers are peered via BGP
- Router9 has the network 24.83.176.1/24 attached via a loopback
- Router2 has the network 24.83.177.1/24 attached via a loopback
- All networks MUST be inserted into the BGP process
- Now ensure that Router8 and Router1 see the full aggregate of 24.83.176/23 advertised. More specific routes MUST be supressed. i.e. Router1 and Router8 should have the aggregate ONLY – Do this WITHOUT removing any of the networks from the BGP process
- Now change the configuration so that Router1 and Router8 get the aggregate as well as the more specific routes, however using a community tag (on Router2), ensure that Router1 does NOT advertise the more specific routes to Router6.
- Router6 should still get the aggregate route
- Check to make sure Router1 has all the routes and Router6 ONLY has the aggregate route
Click on the thumbnail for the full topology:
Comments