Archives for category: policy

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 »

Using Cisco ACLs to match routing prefixes or just to mystify the configuration?

A decade ago route classification or filtering in Cisco IOS was commonly done with the help of access control lists (ACLs). You will still find this method in some (very) old configurations and Cisco trainings (no matter how advanced they are ;-)). I’ve run into this legacy stuff recently and I was forced once again to understand how it works. It is confusing but rather simple.

An entry in the extended IPv4 ACL has the following meaning:

permit|deny ip <network> <wildcard mask of network> <subnet mask> <wildcard mask of subnet mask>

The “source” part of the rule selects the prefixes and the “destination” part selects prefix masks (prefix lengths). Read the rest of this entry »

Let’s play with BGP for a while. Remember, BGP is all about policy ;-).

Here, customer (AS 300) uses AS 1 for his primary upstream and he has another upstream provider for redundancy. In this simple scenario both providers announce a default route for the customer:
multihop_ebgp
Read the rest of this entry »

I’ve found one of the best answers to the question “What is BGP for?” in one of Philip Smith’s presentations (google for “BGP Best Current Practices”): “What is an IGP not for?”

Internal Routing Protocols (IGPs), like IS-IS and OSPF, are used to maintain infrastructure connectivity. They carry infrastructure addresses and are designed for rapid convergence within reasonably sized and manageable routing domains. On the other hand, BGP is designed primarily as a routing policy tool. External BGP carries Internet prefixes and exchanges them between autonomous systems according to some policy and rules of good behaviour. BGP is also used internally to carry customer prefixes and adds full flexibility to the routing decisions. BGP can handle huge routing tables, but in a somehow stable environment. It is designed to scale with expanding networks but not to respond quickly to topology changes. 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 »