I had to perform troubleshooting of management traffic exchanged between IPS module in ASA5525-X and management station. I had some communication problems resulting in denied traffic on firewall placed in between (and it’s not the ASA itself). The best option is always sniffing packet headers on either end, as I had no possibility to do it on management station IPS was the next option.
Read More
BFD – presentation from PLNOG10
A little late but here it is – presentation from my session on PLNOG10 conference that took place in Warsaw 28th Feb – 1st Match. This is one of best conferences for Service Providers in country and region.
This time I was talking about BFD protocol, deployment strategies and caveats. The presentation was in Polish but slides are in English.
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…..
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.
Last week RIPE announced that they are down to last /8 of public IPv4 addresses. This means problems. PI addresses are not assigned anymore and LIR’s can get up to single /22. Dark day in Europe…. But maybe now we start moving to IPv6?
You can now get /29 IPv6 subnet instead of default /32 from RIPE, when you’re getting new address allocation. RIPE-552 document has been updated in point 5.1.2 and now not only /32 is default allocation size for new IPv6 subnets. Of course any allocation between /29 and /32 is possible without providing additional documentation.
It’s possible to extend current /32 allocation to /29. The subnets were allocated in schema that if you requested initial /32 subnet, next /32 were reserved not straight after that, but space for extending to /29 were left.
Look to Jan Zorz’s presentations or check RIPE webpage for more details.
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
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.
Our network is now able to carry vpnv4 prefixes, so it’s now time to receive them from customers. As mentioned before vpnv4 prefix consist of route distinguisher (RD) and IPv4 prefix. But that’s not all. We have to have set of tools to differ one customer from another and control propagation of prefixes. Those tools are VRFs, RDs and RTs.
Read More