MIPv6 ready kernel

If you are interested in installing mip6d daemon and testing IPv6 Network Mobility.

The following deb modified kernel (64 bit) file has been generated using the instructions as posted on umip.org.

You can install the following deb Download file on your debian machine, this is Kernel 2.6.32, tested on the most current debian distribution 6.0.5 squeeze.


you have to follow the rest of the guide on umip.org which is essentially 5 lines to install the userland daemon after.

Migrating SMTP server ... no problem

In the process of migrating the SMTP server to the cloud or another server, it can be painful to go around change smtp server in all printers, scripts, SNMP servers .... assuming some of them take only IPs and not hostnames.

I found this amazing tool to use in the interim phase until officially moving to the new server.

RINETD is very handy to redirect a connection to a certain port to a different machine and port.

http://www.boutell.com/rinetd/

At the final migration you can use a router or firewall to translate the IP of the old machine to  the new server.

ASA syslog ID 419002

Duplicate TCP SYN from inside:source-ip/source-port to inside:dest-ip/dest-port with different initial sequence number

After spending an hour looking at this and capturing traffic, turns out to be a routing problem.

Just thought I put this out there, might help someone.

Mobility Support in IPv6 - RFCs 3775 and 6275

Mobility Support in IPv6 is defined in RFC 6275, yet most current implementations are based on RFC 3775.

I wanted to highlight the main differences between the two RFCs in this article.

There is no dramatic change in the header format or size that would render previous implementations obsolete.


Aside from replacing plenty of "Which"s by "That"s and references to updated RFCs (ex Neighbor Discovery RFC 4861).

Below is a table of the main points :

 

RFC 3775	RFC 6275
Home and CoA must be Site-Local Addresses	Home and CoA must be Unique-Local Addresses
IKE	IKEv2
	Handling Interruptions to Return Routability
	Defines a new status code in the binding update acknowledgement message (174 - Invalid CoA)
Specifies processing of the binding update according to the lifetime and CoA value	Specifies processing of the binding update according to the lifetime only
	Primary CoA de-registration is redefined to prevent a race condition.
	Two new Protocol Constants defined MAX_DELETE_BCE_TIMEOUT MAX_RO_FAILURE

Automate backing up your Cisco routers/switches config to FTP server

After many years of working with Cisco IOS, I just discovered Kron, the *nix cron reincarnated.

Handy to automate configuration backup to an FTP server.

Bad news :

1.  it does not deal with interactive style commands (expected)
2. It does not work on PIX/ASA

 conf t  
 kron policy-list BCKP  
 cli sh running-config | redirect ftp://username:password@ftp_server_ip/hostname.cfg  
 exit  
 kron occurrence MONTHLY in 30:00:00 recurring  
 policy-list BCKP  
 end  
 wr mem  

Manipulating BGP attributes for route selection

Weight	Affect local router (O/G traffic)	Encourages local traffic to use a specific AS exit point to reach a remote subnet or AS. Ex: For a router to prefer a neighbour over another (IBGP or EBGP) for specific o/g traffic.
Local Preference	Affects local AS IBGP peers (O/G traffic)	Encourages local traffic to use a specific AS exit point to reach a remote subnet or AS. Ex:  For the AS to use one ISP link as main and one to a different ISP as backup.
AS_PATH	Affects remote AS and other upstream ASes (I/C traffic)	Discourages remote traffic from using a specific AS entry point to reach a local subnet. Ex:  For the AS to prefer Web server traffic to enter through a specific link.
MED	Affects directly remote AS only (When there are two links)(I/C traffic)	Discourages remote traffic from using a specific AS entry point to reach a local subnet. Ex:  For the neighbour AS to use one link as main and another as Backup.
Community	Affects remote AS and other upstream ASes	Mark traffic with a community so that neighbor can perform a specific action on it. Ex:  For the BGP peer to apply a specific policy on the traffic.

Route advertisement (based on BGP table)

BGP Route advertisement rules


