|
| ||||||||||||||||
| enum ASPathSegType { AS_NONE = 0, AS_SET = 1, AS_SEQUENCE = 2, AS_CONFED_SEQUENCE = 3, AS_CONFED_SET = 4 } | ASPathSegType |
#include <aspath.hh>
This file contains the classes to manipulate AS segments/lists/paths
An AS_PATH is made of a list of segments, each segment being an AS_SET or an AS_SEQUENCE. Logically, you can think an AS_SEQUENCE as a list of AsNum, and an AS_SET as an unordered set of AsNum; the path would then be made of alternate AS_SET and AS_SEQUENCEs. However, the max number of elements in an AS_SEQUENCE is 255, so you might need to split a sequence into multiple ones.
The external representation of AS_SET or AS_SEQUENCE is: 1 byte: segment type 1 byte: number of element in the segment n entries: the ASnumbers in the segment, 2 or 4 bytes each
In terms of internal representation, it might be more efficient useful to store segments as either an AS_SET, or a sequence of size 1, and then do the necessary grouping on output.
The current implementation allows both forms.
Note that the external representation (provided by encode()) returns a malloc'ed chunk of memory which must be freed by the caller.
RFC 3065 (Autonomous System Confederations for BGP) introduced two additional segment types:
AS_CONFED_SEQUENCE: ordered set of Member AS Numbers in the local confederation that the UPDATE message has traversed
AS_CONFED_SET: unordered set of Member AS Numbers in the local confederation that the UPDATE message has traversed
4-byte AS numbers need to be handled carefully. There are two main cases to consider: when we are configured to do 4-byte AS numbers, and when we are not.
When we are not configured to do 4-byte AS numbers all AS path information received from peers will be 2-byte AS numbers. If they're configured to do 4-byte AS numbers, they will send us an AS_PATH and an AS4_PATH, but if we're not configured to do 4-byte AS numbers, we shouldn't care. We don't merge the two; we propagate AS4_PATH unchanged, and do the normal stuff with the regular AS_PATH. The AS4_PATH is actually stored internally in an UnknownAttribute, as we don't need to know anything about it.
When we are configured to do 4-byte AS numbers, we can tell from the negotiated capabilities whether a peer is sending 4-byte AS numbers or 2-byte AS numbers. If a peer is sending 4-byte AS numbers, these arrive in the AS_PATH attribute, and we store them internally in an AS4Path, but stored in the ASPathAttribute, NOT in the AS4PathAttribute. If a peer is sending 2-byte AS numbers in AS_PATH, he may also propagate an AS4_PATH. We merge these on input, cross-validate the two, and store the results just like we would if we'd received a 4-byte AS_PATH. So, whatever our peer does, the only place we have AS path information that we use for the decision process is in the ASPathAttribute.
If we're doing 4-byte AS numbers and our peer is doing 4-byte AS numbers, then all routes we send him will contain 4-byte AS_PATH attributes. We just need to make sure we use the right encode() method. If our peer is not doing 4-byte AS numbers, then we send a 2-byte AS_PATH, substituting AS_TRANS for any AS numbers that can't be represented in 2 bytes. We also construct an AS4_PATH from our ASPathAttribute, and send that too.
| typedef enum -- | -- |
#include <dump_iterators.hh>
| enum -- { STILL_TO_DUMP, CURRENTLY_DUMPING, DOWN_DURING_DUMP, DOWN_BEFORE_DUMP, COMPLETELY_DUMPED, NEW_PEER, FIRST_SEEN_DURING_DUMP } | -- |
#include <dump_iterators.hh>
| enum BgpPacketType { MESSAGETYPEOPEN = 1, MESSAGETYPEUPDATE = 2, MESSAGETYPENOTIFICATION = 3, MESSAGETYPEKEEPALIVE = 4 } | BgpPacketType |
#include <packet.hh>
| enum Notify { MSGHEADERERR = 1, OPENMSGERROR = 2, UPDATEMSGERR = 3, HOLDTIMEEXP = 4, FSMERROR = 5, CEASE = 6 } | Notify |
#include <packet.hh>
Notification message error codes with associated subcodes.
| enum Afi { AFI_IPV4 = AFI_IPV4_VAL, AFI_IPV6 = AFI_IPV6_VAL } | Afi |
#include <parameter.hh>
| enum Safi { SAFI_UNICAST = SAFI_UNICAST_VAL, SAFI_MULTICAST = SAFI_MULTICAST_VAL, } | Safi |
#include <parameter.hh>
| inline
const char *
pretty_string_safi (Safi safi)
| pretty_string_safi |
#include <parameter.hh>
| enum ParamType { PARAMINVALID = 0, PARAMTYPEAUTH = 1, PARAMTYPECAP = 2 } | ParamType |
#include <parameter.hh>
| enum CapType { CAPABILITYMULTIPROTOCOL = 1, CAPABILITYREFRESH = 2, CAPABILITYREFRESHOLD = 128, CAPABILITYMULTIROUTE = 4, CAPABILITY4BYTEAS = 65, CAPABILITYUNKNOWN = -1, } | CapType |
#include <parameter.hh>
| typedef ref_ptr<const BGPParameter> ParameterNode | ParameterNode |
#include <parameter.hh>
| typedef list <ParameterNode> ParameterList | ParameterList |
#include <parameter.hh>
| enum PathAttType { ORIGIN = 1, AS_PATH = 2, NEXT_HOP = 3, MED = 4, LOCAL_PREF = 5, ATOMIC_AGGREGATE = 6, AGGREGATOR = 7, COMMUNITY = 8, ORIGINATOR_ID = 9, CLUSTER_LIST = 10, MP_REACH_NLRI = 14, MP_UNREACH_NLRI = 15, AS4_PATH = 17, AS4_AGGREGATOR = 18, } | PathAttType |
#include <path_attribute.hh>
PathAttribute
components of the path attribute. They have variable sizes The actual layout on the wire is the following: [ flags ] 1 byte [ type ] 1 byte [ len ][....] 1 or 2 bytes [ data ] len bytes
PathAttribute is the base class for a set of derived class which represent the various attributes. A PathAttribute object of a given type can be created explicitly, using one of the constructors, and then adding components to it; or it can be created by calling the create() method on a block of data received from the wire.
In addition to the parsed components (next hops, AS numbers and paths, and various other attributes), the objects always contain the wire representation of the object, a pointer to which is accessible with the data() method, and whose size is size(). Whenever the object is altered, the wire representation needs to be recomputed.
| enum OriginType { IGP = 0, EGP = 1, INCOMPLETE = 2 } | OriginType |
#include <path_attribute.hh>
| typedef NextHopAttribute<IPv4> IPv4NextHopAttribute | IPv4NextHopAttribute |
#include <path_attribute.hh>
| typedef NextHopAttribute<IPv6> IPv6NextHopAttribute | IPv6NextHopAttribute |
#include <path_attribute.hh>
| enum FSMState { STATEIDLE = 1, STATECONNECT = 2, STATEACTIVE = 3, STATEOPENSENT = 4, STATEOPENCONFIRM = 5, STATEESTABLISHED = 6, STATESTOPPED = 7 } | FSMState |
#include <peer.hh>
| enum FSMEvent { EVENTBGPSTART = 1, EVENTBGPSTOP = 2, EVENTBGPTRANOPEN = 3, EVENTBGPTRANCLOSED = 4, EVENTBGPCONNOPENFAIL = 5, EVENTBGPTRANFATALERR = 6, EVENTCONNTIMEEXP = 7, EVENTHOLDTIMEEXP = 8, EVENTKEEPALIVEEXP = 9, EVENTRECOPENMESS = 10, EVENTRECKEEPALIVEMESS = 11, EVENTRECUPDATEMESS = 12, EVENTRECNOTMESS = 13 } | FSMEvent |
#include <peer.hh>
| enum PeerOutputState { PEER_OUTPUT_OK = 1, PEER_OUTPUT_BUSY = 2, PEER_OUTPUT_FAIL = 3 } | PeerOutputState |
#include <peer.hh>
| enum PeerType { PEER_TYPE_EBGP = 0, PEER_TYPE_IBGP = 1, PEER_TYPE_EBGP_CONFED = 2, PEER_TYPE_IBGP_CLIENT = 3, PEER_TYPE_UNCONFIGURED = 4, PEER_TYPE_INTERNAL = 255 } | PeerType |
#include <peer_data.hh>
| void initialize_profiling_variables (Profile& p)
| initialize_profiling_variables |
#include <profile_vars.hh>
Profile variables See: profile_vars.cc for definitions.
| typedef enum ribout_queue_op | ribout_queue_op |
#include <route_queue.hh>
| enum ribout_queue_op { RTQUEUE_OP_ADD = 1, RTQUEUE_OP_DELETE = 2, RTQUEUE_OP_REPLACE_OLD = 3, RTQUEUE_OP_REPLACE_NEW = 4, RTQUEUE_OP_PUSH = 5 } | ribout_queue_op |
#include <route_queue.hh>
| enum RouteTableType { RIB_IN_TABLE = 1, RIB_OUT_TABLE = 2, CACHE_TABLE = 3, DECISION_TABLE = 4, FANOUT_TABLE = 5, FILTER_TABLE = 6, DELETION_TABLE = 7, DUMP_TABLE = 8, NHLOOKUP_TABLE = 9, DEBUG_TABLE = 10, POLICY_TABLE = 11, AGGREGATION_TABLE = 12, DAMPING_TABLE = 13 } | RouteTableType |
#include <route_table_base.hh>
