Archives for category: juniper junos

You might have been DoS-ed recently. And you can’t spend more money on special and expensive DoS detection and mitigation systems. Well, you have routers, don’t you? Some routing platforms support features which can be efficiently used to limit the impact of DoS attacks.

Let us take a brief look into one of these features on the Juniper MX gear. Read the rest of this entry »

Internet runs on BGP. Securing the BGP is the foundation for Internet routing security.

But it is not only the protocol we must take care of. BGP as an application is also vulnerable to various threats, like route manipulation and route hijacking. BGP will originate IP prefixes as it is being told to do. It is up to network administrators to mitigate the risk of BGP misusage or exploit attempts. Internet was ment to be a place for well-behaved, but, being enormous as it is today it can not be based on trust anymore. Internet resources, like autonomous system numbers (ASNs) and IP prefixes, must be given a validatable proof of holdership. This kind of proof can be given by Resource Certification systems. The resource certificates offers the basics for a secure Internet routing, particularly BGP route origin validation.
Read the rest of this entry »

Juniper Junos OS is full of useful tricks. Here is one of them…

Apply-path is a really cool feature in Junos OS. With the apply-path statement you can expand a prefix list to include all prefixes pointed to by a defined path. This give you the ability to create dynamic prefix lists thus facilitates many configuration tasks like firewall filters and policy statements. Read the rest of this entry »

Granular, efficient and distributed firewalling based on good old BGP.

BGP can carry many different network-related information, sometimes described as address families or NLRI (Network Layer Reachability Information). One of them is FlowSpec (RFC 5575), which allows BGP to propagate a filter for a specific IPv4 packet flow. A flow, which is defined by an n-tuple, like a combination of source and destination IP address, protocol number and ports, can be discarded, rate-limited, redirected to some analysis or mitigation device etc. BGP is simply used to signal the routers to perform appropriate filtering actions for a certain flow. Read the rest of this entry »

Router software is facing a new era with IPv6. Some of the methods, which worked perfectly well for v4, were not updated for v6 and they silently ignore the new IP protocol. Ignorance might be a bliss, but not in routing software.

Apply this policy on your Cisco gear to all IPv4 prefixes present in the BGP routing table for IPv4 (show bgp ipv4 unicast route-map IgnoranceIsBliss):

ipv6 prefix-list MatchSomeV6 permit 2001:678:4::/48
!
route-map IgnoranceIsBliss permit 10
 match ipv6 address prefix-list MatchSomeV6
 set community 2107:12345
route-map IgnoranceIsBliss deny 20

… or this one on your Juniper router (test policy IgnoranceIsBliss 0/0 will do the job):

[edit policy-options]
prefix-list MatchSomeV6 {
    2001:678:4::/48;
}
community Test12345 members 2107:12345;
policy-statement IgnoranceIsBliss {
    term Match6 {
        from {
            prefix-list MatchSomeV6;
        }
        then {
            community set Test12345;
            accept;
        }
    }
    term DenyOther {
        then reject;
    }
}

The policy is telling you: “set community for some IPv6 prefixes that match certain criteria and don’t mess with others”. One would expect that all IPv4 prefixes will be ignored by that policy, since they do not match the criteria in any of the terms. Not true on a Cisco router (I’ve verified this on 6500, 3560/3750 and 7200 running some decently up-to-date IOS) – match ipv6 address prefix-list catched all IPv4 prefixes and the community was set for them according to the route-map. JUNOS, however, passed the test – none of the IPv4 prefixes matched the IPv6 criteria.


As always, do not trust the damn machines!

A clean and powerful design of a routing policy in Juniper JUNOS rewards many network engineers, tired of looking into Cisco IOS route-maps, for crossing the line and juniperizeing themselves.

Routing tables (Routing information base – RIB) are like a heart in the router. These tables are pumping routes from one network neighbour to another and building up the forwarding table (Forwarding information base – FIB) which actually conducts the flow of the data packets. The interaction with network neighbours is controlled by policy. Routes are imported from some neighbour via some routing protocol and through some policy into a corresponding routing table. From there they can be exported via another policy to another protocol and to the outside world. Feeding the forwarding table is also controlled by an export policy.


It is easy to remember (while keeping in mind that routing table is the one in the centre): import to a routing table, export from a routing table, import to, export from, import to, export from …
Read the rest of this entry »