Archive for the ‘notes’ tag
Redistribution Notes – AD Manipulation
- Manipulating administrative distance (AD) is another way to help with a mutual redistribution scenario.
- EIGRPs has different ADs for internal and external (redistributed) routes
- OSPF and RIP have the same AD no matter where the route orginated.
- This means that routes redistributed into OSPF may be used instead of a local RIP route.
- AD 110 (OSPF) beats 120 (RIP) every time.
- The distance subcommand allows you to change the AD on specific routes from specific neighbors.
- This example changes the AD of the route to 10.0.0.0/16 advertised from 1.1.1.1 to 121.
- This will make this router prefer a RIP route to the same destination.
ip access-list standard RIP-ROUTES permit 10.0.0.0 0.255.255.0 ! router ospf 1 distance 121 1.1.1.1 0.0.0.0 RIP-ROUTES
–
Corrections are encouraged.
Redistribution Notes – Tagging
- Tagging provides a way to mark common or similar routes to manipulate later.
- In redistribution scenarios with mutual redistribution on two different routers, any routes that gets redistributed from one route process to another are tagged.
- When the other router sees those tags on the route, that route to keep from adding non-optimal routes to its routing table.
- Tags can also be used to do other manipulation such as setting higher metrics or changing ADs.
OSPF
R102#show run ... router ospf 1 log-adjacency-changes redistribute connected subnets route-map SETTAG network 192.0.2.0 0.0.0.255 area 0 ! route-map SETTAG permit 100 set tag 55555 ... R101#sh ip route 10.0.0.2 Routing entry for 10.0.0.0/24 Known via "ospf 1", distance 110, metric 20 Tag 55555, type extern 2, forward metric 10 Last update from 192.0.2.102 on Ethernet0/0, 00:00:13 ago Routing Descriptor Blocks: * 192.0.2.102, from 192.0.2.102, 00:00:13 ago, via Ethernet0/0 Route metric is 20, traffic share count is 1 Route tag 55555
EIGRP
R102#sh run
...
router eigrp 1
network 192.0.2.0
redistribute connected route-map SETTAG
no auto-summary
!
route-map SETTAG permit 100
set tag 55555
...
R101#sh ip route 10.0.0.2
Routing entry for 10.0.0.0/24
Known via "eigrp 1", distance 170, metric 409600
Tag 55555, type external
Redistributing via eigrp 1
Last update from 192.0.2.102 on Ethernet0/0, 00:00:14 ago
Routing Descriptor Blocks:
* 192.0.2.102, from 192.0.2.102, 00:00:14 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Route tag 55555
–
Corrections are encouraged.
BGP Notes – Synchronization
- With synchronization on, route must be synchronized to an IGP in order for that routes to be able to be voted ‘best” by BGP.
- That means the exact route must already be in the routing table via an IGP.
- Static routes don’t count.
- This is traditionally accomplished by redistributing BGP routes into an IGP.
- With today’s Internet prefix count over 350k, this may not be such a good idea in some situations.
- Synchronization is off by default.
- Synchronization prevents black hole routes from being advertised via iBGP.
- Unless every router is participating in iBGP, there’s no guarantee that any one router will have a route to NEXT_HOP.
- Synchronization also prevents a router from advertising the black hole to an eBGP neighbor.
- You don’t want to tell the world you have a path to a prefix when you really have a !N.
- Synchronization can be safely disabled with the use of route reflectors or confederations.
—–
These are just some notes I’ve been taking. Comment with corrections, please.
BGP Notes – Backdoor Routes
- The fact that eBGP has an AD of 20 can be a problem.
- You may have a very short path via EIGRP (or OSPF or RIP or whatever other IGP), but the longer eBGP path will be preferred.
- For God’s sake, do not lower the AD of EIGRP! Havoc will ensue.
- Using backdoor routes causes eBGP routes to have an AD of 200.
- Allows the shorter-path IGP routes to be added to the routing table.
router bgp 123 network 1.1.1.0 backdoor
—–
Comment with corrections, please
BGP Notes – Authentication
Corrections welcome.
It’s simple as pie to enable MD5 auth to a BGP peer.
R102(config-router)#neigh 192.0.2.101 pass MYKEY
BGP Notes – Path Decision
This is required blogging…and reading for that matter. A good chunk of this is taken from my CCNP posts from last year. Corrections, please.
—–
How does a BGP router decide which BGP route is the best?
Next-hop : Does the router have a route to the next-hop?
Weight : This is a numeric value where bigger is better. Weight is not passed onto other peers and is a Cisco proprietary feature.
LOCAL_PREF : This is a numeric value where bigger is better. All iBGP peers pass this value around amongst themselves.
Local : Is the next hop me (0.0.0.0)?
AS_PATH length : This is the number of AS hops to the destination. If you don’t know this one by now, then you missed something big.
ORIGIN : Did this route come from a netowork statement in an IGP (I), from EGP (E, which shouldn’t exist any more), or somewhere else (?) like a redistributed route? I is better than E is better than ?.
MED : The Multi Exit Discriminator can be used by one AS to influence routes to that AS. The smaller the better.
Neighbor type : eBGP are better than iBGP routes.
IGP metric : Prefer the next-hop address that’s closest via an IGP like OSPF or EIGRP (or RIP, Ivan).
Route age : Prefer the oldest (and, thusly, the most stable) route.
Lowest BGP neighbor router ID : Do I have to explain that one?
Lowest BGP neighbor IP : You know what this is, right?
BGP Notes – Path Attribute Categories
Make my corrections! Please!
Well-known mandatory : These PAs must be recognized by all BGP routers and passed along to other peers.
Well-known discretionary : These PAs do not need to be in every update, but they must be recognized by all BGP routers.
Optional transitive : These PAs don’t have to be recognized but they must be passed along to other BGP peers if they are present in an update.
Optional notransitive : These PAs neither have to be recognized nor passed along.
BGP Notes – Neighbor States
Corrections appreciated.
Idle : There is no relationship, but the router sends out a TCP SYN to the neighbor to get the ball rolling.
Idle (admin) : The neighbor is admined down.
Connect : The router is waiting for the TCP connection to finish. If the TCP connection finishes, the router sends an open and transitions to OpenSent. If it times out, it transitions to Active.
Active : The router tries to initiate a TCP connection. If the TCP connection finishes, the router sends an open and transitions to OpenSent.
OpenSent : The router is waiting for an open to be returned. If one is received, the router transitions to OpenConfirm.
OpenConfirm : The router is waiting for a keepalive. If one arrives, the router transitions to Established.
Established : The neighbor relationship is complete and updates are exchanged.
BGP Notes – Message Types
Corrigeme, por favor.
Open : When a neighbor is configured, the router sends an open to that neighbor to get the ball rolling.
Destination: The neighbor's configured IP Important fields: My AS
Update : The routing information
Destination: The neighbor's configured IP Important fields: Advertised network Path attributes
Keepalive : Sent every 60 seconds by default
Destination: The neighbor's configured IP Important fields: Nothing, really
Notification : When something is amiss, the router sends a notification message. The receiver then closes the connection.
Destination: The neighbor's configured IP Important fields: Error code
EIGRP Notes – Route Filtering
As always, correction are encouraged.
You can configure an EIGRP router to filter routes from being advertised or from being accepted.
Objective: Filter out the route to 10.0.254.1/32 from being advertised to the rest of the network via EIGRP.
ip prefix-list PRE1 deny 10.0.254.1/32 ip prefix-list PRE1 permit 0.0.0.0/0 le 32 ! router eigrp 1 distribute-list prefix PRE1 out -- OR -- ip access-list standard ACL1 deny 10.0.254.1 0.0.0.255 permit any ! router eigrp 1 distribute-list ACL1 out