Thursday, December 23, 2010
Adtran MX2820 DS3 Status
Cisco BGP Communities
This is a repost from http://puck.nether.net/bgp/cisco-config.html, I simply am saving a copy for my reference. I DEFINITELY recommend reading the source in case anything updates.
Cisco BGP Config Example for Customers, Transit and Peers
Due to the ease of configuring bgp, it is easy to leave out critical steps that will result in some unintended consequences. There are a number of cases that exist persistently in the routing tables where some small network is actually connecting two "larger" networks together for some routes/prefixes for various reasons.
NOTE: Your ISP may have referred you here if you were detected to be involved in a routing leak.
As a result of this, and the ease of these errors/mistakes, we wanted to provide a few simple examples that would ease most networks configuration needs and provide a common reference.
These examples cover a few basic bgp related topics, including:
Some requirements for these examples, make sure the following are configured on your router(s):
Router(config)#ip bgp-community new-format
Router(config)#router bgp xxx
Router(config-router)#bgp always-compare-med
Router(config-router)#bgp bestpath med confed
Router(config-router)#bgp log-neighbor-changes
Router(config-router)#no auto-summary
Router(config-router)#no synchronization
This enables the usage of bgp communities in your configuration files in the asn:xxx format which ease their readability as compared to a "really big" number. The BGP specific config(s) will help in debugging, as well as provide for a more normalized and deterministic bgp decision process. It should be noted that these changes should perhaps not be made during any mission-critical time of day unless you are prepared to find the console quickly ;).
These examples also assume a simple model, that i've placed in the following table. The basic premise is that you want to send traffic to your customers before you send it to peers before you send it to your transit(s). This means send it to those that pay you to the increasing cost of those places that bill you. While you may think that bgp will automatically do this for you, it may not do it exactly as you expect. It's generally much better to configure this explicitly.
| Type | Local Pref | Community |
| Transit | 80 | xxx:180 |
| Peer | 100 | xxx:200 |
| Customer | 120 | xxx:220 |
Now for the more specific BGP configs, you will want to start with your customer links and move towards your peers and transit links. This will keep their local-prefernece higher than the default (100) and start to tag their routes with the community that says you want to send it to your upstreams/peers.
router bgp xxx
neighbor 1.2.3.4 remote-as 267
neighbor 1.2.3.4 prefix-list AS267-in in
neighbor 1.2.3.4 route-map customer-in in
neighbor 1.2.3.4 route-map customer-out out
!
route-map customer-in
set community xxx:220
set local-preference 120
!
route-map customer-out
match community cust-out
!
ip community-list expanded cust-out permit xxx:220
ip community-list expanded cust-out permit xxx:200
ip community-list expanded cust-out permit xxx:180
!
ip prefix-list AS267-in seq 5 permit 204.42.0.0/16
ip prefix-list AS267-in seq 10 deny 0.0.0.0/0
!So, this does a few things for you. First, it only sends them prefixes that match your transit, peer and customer routes that have been tagged with these communities. It also sets their routes with the customer (xxx:220) community, and sets the prefernece internally to 120. This will also go to your other internal bgp peers (if any) within your ibgp mesh. You want to populate the AS267-in prefix-list with those routes that you want to accept from your customers. You don't want to accept all routes, as they may have misconfigured their router to send you some of their peer or transit routes that they are not expecting to go via this link. I listed an example prefix above, with an explicit deny at the end.
Now that you've tagged your customer routes, you may want or need to tag your itnernal routes as well with the appropriate community. The best way to do this is to have a route-map that matches against a prefix-list that contains your aggregate routes. This is currently left as an excersise for the reader to implement, as there are numerous ways to announce, including connected (Null0) routes, aggregate and other ways to originate the routes.
transit/peer configs
Tagging your transit and peer routes is perhaps the most important thing to do. You don't want to leak one transit/peer to another (unless you have some very specific needs).
Following the above configuration example for a customer routes, the natural evolution is the following configuration example:
router bgp xxx
neighbor 1.2.3.4 remote-as 267
neighbor 1.2.3.4 route-map peer-in in
neighbor 1.2.3.4 route-map peer-out out
!
route-map peer-in
set community xxx:200
set local-preference 100
!
route-map peer-out
match community peer-out
!
ip community-list expanded peer-out permit xxx:220
!This matches just routes that were tagged with the "220" community, which would be your internal+customer routes. You could tag your internal routes with some additional new community you create to make them show up differently from your "customer" prefixes. If so, add those to your peer-out community-list.
Transit routes generally are identical to peer routes, but you may want to do soemthing different with them in the future so it's ideal to have a different route-map and community-list for manipulating those announcements. If you're trying to go easy on this all, here is the cut+paste that may help you out:
router bgp xxx
neighbor 1.2.3.4 remote-as 267
neighbor 1.2.3.4 route-map transit-in in
neighbor 1.2.3.4 route-map transit-out out
!
route-map transit-in
set community xxx:180
set local-preference 80
!
route-map transit-out
match community transit-out
!
ip community-list expanded transit-out permit xxx:220
!
Wednesday, February 24, 2010
Basic Ethernet Router with NAT and Destination NAT
/ip pool add name=dhcp-pool-1 ranges=192.168.1.100-192.168.1.200/ip dhcp-server add address-pool=dhcp-pool-1 authoritative=after-2sec-delay bootp-support=\static disabled=no interface=ether5 lease-time=3d name=dhcp1/ip dhcp-server network add address=192.168.1.0/24 comment="private dhcp" dns-server=209.173.36.11 \gateway=192.168.1.254
/ip address add address=xx.xx.xx.22/29 broadcast=xx.xx.xx.23 comment="public main ip" \disabled=no interface=ether2 network=xx.xx.xx.16 add address=192.168.1.254/24 broadcast=192.168.1.255 comment="private main ip" \disabled=no interface=ether5 network=192.168.1.0 add address=xx.xx.xx.18/32 broadcast=xx.xx.xx.18 comment="" disabled=no \interface=ether2 network=xx.xx.xx.18 add address=xx.xx.xx.19/32 broadcast=xx.xx.xx.19 comment="" disabled=no \interface=ether2 network=xx.xx.xx.19 add address=xx.xx.xx.20/32 broadcast=xx.xx.xx.20 comment="" disabled=no \interface=ether2 network=xx.xx.xx.20/ip route add comment="default route" disabled=no distance=1 dst-address=0.0.0.0/0 \gateway=xx.xx.xx.17 scope=30 target-scope=10
/ip firewall nat add action=src-nat chain=srcnat comment="" disabled=no src-address=\192.168.1.0/24 to-addresses=xx.xx.xx.22 add action=dst-nat chain=dstnat comment="" disabled=no dst-address=\xx.xx.xx.18 to-addresses=192.168.1.87 add action=dst-nat chain=dstnat comment="" disabled=no dst-address=\xx.xx.xx.19 to-addresses=192.168.1.238 add action=dst-nat chain=dstnat comment="" disabled=no dst-address=\xx.xx.xx.20 to-addresses=192.168.1.45
/system clock set time-zone-name=America/Chicago/system clock manual set dst-delta=+00:00 dst-end="jan/01/1970 00:00:00" dst-start=\"jan/01/1970 00:00:00" time-zone=+00:00/system identity set name=Customer1/system ntp client set enabled=yes mode=unicast primary-ntp=192.43.244.18 secondary-ntp=\66.187.224.4
Tuesday, February 23, 2010
Mikrotik EoIP
There are several versions of this article out there describing how to use MikroTik's EoIP (Ethernet over IP) feature with using a PPtP encryption. I needed a simpler version of just creating the EoIP tunnel without needing to create a secure tunnel due to the network it is traversing is all privately owned but with multiple layer 3 hops of varying name brands. The easiest way to do this was by letting the endpoints create the virtual layer 2 network.
What we will attempt to do is create a transparent network link from Building A to Building B. Remember, this is not encrypted so please keep this in consideration of crossing networks you do not own. This setup will allow all layer 2 traffic cross from both buildings. and the PCs to act like they are right next to each other without any special setups outside of the endpoints.
First you would need to add your external interface. The information here can be changed to whatever your situation requires. The main thing is to insure that Building A and Building B has a default gateway that allows communication between each other.
Building A Router:
/ip address
add address=172.16.3.7/24 broadcast=172.16.3.255 comment="external" \
disabled=no interface=ether1 network=172.16.3.0
/ip route
add comment="default gateway between buildings" disabled=no \
distance=1 dst-address=0.0.0.0/0 gateway=172.16.3.1 scope=30 \
target-scope=10
Building B Router:
/ip address
add address=172.16.23.32/24 broadcast=172.16.23.255 comment="external" \
disabled=no interface=ether1 network=172.16.23.0
/ip route
add comment="default gateway between buildings" disabled=no \
distance=1 dst-address=0.0.0.0/0 gateway=172.16.23.1 scope=30 \
target-scope=10
At this point, with cables leading to the external networks plugged into eth1, the two routers should be able to see each other. Next you add the EoIP tunnel.
Building A Router:
/interface eoip
add name=eoiptunnel remote-address=172.16.23.32 \
tunnel-id=101 disabled=no
Building B Router:
/interface eoip
add name=eoiptunnel remote-address=172.16.3.7 \
tunnel-id=101 disabled=no
The tunnel-id must match; this is a part of the association of the tunnel. After this we then add the interfaces to permit the traffic to be bridged over this tunnel.
Building A Router:
/interface bridge
add name="eoipbridge"
/interface bridge port add bridge=eoipbridge interface=ether5
/interface bridge port add bridge=eoipbridge interface=eoiptunnel
Building B Router:
/interface bridge
add name="eoipbridge"
/interface bridge port add bridge=eoipbridge interface=ether5
/interface bridge port add bridge=eoipbridge interface=eoiptunnel
At this point the two buildings should be bridged on the same layer 2 network and be able to act accordingly.
Mikrotik System Reset
Zhone Malc 723 and ADSL Interfaces
Below is SNMP OIDs for Zhone MALC 723
OBJECT NAME OID
ifAdminStatus 1.3.6.1.2.1.2.2.1.7
zhoneDslLineStatusChangeTrapEnable 1.3.6.1.4.1.5504.5.4.1.1.15
zhoneAdslTransmissionMode 1.3.6.1.4.1.5504.5.4.11.1.3
zhoneAdslChannelMode 1.3.6.1.4.1.5504.5.4.11.1.4
adslTrellisModeEnabled 1.3.6.1.4.1.5504.5.4.11.1.1
adslNTRModeEnabled 1.3.6.1.4.1.5504.5.4.11.1.2
adslPotsBypassRelayMaxDuration 1.3.6.1.4.1.5504.5.4.11.1.9
adslLineDMTConfMode 1.3.6.1.4.1.5504.5.4.11.1.11
adslMaxDownstreamToneIndex 1.3.6.1.4.1.5504.5.4.11.1.5
adslMinDownstreamToneIndex 1.3.6.1.4.1.5504.5.4.11.1.6
adslAtucConfRateMode 1.3.6.1.2.1.10.94.1.1.14.1.2
adslAtucConfRateChanRatio 1.3.6.1.2.1.10.94.1.1.14.1.3
adslAtucConfTargetSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.4
adslAtucConfMaxSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.5
adslAtucConfMinSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.6
adslAtucConfDownshiftSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.7
adslAtucConfMinDownshiftTime 1.3.6.1.2.1.10.94.1.1.14.1.10
adslAtucConfUpshiftSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.8
adslAtucConfMinUpshiftTime 1.3.6.1.2.1.10.94.1.1.14.1.9
adslAtucChanConfFastMaxTxRate 1.3.6.1.2.1.10.94.1.1.14.1.13
adslAtucChanConfFastMinTxRate 1.3.6.1.2.1.10.94.1.1.14.1.11
adslAtucChanConfInterleaveMaxTxRate 1.3.6.1.2.1.10.94.1.1.14.1.14
adslAtucChanConfInterleaveMinTxRate 1.3.6.1.2.1.10.94.1.1.14.1.12
adslAtucChanConfMaxInterleaveDelay 1.3.6.1.2.1.10.94.1.1.14.1.15
zhoneAdslAtucConfREADSL2 1.3.6.1.4.1.5504.5.4.19.1.1
adslMaxUpstreamToneIndex 1.3.6.1.4.1.5504.5.4.11.1.7
zhoneAdslMinUpstreamToneIndex 1.3.6.1.4.1.5504.5.4.11.1.8
adslAturConfRateMode 1.3.6.1.2.1.10.94.1.1.14.1.16
adslAturConfRateChanRatio 1.3.6.1.2.1.10.94.1.1.14.1.17
adslAturConfTargetSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.18
adslAturConfMinSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.19
adslAturConfMinSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.20
adslAturConfDownshiftSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.21
adslAturConfUpshiftSnrMgn 1.3.6.1.2.1.10.94.1.1.14.1.22
adslAturConfMinUpshiftTime 1.3.6.1.2.1.10.94.1.1.14.1.23
adslAturConfMinDownshiftTime 1.3.6.1.2.1.10.94.1.1.14.1.24
adslAturChanConfFastMaxTxRate 1.3.6.1.2.1.10.94.1.1.14.1.27
adslAturChanConfFastMinTxRate 1.3.6.1.2.1.10.94.1.1.14.1.25
adslAturChanConfInterleaveMaxTxRate 1.3.6.1.2.1.10.94.1.1.14.1.28
adslAturChanConfInterleaveMinTxRate 1.3.6.1.2.1.10.94.1.1.14.1.26
adslAturChanConfMaxInterleaveDelay 1.3.6.1.2.1.10.94.1.1.14.1.29