Juniper EX BGP with Default Routes

Question

I'm new to BGP - so this is certainly a learning exercise. I'm moving away from PA space provided on 2 routed uplinks to having my own IP space and multi-homing my transit.

To begin with, there will only be a single transit provider - and they have provided 2 RJ45 cable drops with a different /30 VLAN on each - to go to each of my Juniper EX3200 switches.

I only intend to take default routes for now - and in the mean time, I need to continue to use the routed uplinks and PA space - whilst maintaining another routing table for the new BGP gateway/network.

There is 2x uplinks (ge-0/0/0 and ge-0/0/1) on which my WAN glue block VLAN resides (vlan4000). VRRP runs on this VLAN and all my IP's are routed from my provider to this virtual IP. Then internal routes are direct over VLAN L3 interfaces. The gateway IP (ie. my provider's router virtual IP) in vlan4000 acts as my default route.

So I'm aware that I'll likely need to run two routing tables (VRFs) to separate the BGP IPs from the "other" IPs - and maybe do some filter based forwarding for selecting the right gateway.

I've been doing some fairly extensive reading of both,

1. http://www.juniper.net/us/en/training/certification/JNCIA_studyguide.pdf
2. http://www.juniper.net/us/en/training/certification/JNCIS_studyguide.pdf

To get a good understanding of the config required.

---

From my (limited) understanding thus far, I think I need to ...

1. Bring up a BGP session with my transit provider
2. Announce my IP block over my ASN
3. Route the BGP IP block over that specific interface
4. Form some kind of failure/HA between the two EX3200's so that a single failure doesn't drop the BGP session.

What I'm essentially unsure of is how the two EX3200's bring up their BGP sessions. As each have their own IPs (router-ids) in two separate VLANs - this looks to be two separate BGP sessions - and I'll need to conditionally route between each BGP default gateway if either goes down?

Has anyone got any example configurations of where to begin?

Answer 1

EX switches can do VRF-Lite to support multiple routing tables. To start you can look at this KB article from Juniper:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB14926

What you need is BGP support for the VRF/virtual-router. For this you need the AFL license on the EX switches. Here is a software feature table for the EX series, which is always useful:

http://www.juniper.net/techpubs/en_US/junos10.2/topics/concept/ex-series-software-features-overview.html#layer-3-protocols-features-by-platform-table

If you've installed the license you can configure a routing-instance and the BGP protocol under it:

routing-instances {
test {
    instance-type virtual-router;
    protocols {
        bgp {
            local-as 65565;
        }
    }
}

eBGP (external BGP, to your provider) sessions are normally made between interface IPs. So you configure your IP in the /30 on an interface(repeat for second uplink on the other switch) and establish the BGP session to the IP of the provider router. Ask your provider to announce you a default route.

You should connect your two switches and speak iBGP (internal BGP) between them so that they both get the routing information from each other.

If one uplink fails or the BGP session drops your switch will automatically switch to the other uplink.

General information regarding BGP on EX switches is here:

http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway-pages/ex-series/bgp.html

This is just a short answer. Please be aware that BGP routing is a very broad topic and it's easy to wreak havoc not only in your network but in your providers network or in an extreme case even worldwide. I would advise getting professional help for the initial setup.

Answer 2

Thanks @Sebastian for putting me on the right track. I wanted to follow up on this with what I've learnt/implemented so far with a single EX3200 in a lab. This is a working configuration.

The only bit I'm missing from my original requests was how the high-availability will work for the default gateway on the BGP connection - but I think iBGP will fit that bill.

I might add another routing instance to mimic a second switch - then run a physical trunk between interfaces assigned to each instance. Then bring up eBGP and iBGP on both.

---

I set up two routing instances, to isolate the two networks (PA IPs and BGP IPs) and gateways.

vlan.10 and vlan.20 served as the BGP uplinks, vlan.3999 is for the /22 IPs we're announcing over our ASN.

vlan.30 is an existing /24 of PA space - with a static route to the main gateway on vlan.40

You can see that the BGP instance was configured specifically on that routing instance - so its not shared amongst the other routing table.

routing-instances {
  transit-bgp {
    instance-type virtual-router;
    interface vlan.10;
    interface vlan.20;
    interface vlan.3999;
    routing-options {
      router-id x.x.x.50;
      autonomous-system xxxxx;
    }
    protocols {
      bgp {
        group bgp1 {
          type external;
          peer-as xxxxx;
          neighbor x.x.x.109 {
            import import-route-transit1;
            export export-route;
          }
        }
        group bgp2 {
          type external;
          peer-as xxxxx;
          neighbor x.x.x.113 {
            import import-route-transit2;
            export export-route;
          }
        }
      }
    }
  }
  transit-pa {
    instance-type virtual-router;
    interface vlan.30;
    interface vlan.40;
    routing-options {
      static {
        route 0.0.0.0/0 next-hop x.x.x.1;
      }
    }
  }
}

So the vlans were assigned as follows

vlans {
  bgp1 {
    vlan-id 10;
    l3-interface vlan.10;
  }
  bgp2 {
    vlan-id 20;
    l3-interface vlan.20;
  }
  liveips {
    vlan-id 3999;
    l3-interface vlan.3999;
  }
  routedips {
    vlan-id 30;
    l3-interface vlan.30;
  }
  routedgw {
    vlan-id 40;
    l3-interface vlan.40;
  }      
}

Then to make sure that the two BGP links were preferenced (should one fail), policies were set up to alter the local-preference. A policy was also created to export specific routes to be advertised over BGP.

policy-options {
  policy-statement export-route {
    term local-routes {
      from {
        route-filter x.x.x.0/22 exact;
      }
      then accept;
    }
  }
  policy-statement import-route-transit1 {
    term default {
      then {
        local-preference 220;
        next policy;
      }
    }
  }
  policy-statement import-route-transit2 {
    term default {
      then {
        local-preference 200;
        next policy;
      }
    }
  }
}

At this point - everything was perfect and both routing tables worked in harmony - but completely isolated. Ie. there was no routes shared/leaked between each other. So I set up some filter based forwarding to allow routes to be distributed.

First, I used an input filter on the vlan interface

interfaces {
  vlan {
    unit 10 {
      family inet {
        address x.x.x.110/30;
      }
    }
    unit 20 {
      family inet {
        address x.x.x.114/30;
      }
    }
    unit 30 {
      family inet {
        filter {
          input transit-pa-int;
        }
        address x.x.x.50/24;
      }
    }
    unit 30 {
      family inet {
        address x.x.x.1/24;
      }
    }                
    unit 3999 {
      family inet {
        filter {
          input transit-bgp-int;
        }
        address x.x.x.1/22;
      }
    }
  }
}

Which used the following firewall rules

firewall {
  family inet {
    filter transit-pa-int {
      term one {
        from {
          destination-address {
            x.x.x.0/22;
          }
        }
        then {
          routing-instance transit-bgp;
        }
      }
      term default {
        then {
          routing-instance transit-pa;
        }
      }
    }
    filter transit-bgp-int {
      term one {
        condition {
          destination-address {
            x.x.x.0/24;
          }
        }
        then {
          routing-instance transit-pa;
        }
      }
      term default {
        then {
          routing-instance transit-bgp;
        }
      }
    }
  }
}