MPLS VPN lab #4

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):

MPLS4 - small

  • 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

MPLS VPN lab #2

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:

    MPLS1

    • 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

    MPLS Topology 1.2

    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:

    MPLS_Backbone_small

    This is the .net file contents:

    #MPLS 1.1 created 23/02/10
    #MPLS 1.2 created 24/02/10
    #MPLS 2.0 created 29/03/11 - Changed routers to 3725s and moved idlepc to the 3725 box at the top
    #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
    
    [[3725]]
    image = /data/dynamips/IOS_Images/3725/c3725-adventerprisek9-mz.124-15.T14.UNCOMPRESSED.bin
    ram = 142
    disk0 = 16
    disk1 = 0
    ghostios = true
    sparsemem = true
    idlepc = 0x6026be14
    
    ###########################
    #                         #
    # Mpls Topology   1.2     #
    #                         #
    ###########################
    
    [[Router CR1]]
      model = 3725
      console = 2001
      autostart = true
      #slot3 = 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/mpls/CR1.cfg
    
    [[Router CR2]]
      model = 3725
      console = 2002
      autostart = true
      #slot3 = 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/mpls/CR2.cfg
    
    [[Router CR3]]
      model = 3725
      console = 2003
      autostart = true
      #slot3 = 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/mpls/CR3.cfg
    
    [[Router CR4]]
      model = 3725
      console = 2004
      autostart = true
      #slot3 = NM-1FE-TX
      slot1 = NM-4T
      slot2 = NM-1FE-TX
      s1/0 = AR4 s1/0
    
    [[Router AR1]]
      model = 3725
      console = 2005
      autostart = true
      #slot3 = NM-1FE-TX
      slot1 = NM-4T
      slot2 = NM-1FE-TX
      Fa0/0 = CPE1 Fa0/0
      Fa2/0 = CPE2 Fa0/0
      #cnfg = /data/dynamips/Topology/mpls/AR1.cfg
    
    [[Router AR2]]
      model = 3725
      console = 2006
      autostart = true
      #slot3 = NM-1FE-TX
      slot1 = NM-4T
      slot2 = NM-1FE-TX
      Fa0/0 = CPE4 Fa0/0
      Fa2/0 = CPE3 Fa0/0
      #cnfg = /data/dynamips/Topology/mpls/AR2.cfg
    
    [[Router AR3]]
      model = 3725
      console = 2007
      autostart = true
      #slot3 = NM-1FE-TX
      slot1 = NM-4T
      slot2 = NM-1FE-TX
      Fa0/0 = CPE5 Fa0/0
      Fa2/0 = CPE6 Fa0/0
      #cnfg = /data/dynamips/Topology/mpls/AR3.cfg
    
    [[Router AR4]]
      model = 3725
      console = 2008
      autostart = true
      #slot3 = NM-1FE-TX
      slot1 = NM-4T
      slot2 = NM-1FE-TX
      Fa0/0 = CPE8 Fa0/0
      Fa2/0 = CPE7 Fa0/0
      #cnfg = /data/dynamips/Topology/mpls/AR4.cfg
    
    [[Router CPE1]]
      model = 3725
      console = 2009
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE1.cfg
    
    [[Router CPE2]]
      model = 3725
      console = 2010
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE2.cfg
    
    [[Router CPE3]]
      model = 3725
      console = 2011
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE3.cfg
    
    [[Router CPE4]]
      model = 3725
      console = 2012
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE4.cfg
    
    [[Router CPE5]]
      model = 3725
      console = 2013
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE5.cfg
    
    [[Router CPE6]]
      model = 3725
      console = 2014
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE6.cfg
    
    [[Router CPE7]]
      model = 3725
      console = 2021
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE7.cfg
    
    [[Router CPE8]]
      model = 3725
      console = 2022
      autostart = false
      #slot3 = NM-1FE-TX
      #cnfg = /data/dynamips/Topology/mpls/CPE8.cfg
    
    [[Router GR1]]
       model = 3725
       console = 2023
       autostart = true
       #slot3 = NM-1FE-TX
       slot1 = NM-4T
       Fa0/0 = ISP2 Fa0/0
       #cnfg = /data/dynamips/Topology/mpls/GR1.cfg
    
    [[Router ISP2]]
       model = 3725
       console = 2024
       autostart = false
       #slot3 = NM-1FE-TX
       #cnfg = /data/dynamips/Topology/mpls/ISP2.cfg

    And here are the updated config files: http://mellowd.co.uk/ccie/wp-content/uploads/2010/02/mpls.tar2.gz

    BGP Confederations – How, What and Why.

    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):

    Confederations

    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.9
     
            SPF algorithm executed 3 times
    R3#sh ip ospf 
     Routing Process "ospf 1" with ID 3.3.3.3
     
            SPF 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.9
     
            SPF 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.3
     
            SPF 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

    BGP Lab 12

    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:

    BGP - 12