BGP Design Case Study

Below BGP design case study is taken from the Orhan Ergun’s CCDE Practical Workbook.In the new version of the workbook there are more than 50 case studies are shared for many technologies.

If you are in the network design field or want to learn about it,don’t miss the book.

I am explaining this topic in deep detail in my Live/Webex “BGP  Zero to Hero” course. Click here for our Special Offer.

Scenario :
Network A is a customer of Network Z, Network B is a peer of Network Z.
Network A becomes transit customer of Network B.
Network A announces aggregate to Network Z and more specific prefixes, and to Network B. Network B sends more specific to its peer Z.
Network Z only announces the aggregate to the world. Network B doesn’t announce anything to the upstream SP.

What is the impact of this design ?
Is there any problem ? If there is , how you can fix ? 

bgp peering


As it is depicted on the above diagram, Network B doesn’t announce the specific to the world. As a result traffic from internet to Network A goes through Network Z and then through Network B over the peer link.(Longest match wins., vs.


Network A doesn’t have to pay its provider Network Z.

This is known as Jack Move.

Here Network A and Network pull the Jack Move on network Z.

Thanks for the participants for their comments. In the new version of my workbook there will be 50+ case studies. It will come out in a month.Stay tuned..


[button_1 text=”CCDE{ea8372c0850978052e20c0d53be15bc420c794e9b9b32f0ee9dfe0056552e01e}20Bootcamp{ea8372c0850978052e20c0d53be15bc420c794e9b9b32f0ee9dfe0056552e01e}20Sample{ea8372c0850978052e20c0d53be15bc420c794e9b9b32f0ee9dfe0056552e01e}20Videos” text_size=”32″ text_color=”#000000″ text_bold=”Y” text_letter_spacing=”0″ subtext_panel=”N” text_shadow_panel=”Y” text_shadow_vertical=”1″ text_shadow_horizontal=”0″ text_shadow_color=”#ffff00″ text_shadow_blur=”0″ styling_width=”58″ styling_height=”51″ styling_border_color=”#000000″ styling_border_size=”1″ styling_border_radius=”6″ styling_border_opacity=”100″ styling_shine=”Y” styling_gradient_start_color=”#ffff00″ styling_gradient_end_color=”#ffa035″ drop_shadow_panel=”Y” drop_shadow_vertical=”1″ drop_shadow_horizontal=”0″ drop_shadow_blur=”1″ drop_shadow_spread=”0″ drop_shadow_color=”#000000″ drop_shadow_opacity=”50″ inset_shadow_panel=”Y” inset_shadow_vertical=”0″ inset_shadow_horizontal=”0″ inset_shadow_blur=”0″ inset_shadow_spread=”1″ inset_shadow_color=”#ffff00″ inset_shadow_opacity=”50″ align=”center” href=”” new_window=”Y”/]

9 Replies to “BGP Design Case Study”

  1. Hi,
    The link between Network Z and B is transit link. This problem can be solve using using BGP community “No-Export” to fix this problem.

  2. Problem is network Z is a single point of failure for network a. Should advertise aggregate to network b also, have network z advertise everything outbound, and use weight and med to set preferences for primary traffic paths.

  3. Hey Orhan,

    All applies on what kind of local pref behaviour is in the network of Network Z.
    More specifics won’t appear from outside the Network Z due to the ‘atomic aggregate’ configured there. However traffic flowing towards 4.0.0/24 & 4.0.1/24 will never go through over the direct link between Network Z and Network A. This is suboptimal for the customer and therefor we should fix it with the lower noted stuff.

    We can resolve this multiple ways:
    – Network A can advertise towards Network Z (4.0.0/24 & 4.0.1/24) – best ‘fix’
    having the same advertisement even with or without ‘no-export’ applied.
    – Network Z can filter out 4.0.0/24 & 4.0.1/24 from Network B – less ideal but still work-a-ble. (maintaining filters should be a ‘day to day automated thing’ by bigger networks and even smaller for example by using IRRdb)
    – Network Z can add a static route for 4.0.0/24 & 4.0.1/24 towards Network A – this will be less dynamic (since it includes static routes on customer facing router) but can also be with a ‘no-export’ policy applied.

    Networks should do consistant advertisement across peers/transit, this makes the Internet a better place.

  4. Network B should advertise the /24 to the upstream provider.

    Customer B is bluffing network Z and network A

    Customer A expecting to reach internet from B since the network with more prefixes advertised to them. And this is happening ?
    Also network Z is utilizing his internet link since no more prefixes advertised than /16.

  5. Hey Orhan,
    hope you are great!

    This is an example of a common jack move, sending more specific routes via a peer and less specifics
    via a customer, to obtain inbound transit.

    Guys at Network Z should not allow peers to advertise more specific routes to from their customer then the customers itself.

    kind regards!!


  6. @ Network A, receiving full bgp rt table from both Network Z and B? or it is default route? or specific routes for specific destinations either from Network Z and Network B? what is the outbound policy or it is set on default?

    From the current network setup, it looks like Network A uses Network Z for the internet traffic and Network B for the local/regional traffic.

    Based on the above assumption, with this current state of the network, it will cause asymmetric routing and will use Network B resources for any inbound traffic from the internet.

    one way to cover the up, to use no-export policy on Network B so that specific routes don’t get advertised to Network Z. (if one have the admin control of that network)

    otherwise in addition to aggregate route, more specific routes are to be advertised from Network A to Network Z to resolve asymmetric issue.

  7. Network B becomes transit for traffic from internet towards 4.0.0.x and 4.0.1.x subnets
    Network A should advertise and to Network B but with community ‘no-export’

  8. As Network A is customer of Network Z so traffic for customer A should transit directly from internet towards Networks A to Network Z , but due to more specific prefix advertisement towards Network B from Network A , download traffic from internet towards Network A will use Network B as transit for destination 4.0.0/24 and 4.0.1/24.

    Download traffic from internet towards Network A for 4.0.0/24 and 4.0.1/24

    Internet—>Network Z —> Network B —> Network A–> 4.0.0/24 , 4.0.1/24

    This can fixed by advertise more specific prefixes towards only Network Z (say 4.0.0/24 and 4.0.1/24) and less specific or aggregate prefix 4.0.0/16 towards both Network Z and Network B from Network A

    another solution advertise specific and aggregate prefixes to both Network Z and Network B , if Network B and Network A and Network Z are different AS(s) then automatically due to AS path length routes received directly from Network A to Network Z will be active due to short AS path as compare to same prefix receive from Network B other wise this thing can controlled using input high Local preference towards Network A on Network Z

    Internet —> NetworkZ —> Network A –> 4.0.0/24 , 4.0.1/24

Leave a Reply

Your email address will not be published.