24 Aug

IGMP Snooping on single switch

The IGMP Snooping is a nice feature to limit propagation of multicast traffic in Layer 2 Ethernet network. It listens to IGMP (Internet Group Management Protocol) messages traversing the network to learn about source and receivers. Using this information switch builds a map of links where it replicates the multicast frames. What if we do not have this feature enabled? The switch will treat multicast frames as an unknown type and will broadcast over all active ports no matter is there is receiver interested in frames from the particular multicast group or not.

IGMP Snooping on a single switch is useful to limit propagation of multicast frames when source and receivers are in same layer 2 broadcast domain, in the same VLAN. IGMP Snooping is enabled on Cisco switches by default, but it does not mean it will work out-of-box.

Read More

18 Aug

Generate multicast​ traffic in VIRL using Ostinato

Cisco and VIRL logos

Ostinato is a traffic generator. You can use it to craft packets and send flow into your network. You can even send multiple streams if required. It is a tool that network admins and developers should use for testing the system or application against various scenarios. Ostinato is by default available on Cisco VIRL so we can use it as a packet generator in our simulations.

Ostinato consists of two components – the LXC image run in a simulation that generates the traffic and GUI frontend. In this article, I will show you how to use it to generate a multicast stream in VIRL simulation.

Read More

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