Tuesday, 18 October 2016

Customer - ISP BGP Lab (Removing private ASN's)

For this lab we will have a customer site (ASN 16500) that connects to an ISP over over BGP.

The customer has an inner core consisting of 3 routers (R1, R2 and R3) running OSPF as an IGP. The customer's edge has a border router that is running BGP and will peer with the ISP's router R5.

The goal here is to ensure that when clients within the core network attempt to access the internet - will be directed towards are edge router and in turn the IPS's edge router (R5.)



The GNS3 lab can be downloaded here.

The process flow is as follows:

1. Client in customer core (e.g. 172.16.0.200) attempts to ping a public IP: 8.0.0.1

2. R1 is hooked up to the OSPF backbone and is aware of a default route being advertised on R4. R2 also has a default route pointing to R5 (which is not part of the OSPF domain, rather BGP.)

3. R4 is advertising a public (BGP) prefix of 14.0.0.0/24 - so in order to make sure any packets originating from our internal subnet (172.16.0.0/23) are reachable by the remote subnets we should NAT the traffic to the 14.0.0.0/24 subnet.

4. Once NAT'd R4 will lookup the appropriate root for 8.0.0.1 in it's routing table - although we will configure prefix filtering - so R4 will only see a default route to R5.

5. Once the packet arrives at R5 the route will be looked up against the routing table and it will identify that 8.0.0.0/24 is within ASN 500 and will forward the packet out lo0.

Since we are connecting to a private ASN from the customer to ISP we will have to remove the private AS when it hits the IPS's public ASN / router.

R1>
enable
conf t

int e0/0
ip address 192.168.10.1 255.255.255.252
no shutdown
ip ospf 1 area 0

int e0/1
ip address 192.168.20.1 255.255.255.252
no shutdown
ip ospf 1 area 0

int lo 0
ip address 172.16.0.1 255.255.254.0

router ospf 1
network 172.16.0.0 0.0.1.255 area 0

Note: At this point I expected the loopback adapter subnet to be advertised via OSPF - well it was - but only as a /32 (rather than /24)... It turns out by default the router treats the address as a single IP e.g. /32 even if you have defined something other than /32 - in order to instruct the router to advertise its actual subnet we can issue:

int lo 0
ip ospf network point-to-point
do clear ip ospf pro

R2>
enable
conf t

int e0/0
ip address 192.168.20.2 255.255.255.252
no shutdown
ip ospf 1 area 0

int e0/1
ip add 192.168.30.1 255.255.255.252
no shutdown
ip ospf  1 area 0

int e0/2
ip add 192.168.40.2 255.255.255.252
no shutdown
ip ospf 1 area 0

R3>
enable
conf t

int e0/0
ip address 192.168.10.2 255.255.255.252
no shutdown
ip ospf 1 area 0

int e0/1
ip address 192.168.30.2 255.255.255.252
no shutdown
ip ospf 1 area 0

R4>
enable
conf t

int e0/0
ip address 192.168.40.1 255.255.255.252
no shutdown
ip ospf 1 area 0

int e0/1
ip address 192.178.50.1 255.255.255.252
no shutdown

Ensure that we do not advertise anything over our link to the ISP:

router ospf 1
passive-interface e0/1

Check neighbor adjacencies etc. with:

do show ip ospf ne

and

do show ip route [ospf]

Now we will setup eBGP between R4 and R5:

R4>
router bgp 16000
neighbor 14.0.0.2 remote-as 16001

R5>
enable
conf t

int e0/0
ip address 14.0.0.1 255.255.255.0
no shutdown

router bgp 16001
neighbor 14.0.0.1 remote-as 16000
network 14.0.0.0 mask 255.255.255.0

we want the customers edge router to use the ISP's edge router as the default gateway - so in order to this we need to use the 'defualt-originate' command:

R5>
neighbor 14.0.0.1 default-originate

We also want to ensure that R4 is not flooded with prefixes when its hooked up to BGP - so we can configure a prefix list to filter out all routes accept the default route R5 is advertising:

R5>
ip prefix-list default-route seq 5 permit 0.0.0.0/0
router bgp 16001
neighbor 14.0.0.1 prefix-list default-route out

This will instruct the ISP's router (R5) to inject a default route into the BGP table for the R4 peer (only).

R5>
int e0/1
ip address 192.168.60.2 255.255.255.252
no shutdown

router bgp 16001
neighbor 192.168.60.1 remote-as 500

Now review the routing table on R4 and confirm that only the default route is present:

do show ip route

R6>
int e0/0
ip address 192.168.60.1 255.255.255.252
no shutdown

int lo 0
ip address 8.0.0.1 255.255.255.0

router bgp 500
neighbor 192.168.60.2 remote-as 16001

We also want to ensure that the traffic is NAT'd to 14.0.0.0 or else return traffic from the remote subnets will not reach us (since they are unaware of our internal subnets as they are not present in our BGP table.):

R4>
int e0/0
ip nat inside

int e0/1
ip nat outside

ip access-list standard NAT
permit 172.16.0.0 0.0.1.255
ip nat inside source list NAT interface e0/1 overload

We can then attempt to ping 8.0.0.1 from R1 (source address 172.16.0.1):

R1>
do ping 8.0.0.1 source 172.16.0.1

You should see a new translation in the NAT table:

R4>
do show ip nat trans

Now lets setup R6 and configure BGP:

R6>
int e0/1
ip address 192.168.70.2 255.255.255.252
no shutdown

router bgp 500
neighbor 192.168.70.1 remote-as 600

R7>
int e0/0
ip address 192.168.70.1 255.255.255.252
no shutdown

router bgp 600
neighbor 192.168.70.2 remote-as 500

Also note that the ISP in this scenario is using a private ASN to peer with the customer - the traffic's next hop will be ASN 500 which is reversed for public use and hence we will need to ensure that the private AS number is removed before before it forwards the prefix to other public AS's. To do this we will apply the 'remove-private-as' command:

R6>
router bgp 500
neighbor 192.168.70.1 remove-private-as
do clear ip bgp *

and then check the 14.0.0.0/24 prefix in our BGP table:

do show ip bgp 14.0.0.0/24

and we should notice that the AS_PATH now only contains ASN 500.

0 comments:

Post a comment