25 Jan

No LACP on Juniper SRX650 built-in ports

Quite a surprise – I was configuring etherchannel on SRX650 to provide redundancy between SRX and EX switch. Quite natural is to use LACP as a control protocol for that. Unfortunately SRX650 does not support LACP on built-in ports. It is supported only on extension cards. You can see LACP counters of received LACP packets increasing but none are sent. That means if you want to build etherchannel with built-in interface (in example in case of extension module failure) you have to build bundle without LACP. It’s not the way I prefer…..

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.