04 May

How to setup VPN between Juniper SRX and AWS Cloud

I’ve said during several conferences where I had a privilege to be a speaker that clouds are one of the futures of computing along with DevOps/SysOps and Machine Learning. But there is no computing if you don’t have the data to compute or you have no way to send it to the cloud in reliable and secure way or you don’t have cloud infrastructure to perform computation. That’s why we need to take a look how to setup VPN between Juniper SRX and AWS Cloud.

I think that hybrid cloud will be the model how many of computer system will work in net few years. Private clouds are not scalable and public clouds cannot address all needs of current systems. So hybrid mode is a solution. But it requires reliable and easy to setup and maintain ways to connect on-premise resourced to public cloud. The technology is here and it’s called VPN.

Read More

01 Jan

Prefix exports between routing-instances on Juniper

Juniper devices are quite flexible when it comes to routing tables and exporting prefixes between them, but all rib groups mechanism is not well explained in documentation. In general Juniper documentation is not really good but well….

Let’s first define two routing instances

routing-instance {
    CUSTOMER1 {
        instance-type virtual-router;
        interface ge-0/0/2.20;
    }
    CUSTOMER2 {
        instance-type virtual-router;
        interface ge-0/0/2.21;
    }
}

By default those two routing tables are totally separated so customers can’t communicate with each other.

CUSTOMER1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/27       *[Direct/0] 4w2d 10:52:08
                    > via ge-0/0/2.20
10.0.1.28/32      *[Local/0] 4w2d 10:52:08
                      Local via ge-0/0/2.20

CUSTOMER2.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.2.0/27       *[Direct/0] 4w2d 10:52:08
                    > via ge-0/0/2.21
10.0.2.28/32      *[Local/0] 4w2d 10:52:08
                      Local via ge-0/0/2.21

Now if we want to let them communicate with each other we have to export prefixes between routing tables. To do that we have to use rib-groups and import/export policies.

routing-instance {
    CUSTOMER1 {
        instance-type virtual-router;
        interface ge-0/0/2.20;
        routing-options {
            interface-routes {
                rib-group inet CUSTOMER1-RG;
            }
        }
    }
}

for first customer we define rib-group for all routes directly connected. To make things little easier let’s say it’s just an identifier for prefixes of directly connected routes. Now we have to define export policies

routing-options {
        CUSTOMER1-RG {
            import-rib [ CUSTOMER1.inet.0 CUSTOMER2.inet.0 ];
        }
    }
}

What we see above is import-policy defined for for rib-group CUSTOMER1-RG. We tell the routers to import matching prefixes (in this case matching only CUSTOMER1-RG) from CUSTOMER1.inet.0 routing table to CUSTOMER2.inet.0 routing table. We can specify more destination routing tables within this command.

CUSTOMER2.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/27       *[Direct/0] 4w2d 10:56:08
                    > via ge-0/0/2.20
10.0.1.28/32      *[Local/0] 4w2d 10:56:08
                      Local via ge-0/0/2.20
10.0.2.0/27       *[Direct/0] 4w2d 10:56:08
                    > via ge-0/0/2.21
10.0.2.28/32      *[Local/0] 4w2d 10:56:08
                      Local via ge-0/0/2.21

So now we have CUSTOMER1 prefixes in CUSTOMER2 routing table. To make configuration all working we have to perform same export from CUSTOMER2 to CUSTOMER1 routing-instance using same configuration way.

01 Jul

MPLS workshop #5 – CE-PE connection using EIGRP

Last protocol I’ll be focusing on for CE-PE connection is EIGRP. As in OSPF redistributing routes from EIGRP to BGP and back to EIGRP makes them external from routing protocol perspective. Using BGP extended communities many characteristics including AS number, tags or metric components are passed between PE routers and allows reconstruction of prefix. If the EIGRP route is internal it’s redistributed back as internal if AS numbers on remote PE router matches the source one (it’s encoded using external community). Otherwise it’s redistributed as EIGRP external.
Read More

26 Jun

MPLS workshop #4 – CE-PE connection using OSPF

In previous example a CE-PE routing protocol was BGP, but it’s not only option. We can also use IGP protocols like OSPF. We use this protocol for customers in VRF_A. On PE router OSPF is redistributed to iBGP and vice versa, otherwise vpnv4 routes won’t be propagated through MPLS domain. MPLS VPN area is usually referred as super backbone and PE routers are ASR routers.

Because of redistribution in normal OSPF operation those routes would be treated as external routes (LSA Type 5) when redistributed back to OSPF. PE router is treated as ASBR. When redistributing from MP-BGP back to OSPF those routes are marked as inter-area routes (LSA Type 3), even if the area numbers on both ends does not match. However if customer network has more than one area PE routers must be in area 0 or virtual-link between PE router and nearest ABR must be configured.

Read More

18 Jun

MPLS workshop #2 – MP-BGP for L3VPN in the Core

Our core network after first chapter of workshop is able to forward labeled packets. Let’s focus now on deploying some services within this network. First MPLS L3VPN. As for now we have IS-IS as an IGP protocol in the core to forward prefixes of links and loopbacks, and LDP to maintain label exchange. Next step is to introduce mechanism that will allow us to attach label information to prefixes. MP-BGP is an extension of standard BGP protocol that let us carry MPLS VPN routes. It’s flexible and well known protocol. At this step we configure core routers (P and PE) to carry MPLS VPN routes.
Read More

16 Jun

MPLS workshop #1 – Basic MPLS Core configuration

This is the first post in a series where I’ll be presenting various aspects of MPLS network. Starting from basics and moving forward to more advanced topics. We’ll be using following topology:

As you can see we have two P routers, three PE routers, four CE routers and one of PE routers will also act as BGP route reflector. Different MPLS L3VPN networks are using different CE-PE protocols. Every router have Loopback0 interface configured with address 10.0.0.x/32 where x is the router number. Subnets on links between routers are addressed in scheme known from CCIE workbooks, that third octet shows between what routers link is configured and fourth octet represents router number. So if we are talking about link between R4 and R5 the address on R4 E0/1 interface is 10.0.45.4/24 and on R5 E0/1 interface 10.0.45.5/24.
Read More