BGP Challenge: Merge Autonomous Systems

Here’s a challenge in case you get bored during the Christmas break: merge two networks running BGP (two autonomous systems) without changing anything but the configurations of the routers connecting them (the red BGP session in the diagram). I won’t give you any hints; you can discuss it in the comments or a GitHub discussion.

Hopefully, you won’t have to deal with something similar in real life, but then we know that crazy requirements trump good designs any day of the week.

keep reading

2 comments:

  1. There's a hint in your topology file.

    > Each one has a public AS number.

    None of them has a public AS number. They all have a private AS number.

    > The only change you can make is a new BGP session between PE2 and PE2.

    It should be PE3 there.

    To meet your requirements I would configure BGP with something along "neighbor 172.29.42.x local-as 65003 no-prepend" on PE2 respectively "neighbor 172.29.42.x local-as 65000 no-prepend" on PE3 and "neighbor 172.29.42.x next-hop-self" on both PE2 and PE3.

    I haven't tested it with your lab tool.

    Replies
    1. Not sure it would work, it seems that you cannot use local-as with the same value as the AS of the peer:

      https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13761-39.html

      "Local-AS cannot have the local BGP protocol AS number or the AS number of the remote peer."

    2. @Anonymous: thanks a million for the typo report. Hopefully, I fixed everything you mentioned.

      As for the "hint in the topology file" -- I had to use that parameter to prevent the automatic configuration of a BGP session between PE2 and PE3. Found a better way to do that.

    3. @chris: You were right (at least for Cisco IOS).

      I found a convoluted solution (not sure if it still meets all requirements):

      PE2#
      router bgp 65000
       neighbor 10.0.0.2 remote-as 65000
       neighbor 10.0.0.2 update-source 10.0.0.3
       neighbor 10.0.0.2 next-hop-self all
       neighbor 172.29.24.1 remote-as 65003
       neighbor 172.29.24.1 local-as 65003
       neighbor 172.29.24.1 route-reflector-client
       neighbor 172.29.24.1 route-map NEXT_HOP in
      !
      route-map NEXT_HOP permit 10 
       set ip next-hop 172.29.24.1
      

      PE3#
      router bgp 65003
       neighbor 10.0.0.5 remote-as 65003
       neighbor 10.0.0.5 update-source 10.0.0.4
       neighbor 10.0.0.5 next-hop-self all
       neighbor 172.29.24.2 remote-as 65003
       neighbor 172.29.24.2 route-reflector-client
       neighbor 172.29.24.2 route-map NEXT_HOP in
      !
      route-map NEXT_HOP permit 10 
       set ip next-hop 172.29.24.2
      

      I tested it in my own lab.

  2. I think i got it right ! My only assumption is that the PE/RR peers use next-hop-self knobs, which makes sense at least for PE1 and PE4. An alternative is to advertise the network 172.29.42.0/24 into BGP, which is not forbidden :)

    For my lab, i replaced backbone AS by 5000 and 5003 in order to use public AS and it is still OK !

    Thanks Ivan for the fun !

    x2#sh ip bgp | b Netw
         Network          Next Hop            Metric LocPrf Weight Path
     *>  192.168.100.0    10.1.0.17                              0 5003 65100 i
     *>  192.168.107.0    0.0.0.0                  0         32768 i
    x2#
    
    Replies
    1. Looks like you lost the customer prefixes (192.168.1.0/24 and 192.168.3.0/24). Have no idea what could cause that as the transit prefixes got across.

      Also, did you preserve the next hops of the BGP prefixes across both autonomous systems (the last "at the end of the migration project" bullet)?

    2. Yes, i forgot to configure the customer prefixes. But worst, i do not have the expected next-hops at PE1 and PE4 ! -> Back to study :)

      Question: Are we allowed to add static routes or to edit the isis/ospf configuration ?

    3. > Are we allowed to add static routes

      I wouldn't (and you don't need them)

      > or to edit the isis/ospf configuration

      As long as you don't change anything on any other router. However, the real-life answer would probably be " NO!!!"

    4. OK, this time, the lab pass the verifications, and, yes, no static routes and no IGP changes !

      next-hop is not modified by the bgp session between PE4 and PE3 :

      PE1#sh ip bgp 192.168.3.0
      BGP routing table entry for 192.168.3.0/24, version 25
      Paths: (1 available, best #1, table default)
        Advertised to update-groups:
           5         
        Refresh Epoch 1
        (5003)
          10.0.0.6 (metric 11) from 10.0.0.2 (10.0.0.2)
            Origin IGP, metric 0, localpref 100, valid, internal, best
            Community: internet
            Originator: 10.0.0.3, Cluster list: 10.0.0.2
      PE1#
      

      and x1/x2 receive exactly 3 prefixes with the correct AS-path :

      x1#sh ip bgp | b Netw
           Network          Next Hop            Metric LocPrf Weight Path
       *>  192.168.1.0      10.1.0.1                 0             0 5000 i
       *>  192.168.3.0      10.1.0.1                               0 5000 i
       *>  192.168.100.0    0.0.0.0                  0         32768 i
       *>  192.168.107.0    10.1.0.1                               0 5000 65107 i
      x1#
      

      Thanks again Ivan !

    5. I built it with netlab and FRR containers. Here is my solution for configuration:

      hostname pe2
      !
      router bgp 65000
       neighbor 172.29.42.2 remote-as 65003
       neighbor 172.29.42.2 local-as 65003 no-prepend replace-as
       !
       address-family ipv4 unicast
        network 10.0.0.1/32 route-map NO_EXPORT
        network 172.29.42.0/24 route-map NO_EXPORT
        neighbor 172.29.42.2 activate
        neighbor 172.29.42.2 route-reflector-client
       exit-address-family
      exit
      !
      route-map NO_EXPORT permit 10
       set community no-export
      

      hostname pe3
      !
      router bgp 65003
       neighbor 172.29.42.1 remote-as 65003
       !
       address-family ipv4 unicast
        network 10.0.0.6/32 route-map NO_EXPORT
        network 172.29.42.0/24 route-map NO_EXPORT
        neighbor 172.29.42.1 activate
        neighbor 172.29.42.1 route-reflector-client
       exit-address-family
      exit
      !
      route-map NO_EXPORT permit 10
       set community no-export
      
Add comment
Sidebar