| 9.6 | Practical BGP Design Example | ||
| 9.6.3 | Problem 2 |
|
Note: Click on topology to view command outputs. We still do not see the BGP entries; the only difference is that 128.213.63.0 is now reachable via OSPF. This is a synchronization issue; BGP is not putting these entries in the routing table and will not send them in BGP updates because it is not synchronized with the IGP. Note that RTF has no notion of networks 192.208.10.0 or 195.211.10.0 because we have not redistributed BGP into OSPF yet. In this scenario, if we turn synchronization off, we will have the entries in the routing table, but connectivity would still be broken. If we turn off synchronization on RTB, the routing table looks fine, but there is no way we can reach those networks because RTF in the middle does not know how to reach them. So, turning off synchronization in this situation did not help this issue, but we will need it for other issues later on. Let's redistribute OSPF into BGP on RTA, with a metric of 2000. The BGP entries have disappeared because OSPF has a better distance (110) than internal BGP (200). We will also turn sync off on RTA in order for it to advertise 203.250.15.0, because it will not sync up with OSPF because of the difference in masks. We will also keep sync off on RTB in order for it to advertise 203.250.13.0 for the same reason. Let us bring the RTB s1 up and see what all the routes will look like. We also enable OSPF on serial 1 of RTB and make it passive in order for RTA to know about the next-hop 192.208.10.5 via IGP. Otherwise some looping will occur because in order to get to next-hop 192.208.10.5 we would have to go the other way via EBGP. There are multiple ways to design our network to talk to the two different ISPs, AS200 and AS300. One way is to have a primary ISP and a backup ISP. We could learn partial routes from one of the ISPs and default routes to both ISPs. In this example, we have chosen to receive partial routes from AS200 and only local routes from AS300. Both RTA and RTB are generating default routes into OSPF, with RTB being more preferred (lower metric). This way we can balance outgoing traffic between the two ISPs. Potential asymmetry might occur if traffic going out from RTA comes back via RTB. This might occur if you are using the same pool of IP addresses (same major net) when talking to the two ISPs. Because of aggregation, your whole AS might look as one whole entity to the outside world and entry points to your network could occur via RTA or RTB. You might find out that all incoming traffic to your AS is coming via one single point, even though you have multiple points to the Internet. In our example, we have chosen two different major nets when talking to the two ISPs. One other potential reason for asymmetry is the different advertised path length to reach your AS. One service provider might be closer to a certain destination than another. In our example, traffic from AS400 destined to your network will always come in via RTA because of the shorter path. You might try to affect that decision by prepending path numbers to your updates to make the path length look longer (set as-path prepend). But, if AS400 has somehow set its exit point to be via AS200 based on attributes such as local preference, metric, or weight, then there is nothing you can do. On RTA, the local preference for routes coming from AS200 is set to 200. We have also picked network 200.200.0.0 to be the candidate default, using the ip default-network command. The default-information originate command is used with OSPF to inject the default route inside the OSPF domain. This command is also used with IS-IS and BGP. For RIP, 0.0.0.0 is automatically redistributed into RIP without additional configuration. For IGRP and EIGRP, the default information is injected into the IGP domain after redistributing BGP into IGRP/EIGRP. Also with IGRP/EIGRP we can redistribute a static route to 0.0.0.0 into the IGP domain. For RTB, the local preference for updates coming in from AS300 is set to 300, which is higher than the IBGP updates coming in from RTA. This way AS100 will pick RTB for AS300 local routes. Any other routes on RTB (if they exist) will be sent internally with a local preference of 100, which is lower than 200 coming in from RTA, and this way RTA will be preferred. Note that we have advertised only AS300 local routes. Any path information that does not match ^300$ will be dropped. If you want to advertise the local routes and the neighbor routes (customers of the ISP), use the following: ^300_[0-9]*. Note: the RTF routing table, which indicates that networks local to AS300, such as 192.208.10.0, are to be reached via RTB. Other known networks, such as 200.200.0.0, are to be reached via RTA. The gateway of last resort is set to RTB. If something happens to the connection between RTB and RTD, then the default advertised by RTA will kick in with a metric of 2000.
|