Looking at the BGP table only Best ruotes are examined for advertisement 
(because they will be in the routing table) the rest of the routes can be ignored.


Cisco IOS only consider routes in the routing table for advertisement.

Router to IBGP peer (Route-NH-LP-MED-AS Path)

1. Only Best routes are candidate for advertisement.
2. Connected routes always advertised.
2. If next-hop-self is not set the route will have next hop of whatever is in the BGP table.
3. If the route has a next hop of an IBGP peer it is not advertised.
4. If the route has a next hop of an EBGP peer it is advertised to the IBGP peer even if it is also learned from that IBGP peer.

Router to EBGP peer (Route-NH-AS Path)

1. Only Best routes are candidate for advertisement.
2. Connected routes always advertised.
3. Next hop is always set to self.
4. If the best route has a next hop of that specific EBGP peer it is not advertised back (split horizon).

Memorize BGP route selection process

Hope this helps memorize the BGP route selection process.

Most significant to least significant

Weight  (local to router) Local-Pref (local to AS) AS path (between ASes)
Origin (route specific) and finally Metric (between EBGP peers)

Understanding BGP table

BGP Attributes comparaison

BGP attributes comparaison table

Characteristic	Attribute	Shared between	Value	BGP prefers	Significance	Config
well-known, mandatory	Next hop		by default not changed by IBGB
well-known, mandatory	Origin		i=IGP, INCOMPLETE=redistribution	IGP then EGP then INCOMPLETE	Route selection. lowest wins for IGP < EGP < INCOMPLETE
well-known, mandatory Discourages remote traffic from using a specific AS entry point	AS_PATH		sequence of AS	shorter	Detect routing loops Used by filter-list to stop propagation of routing updates from a specific AS, Affects route selection for external AS (to internal destination), disadvantage a local network route through one IBGP to get more traffic from external AS through another IBGP	neighbor x.x.x.x route-map yy out route-map : set as-path prepend xx route-map: match as-path xx
Encourages local traffic to use a specific AS exit point to reach a remote subnet	weight	local to router	0=learned routes 32768=self-originated	Largest	Local router significance. Change route selection in one IBGP router to define which path to reach external routes. Highest value chosen	neighbor x.x.x.x route-map yy in           route-map : set weight
well-known,discretionary Encourages local traffic to use a specific AS exit point to reach a remote AS	local preference	IBGP peers	default 100	Largest	Passed among IBGP routers, Changes route (to external destination) selection among IBGP routers. Highest value chosen	bgp default local-preference xx neighbor x.x.x.x route-map yy in route-map : set local-preference
Optional, non-transitive Discourages remote traffic from using a specific AS entry point to reach a local subnet	MED	EBGP peers set on router but sent to his EBGP peer	default 0	Smallest	Arrives in an AS and stay there, by default MED from different AS are not comparable. Exchanged between EBGP peers.	route-map : set metric
Optional,  transitive Mark traffic with a community so that neighbor can perform a specific action on it	Community				To mark specific traffic with a community (similar to tag) that then the remote router use route-map to apply specific action to this traffic.
well-known,discretionary	atomic_aggregate				set to indicate aggreagation happened
Optional,  transitive	aggregator		the router who aggregated the routes
	AS_Set				summarization of the AS_Path from all the routes that has been aggregated.

BGP route selection criteria

1. Prefer the path with the highest WEIGHT. 2. Prefer the path with the highest LOCAL_PREF. 3. Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP. 4. Prefer the path with the shortest AS_PATH. 5. Prefer the path with the lowest origin type. 6. Prefer the path with the lowest multi-exit discriminator (MED). 7. Prefer eBGP over iBGP paths. 8. Prefer the path with the lowest IGP metric to the BGP next hop. 9. Determine if multiple paths require installation in the routing table for BGP Multipath. 10. When both paths are external, prefer the path that was received first (the oldest one). 11. Prefer the route that comes from the BGP router with the lowest router ID. 12. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length. 13. Prefer the path that comes from the lowest neighbor address.