The next step of this workshop lab will set up eBGP with our upstream provider so that we can see the Internet.
The diagram below is a reminder of the lab topology:
The lab instructors will be running the routers for the two Transit Providers and will have already configured them. Please remember to discuss any problems with setting up BGP with the two Transit Operators. Don’t just assume that if eBGP doesn’t come up that the lab instructors will fix the problem for you in the background.
Follow the guidelines in the IP Address Plan document to configure the link to the upstream. Make sure that you can ping the upstream’s router using both IPv4 and IPv6 - if it doesn’t work, investigate why not.
Here is an typical configuration sample - note that we are following the same good practices as we did when we set up the internal interfaces on our network:
interface GigabitEthernet 2
description Link to Transit Provider N
ip address <ipv4-ptp> 255.255.255.254
no ip redirects
no ip proxy-arp
ipv6 address <ipv6-ptp>/127
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
no shutdown
!Note that you might get the following notification from the router CLI:
% Warning: use /31 mask on non point-to-point interface cautiouslyDon’t worry about the notification. /31 subnets are supported on Cisco IOS, and this is the router warning that this point-to-point link is actually a broadcast media (ethernet).
Do not configure IS-IS towards the upstream provider! They are not part of your autonomous system.
We now configure eBGP with the upstream. Again, the configuration on the two transit routers will have already been completed by the instructors, so once configured, the eBGP session should just come up and work.
Don’t forget to filter what you hear from the upstream, and what you send to them. Right now we will accept the full1 BGP table that the upstream is sending us, and we should only send prefixes we originate!
In the following sections we will set up the filters we will use, and then we will set up the eBGP session with our external neighbour.
Let’s create an outbound filter for the prefixes we will send to our upstream provider.
In the previous lab we tagged our aggregate with a specific community. So we can now look for this community in the prefixes we carry, and only allow those out which match the community. We create a route-map to do this (note we allow customer-pi tagged prefixes as well):
route-map Transit-out permit 5
description Prefixes to our Transit Provider
match community aggregate
match community customer-pi
!Note that this route-map is address-family independent - it can be used for both IPv4 and for IPv6.
Next we need to create an inbound filter for the prefixes we will receive from our upstream provider.
First we create the prefix-lists to allow the full table we are hearing from the upstream provider.
IPv4 Example:
ip prefix-list FULL-ROUTESv4 permit 0.0.0.0/0 le 32IPv6 Example:
ipv6 prefix-list FULL-ROUTESv6 permit ::/0 le 128We will use route-maps for managing our inbound policy on the transit link - this is a more advanced configuration, but it is more scalable in the longer term. The IPv4 version of the route-map looks like this:
route-map Transitv4-in permit 10
description Allow full routes
match ip address prefix-list FULL-ROUTESv4
!and the IPv6 version looks like this:
route-map Transitv6-in permit 10
description Allow full routes
match ipv6 address prefix-list FULL-ROUTESv6
!Then we can set up the eBGP configuration. Here is a configuration sample, first for IPv4:
router bgp X0
!
address-family ipv4
neighbor <ipv4-ptp> remote-as <Transit-AS>
neighbor <ipv4-ptp> description eBGP with TRANSIT N
neighbor <ipv4-ptp> password BGPlab
neighbor <ipv4-ptp> route-map Transit-out out
neighbor <ipv4-ptp> route-map Transitv4-in in
neighbor <ipv4-ptp> activate
!and then for IPv6:
router bgp X0
!
address-family ipv6
neighbor <ipv6-ptp> remote-as <Transit-AS>
neighbor <ipv6-ptp> description eBGP with TRANSIT N
neighbor <ipv6-ptp> password BGPlab
neighbor <ipv6-ptp> route-map Transit-out out
neighbor <ipv6-ptp> route-map Transitv6-in in
neighbor <ipv6-ptp> activate
!Once this has been configured, you should now see several routes coming from the upstream provider, and you should be able to see your aggregate being sent to your upstream.
If you see nothing from the upstream provider, check your filters first before asking the lab instructors. Check also with your lab instructors to make sure that they are seeing your IPv4 and IPv6 aggregates. Don’t just assume they will somehow look on your behalf.
The commands to see what you are receiving from the Transit Provider are:
show ip bgp neighbor <ipv4-ptp> routes
show bgp ipv6 unicast neighbor <ipv6-ptp> routesand to show what you are sending to the Transit Provider:
show ip bgp neighbor <ipv4-ptp> advertised-routes
show bgp ipv6 unicast neighbor <ipv6-ptp> advertised-routesNote that there are IPv4 versions of the IPv6 commands too, although they are a bit more to type than the versions given above:
show bgp ipv4 unicast neighbor <ipv4-ptp> routes
show bgp ipv4 unicast neighbor <ipv4-ptp> advertised-routes
Here is an example from a previous workshop showing what the BGP table of the Border router of Group 2 should look like:
B2#show ip bgp
BGP table version is 14, local router ID is 100.68.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 100.121.1.2 0 121 i
*> 100.68.1.0/24 100.121.1.2 0 121 10 i
*>i 100.68.2.0/24 100.68.2.2 0 100 0 i
*>i 100.68.2.28/30 100.68.2.2 0 100 0 i
*>i 100.68.2.64/26 100.68.2.4 0 100 0 i
*> 100.68.3.0/24 100.121.1.2 0 121 30 i
*> 100.68.4.0/24 100.121.1.2 0 121 40 i
*> 100.68.5.0/24 100.121.1.2 0 121 122 50 i
*> 100.68.6.0/24 100.121.1.2 0 121 122 60 i
*> 100.68.7.0/24 100.121.1.2 0 121 122 70 i
*> 100.68.8.0/24 100.121.1.2 0 121 122 80 i
*> 100.121.0.0/16 100.121.1.2 0 0 121 i
*> 100.122.0.0/16 100.121.1.2 0 121 122 iEach group should see something very similar to this on their Border router.
Check on the Core, Access and Peering Routers for what you now see in the BGP table. Are there differences from what is on the Border router? Can you explain what they are, and why?
The border router connects to the upstream provider, and therefore gives us access to the whole Internet. The upstream provider will usually send us a default route by eBGP. Once we hear this default route, how should it be propagated around the autonomous system?
It can be propagated using iBGP as we have just seen, but that tends to be non-optimal, certainly when trying to load balance between two or more transit providers, as the BGP best path is just that, the one and only best path. If we distribute the default by the IGP instead, then at least the default route becomes the nearest exit, to the nearest border router (we only have one in this lab, but a future scaled version of this network infrastructure would double up on the core, border and peering routers at least).
IS-IS by default will always originate a default route with the default-information originate command (unlike OSPF which will do it only if there is a default route in the Global RIB)2. So we need to fix this so that IS-IS will only announce a default if it sees the default in the Global RIB. To do this we will create IPv4 and IPv6 prefix-lists which have the default route in them:
ip prefix-list DEFAULT-ROUTEv4 permit 0.0.0.0/0
ipv6 prefix-list DEFAULT-ROUTEv6 permit ::/0Now we create a route-map which matches the default route, first for IPv4:
route-map DEFAULT-ORIGv4 permit 10
match ip address prefix-list DEFAULT-ROUTEv4
!and then for IPv6 (using same name, but replacing v4 with v6):
route-map DEFAULT-ORIGv6 permit 10
match ipv6 address prefix-list DEFAULT-ROUTEv6
!and finally we apply the route-map to the default-information originate command in IS-IS:
router isis asX0
default-information originate route-map DEFAULT-ORIGv4
!
address-family ipv6
default-information originate route-map DEFAULT-ORIGv6
!
Check on the Core, Access and Peering Routers what you now see in the BGP table. And look at the Routing table on each. Are there differences? Can you explain what is happening now?
What does:
show ip bgp 0.0.0.0 0.0.0.0
show ip route 0.0.0.0 0.0.0.0and
show ipv6 route ::/0
show bgp ipv6 unicast ::/0show you on the core router and on the peering router?
You will notice that the default route is being propagated by BGP throughout the AS.
On the core and access routers, you should see “complaints” of a RIB failure when you look at the BGP table, because IS-IS has a default route with a lower protocol distance.
On the peering router, it will complain of a RIB failure when you look at the BGP table, because there is a static default route to the Null interface.
While there is nothing wrong with a RIB failure, we can just remove the default from being propagated by the iBGP process.
To do this, we go back to the eBGP session with the transit provider (on the border router), look for the default, tag it with the no-advertise community, and then the border router will no longer announce the default by iBGP.
To do this we are going to augment the existing inbound route-map. Statement 10 already allows all prefixes incoming, so what we need to do is insert a line before Statement 10 that looks for the default route, and tags it with the no-advertise community. We already have a prefix-list for the default route on the Border router, so we can re-use it for the extra line in the route-maps.
Here is the enhanced route-map for IPv4 (you do not need to re-enter Statement 10 as it already exists - all you need to do is added Statement 5):
route-map Transitv4-in permit 5
description Do not propagate the default route
match ip address prefix-list DEFAULT-ROUTEv4
set community no-advertise
!
route-map Transitv4-in permit 10
description Allow full routes
match ip address prefix-list FULL-ROUTESv4
!and then we create the IPv6 version:
route-map Transitv6-in permit 5
description Do not propagate the default route
match ipv6 address prefix-list DEFAULT-ROUTEv6
set community no-advertise
!
route-map Transitv6-in permit 10
description Allow full routes
match ipv6 address prefix-list FULL-ROUTESv6
!Once this is done, we need to refresh the eBGP session the Border router has with the Transit router:
BX# clear ip bgp <Transit-AS> in
BX# clear bgp ipv6 unicast <Transit-AS> inTo confirm, has the default route now disappeared from the BGP table on the Core, Access and Peering routers? If not, check your configuration, check the route-refresh command you issued above.
Once this has been completed, test the connectivity. Can you reach the other groups in the class? You should be able to ping all the IPv4 and IPv6 loopbacks across the whole classroom.
Can you see the Internet too? The lab has IPv4 connectivity to the Internet - check that this works by trying a few pings or traceroutes to well known destinations (e.g. to 8.8.8.8).
The instructors will let you know if the lab has IPv6 connectivity. If it does, check IPv6 connectivity to the Internet as well, by trying a few pings or traceroutes to well know destinations (e.g. to 2001:4860:4860::8888).
Hint: for the traceroutes, try using the loopback address as the source for your pings and traceroutes3.
This appendix shows the minimum configuration used for the TR1 router in this lab. The TR2 router has a very similar configuration.
interface GigabitEthernet0/0
description Link to TR2 (and to the world)
ip address 100.121.0.0 255.255.255.254 secondary
ip address 100.64.0.2 255.255.252.0
no ip redirects
no ip proxy-arp
ipv6 address FE80::2 link-local
ipv6 address 2001:18::/127
ipv6 address 2001:DB8::2/64
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
!
interface GigabitEthernet0/1
description Link to AS10
ip address 100.121.1.0 255.255.255.254
ipv6 address 2001:18:0:10::/127
!
interface GigabitEthernet0/2
description Link to AS20
ip address 100.121.1.2 255.255.255.254
ipv6 address 2001:18:0:11::/127
!
interface GigabitEthernet0/3
description Link to AS30
ip address 100.121.1.4 255.255.255.254
ipv6 address 2001:18:0:12::/127
!
interface GigabitEthernet0/4
description Link to AS40
ip address 100.121.1.6 255.255.255.254
ipv6 address 2001:18:0:13::/127
!
router bgp 121
bgp log-neighbor-changes
bgp deterministic-med
no bgp default ipv4-unicast
neighbor 2001:18::1 remote-as 122
neighbor 2001:18::1 description eBGP with TR2
neighbor 2001:18::1 ttl-security hops 1
neighbor 2001:18::1 password BGPlab
neighbor 2001:18:0:10::1 remote-as 10
neighbor 2001:18:0:10::1 password BGPlab
neighbor 2001:18:0:11::1 remote-as 20
neighbor 2001:18:0:11::1 password BGPlab
neighbor 2001:18:0:12::1 remote-as 30
neighbor 2001:18:0:12::1 password BGPlab
neighbor 2001:18:0:13::1 remote-as 40
neighbor 2001:18:0:13::1 password BGPlab
neighbor 100.121.0.1 remote-as 122
neighbor 100.121.0.1 description eBGP with TR2
neighbor 100.121.0.1 ttl-security hops 1
neighbor 100.121.0.1 password BGPlab
neighbor 100.121.1.1 remote-as 10
neighbor 100.121.1.1 password BGPlab
neighbor 100.121.1.3 remote-as 20
neighbor 100.121.1.3 password BGPlab
neighbor 100.121.1.5 remote-as 30
neighbor 100.121.1.5 password BGPlab
neighbor 100.121.1.7 remote-as 40
neighbor 100.121.1.7 password BGPlab
!
address-family ipv4
network 100.121.0.0 mask 255.255.0.0
neighbor 100.121.0.1 activate
neighbor 100.121.1.1 activate
neighbor 100.121.1.1 default-originate
neighbor 100.121.1.3 activate
neighbor 100.121.1.3 default-originate
neighbor 100.121.1.5 activate
neighbor 100.121.1.5 default-originate
neighbor 100.121.1.7 activate
neighbor 100.121.1.7 default-originate
distance bgp 200 200 200
exit-address-family
!
address-family ipv6
network 2001:18::/32
neighbor 2001:18::1 activate
neighbor 2001:18:0:10::1 activate
neighbor 2001:18:0:10::1 default-originate
neighbor 2001:18:0:11::1 activate
neighbor 2001:18:0:11::1 default-originate
neighbor 2001:18:0:12::1 activate
neighbor 2001:18:0:12::1 default-originate
neighbor 2001:18:0:13::1 activate
neighbor 2001:18:0:13::1 default-originate
distance bgp 200 200 200
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 100.64.0.1
ip route 100.121.0.0 255.255.0.0 Null0
!
ipv6 route 2001:18::/32 Null0
ipv6 route ::/0 GigabitEthernet0/0 FE80::1
!Later on in this workshop we will start looking at what routes we really need to accept from our upstream.↩︎
OSPF version of the command has a different result from the IS-IS version of the command. To conditionally announce the default in OSPF, default-information originate is sufficient. If the operator needs to always announce the default, regardless of whether it is in the Global RIB or not, the always keyword needs to be added.↩︎
Can you explain why we are doing this, and not using the default (which would be the point-to-point link address of the outbound interface)?↩︎